The argument about AI coding agents is usually framed as a capability question. Can a model build a whole product? At this point, mostly yes. Point one at an empty repo and you get something running.

I think capability is the wrong thing to argue about. The interesting question is what happens on day 400, when the product is real, has users, and someone has to change one thing without breaking three others.

That is where I'd expect the current model of "let the agent build it" to stop scaling. Not because the agent gets worse, but because of what it quietly took from the team on the way there.

The part nobody plans for

Greenfield is the easy half. There is no history, no half-migrated schema, no decision made in a hurry eighteen months ago that everything now leans on. The constraints are thin, so an agent can move fast and be genuinely useful.

Mature products are the opposite. Most of the work is small, surgical, and risk-managed. Change this rule, keep that invariant, don't touch the thing three services depend on. The value is not in producing code. It's in knowing which ten lines to touch and what they will affect.

Almost nobody plans the transition between these two states. Teams plan the build. They don't plan the handoff.

Context debt

Technical debt is when the code is worse than it should be. This is different. The code can be perfectly clean and still leave you stuck, because the understanding of why it is shaped that way never existed in a human head.

Call it context debt. It accumulates quietly. Every prompt that produces working code you didn't reason through is a small withdrawal against your future ability to change that code confidently.

For a while this is invisible. The tests pass, the product ships, everyone feels fast. Then something breaks in production at an awkward hour, or a customer asks for a change that cuts across four modules, and you discover that no one on the team can say with confidence what will happen if you touch it. You can re-derive the answer by reading the code, but re-derivation is slow and it is exactly what you thought you were buying your way out of.

The part I care about most is ownership. Someone has to be accountable for the system. You can pretend for a while, but accountability without understanding is not real, and everybody in the room knows it.

The ten-minute change

Here is the case that convinces me.

A request comes in to change a piece of business logic in an area you know well. You wrote it or you've worked in it for months. There are tests around it. You know the layers it touches and the two edge cases that matter.

You make that change in ten minutes. No spelunking, no reading a hundred files just in case, no second-guessing whether some distant thing depends on the behaviour you just altered. The risk is low because the context is already in your head.

Now give the same task to an agent with no persistent context. It reads a large slice of the codebase to reconstruct what you already knew, produces a reasonable patch, and hands you something you now have to review carefully because you don't have the context either. It might be correct. Verifying that it is correct is the expensive part, and it lands on a human anyway.

On a mature system with a team that actually knows it, I'd expect the human to win that comparison more often than the current discourse suggests. Not always. Often enough that "AI does the maintenance" is the wrong default.

That level of context is only available to people who work in the system regularly and write code in it, rather than describing what they want in vague instructions and reviewing the result.

Where AI compounds instead

None of this makes AI less useful. It moves where the value is.

The strongest applications I see are around the code rather than inside it:

  • Documentation that stays current. The task everyone agrees matters and nobody does. Well suited to an agent, and it directly attacks context debt instead of adding to it.
  • Tests. Especially covering the paths a team wouldn't get around to. Tests are also how you make future changes safe, whoever makes them.
  • Triage. Error reports, issue grooming, first-pass diagnosis, linking a stack trace to the likely area and the last change that touched it. Enormous time sink, high signal, low risk when a human approves the outcome.
  • The boring repetitive code. Migrations, adapters, the fifth CRUD resource that looks like the previous four. Real work, no context lost, because nobody was carrying that in their head anyway.

What these have in common is that a human stays in the loop on anything that changes behaviour, and the output tends to increase the team's understanding of the system rather than route around it.

The bridge worth building

If AI is going to keep dominating greenfield, and I think it will, then the interesting engineering problem is the transition. How does an AI-built product become a human-owned system?

Ways I'd approach it:

Treat context as a deliverable, not a byproduct. If an agent builds a module, the module isn't done until there's a written account of what it does, why it's shaped that way, and what it depends on, in a form a new engineer can absorb.

Decide early which parts of the system humans own outright. The domain core, the data model, the money paths. Let AI move fast on the perimeter.

Make someone read the code. Not review a diff at speed, actually read it, in the areas that will matter later. This feels like a waste of time right up until the moment it isn't.

Watch for the signal that you've drifted: when nobody can answer a question about behaviour without opening the codebase.

Speed is easy to measure and context is easy to ignore, which is exactly why teams trade one for the other without noticing. The teams that stay fast in year two will be the ones that let AI build the parts they were never going to hold in their heads, and kept the parts they need to own.

This is an opinion piece, not a claim about benchmarks or measured outcomes. The argument is about ownership and context, and it should be read that way.