AI Coding: Greenfield vs Legacy Codebase
AI coding on a greenfield project and a legacy codebase are two different jobs. Here is how the workflow changes and why legacy is the bigger prize.
AI coding on a greenfield project and AI coding on a legacy codebase are not the same task. On greenfield, the model writes into empty space and looks like a genius. On legacy, it has to earn a right to touch code that already carries a business. Most teams learn the greenfield workflow, get excited, then get burned when they point the same workflow at a ten-year-old repo. The fix is to treat them as two different disciplines, because they are.
Why greenfield makes AI look better than it is
On a blank repo, there is no prior art to contradict. The model picks a structure, writes the code, and every choice is internally consistent because it made all of them. You get a working prototype in an afternoon and you conclude AI coding is solved.
It is not solved. It is unconstrained. The absence of constraints is exactly what made it fast. There was no existing auth to respect, no naming convention to match, no weird invariant that a customer depends on. Greenfield speed is real, but it is the easy 80 percent. The reason so many AI builds die is that the prototype stalls the moment it meets real constraints, and greenfield hides every one of those constraints until later.
Use greenfield speed for what it is good at: proving a shape, throwing away three versions, finding the design. Just do not confuse that with shipping.
Why legacy is the harder and more valuable job
Legacy code is where the money already is. A greenfield app has zero users. A legacy monolith has revenue, obligations, and a hundred decisions encoded in ways nobody wrote down. AI that can safely modify that is worth far more than AI that can spin up another todo app.
The problem is context. The model cannot see the invariant that says "never call this without a lock" unless you make it visible. It cannot know that the ugly function is ugly because of a production incident in 2021. So on legacy, most of the work is not prompting. It is loading the model with enough context to not do damage, then constraining what it is allowed to change. Auditing a codebase you inherited is the precondition, not an optional first step.
How the workflow actually changes
On greenfield, the loop is: describe, generate, run, iterate. Fast and loose is fine because there is nothing to break.
On legacy, the loop inverts. It starts with reading, not writing:
- Map the area first. What calls this, what does this call, what tests cover it.
- Pin the change to a small blast radius. One module, one behavior, one seam.
- Write characterization tests before you let AI refactor so you can prove behavior did not change.
- Make the model work in small, reversible steps instead of one giant diff.
- Review the diff against the existing conventions, not against what looks clean in isolation.
The single biggest difference: on greenfield you review for correctness, on legacy you review for damage. The question is not "is this good code" but "did this quietly change something a customer relies on."
Where the model needs your codebase, not just your prompt
On legacy, a good prompt is not enough. The model needs the actual conventions of your repo loaded into context, or it will invent its own and create a second dialect inside your codebase. That is how a legacy repo turns into five styles fighting each other. Teach the model your codebase conventions up front, and it will match instead of impose. The tools that do legacy well are the ones that read the repo before they write, which is why repo intelligence matters before you refactor.
This is the split I design around at Bootspring: a fast lane for greenfield exploration, and a context-heavy, gated lane for legacy work where the model is loaded with the real repo before it touches anything. The tooling for reading and scoring an existing repo is where ReformCode does the heavy lifting.
The takeaway
Do not run one workflow for both. On greenfield, let AI run fast and throw away drafts. On legacy, slow the front of the loop way down: read, map, constrain, test, then let the model make one small change you can prove is safe. Greenfield is where AI feels impressive. Legacy is where it pays.