Agents Can't Do Brownfield. Yes, They Can.
Everyone says AI agents only work on greenfield. That your legacy monolith is too complex, too fragile, too undocumented. They're wrong, but the approach has to change. Agents don't replace your monolith. They reverse-engineer it, rationalize it, and build around it.
Pendo Feature Adoption Report
Wakefield Research, 250 tech leaders surveyed
Accenture Digital Core Report
EffectiveSoft / RightFirms analysis, 2024
What People Get Wrong About AI and Legacy Code
Walk into any enterprise architecture review and say "we're going to use AI agents on the legacy codebase." You'll get the same three objections every time.
- "Agents can't understand a 10-year-old monolith." They can't understand it the way a 20-year veteran who wrote half of it does. But they can analyze it, map its dependencies, trace its call chains, identify its dead code, and document its actual behavior in hours, not months. That's not understanding. That's telemetry. And telemetry is what you need to make strategic decisions.
- "It's too fragile to touch." Correct. Which is exactly why the strategy isn't to touch it. It's to build around it. The monolith stays running. The agents build new services alongside it. Traffic shifts incrementally. The old code dies of natural causes.
- "The data model is unmaintainable." Also correct. And also irrelevant if the strategy is to wrap the existing data layer in a clean API boundary, let the agents reverse-engineer what the current schema actually does (vs. what the ERD from 2014 says it does), and build the new data model against observed reality rather than inherited documentation.
What You Don't Know About Your Monolith
Here's the uncomfortable starting point: you don't actually know what your legacy application does. Not completely. Not accurately. Not anymore.
Pendo's Feature Adoption Report found that 80% of features in enterprise software are rarely or never used. The Standish Group's research is even more specific: only 7% of enterprise application features are "always" used, 13% are "often" used, and 16% are used "occasionally." That leaves 64% as "rarely" or "never."
Your 10-year-old monolith that's "critical to a multi-million-dollar business"? Most of it isn't. Most of it is dead weight: deprecated features nobody turned off, integrations with systems that were decommissioned in 2019, error-handling paths for edge cases that haven't triggered in years, and admin screens that three people use once a quarter.
But you don't know which 64% is dead weight. And that's the actual problem. Without objective telemetry on what your application actually does in production, every modernization decision is a guess. And a wrong guess on a multi-million-dollar system is how you end up in the 79% failure cohort.
The Agent Reverse-Engineering Process
Agents are faster than humans at analyzing existing functionality. Not because they're smarter: because they don't get bored, they don't skip files, and they can hold the entire codebase in working context simultaneously.
As reported by GitHub's engineering blog, a top-five US bank used this pattern: GitHub Copilot converted 1.5 million lines of COBOL to Java microservices, with automated tests ensuring 99.9% functional equivalence. The agents didn't guess what the COBOL did. They analyzed it, extracted the business logic, generated tests against the existing behavior, and then built the replacement, verified against those tests. Industry analysts project that by 2026, a significant share of legacy modernization projects will incorporate AI-assisted reverse engineering, up from less than 10% in 2023.
Branch, Don't Break: The Strangler Strategy
The question isn't "can agents modify the monolith?" They shouldn't. The question is: can agents build around it, progressively replace it, and let the old code atrophy naturally? The answer is yes, and there's a well-established pattern for exactly this.
Martin Fowler coined the strangler fig pattern in 2004: surround the legacy application with new services that progressively take over its responsibilities, until the old system can be decommissioned. AWS, Azure, and every major cloud provider document this as the recommended modernization approach. What's new is that AI agents can execute the pattern at dramatically accelerated timelines.
How Agents Execute the Strangler Pattern
- Step 1: Facade construction. Agents build an API gateway that intercepts all traffic to the monolith. Initially, 100% of requests pass through to the legacy system. The facade is a transparent proxy: it doesn't change behavior, it just creates a routing layer. This is low-risk, high-value, and exactly the kind of bounded task agents excel at.
- Step 2: Service extraction. Starting with the highest-value, lowest-risk functionality (informed by the Phase 2 rationalization), agents generate new microservices that replicate specific capabilities. Each new service is built against the specs from Phase 3, tested against the behavior of the existing system, and deployed behind the facade. Traffic shifts from legacy to new: incrementally, reversibly.
- Step 3: Progressive decommission. As services prove themselves in production, the legacy endpoints they replace go dormant. The monolith shrinks. The 64-80% dead functionality is never rebuilt: it's simply identified and abandoned. You don't modernize what nobody uses.
Agents can build the facade, generate the services, and run the tests. But someone has to decide what to extract first, what to abandon, where the domain boundaries are, and what the business impact of a wrong routing decision looks like. That's not computation. That's judgment. And it requires the same caliber of senior, domain-expert human we've been arguing for across this entire content series.
The Argument Is About Approach, Not Capability
"Agents can only do greenfield" is a statement about approach, not about technology. It's true if you ask agents to do what failed modernization projects have always done: understand the entire monolith, rewrite it from scratch, and flip the switch. It's false if you change the approach.
- ✕Attempt to understand the entire monolith before acting
- ✕Rewrite everything, including the 64% nobody uses
- ✕Big-bang cutover with a "go/no-go" decision
- ✕12-18 month timelines with late-stage integration testing
- ✕Hope the documentation is accurate
- ✕Measure success by "feature parity"
- ✓Agents analyze the monolith for objective telemetry, in days
- ✓Rationalize: only rebuild the 20-36% that's actually used
- ✓Incremental traffic shift via facade, reversible at every step
- ✓Weeks-long extraction cycles with continuous verification
- ✓Generate specs from observed behavior, not stale docs
- ✓Measure success by business outcomes, not line-for-line parity
By 2026, 45% of modernization budgets are allocated to AI-driven solutions that analyze legacy codebases to identify technical debt hotspots and generate modern equivalents. The industry isn't debating whether agents can do brownfield anymore. It's debating how fast.
Where This Connects
Our Greenfield vs. Brownfield piece laid the foundation. When Agents Fail explained why human oversight is non-negotiable. Spec-Driven Development showed that agents execute best when given rigorous specifications. This piece closes the loop: the agents generate the specs from the existing system, senior humans validate them, and then agents build the replacement, all without touching the running monolith.
It's not greenfield vs. brownfield. It's greenfield around brownfield. And agents are exceptionally good at it, when the approach is right and the humans guiding them are senior enough to make the strategic calls.
Your Monolith Isn't a Roadblock. It's a Starting Point.
Critical Propulsion runs agent-driven legacy analysis that tells you what your application actually does, so your modernization plan is built on reality, not assumptions.