Putting It Together

Even the most basic carpenter plans before building.

Four posts ago, that's where this series started. The carpenter analogy was doing real work even then, because the principle it points at is durable across every kind of construction work: the plan is what makes the cuts work. Better tools don't replace the blueprint. They make the blueprint more important, because better tools amplify whatever direction they're given, including the wrong direction.

That's been the through-line of this entire series. The architect mindset. The hammers-and-nails philosophy. The 99 percent problem. The structural unlock that makes stack migration suddenly viable. All of it pointing at the same conclusion, which I want to make explicit in this post.

What Each Project Type Taught Us

The previous four posts each made a different argument, and they fit together into a single picture.

Part 1 laid out the lifecycle thesis. Software estimates failed pre-AI because the front of the lifecycle was under-invested, and that under-investment was rational under the old economics where coding was the bottleneck. AI changed the bottleneck. The front of the lifecycle now gets the investment it always deserved, which is what makes everything downstream possible.

Part 2 walked through greenfield work. The argument: a philosophy I have practiced for decades, that with proper planning the rest is just hammers and nails, can finally run uninterrupted. Greenfield builds were always executable, but the rhythm was stop-start: build, hit a gap, pause, discuss, pivot, re-spec, then back to the build. AI compresses the spec phase enough that the gaps surface before the build starts. The build finally runs the way the philosophy always intended.

Part 3 covered brownfield work. The argument: the compression is real but it lives in analysis, not execution. An analysis can be 99 percent accurate about where to make edits, and the edits themselves can be locally correct, and the system can still fail because brownfield codebases carry coupling the analysis cannot fully see. The risk is ripple, not edit accuracy. The implementation phase stays human-paced because surgical discipline is what catches the cascades the analysis missed.

Part 4 introduced stack migration as a third category. The argument: stack migration was rarely a question of whether the work was worth doing. It was whether organizations could afford the timeline and commitment. AI changes this in two directions at once. It removes the language barrier so new developers can be hired into legacy stacks. And it lets existing teams safely migrate to a new stack without losing the business knowledge they hold, because the spec for the new system gets produced from the system they already understand. The choice between hybrid modernization and full migration is now decided by situation, not by who can be hired or who will be lost.

Three project types. Three different shapes of compression. One unifying principle: the human's job moved upstream, the AI's job is execution, and the work that doesn't carry production risk is what compresses.

The Head-to-Head

Now that all three project types have been laid out, the comparison earns its place.

On greenfield, AI compresses execution. The cost curve inverts because implementation stops being the constraint. The architect's spec becomes the leverage point, and the code generation collapses around it. The thinking happens upstream, the build happens downstream, and the build looks like hammers and nails finally working the way it always should have.

On brownfield, AI compresses analysis. The cost curve doesn't invert because the edits still have to be surgical. The leverage lives upstream of the keyboard. The inventory, the impact map, the remediation plan, the post-mortem. AI handles all of that at twenty times human speed. But the keyboard work itself, the actual edits, stays human-paced because every line touches a system with production behavior to preserve.

On stack migration, both compressions stack. The new codebase is greenfield-shaped on the build side. The existing system is the spec, brownfield-shaped on the analysis side. AI compresses both halves simultaneously. What remains is the testing and cutover phase, which is the part of the work where the consequences of being wrong are real and the rate-limiting step belongs to humans.

A few specific contrasts worth naming across all three:

The role of the spec is different in each case. On greenfield, the spec is forward-looking, written before the system exists, and serves as the source of truth for what gets built. On brownfield, the spec is backward-looking, describing what the existing system does, where the gaps are, and what needs to change. On stack migration, the spec is hybrid: the existing system describes the behavior, the new system describes the architecture, and both are inputs to the build.

The role of the AI is different in each case. On greenfield, AI is an execution partner. The architect specifies, the AI builds, the architect reviews. On brownfield, AI is an analyst and plan author. The AI maps the system, identifies the changes, drafts the remediation plan. The architect or experienced developer then makes the actual edits with surgical care, because the AI's edit-risk on a brownfield codebase is unacceptable. On stack migration, AI plays both roles in sequence: analyst on the legacy side, builder on the new side, and the human supervises the handoff between them.

The role of the human is different in each case, but the same in one critical respect. The human always owns the architectural decisions, the validation against expected behavior, and the production cutover. The work the human does shifts. The need for the human does not.

The risk profile is different in each case. On greenfield, the worst case during the build is wasted time. On brownfield, the worst case is a production outage. On stack migration, the worst case is a successful build that fails to replicate behaviors the old system handled correctly, which is why the testing phase eats so much of the calendar.

The Scoping Framework

Across all three project types, the scoping implications follow the same principle: pay for the work where the human's leverage actually lives, and don't underprice the phases that AI cannot fully own.

