There Is No Such Thing as Greenfield. Your Codebase Goes Legacy in a Week.

The greenfield-versus-brownfield distinction is mostly an illusion, and with AI writing code it collapses faster than ever. In this talking-head clip, Matt Pocock (the TypeScript educator behind AIhero.dev) answers a question he keeps getting about his AI coding skills: do they work on greenfield or only brownfield? His answer is that the two are basically the same thing, because every codebase is built for the real world, and a fresh repo stops being fresh almost immediately once AI starts filling it with code.

What Greenfield and Brownfield Actually Mean

The two terms describe where you start. Greenfield is a brand-new project with nothing built yet. Brownfield is existing software you are editing, integrating with, and extending. The common assumption is that greenfield is the easy, unconstrained case and brownfield is the messy, constrained one.

Pocock's pushback is that the "green field" is a fantasy. Whatever you build ships into the real world, which means external constraints, integrations with existing systems, and actual problems to solve. You are never truly working from a blank slate, so the clean-slate premise behind greenfield rarely holds.

The Only Real Difference

He does concede one distinction. In a brownfield codebase, the working experience is already sorted out: there are existing coding conventions, probably a test suite, and established standards. Even when none of that is written down, it is implicit in the code that has already been shipped.

In greenfield, you get to choose all of that up front. That freedom is the actual difference, not some fundamentally different kind of work. And it is a narrow, front-loaded window rather than a lasting property of the project.

How Fast Green Turns Brown

Here is the sharp part of the argument. Once you make those early choices and the AI spits a bunch of code into the repo, the choices start to harden. They become harder to change the further you go. So how long does a greenfield codebase stay green? In Pocock's estimate, not very long. Maybe a couple of days, a week at most.

The AI angle accelerates this. Because agents generate code so quickly, you move from fresh codebase to legacy codebase at a faster rate than ever before. The window where nothing is decided is now measured in days, which is why he treats the greenfield label as barely worth arguing over.

Why This Argument Holds Up

The clip is a single presenter talking to camera in a home office, bookshelf behind him, a podcast-style mic in frame, with burned-in captions and his AIhero.dev branding on screen. There is no code demo, so the weight sits entirely on the reasoning, and the reasoning is consistent with how AI-assisted development actually plays out. Conventions, folder layout, and test patterns calcify the moment they exist, and agents make them exist sooner.

His conclusion is practical rather than fatalistic. Brownfield codebases can hold a lot of code and still be easy to navigate if you design the documentation and the folder structure properly. The takeaway is to stop worrying about which field you are standing in and instead invest early in the structure and docs that keep any codebase legible, because you are going to be in brownfield territory almost immediately either way.

Key Takeaways

Greenfield and brownfield are not fundamentally different kinds of work; every codebase ships into the real world with external constraints.
The one real difference is that brownfield already has conventions, tests, and standards, while greenfield lets you choose them up front.
Those early choices harden fast and become expensive to change the longer the project runs.
AI-generated code moves a repo from fresh to legacy faster than ever, often within days.
Because you are effectively always in brownfield, invest early in documentation and folder structure to keep the codebase navigable.