Why coding agents get worse as the codebase gets bigger

Every coding agent demos well on an empty repository. Give it a mature codebase, four hundred files, two competing conventions and a database schema built over six years, and the same agent starts inventing helpers that already exist under another name.

The gap comes from what the model was shown before it began writing, more than from model quality.

Selection matters more than window size

Long context windows made an easy answer available: send more. Send the whole directory, then the whole repository. The problem is that relevance does not scale with volume. A model given four hundred files spends its attention deciding what matters, and it decides worse than a well-built index would.

Worse, sending everything is expensive and slow, and the cost falls on the projects that are already large. The teams who most need help get the worst service.

What a useful context contains

For a task that touches one feature, the useful set is small and specific:

• The files the change will modify, in full.
• The shape of what they call: signatures, types and table columns, without the bodies.
• The conventions this repository follows in practice, which often differ from what its documentation claims.
• The tests that currently cover this area, because they define the behaviour that must survive.

That is usually a dozen files out of four hundred. Assembling it takes a map of the project, built once and kept current, rather than a search performed from scratch on every prompt.

The duplicate function problem

The most common failure of an under-informed agent is a second implementation of something that already exists, under a different name, with slightly different behaviour on an edge case.

Nothing breaks that day. It breaks eighteen months later, when someone fixes a bug in one of the two copies. This is the cost that never shows up in a benchmark, and it is the reason “search before you write” is a rule rather than a suggestion in any codebase meant to last.

What follows from this

An agent should read the repository before it writes, and should send the model only what the task involves. That is how StrucTime Code is built: a map of the architecture, the dependencies, the routes and the tables, and a selection made from it.

It also explains a habit that looks like politeness and comes from engineering. When the requirement is ambiguous, asking beats guessing. A guess produces code that compiles and does the wrong thing, and the wrong thing is much more expensive to find than a question is to answer.