Last month an agent I was working with wrote a completely new paging mechanism.
The problem was that the system already had a built-in way of doing this. The agent didn’t use it.
This was not the first time I noticed it. Over the last few months I have seen it as a pattern.
Coding agents prefer creating a new mechanism over reusing an existing one.
And over time this increases development cost, as the system gets more complex and harder to understand.

WHY IT HAPPENS

An agent starts each session with a clean slate. Whatever it knows about the codebase is derived from the given context, the request, and the learning it does during the session, and all of it is lost when the session ends.

In order to make a reuse decision, it first needs to find that a relevant mechanism exists, then learn how to use it and, if needed, change it to support the new use case.

Which means that without prior knowledge (context), the agent needs to scan the entire system, examining each part to see if it is related to the job at hand, and if and how it can be updated to fit the purpose.
Without any guarantee that such a thing exists.
And by default it won’t do it.

This search is proportional to the system size, and it has no built-in finish line:
an agent cannot know it has looked enough without already knowing the system.

Building a new mechanism instead is easier. It is mostly a matter of locating where to put that mechanism, and it is usually proportional to the size of the feature that was asked for.
And unlike the search, it has a clear finish line: once the new mechanism works, the job is done, and that can be checked.

Then there is the bill. Suppose the agent could read and understand the entire system from scratch every session.
This would require a large enough context window (and depending on your system, existing ones may not be enough).
It also means paying for this, in tokens, on every task, and paying again on the next one.

So in essence this tendency to prefer new stuff is actually the right decision, given what the agent knows.

And just to keep things honest, this is standard behavior for human developers as well.

Most developers, when facing areas they lack understanding of, will also prefer writing new features separately, missing existing mechanisms along the way.
The only difference is that people (at least most of them) have a lasting memory, and over time they learn the system’s architecture and the methods used to achieve things.
As they gain experience (it may take a few years in a large enough system), they make better decisions.
An agent has no such built-in memory. Every session starts with zero knowledge of the system.

AND IT GETS WORSE

There is a nasty loop here.
Over time, each parallel mechanism makes the system larger.
A bigger system increases the cost of understanding.
A larger cost of understanding decreases the chances of reuse, and results in more parallel mechanisms.
More mechanisms increase the system’s complexity and size, and the loop goes around again.

It is also hard to see while it is happening.
Separately, each change works.
Its tests pass. Review approves it, because looking at the change alone, nothing inside it is wrong.
This is detectable only when reviewing the system as a whole.
Classically, that is the job of the system architect.
Coding agents focus on writing code. They will not do this for you.

WHAT TO DO ABOUT IT

Start from what the agent is missing, which is an understanding of the system.
Create a knowledge base to capture that understanding.
It serves as the “long-term” memory of the agent, which helps it bridge the years of codebase experience an engineer has.
One way to build it is to think of what a new developer needs to learn, then capture all that information and make it available to the agent.
For each mechanism, capture:
where it lives,
what it does,
when to use it, and when not to,
and how to use it properly.
Make the agent use that knowledge base, so that “do we already have a way to do this” has a cheap answer.
Be aware that this is an ongoing effort: as the system grows, its knowledge base should grow with it.

And the hard part is getting all agents to use a single source, while keeping it current with ongoing work.

Second, put a person at the design decision, before any code is written.
Trying to catch these mistakes at the code review phase is really hard. There the focus shifts more to what was added and how it works (or doesn’t), and less to whether that was the correct solution to begin with.
At design time, use a ladder for every decision, and take the first option that fits:

1.  configure something that exists,
2.  use an existing mechanism as it is,
3.  extend an existing mechanism,
4.  build new, only when nothing else fits.

And ask the agent to capture which one it used, and why the previous options did not fit.

The two feed each other. Every time a person says “we already have that” or “we can use this”, the answer goes into the knowledge base, and the agent does not need to be told again.

Over time, judge how involved the person needs to stay, based on what you observe.
The recorded decisions give the human in the loop enough information to judge whether the agent’s decisions are getting better over time in a given part of the system.
Where the agent is good enough, less human gating is needed.
But keep in mind, I would not expect it to disappear in the near future. This is something that is really hard even for people.
The system keeps changing, and the choice between reusing and building new is a judgement call in both directions.

One thing to be very aware of: forcing reuse can create its own failure.
A mechanism bent to a job it was never built for adds as much complexity as a new one, and it does not even show up as a new file.
The aim is to make knowing what exists about as cheap as building new, and then let the decision be made on its merits.

WHERE TO START

Start by judging where you are.

If you are using agents to design and implement code, look in two places.
Take last month’s agent-written changes, check how many of them created new mechanisms for existing capabilities, and see where they cluster.
Then ask your developers how many times they had to tell the agent to use a specific mechanism, different from the one it suggested or found.
Together these show the parts of the system your agents know least about.

Once you have that, start working on the knowledge base.

Start by asking what the agent would have needed to know to choose differently, and where that knowledge sits today:
in a document,
in the code,
or in one person’s head.

Then gather that knowledge and start making it available to all your agents.

Remember: What your agents do not know about your system, they will build again.

* * *

Written by Lior Friedman.
Lior is a Senior Software Architect and R&D Leader with 25+ years of experience building mission-critical systems and leading large-scale engineering transformations. Today, he focuses on helping R&D organizations adopt AI-enabled engineering practices-turning AI capabilities into practical, repeatable, and scalable workflows across coding, testing, and documentation.

* * *

Practical AI helps organizations move from individual AI experimentation to a shared, scalable way of working. We combine deep software engineering expertise with organizational change to build the standards, workflows, and practices that make AI work across teams — not just for individuals.
Let’s talk about building your AI capability at scale.