Brownfield modernisation with AI: beyond the hype

The ‘AI-native engineering’ dream is always sold as a greenfield paradise – pristine prompt files, flawless context engineering, zero technical debt.

But if you are a CTO or lead engineer at an established enterprise, this isn’t your reality. You are more likely managing a highly successful, revenue-generating application that is five, ten or twenty years old: a ‘brownfield’ estate, a complex monolith held together by hope, undocumented logic and a build pipeline everyone is terrified to touch.

An estimated 60–70% of enterprise software is brownfield. Yet most modernisation attempts stall or fail outright. Why? The industry has focused heavily on how AI accelerates greenfield builds, while overlooking the architectural and organisational challenges that make brownfield modernisation fundamentally harder.

Deploying unbounded autonomous coding agents into brownfield architectures often generates ‘dark code’ – visually clean but semantically flawed implementations that violate undocumented, implicit contracts. Bound by context window limitations, these agents analyse isolated components and suffer from ‘intent blindness’, failing to comprehend the historical rationale or cross-cutting dependencies behind specific system behaviours.

This creates an ‘aesthetic trap’, where over-optimised, structurally pristine outputs mask a profound lack of system-wide understanding, quietly introducing hidden technical debt under a veneer of professional syntax.

The architectural risk compounds when these agents hit context gaps and default to confident hallucination over graceful degradation. Rather than surfacing missing dependencies or knowledge boundaries, they fabricate untraceable business logic and generate unit tests that verify their own assumed implementations instead of reality. By asserting against hallucinated logic, the agents codify existing bugs behind seemingly robust green builds, replacing legacy systems with a functionally divergent black box that offers a false sense of security.

To safely reclaim your architecture, you need a disciplined, surgical approach that combines classic software engineering patterns with AI force multiplication.

When modernising a live system, you cannot take the plane offline to fix the engine. You have to evolve it at 30,000 feet while it keeps running in production.

Depending on your risk tolerance and system constraints, three methodologies do the heavy lifting:

1. Pseudo-greenfield development: Isolate a specific feature or module into a separate branch, building the replacement using Spec-Driven Development (SDD) patterns. While early velocity is fast, this approach carries a high risk of a painful reintegration phase and potential duplication of shared concerns like auth or logging if left unchecked.
2. The strangler fig pattern: Replace the legacy system section by section from the outside in. A facade or routing proxy layer intercepts edge boundaries, sending traffic to a newly built external service while the old code is systematically strangled and retired. This suits microservices migrations but requires long-term organisational commitment.
3. Branch by abstraction: Work from the inside out, directly inside the codebase. Place an interface contract over the deeply embedded component you want to replace, migrate all call sites to that abstraction, build the new implementation in parallel and swap it seamlessly once verified. This keeps your main trunk releasable at all times and prevents long-running, breaking forks.

To keep AI honest and eliminate the risks of ‘vibe coding’, engineering teams must transition to a structured, 7-step execution loop where humans own the intent and AI handles the mechanical groundwork:

1. Map: Use agentic AI to crawl the repo, generate dependency graphs, surface hidden call sites and identify test coverage gaps automatically.
2. Draft: Direct the AI agent to draft an initial technical specification based purely on observed code behaviour and current runtime outputs.
3. Correct (the human handshake): Senior engineers review and edit the spec, injecting critical tribal knowledge, complex business logic, edge cases and architectural constraints that code scans can’t catch.
4. Characterise: The agent automatically generates a regression safety net of characterisation tests directly from the validated spec.
5. Contract: The spec formally becomes the explicit interface contract for your abstraction layer.
6. Implement: The new implementation is built spec-first, with the agent continuously validating code changes against the test suite.
7. Retire: Once the spec passes fully and functional parity is proven, the legacy path is safely retired.

This isn’t theoretical. Nearform has been applying these exact architectural boundaries to drive delivery gains in complex, legacy environments:

Codebase mapping dropped from two weeks to mere hours.

• Shipping months of scope in weeks: In a legacy modernisation engagement for a senior leadership advisory firm, a pseudo-greenfield approach was used to reverse-engineer product requirements from old documentation. Codebase mapping dropped from two weeks to mere hours, enabling the team to ship six months of product scope in just eight weeks – 4x faster than competitor timelines. This work then became the blueprint for further strangler fig pattern redevelopment.
• The component flywheel: On a highly complex distributed monolith exceeding 500,000 lines of code, a team used branch by abstraction to modernise embedded grid components. The stakeholder had been resigned to component library upgrades taking months, and a previous attempt to upgrade the first component manually took a month before being abandoned. By building a specialised ‘planning skill’ and an agentic multi-step developer flow, the team accelerated to migrating three complex components a week, building a reusable skills library that dropped subsequent upgrade times to hours.

If you are architecting your organisation’s transition to AI-native engineering, enforce these three constraints across your pipelines:

1. Start with a map, not a migration: Never let an AI agent loose to rewrite an open-ended codebase. Use agentic automation to document and index your system first – a documentation project earns its keep on day one.
2. Let the spec be the contract: Define what a system should do, before modifying how it does it. The specification is the version-controlled, durable anchor that both your developers and AI agents must answer to.
3. Think in slices, not rewrites: Abandon the high-risk ‘big bang’ rewrite mentality. Evolve incrementally – one abstracted component, one passing specification and one retired legacy path at a time.

AI-native engineering is not a greenfield privilege. It is a surgical tool, most valuable where complexity already lives.

Stop using AI to add to your technical debt, and start using it to pay it down.

AI has changed both the economics and the time frame for modernisation. Therefore, before you choose your architectural approach, you need to know how to frame your argument before presenting to the board.

Clifton Cunningham, ex-CTO, SVP of Advisory & Alliances at Nearform, has written a guide to making that case: The Business Case for AI-Led Modernisation. It includes three formats and when to use each one, worked examples, the conversation to have with your CFO (including whether modernisation counts as capex), and where to start.

To complement the guide, our calculator gets your payback point, annual savings, and 5-year impact in minutes. Simply input your running costs to see when modernisation pays for itself.