Senar: why AI agents don't replace programmers, and how they change the development process

In part two of the SENAR series, the author looks not at model quality but at the development process itself when AI agents are involved. The main idea is simple: an agent can write code faster than a human, but it doesn't behave like an engineer when it hits a gap in its knowledge.

Where the agent goes wrong

The most telling case is an audit of an old Java system with 17 modules and no up-to-date documentation. The agent produced a convincing architecture map: dependencies, interfaces, component descriptions, links between services. Almost everything looked accurate until it reached an old proxy layer left over from a migration to a message queue. In the code, this layer looked like an ordinary HTTP call, and the agent confidently described it as a standard part of the architecture. For people who had worked on the project earlier, though, it was a temporary hack and a trace of an old solution.

This is where the key difference between an agent and a developer shows. A person usually notices a strange construct, flags the risk and goes to ask the team or the code's author about the history of the decision. An agent more often fills in the missing explanation itself: it formulates a plausible reason, invents a purpose, and doesn't separate a fact from the repository from its own reconstruction. The neater such a result looks, the higher the chance of missing the error in review and taking a hypothesis for architectural truth.

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

Five key takeaways

From this case the author draws five recurring patterns that, in his experience, appear on almost any project with AI coding agents. They concern not only code quality but also how the agent perceives the task, the context and the consequences of its decisions. Taken together, they explain why the same tool can sharply speed up development on simple tasks and just as quickly create hidden problems on complex ones.

• The agent has no project memory: if the history of decisions isn't passed on explicitly, it doesn't exist for the agent.
• It executes the task literally and doesn't fill in business context the way an experienced developer does.
• 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 picks the locally convenient path.
• It doesn't live with the consequences of its decisions, so responsibility for the release and the data stays with the human.

The practical conclusion from these observations is strict: a task must contain not only a goal and acceptance criteria but also negative scenarios, constraints, prohibitions and architectural boundaries. If you leave gaps, the agent will fill them itself. That is why the quality entry gate in SENAR requires collecting the specification and context first, and only then launching generation. Speed is useful here only when a human has narrowed the room for guesswork in advance.

The price of fast automation

Fast code from an agent creates a different kind of debt: cognitive debt. A module may work, tests pass and the linter stays silent, yet the team doesn't understand why it is built the way it is and which decisions are baked into it. The author gives the example of a cache module of about 500 lines: a couple of weeks later its strategy for evicting stale data had to change, and instead of an hour of work it took half a day to recover logic that no human had explicitly decided on or recorded.

To avoid masking systemic failures with manual fixes, the author suggests tracking MIR: the share of tasks where, after the agent's work, someone had to go into the code by hand. On mature projects, he kept this metric at around 5–15%; at the start of a new one, around 20%. The point isn't a nice report but feedback: if manual fixes repeat, the problem isn't in one file but in the context, the specification, the architectural boundaries or the chosen model.

The engineer's new role

This also changes the human's role on the team. By the author's estimate, up to 60% of time now goes to framing tasks, gathering context and making architectural decisions, about 30% to checking results, and another 10% to configuring tools, metrics and the process itself. Writing code is no longer the center of the work: the engineer looks more and more like someone who sets tolerances, decomposes a complex system and checks whether the agent's tidy output has turned into an expensive mistake.

One conclusion is blunt: anything that isn't written down doesn't exist for the agent. If module boundaries, API conventions, the reasons for past decisions and forbidden dependencies live only in the tech lead's head, the agent will almost certainly violate them, because technically the import may work and tests may pass. That is why documentation in the SENAR model exists not for reporting but as a working interface between the human, the agent and future developers who will have to maintain this code.

What this means

For teams seriously adopting AI agents in development, the main news isn't that agents speed things up. What matters far more is this: without a strict specification, recorded decisions and constant verification, speed quickly turns into cognitive debt, and the engineer goes from code author to editor, architect and quality controller.