Where AI Compression Actually Lives

How the Software Development Lifecycle Has Shifted (Part 1 of 5)

Even the most basic carpenter plans before building.

Before any wood gets cut, there are measurements taken. Materials chosen. Load paths considered. A sketch on paper, even if it's rough. Nobody walks onto a job site and starts cutting boards and hopes a house emerges. Even something as simple as a shelf gets measured first. The plan is what makes the cuts work.

Software development has always followed the same shape in principle. Requirements (including specifications), implementation (including development and unit testing), QA, then delivery. The stages are simple. The problem has never been the stages. The problem has always been that the bulk of the real work lived in implementation, where gaps got discovered, change requests came in, and integration surfaced everything the spec missed.

That made software estimates notoriously unreliable. House construction is predictable, weather delays aside, because the gaps get caught before the foundation is poured. Software construction was unpredictable because the gaps got caught when people tried to make the pieces fit together, three months in, with the schedule already committed.

The lifecycle was correct. The estimate failed because the front of the lifecycle was under-invested. Pre-AI, that under-investment was rational, because every hour spent specifying was an hour not coding, and coding was the constraint. Teams chose the schedule risk over the upfront cost.

AI changes that math.

The Cost Curve Inverts

In conventional software delivery, the cost curve is roughly:

• Requirements gathering: 5 to 10 percent of total effort
• Tech spec and architecture: 5 to 10 percent
• Implementation: 50 to 60 percent
• Testing, integration, rework: 20 to 30 percent

That distribution is the visible expression of the problem we just named. The front of the lifecycle gets 10 to 20 percent of the effort. The back half lives in implementation and rework. Schedules slip in the back half because gaps surface in the back half.

AI-accelerated work breaks that equation. With implementation no longer the bottleneck, the front of the lifecycle gets the investment it always deserved. Gaps surface in the spec, where they're cheap to fix, instead of in integration, where they're expensive. The cost curve inverts:

• Requirements gathering: 25 to 40 percent
• Tech spec and architecture: 20 to 30 percent
• Implementation: 15 to 25 percent
• Testing, integration, rework: 15 to 20 percent

Time invested in the spec is no longer competing with implementation time. It directly multiplies code generation throughput. A well-specified module with a defined schema, clear inputs and outputs, and documented acceptance criteria gets generated correctly on the first or second pass. An ambiguous one produces code that has to be thrown away and re-prompted.

That inversion is what makes the dramatic timelines possible. Not the model. The model is downstream.

Two Things Become Obvious

I work on both kinds of projects. Greenfield platforms built from an empty canvas, and brownfield remediation on systems that have been in production for years. On both, AI is genuinely making development faster than I have ever experienced in 30 years of doing this work. But once you see where the compression actually lives on each, two things become obvious.

First, the architect mindset matters more than it used to, not less.

Second, we still need developers. We just need them doing different work than they used to do.

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.

Why the Architect Mindset Matters More Now

In the old lifecycle, the architect's job was upstream of the bottleneck. Specification mattered, but implementation was where the project lived or died, and a strong implementation team could compensate for a weak spec. The bottleneck was code production, and code production absorbed the consequences of unclear thinking.

That cushion is gone.

With AI handling implementation, the spec is the bottleneck. Unclear thinking shows up immediately in unclear code, and unclear code in a brownfield codebase shows up as a production incident. The architect's job has moved from "set the direction and trust the team" to "be the direction the AI executes against." Better tools have not made the blueprint less important. They have made the blueprint the entire game.

Brownfield is different and worth saying clearly, because the same compression principle does not apply identically. Even when the analysis is compressed and excellent, implementation on a brownfield system is not simple. There is constant back-and-forth between what the analysis predicts and what the code actually does, because brownfield systems carry decisions and behaviors that aren't fully documented anywhere. Analysis compresses dramatically. Implementation does not. The edits stay surgical, and surgical work belongs to an experienced developer who can hold the codebase's idioms and risks in their head while making each change.

That asymmetry is what most of the AI development discourse keeps missing.

What's Coming in This Series

This is the first of five posts that walk through where AI compression actually lives across the kinds of projects I work on. Each post stands on its own and can be read independently.

The next post takes greenfield projects head-on. The argument, in advance: a philosophy I've held for decades, the idea that with proper planning the rest is just hammers and nails, has finally become possible to execute. AI is the missing piece that lets the spec actually get complete before the build starts.

The post after that turns to brownfield work, where the math is different and the risks are higher. The compression is real but it lives in analysis, not in code generation, because the production system underneath does not forgive sloppy edits.

The fourth post addresses a project category that, in the old economics, almost never made sense: stack migration. Rebuilding a working system on a different technology stack used to be a year of effort, minimum, and a hiring problem on top of that. AI changed both, and stack migration is going to be one of the busier corners of enterprise software work over the next several years.

The final post pulls everything together. How the three project types compare, what the scoping implications are, and the position I have arrived at after a year of working with AI on real client projects: AI is not ready to replace developers. It has changed almost everything about how the work gets done. It has not changed whether the work needs experienced people doing it.

The Closing Thought for This Post

The lifecycle hasn't fundamentally changed. Requirements still come first. Implementation still has to happen. Testing still matters. Delivery still has consequences when something breaks.

What changed is where the bottleneck lives, which means where the human leverage lives. The bottleneck moved from the keyboard to the blueprint. From typing to thinking. From producing output to deciding what the output should be.

That's not a small change. It's the biggest shift I have seen in three decades of building software. And it puts the architect mindset, the practice of thinking carefully about what should be built before any of it gets built, at the center of the work.

That's the foundation. The next four posts walk through what that looks like in practice across different kinds of projects.