A Blank Page Still Needs Gates

The argument in part 1 ends where most greenfield stories begin: the diagnosis came back genuine, the decision is made, and someone opens an empty repository. This is the most dangerous moment in the whole project — not because anything has gone wrong, but because nothing can go wrong yet. There is no failing build, no regression suite objecting, no downstream team complaining. A blank page grants you maximum freedom at the exact moment you hold minimum information, and every constraint the old system used to impose for free — the review culture its fragility demanded, the caution its outages taught — is gone. Greenfield failures are freedom failures, and the cure for a freedom failure is a gate you build yourself.

Delivery frameworks answer this with structure, and some answer with a great deal of it. TheLinuxCode's greenfield playbook breaks this into ten stages and a 90-day cadence; my compression of it is three questions, asked continuously rather than in sequence — what did we decide, what have we proved, what lets us ship? Their material is thorough, and staged discipline is real discipline; my objection from the field is that named stages become ceremony faster than they become safety, and the value survives compression. Decide, prove, ship. The rest of this post is those three gates, then a fourth section on what changes when half your first drafts are machine-written.

Decide — and write the decision down

The first gate is a document, and it is deliberately short: what business outcome must change, how we will know it changed, what is explicitly out of scope, and — the clause most decision records omit — what evidence would reverse the decision. If the team cannot state the outcome in plain language, code should not start; if the record has no reversal clause, it is not a decision, it is a commitment ceremony.

The out-of-scope list earns special defence. On a blank page, scope is the only thing with no natural predator — part 1's first failure mode — so the list of what you are not building is the most load-bearing artefact of the early weeks. I keep it in the repository, next to the code, and treat additions to scope like schema migrations: written down, reviewed, owned.

Every significant technical choice gets the same treatment in miniature — what we picked, why, what we rejected, and a date to re-examine it. Not for the auditors; for the team you will be in eighteen months, who will otherwise re-litigate every choice from memory.

Prove — before the architecture hardens

The second gate is evidence, and the operative word is early. When I stand up a new orders-api, the first milestone is not the domain model and it is certainly not the platform — it is one request travelling end to end through the real seams: a genuine client call, through authentication, business logic, persistence and telemetry, in a deployed environment. Thin to the point of embarrassment, and worth more than any diagram, because it proves the seams — the places integration actually fails — while changing them is still cheap.

The same gate applies to the scary assumptions. If the case for greenfield rested on a throughput target or a failure-recovery story (part 1's discovery exercise), the first weeks of real construction should re-prove those against production-shaped data, not fixtures. Assumptions age fastest exactly when construction is most enthusiastic.

And the gate has a calendar form, which is my sharpest test of a greenfield plan: if the plan cannot show a user-visible result until its final month, it is not a plan — it is a launch bet. Working software on a steady rhythm, each slice a little deeper than the last, is what proof looks like from the outside. A quiet repository with a confident roadmap is what hope looks like.

Ship — like you intend to keep shipping

The third gate is the one teams deprioritise because launch feels far away, which is precisely how launch stays far away. Ship discipline on a greenfield build means three things arranged before the first release, not after.

Release progressively. First to yourselves — the team using its own system finds what no test plan will — then to a small cohort, then wider, with the ability to retreat at every step. A release you cannot roll back is a release you have not finished designing.

Operate from day one. Telemetry, alerting and service-level targets go into the first vertical slice, because instrumenting a system after it misbehaves is archaeology, and because the operational habits a team forms in month two are the ones it keeps.

And plan the funeral. If the new system overlaps anything that exists — and per part 1, it almost always does — the old thing's decommissioning belongs on the same roadmap as your feature work, with an owner and a date. A greenfield project that never retires its predecessor has not replaced a system; it has added one, and doubled the estate it swore to simplify.

The gates an agent does not get to open

Now the 2026-and-after complication. On my current projects most first drafts are agent-written — scaffolding, test suites, migration script drafts, documentation — and a blank page is where agents are most seductive, because there is nothing yet for their output to contradict. Volume arrives effortlessly. Understanding does not arrive with it. The discipline I have settled on is a division of ownership rather than a division of labour, and it maps onto the three gates directly.

The human owns the decision record. An agent can draft the options analysis, and mine routinely do — but the choice, its rationale and its reversal clause are authored by the person who will answer for them. The moment your architecture decisions are machine-drafted and human-skimmed, the record stops describing your intent and starts describing a plausible average of everyone else's.

The human owns the acceptance bar. What “done” means — the tests that must pass, the review every change receives regardless of author, the targets that fail a build — is set by people and applied uniformly. Agent-drafted code goes through the same gate as mine, not a politer one; an agent-drafted migration gets rehearsed against production-shaped volumes exactly as part 1 demanded of human-written ones.

The human owns the integration seams. The contracts between components — say, the events a ledger-web consumes from orders-api — are designed and reviewed by people, because seams are where generated code diverges from intent most quietly. Inside a seam, a wrong draft fails a test; across a seam, it ships a misunderstanding to another team.

Within those boundaries, the agent drafts freely, and the productivity is real. The agent drafts inside gates a human owns; the moment the gate itself is agent-drafted, you have delegated the decision, not the work.

What this treatment leaves out

A two-part mini-series owes you its own out-of-scope list, so here is the honest ledger for the pair.

Brownfield got a diagnosis and no treatment. Part 1 argued that most enterprise work is brownfield and then spent both posts on the minority path; the incremental modernisation craft — seam-finding in legacy code, extraction patterns, running old and new in harness — deserves its own series and did not get one here.

The politics are missing. Rewrites are organisational events — funding fights, morale, the fate of the team that owns the old system — and those forces sink more greenfield projects than architecture does. I have said almost nothing about them, mostly because my scars there are harder to generalise honestly.

The evidence is practitioner-grade. This series rests on my own field experience and on credited practitioner writing, not on controlled studies. Weigh it as testimony, not as data.

And the AI-era section is a snapshot. The gates I described are the ones I hold as I write; they have already tightened once as the tools improved, and they will move again. If you are reading this long after the publish date, assume the boundary between what agents draft and what humans own has shifted — and then notice that the three questions underneath it have not. Decide, prove, ship survived the move from waterfall to agile to agents, which is the best evidence I can offer that they are the field-invariant part.

The field you build on matters less than the gates you carry onto it. That is the series, in one sentence.