Senar: why AI agents do not replace programmers and are changing the development process

In the second part of a series on SENAR, the author examines not the quality of models, but the development process itself with AI agents. The main idea is simple: an agent can write code faster than a human, but it doesn't behave like an engineer when it encounters a gap in knowledge.

Where the agent fails

The most telling case is an audit of an old Java system with 17 modules and no current documentation. The agent compiled a convincing architectural map: dependencies, interfaces, component descriptions, and relationships between services. Almost everything looked accurate until it reached an old proxy layer that remained after migrating to a message queue.

In the code, this layer looked like a regular HTTP call, and the agent confidently described it as a standard part of the architecture, though for people who had worked with the project before, it was a temporary workaround and a trace of an old solution. This is where the key difference between an agent and a developer becomes apparent. A person typically notices a strange construct, flags the risk, and goes to clarify the decision history with the team or the code author.

An agent more often reconstructs the missing explanation itself: formulates a logical reason, invents a purpose, and doesn't distinguish between facts from the repository and its own reconstruction. The more polished such a result looks, the higher the chance of missing an error in review and accepting a hypothesis as architectural truth.

"The difference between a programmer and an agent is not speed."

Five key takeaways

From this case, the author derives five recurring patterns that, in his experience, arise on almost any project with AI agents for development. They concern not only code quality but also how the agent perceives tasks, context, and the consequences of its decisions. Together, this explains why the same tool can sharply accelerate development on simple tasks and just as quickly create hidden problems on complex ones.

• The agent has no project memory: if the decision history is not explicitly passed, it doesn't exist for the agent.
• It executes the task literally and doesn't fill in business context the way an experienced developer would.
• One wrong assumption quickly multiplies across a series of similar files and utilities.
• The agent doesn't see the architecture beyond the current prompt and chooses the locally convenient path.
• It doesn't live with the consequences of its decisions, so responsibility for release and data remains with humans.

The practical conclusion from these observations is harsh: the task must contain not only goals and acceptance criteria, but also negative scenarios, constraints, prohibitions, and architectural boundaries. If you leave gaps, the agent will fill them in itself. That's why the quality gate at SENAR requires first gathering specification and context, then launching generation. Speed is useful only when the space for speculation is narrowed in advance by a human.

The cost of rapid automation

Quick code from an agent creates a different type of debt—cognitive. A module can work, tests pass, the linter is silent, but the team doesn't understand why it's structured the way it is and what decisions are baked into it. The author gives an example of a cache module of about 500 lines: after a couple of weeks, it needed a change in the strategy for purging stale data, and instead of an hour for rework, half a day was spent restoring logic that no one had explicitly accepted or recorded.

To avoid masking system failures with manual fixes, the author proposes calculating MIR—the share of tasks where manual code edits were needed after the agent's work. On mature projects, this metric held around 5–15%, at the start of a new one—around 20%. The point isn't a pretty report, but feedback: if manual fixes repeat, the problem isn't in one file but in context, specification, architectural boundaries, or the chosen model.

The engineer's new role

This changes the role of humans in the team. According to the author, up to 60% of time now goes to task specification, context gathering, and architectural decisions, about 30% to checking results, and another 10% to tuning tools, metrics, and the process itself. Writing code itself stops being the center of work: engineers increasingly resemble those who set tolerances, decompose complex systems, and verify that the agent's polished output hasn't turned into an expensive mistake.

A separate conclusion sounds harsh: everything not written down doesn't exist for the agent. If module boundaries, API conventions, reasons for past decisions, and forbidden dependencies live only in a tech lead's head, the agent will almost certainly violate them, because technically the import can work and tests can pass. That's why documentation in the SENAR model is needed not for compliance, but as a working interface between humans, agents, and future developers who will have to maintain this code.

What it means

For teams seriously adopting AI agents in development, the big news isn't that they accelerate development. What matters far more is this: without strict specification, decision recording, and constant verification, speed quickly turns into cognitive debt, and the engineer shifts from code author to editor, architect, and quality controller.