When Hammers and Nails Finally Worked

Even the most basic carpenter plans before building. Measurements taken. Materials chosen. Load paths considered. The plan is what makes the cuts work.

That's the analogy I opened the first post in this series with, and it's the one that explains greenfield AI development better than anything else I've found. Once the blueprint is right, the rest is just hammers and nails.

That last phrase is one I've used for decades.

A Philosophy I Could Never Fully Sustain

I've said the same thing for decades. With proper planning and specifications, the rest is just hammers and nails.

Meaning, the build itself should be the easy part. Once the specs are right, you're not solving anything new. You're executing. Carpenters who measure carefully don't agonize over each cut. They cut, they nail, they move on. That's how software construction was supposed to work.

In practice, the build never ran that cleanly.

The specs were never fully complete, and they were never fully complete on purpose. Spec-ing everything upfront was known to be too time-consuming and too costly to justify, so we wrote the spec far enough to start and accepted that the rest would surface later. The developers we hired had to be half business analyst, half engineer, because the gaps in the spec became questions during the build. We'd discover during integration that two modules disagreed on what a status field meant, or that a required input was never captured, or that a workflow had three valid endings that nobody had specified. So the build would stop. Pause, discuss, pivot, re-spec, then back to hammers and nails. The "hammers and nails" idea was never wrong as a philosophy. It was just never one sustained motion. It was hammers and nails interrupted, again and again, by planning that could not have happened earlier without spending more than the project could bear.

AI changed the rhythm. Not because AI writes better code than developers do, but because AI is a tireless back-and-forth partner during the specification phase. You can iterate on a data model with AI for a week and surface every implication, every edge case, every constraint, in a way that used to require a team of three meeting twice a week for two months. The spec gets close to complete before the build starts, for the first time in my career. The gaps that used to interrupt the build now surface in conversation beforehand. And the build finally runs closer to what I always said it should be: hammers and nails, sustained.

The compression in greenfield AI work isn't really about how fast the code gets written. It's about how thoroughly the thinking gets done before code gets written, and how much that thoroughness keeps the build phase from stalling.

What This Looks Like in Practice

A few examples from my own work make the pattern concrete.

CourtLingo, the federal court interpreter platform I built recently, came together in roughly 48 hours of building. What made the build that fast was the week or so I spent before that, working through the specs with AI: what the platform needed to do, who the users were, what the data model looked like, what the integration boundaries were. That week wasn't long compared to what the project would have taken pre-AI. It was long compared to what most builders today would consider the "planning phase" before they start coding. The build was fast because the thinking was done.

A second engagement currently underway at WAM DevTech took the same approach at much larger scale. Roughly a month of upfront planning produced a structured spec covering product definition, tech stack, data model, and implementation roadmap. Phase 1 implementation runs 16 to 20 weeks for a full multi-module platform. The data model was generated from the schema document in a single AI session. The application scaffold was set up in hours. The provider abstraction layer was generated directly from the spec. The pipeline stages were generated from a documented operational methodology with minimal correction. None of that compression would have been possible without the month of planning that preceded it.

A recent migration project and a new feature implementation followed the same shape. The deeper the planning phase, the smoother and more predictable the build phase. The pattern is consistent enough at this point that I treat it as a rule.

Same philosophy. Different scales. Same result: when the spec is done, the implementation collapses around it.

What Makes Greenfield Specifically Enable This

Five factors. Each one matters, and the combination is what makes greenfield distinct from any other kind of work.

The biggest factor is that the spec can be the only source of truth. There is no existing system arguing back. No production database whose history dictates what a field can or cannot mean. No legacy API contract pinning down the shape of an integration. The architect and the AI sit down with a blank canvas, and every decision made in the planning phase becomes the decision the build executes against.

A second factor is that acceptance criteria are forward-looking. The questions the AI has to answer during code generation are: does this match the spec, does it pass the test, does it satisfy the schema. Forward-looking criteria are the kind AI handles well, because they're well-defined and the answer is checkable.

A third factor is that there are no implicit conventions to honor. Every existing codebase carries patterns the original team adopted years ago, often for reasons no one remembers. Those patterns become rules whether anyone documents them or not. A greenfield project doesn't have those rules yet. The architect chooses the conventions during planning, the AI applies them during the build, and the conventions are consistent because they're new.

A fourth factor is that there are no regressions to worry about. Nothing is in production. Nothing has users depending on current behavior. The risk profile during the build is purely about whether the new code works, not whether it broke something old. That removes an entire category of caution from the build phase.

A fifth factor, and the one I want to spend the most time on, is that the spec itself can be iterated with AI before any code gets written. This is the change that lets hammers-and-nails run uninterrupted. In the past, the spec was written by humans, reviewed by humans, and approved by humans, and the gaps in human thinking surfaced later, during the build. With AI, the spec is stress-tested through dozens of back-and-forth iterations: what happens if this input is missing, what happens if this user role tries to do that action, what happens at this boundary, what happens during this failure mode. The gaps get surfaced in conversation, before they become interruptions in code. That iteration loop was too costly to run exhaustively before AI, and running it is what keeps the build phase from stalling.

Take any one of those factors away and the compression suffers.

A Scoping Note for Practitioners

The architect mindset I described in the first post has direct implications for how greenfield engagements should be priced and scoped.

The leverage on a greenfield project lives at the front. The Code Intelligence phase, the spec iteration, the architectural decision-making, all of it earns the eventual code generation throughput. Clients who try to shortcut planning to "get to coding faster" are optimizing the wrong constraint. They will save weeks at the front of the project and lose months at the back.

The right way to scope greenfield AI work is to charge for the planning, charge appropriately for it, and let the implementation come in faster than the client expects. That asymmetry is the deal. Not "we'll build it cheaper than the old way." More like "we'll spend longer than you'd expect on the spec, and the implementation will be done before you think it should be possible."

That's the right shape of expectation to set, and it's the right shape of pricing to support it.

The Closing Thought for This Post

The hammers-and-nails idea was always right as a philosophy, and it was always executable. I executed it on every project. What was hard was sustaining it.

Fully spec-ing everything upfront was known to be too time-consuming and too costly to be worth it, so the spec was written far enough to start the build, not far enough to finish it. The build phase began. Hammers-and-nails. Then a gap surfaced, and the work stopped: pause, discuss, pivot, re-spec, then back to hammers-and-nails. Then another gap. The build was never one sustained motion. It was hammers-and-nails interrupted, again and again, by the planning that should have happened earlier but could not have, because doing all of it earlier was not economically rational.

AI did not invent hammers-and-nails. It did not even eliminate the pause-discuss-pivot cycle entirely. What it did was compress the spec phase enough, and make the iteration cheap enough, that the gaps get surfaced before the build starts instead of during it. The interruptions shrink toward the margin. The build phase finally runs closer to the sustained motion the philosophy always described.

That is the real change. Not a binary from impossible to possible. A practitioner's craft that always worked, finally able to run the way it was always meant to.

That's greenfield. The next post in this series turns to brownfield, where the math is different, the risks are higher, and the compression lives somewhere completely different in the lifecycle.