Watch how AI coding tools present themselves and you notice a quiet assumption underneath almost all of them. The examples start from nothing. Build a todo app. Scaffold a new service. Generate a project from a prompt. The clean slate is not incidental, it is the environment the tools are implicitly designed for, because a clean slate is where they look best. This is greenfield bias, and it is a problem because almost no real engineering work happens on a clean slate. It happens on brownfield systems, existing products with years of history, real users, and constraints the tool would prefer to assume away.
The mismatch is not cosmetic. A tool tuned for greenfield and pointed at brownfield does not just underperform, it makes a category of confident mistakes that come directly from assuming a freedom the codebase does not grant.
Greenfield and brownfield are different jobs
Building something new and changing something that exists are related but genuinely different activities, and the difference is exactly the part that makes real work hard.
On a greenfield project, you define the constraints. There is no legacy to respect, no existing contract to honor, no user relying on current behavior, no eight-year-old decision you have to work around. The agent is free to choose the cleanest approach because nothing is in the way. This is the environment where generation shines, and it is the environment the demo lives in, which is why the demo-to-production cliff and greenfield bias are really the same coin from two angles.
On a brownfield system, the constraints define you. The approach that would be cleanest in isolation is often unavailable because something depends on the current shape. The feature has to fit the architecture that exists, not the one you would draw fresh. The change has to preserve behavior that users rely on, avoid breaking contracts other code assumes, and respect conventions that are load-bearing even when they look wrong. Brownfield work is less about generating code and more about generating the right code given a large set of constraints you did not choose, and a tool that does not take those constraints seriously will produce clean code that does the wrong thing.
How greenfield bias shows up as failure
A greenfield-biased tool on a brownfield codebase fails in recognizable ways, all of them versions of assuming a freedom it does not have.
It proposes rewrites where it should propose edits. Faced with existing code that is not how it would have written it, a greenfield-minded agent reaches for "replace it with something clean" when the correct, safe move is a minimal change that fits what is there. The rewrite is prettier and far riskier, because it discards constraints encoded in the old code that nobody wrote down.
It ignores the reach of a change. On a clean slate, nothing depends on anything yet, so blast radius is not a concept. On a real system, every change has a reach, and a tool that does not reason about what a change will touch will confidently break things it never looked at. Reasoning about that reach before acting is exactly the brownfield skill greenfield tools lack, and it is the subject of impact analysis before you touch a line.
It assumes conventions instead of learning them. A greenfield tool brings its own idea of how code should look and imposes it. A brownfield-fit tool learns how this codebase actually does things and matches it, because consistency with the existing system is usually more valuable than conformance to a general ideal. An agent that fights the codebase's conventions generates friction on every change.
It treats the absence of tests or structure as the agent's problem to route around rather than the codebase's problem to fix. Brownfield reality often includes gaps, and the honest response is sometimes to improve the ground the agent stands on rather than to generate confidently on top of sand. What it takes to get an existing codebase into a state where an agent can succeed is covered in getting your codebase agent-ready.
Why brownfield fit is the harder, more valuable target
It is tempting to see greenfield bias as a limitation that will fade as models improve. It will not fade on its own, because it is not mainly a capability gap. It is a design orientation. A tool built to impress on a clean slate optimizes for fluent generation. A tool built to work on real products optimizes for respecting constraints, understanding reach, and fitting what exists, and those are different things to build for, not just different amounts of the same thing.
This is why brownfield fit is the harder target and also the more valuable one. The clean-slate demo serves a market that mostly does not exist, because the teams with budgets and real stakes are working on systems that already ship. A tool that is genuinely good at changing existing products is serving the actual job, and the actual job is where the value is.
The honest limitation
Being built for brownfield does not make an existing codebase easy, it just stops the tool from pretending the codebase is not there. Brownfield work is intrinsically harder than greenfield, and a tool that takes the constraints seriously will sometimes move slower, propose more conservative changes, and refuse approaches that would be fine on a clean slate. That is the correct behavior, but it is not the flashy behavior, and it will always demo less impressively than a tool that generates a shiny thing from nothing.
There is also a limit to how much any tool can infer about constraints that were never written down. A brownfield-fit agent respects the coupling and conventions it can observe, but a codebase's most dangerous constraints are often the implicit ones, and no orientation, however careful, fully closes that gap. The undocumented assumption remains a risk on real systems, which is why human judgment stays essential exactly where the stakes are highest.
Where this leaves you
Greenfield bias is the quiet assumption, baked into most AI coding tools, that you are starting from a clean slate, when the real work is almost always changing a system that already exists. The bias shows up as rewrites where edits belong, blindness to a change's reach, imposed conventions, and confidence built on gaps, and it does not go away with a better model because it is an orientation, not a capability.
Being brownfield-first is a deliberate stance at Loopsfinity rather than an afterthought: the platform is built to ship features into existing products with real history and real users, because that is where software actually gets built and where a clean-slate tool has the least to offer. The demo-to-production version of this is in the demo-to-production cliff, the cost consequences in the rework tax and cost surprise, and the full map of failure modes in why AI coding agents fail in production.