TL;DR
- Coding agents are strongest on an empty page. Brownfield is where the tax arrives, because an old system's meaning lives off-disk.
- A software system is a treaty between code, customers, finance, operations and the people who work around its scars. The agent sees the text of the treaty. It may not understand the peace it preserves.
- The break does not show up at merge time. Tests pass, the change is coherent, and the failure arrives in February in the one territory a regulator cared about.
- The fix is a review surface, not a better model: what behavior changed, what was deliberately preserved, and what source of truth proves the non-obvious rule.
Anthropic acknowledged late April what Claude Code users had been complaining about for weeks. The product had been silently degrading. Product-layer changes around reasoning, caching, and prompt behavior had drifted in ways the people running it did not catch in time.
That is the everyday condition of every system old enough to have its meaning live off-disk. Claude Code is young. The system around it is young. But both are now old enough to have a brownfield problem of their own.
If the people building the agent are vulnerable to it, the people pointing the agent at twelve-year-old codebases are not safe.
Greenfield and brownfield
Software people call the empty page greenfield. Nothing is in the ground yet. The model can invent freely because there are no old promises to keep.
Brownfield is the opposite. The system already exists. It earns revenue. Customers depend on it. Operations has worked around its scars. Finance trusts its reports. Someone once made a strange decision for a good reason, and the good reason has long outlived the person who remembers it.
Coding agents are strongest in greenfield work. Brownfield is where the tax arrives.
Monday morning
Somebody on your engineering team is going to test that on Monday morning. They want a win. The agent is fast. The demo will look good. They will point it at the oldest, ugliest system in the tree, because that is where the visible win lives.
Take a load forecasting model. Twenty thousand lines of Python and SQL. Also a notebook of overrides nobody opens, an Excel file emailed in 2019 that some obscure part of the process still references, and one adjustment that exists because a regulator asked for it after a storm.
The code is the visible half. The meaning lives in the rest.
That is what makes brownfield work hard for agents. Not just missing documentation. Missing reality.
A system is a treaty
A software system is a treaty. Between code and customers. Between finance and operations. Between the official process and the way work actually gets done. Between a vendor API that lies twice a year and the person who knows when to ignore it. Between the clean data model in the diagram and the old rows in the database that will never be clean.
The agent sees the text of the treaty. It may not understand the peace it preserves.
So it does what agents are good at. It makes the code cleaner. It normalizes the strange exception. It replaces a brittle path with something that looks more modern. Tests pass. The change is coherent. The merge request reads well.
Then February arrives.
The forecast is wrong in the territory where the regulator cared most. Or the invoice goes out without the manual adjustment Sarah used to catch. Nobody sees the break at merge time, because the break is not in the code. It is in the agreement the code was quietly honoring.
This is the brownfield tax.
The evidence is starting to arrive
The research is starting to catch up with the intuition. Carnegie Mellon researchers found that AI coding tools produced early speed gains that faded as quality problems accumulated. A separate large study of AI-authored commits found measurable quality issues across every assistant studied. The agent did not slow down. Review did.
That is the CTO problem. Not whether agents can change old systems. They can. The problem is whether the organization can still reconstruct why the system behaves the way it does after agents start changing it.
Three kinds of knowledge
Most brownfield systems have three kinds of knowledge: what the system does, how work moves through it, and why the strange parts still exist. Agents are increasingly good at the first. They can often infer the second. They are weakest at the third, because the third usually lives outside the code repository. Where that third kind of knowledge actually lives, and why software never captured it, is the subject of The Mess Just Got Cheap.
The serious modernization work already follows this shape. IBM’s mainframe modernization work, for example, does this by building an application blueprint, explaining COBOL, PL/I, assembler, and job-control logic in human language, tracing relationships between programs and batch jobs, and validating that the transformed system still means what the old one meant. That is a different review surface: data movement, business meaning, runtime behavior, and evidence that the new thing still behaves like the old thing where it must.
What the agent has to show first
Brownfield agent work outside the mainframe needs the same pattern. Before the agent changes the treaty, it has to show what treaty it thinks it is changing.
What behavior changed? What behavior was deliberately preserved? What source of truth proves the non-obvious rule?
Sometimes the source of truth is a test. Sometimes it is a customer contract, a regulator's email, a data warehouse query, or the person who has run the process for seven years. The point is to make the agent prove it has found the ground before it starts digging.
Every CTO has heard some version of this before, usually as a plea for better documentation. They have rationally ignored it. The labor was expensive. The cost of skipping it was diffuse. Agents change both sides: they make the record cheaper to draft, and the missing evidence more expensive to tolerate.
Better models will not remove the tax
Better models will help. They will not remove the tax.
The information that matters most was never in the training data, because it was never written down anywhere useful. A regulator's letter. Sarah's memory. A vendor's bad habit. Better models without that context are just more confident against an opaque system.
That is worse than slow. The same point about output confidence outrunning ground truth is made in Reliable AI vs. Coin Flip.
Here is the contract. The agent changes the cost of writing code. It does not change what the CTO signs their name to. The agent owns nothing.
Pay the brownfield tax now, as the work happens. Or pay it later in incidents.
Where Moative fits
Moative works with mid-market operators on exactly the systems this essay is about: the ones that earn revenue, carry scars, and have no one left who remembers why. Our order of work is to record the treaty before touching it, which is slower on day one and considerably cheaper in February. In healthcare revenue cycle management the strange exceptions are usually payer-specific rules nobody documented, and in claims processing the non-obvious adjustment is often the one keeping a denial rate down.
Frequently asked questions
What is brownfield software development?
Brownfield work means changing a system that already exists and is already relied on: it earns revenue, customers depend on it, and the organization has built habits around its quirks. Greenfield is the empty page, where nothing has to be preserved because nothing has been promised yet.
Why do AI coding agents struggle with legacy code?
Because the hard part of a legacy system is not in the repository. Agents can describe what code does and often infer how work moves through it, but the reason a strange exception exists usually lives in a regulator's letter, a contract or somebody's memory. Removing that exception looks like a clean-up and behaves like a breakage.
Do AI coding tools actually make teams faster?
The early gains are real, and the evidence so far suggests they can fade as quality problems accumulate downstream. The agent's throughput is not the constraint. Review is, and review gets harder as the volume of plausible-looking change increases.
How do you safely use AI agents on legacy systems?
Require the agent to state its understanding before it changes anything: what behavior is changing, what behavior is being deliberately preserved, and what source of truth proves each non-obvious rule. That source might be a test, a contract, a regulator's email or a person. The review surface is the safeguard, not the model.
Will better AI models solve the legacy code problem?
They will help with the parts that were written down. They cannot help with the parts that never were, and a more capable model without that context is simply more confident while being wrong about the same things.
Who is accountable when an AI agent breaks production?
The person who signed off on the change. The agent changes the cost of producing code and changes nothing about ownership, which is why the review surface has to carry the weight that documentation never did.