That principle translates differently for each project type.

On greenfield, charge for the front of the project. The architectural decisions, the spec iteration, the Code Intelligence phase, all of it. That's where the eventual code generation throughput is determined. Clients who try to shortcut planning to "get to coding faster" are optimizing the wrong constraint. The Code Intelligence phase is not overhead. It is the leverage point. Pricing it as overhead is leaving the entire compression on the table.

On brownfield, scope context-loading explicitly. The first weeks of a brownfield AI engagement are not slow because the team is slow. They are slow because the AI cannot generate good analysis until it understands the existing system. That work is real and it needs a line item. Pricing should reflect it.

On stack migration, price against the new economics. A migration that used to take a year and now takes three months is not just a faster project. It is a different category of project, with different ROI math and different risk profile. Pricing should be short on the build, generous on the testing, and explicit about the cutover.

Match the methodology to the project type. Greenfield AI-accelerated work is a fundamentally different product than brownfield AI-accelerated work, and stack migration is different from both. Selling them as the same engagement creates expectations no project type can meet correctly, and underprices the work that should command a planning premium.

Same human in every case. Same AI in every case. Completely different shape of the work.

What This Means for "AI Replacing Developers"

I have to say this plainly because the AI conversation keeps avoiding it.

Based on these projects, I am more convinced than I was a year ago that AI is not ready to replace developers.

Not less convinced. More convinced.

That sounds counterintuitive coming from someone whose practice is built around AI collaboration, so let me be specific about what changed my mind. The greenfield work convinced me that AI is dramatically faster at generating code when the spec is good. The brownfield work convinced me that "when the spec is good" is doing a lot of heavy lifting in that sentence, and that the parts of development that don't fit that description are exactly the parts where AI keeps creating risk instead of compressing time. The stack migration work convinced me that even when AI compresses both the analysis and the build, the testing and cutover phases still belong to humans because the consequences of being wrong are real.

A human still has to write the spec. A human still has to know which patterns in the codebase are canonical and which are accidents. A human still has to push back when AI proposes a plausible-sounding fix for the wrong root cause. A human still has to reject the over-engineered abstraction in favor of the three-line edit using what's already in scope. A human still has to own the production system when something breaks at 2 AM.

None of that is going away soon.

I want to be honest about what I don't know. Could AI replace developers in the future? Possible. Could that happen in less than a year? Possible. The model improvements over the past 18 months have been faster than most people in the industry predicted, and I do not have a confident bet on where the curve goes next.

What I do know is that the platforms positioned today as "build apps without developers," tools like Replit, Base44, Lovable, v0, are real and they work for the use case they target. A solo founder can ship a working MVP without writing code. That is genuinely a new capability and it is not going away.

But shipping an MVP is not the same as building enterprise software. An enterprise system carries production traffic, integrates with other systems, has compliance requirements, has security boundaries, has audit trails, has years of accumulated decisions, has implicit conventions, and has consequences when it fails. Every project I have done at that level still requires the same things AI cannot reliably do: judgment about what already exists, accountability when something breaks, and the willingness to reject AI's first answer when it's plausible but wrong.

The work has changed. The work has not gone away.

Whether that's a permanent observation or a temporary one, I cannot say. What I can say is that on the projects I work on right now, today, AI is the most powerful tool I have ever used, and it is not ready to do the job alone.

That's not a contradiction. That's the actual state of the work.

The Closing Thought

AI did not make brownfield projects safer to edit. It made the analysis dramatically faster, and the analysis is what unlocks the safe, surgical edits a human still has to perform.

AI did not make greenfield projects easier to specify. It made the act of specification economically rational by collapsing the implementation tail, which is what allows an architect to spend weeks on a tech spec without losing the project.

AI did not make stack migrations cheaper. It made them possible. Projects that were not financially defensible last year are now actively worth doing, and that shift is going to drive a wave of modernization work over the next several years.

The risk-reward asymmetry across all three project types is permanent and structural. The compression follows the work that doesn't carry production risk. Forward-looking work collapses. Production-touching work stays human-paced. Hybrid projects stack both compressions where they live, but the testing and cutover phase still belongs to humans because the consequences of being wrong are real.

The question for any team adopting AI-accelerated development isn't whether AI will compress the work. It will. The question is which part of the work, where on your project that part lives, and whether your architect can see clearly enough to make the spec hold up.

Get that wrong and the schedule slips, the system breaks, or the engagement loses money. Get it right and the math changes in your favor.

The carpenter still cuts the wood. The carpenter just spends more time reading the blueprint, because better tools make a sloppy blueprint more dangerous, not less.

That's the call worth making carefully. And it's the call that's going to define the next several years of how serious software gets built.