The Next SDLC Is Defined by Terrain, Not Stages

Most advice about AI in engineering is written for a codebase that does not exist.

It assumes a clean repository, clear requirements, tests you trust, and no history. Point the agent at it, describe the feature, watch it ship. That demo works every time. Then you try it on your actual system, the one with nine years of history, a test suite nobody believes, and three services whose authors have all left, and the magic evaporates.

The problem is not the model. It is the ground you are standing on.

Stages describe how you work. Terrain decides whether AI helps.

For thirty years we have described delivery in stages: plan, build, test, release. It is a fine map for coordinating humans and a poor one for predicting AI, because an agent does not care what stage you are in. It cares what it can read, run, and verify.

Two teams can run the identical process and get opposite results from the same tool. One ships agent-written code to production; the other watches the agent hallucinate through a legacy module. The difference is not discipline or seniority. It is terrain: the real condition of the codebase the agent has to work in.

So the better question is not "where are we in the process." It is "what field are we building on."

Three fields

Greenfield. New code, no history. This is where every AI demo lives and where almost nobody actually works. Greenfield is not a free win either: built the old way, it is just next year's brownfield. The opportunity is different, which is that you can build it AI-native from the first commit.

Brownfield. Real systems. Legacy, constraints, history, the code that runs the business. This is where most engineering happens, and where AI disappoints most often, because the field was never prepared for an agent to work in it.

WhiteField. The destination. A codebase deliberately cleared for agents: context they can read, tests they can run, boundaries they cannot cross, and work specified clearly enough to verify. WhiteField is not luck you inherit. It is a state you convert toward.

Greenfield and brownfield are where you start. WhiteField is where you are trying to get. Everything that works about AI in engineering is a question of how you move your field toward white.

Why brownfield breaks AI

An agent dropped into a typical brownfield repo fails for reasons that have nothing to do with intelligence. It cannot read the context, because the architectural decisions live in people's heads and old Slack threads. It cannot trust the tests, because half of them are flaky and the suite takes forty minutes. It cannot tell if it succeeded, because "done" was never written down in a form anything could check. These are not model problems; they are field problems, and I have broken down the specific layers a repo needs before agents work reliably separately. Brownfield is not a dead end. It is a field that has not been cleared yet.

Road one: converting brownfield

Brownfield is where the business actually runs, and it is where the honest work is. You cannot restart it, and you should not pretend the agent will figure it out on its own. You convert it, deliberately, in the order that returns leverage soonest.

Conversion is three moves, and they map to what an agent needs before it can be trusted. First, make the context readable. The knowledge a senior engineer carries in their head, why this service exists, what must never change, where the sharp edges are, has to become something an agent can read: context files, an accurate CLAUDE.md, architecture notes that describe the system as it is rather than as it was designed a decade ago. Second, make the tests trustworthy. An agent that cannot run your tests, or cannot believe the result, is flying blind, and so are you. Fast, behavioural, reliable in CI is the bar. Third, specify the work so that "done" is checkable. This is the move most teams skip, and it is the one that unlocks the other two.

That third move is where a specification layer earns its keep, and where I would point a brownfield team first. The failure mode of AI on legacy code is not that the agent is stupid; it is that it is handed a vague ticket, guesses at the intent, and produces plausible code that is wrong in ways only a domain expert catches. A spec closes that gap before a line is written. Open frameworks like OpenSpec, which is built explicitly for brownfield, keep the plan in plain Markdown the agent reads before it acts: you explore an idea, propose the change as a short written spec, the agent implements against that spec, and the work is archived when it matches. The agent operates from documented intent instead of the last twenty messages in a chat window.

I want to be precise about the claim, because the honest version is more useful than the hype. Spec-driven development clearly wins where the work is bounded and the outcome is verifiable: a defined change to a known module, a migration with a checkable end state, a feature with real acceptance criteria. It is worth staying sceptical, and experimental, where the work is genuinely exploratory and you are still discovering what you are building. There a heavy spec slows you down, and a looser loop is better. Spec-driven is one road to WhiteField, and a good one. It is not the only road, and I will write about the others as they prove out.

And to be clear about the process point, because it cuts against a lot of what I argue elsewhere: this is not adding ceremony. I spend most of my time telling teams to kill low-value rituals, not invent new ones. A spec is not a gate. It replaces the two most expensive things in brownfield delivery, the ambiguous ticket and the rework loop that follows it, with a short shared agreement about what you are actually building. The goal is to simplify the process you already have and make it faster, not to bolt a new phase onto it. If your spec practice feels like paperwork, you are doing it wrong.

One more discipline: do not try to convert the whole repository at once. Start with the field you stand on most, the module you touch every week, and clear that first. WhiteField spreads out from the parts you actually work in. It does not arrive as a big-bang migration.

Road two: building greenfield born-ready

Greenfield looks like the easy case and quietly becomes the expensive one. The mistake is treating AI-native as something you will add once the product is real. You will not. The context infrastructure never gets written, the tests keep getting deferred, and eighteen months later you have manufactured a fresh brownfield without even the excuse of legacy. Greenfield is only an advantage if you spend it.

Spent well, it means the things a brownfield team has to retrofit under pressure go in from the first commit, when they are almost free. Context infrastructure grows alongside the code instead of being reconstructed from memory later. Tests are behavioural and agent-runnable from the start, because you are writing them with the feature rather than bolting a suite onto code that was never built to be tested. Boundaries are set early, so an agent has hard limits it cannot cross. None of this is exotic. It is the same discipline as version control, adopted at the same moment and for the same reason: trivial to start, painful to add later.

The piece greenfield teams underweight most is evaluations. Anything your product does with AI, a classifier, an agent, a generation step, is non-deterministic, and ordinary unit tests do not capture whether it is getting better or worse over time. Evals are to that behaviour what tests are to deterministic code: a harness that measures the quality you care about against real cases, runs in CI, and catches a change that quietly degrades the output before a customer does. On greenfield you can build that harness in from day one and treat it as first-class infrastructure. On brownfield you are usually retrofitting it after something has already gone wrong in production. This is the single largest structural advantage a new project has, and the one most teams waste.

Built this way, a greenfield project does not start on the far side of the field from WhiteField. It starts most of the way there, and it stays there, because AI-readiness is a property of how it was built rather than a project bolted on afterward. The specifics, the eval harnesses, the test shapes, the context layout that keeps a growing codebase legible to an agent, deserve their own treatment, and I will write that as a dedicated piece.

How far up the field are you

Terrain tells you where you stand. It does not tell you how far you have climbed. For that, use the AI maturity model: Ad-hoc AI Use, Assisted Development, AI-Native, Agentic Development. Most teams that have used AI tools for six months sit at Assisted Development, individual velocity up, nothing systemic changed, and mistake it for progress. Moving up is deliberate work, usually four to twelve weeks depending on repo size, regulatory load, and business domain. It is not a matter of buying another tool.

The field is the variable

Most teams treat their codebase as the fixed thing and their tools as the lever. It is the reverse. The tools are commoditising fast; the state of your field is the variable you actually control, and the one that decides whether any of this works. You do not need a better model. You need a whiter field.

---

I help engineering teams close the gap between "we use AI tools" and "AI actually changed how we deliver." Book a 20-minute call and I'll tell you where the leverage is.