Habr AI: How Expensive LLMs Became State Managers and Cut Development Costs

Habr AI has published a breakdown of an AI development architecture in which the expensive LLM no longer writes code itself but directs a cheaper executor. The author claims the redesign eliminated endless error loops, shortened the context and noticeably reduced API spending.

Where the agents broke down

The team started with the popular route: they took Aider and built it into CI/CD so that an agent would automatically update documentation after code changes. For that task the tool worked well and cleared part of the technical debt. But when they tried to give it the full development loop, from backlog and specs to code and tests, the system quickly hit its limits. There were two main problems: weak control over integrations, and unclear handoff of artifacts between steps, where the agent creates something but it is hard to reliably pick it up and plug it into the next stage.

The next attempt was closer to a familiar org chart: one orchestrator sets the task and several coder agents carry it out in parts. On paper the scheme looks logical, but in practice it produced two systemic failures. The first was a gap in responsibility: if one agent leaves part of a function unfinished and the next one already builds its logic on top of it, the error snowballs in a cascade. The second was analysis paralysis. The models read the repository endlessly, re-check files and postpone real changes while the context bloats and the token bill grows.

Why swap the roles

During testing, the team noticed that different models do have a working "character". Gemini 3 Pro behaves like an overconfident developer and can drift away from the original spec. MiniMax M2.5, by contrast, is cautious and reads half the project before taking its first step. Claude Sonnet 4.6 showed the best balance between autonomy and discipline, but using it for every small action proved too expensive for a startup.

That is where the new idea came from: put the strong model not on routine work but on oversight.

"The CEO doesn't make cold calls."

Instead of a setup where the expensive LLM writes the hardest code, the team introduced several strict rules:

• One agent owns one spec from start to finish and fixes its own errors.
• The agent works only with a limited "desk" of 5–8 files, not the whole repository.
• When it closes a file, it saves a short memory of useful findings, so it does not have to drag full source code into the context.
• The smartest model does not code by hand; it acts as a state manager for the cheap worker.

How the manager works

In the new architecture, a cheap and fast LLM acts as the worker: it writes code, calls tools, receives compilation errors and makes routine passes. When the worker hits a problem or uses up its action limit, the expensive model, the state manager, takes over. It does not edit code directly. It reads the accumulated history, discards noise and assembles a compact, useful version of the context for the next step.

The state manager does four things in sequence:

• Briefly records what has actually been done and what works.
• Updates the memory: variables, decisions, library conflicts found and dead ends.
• Checks whether it makes sense to continue, or whether the task has hit the limits of the tools.
• Formulates a clear directive on how the worker should proceed and work around errors.

The most interesting trick is how these instructions are delivered. Besides the memory block, the manager's recommendations are given to the worker as a new user message. As a result, the executor treats the instructions as a priority and argues with them less. In parallel, the system clears its previous conversation of logs and errors so that a new cycle starts with a "clean window".

The scheme carries a risk too: if the manager misreads the logs and writes a false fact into memory, the worker will stubbornly follow the wrong course. But the author writes that in an analytical role the expensive model hallucinates far less often than when generating code directly.

An additional effect is that tests and documentation start appearing with the task by default, and developers shift from manual executors to operators and architects of the process.

What this means

This case shows that gains in AI development come not only from choosing a model but from distributing roles among models correctly. If you use the expensive LLM as a memory dispatcher, a decision controller and an emergency brake for pointless loops, you can raise the stability of the process and cut the cost of rework at the same time. For teams that have already been burned by "autonomous programmers", this is one of the most practical architectural takeaways of recent months.