Agents Can't Do Brownfield. Yes, They Can.

Somewhere in your ten-year-old monolith is an admin screen three people open once a quarter. There's an integration with a system that was decommissioned years ago. And there's probably an error handler for a failure mode that hasn't fired since the last CEO transition.

The problem is that nobody currently on the team knows which parts of the codebase are which anymore.

That's the real problem with brownfield. It was never that agents can't handle old code.

A lot of that $2.41 trillion isn't about the difficulty of writing code. It comes from trying to make decisions about systems that nobody fully understands anymore. The people who built them moved on. The documentation drifted out of date. Years of patches, workarounds, integrations, and exceptions piled up.

So when modernization finally comes around, teams end up making decisions with an incomplete picture of what the system actually does.

This is one of the places where agents are genuinely useful. They don't understand the business the way the engineer who spent ten years working in the application did. But they can trace call chains, map dependencies, catalog endpoints, and document behavior at a scale that would take a human team months to work through manually.

That isn't business understanding. It's telemetry. And once you have it, you can make much better decisions about what stays, what gets rebuilt, and what can simply disappear.

What the Objections Get Wrong

"It's too fragile to touch."

It probably is. But modernization doesn't have to begin by tearing into the monolith.

The existing system can keep running while new services are built alongside it. Traffic moves over incrementally as those services prove themselves. You're not rewriting the old application in place and hoping nothing breaks. You're slowly reducing how much work it has to do.

Eventually, parts of it just go quiet.

"The data model is unmaintainable."

That may also be true. You still don't need to redesign the entire thing before you can start.

Put a clean API boundary around the existing data layer, then use agents to reverse-engineer how the schema behaves today. Look at what actually gets queried, what relationships the application depends on, and where the weird exceptions live.

The entity diagram from 2014 can be useful historical context. It shouldn't be the source of truth if the running system is telling you something different.

The 79% failure rate above also points to another problem: sequencing.

A lot of modernization programs have historically been built around some version of the big-bang rewrite. Understand the old system, rebuild the whole thing, test it, then choose a date when everyone crosses their fingers and flips over to the new one.

Human teams struggled with that approach. Giving the same plan to an agent-driven team doesn't fix it. You may have changed who, or what, is doing the engineering work, but the sequencing problem is still there.

You Don't Know What's Actually Running

Here's the uncomfortable part: you probably don't know everything your legacy application does anymore.

Most organizations don't.

The Standish Group's most-cited breakdown, drawn from a 2002 study of four internal applications, puts rough numbers on the same problem: 7% of features get used "always," 13% "often," 16% "occasionally," and 64% "rarely or never." Treat that last figure as directional, not precise. It's an old, narrow study. But it lines up with the 80% figure above from Pendo's much larger and more recent look at the same question.

The problem is that you don't know which part of your own system falls into that 64 to 80%.

And that matters. If you modernize without knowing what the application is actually doing in production, you're making decisions based on documentation, institutional memory, and assumptions. Some of those will be right. Some won't.

On a system that runs the business, the mistakes get expensive quickly.

An agent can help build a much more objective picture. Trace execution paths. Instrument database queries. See which endpoints actually receive traffic. Compare the application people describe in meetings with the application that is really running.

Once you have that picture, the modernization plan gets a lot more concrete.

The Process, Start to Finish

The work breaks down into six steps. The first three are about understanding what you actually have. The next three are about replacing it without betting the company on one giant cutover.

The six steps don't eliminate the hard decisions.

Someone still has to decide what gets extracted first, what gets abandoned, where the domain boundaries should sit, and how much production risk is acceptable at each step. Agents can give that person dramatically better information, but they can't make those calls on their own.

That still requires senior engineers who understand the business and know what happens when they get a decision wrong.

Lift and Shift vs. Wrap and Modernize

Our Greenfield vs. Brownfield piece laid the groundwork for this argument. When Agents Fail covered why human oversight isn't optional. And Spec-Driven Development showed why agents perform better when they have a rigorous spec to work against.

Brownfield modernization is where those ideas start to come together.

The running system gives you the evidence. Agents turn that evidence into a map and a first version of the spec. Senior engineers correct it and make the calls that require business judgment. Then agents can do a large amount of the extraction and implementation work against something much more reliable than an old architecture diagram and a collection of tribal knowledge.

Which raises a pretty useful question:

What would change about your modernization plan if you actually knew which 64% of the system nobody uses?

Who This Is For (and Who It Isn't)