The Observation

During a recent project rebuilding a CMS permission system, something became obvious that I hadn't fully articulated before.

The common assumption about AI-accelerated development is that the time savings come from AI writing code faster than a human. That's true. But it's the smaller part of the equation.

The larger savings come from what happens before any code is written.

We had 189 access checks to implement across more than 30 files. Two approaches were possible:

Approach A: Code-first. Hand AI a file. Let it read, understand, generate changes. Review. Deploy. Discover another file that needs changes. Repeat. Each file requires AI to reason about context. Each discovery adds another cycle. It's like playing whack-a-mole. You keep repeating the cycle, fixing errors until you get it right. Compared to before AI, this cycle is compressed, but you're still running through lots of iterations. Faster chaos is still chaos.

Estimated time: 12 to 20 hours.

Approach B: Planning-first. Map every enforcement point before touching any code. Document file, line number, current state, required change. Identify the three patterns that cover 90% of cases. Organize into phases. Then hand AI the map and let it execute mechanically. This approach compresses the timeline in an organized way. No whack-a-mole. No surprise discoveries mid-stream.

Estimated time: 5 to 9 hours.

The code generation time was identical in both approaches. Everything else was smaller when planning came first.

The discovery, the decision-making, the rework from missed touchpoints. All of it collapsed because the planning was done upfront, systematically, by someone who understood the system.

The Historical Parallel

This pattern has happened before.

Before the assembly line, skilled craftsmen built entire automobiles. One person or a small team took raw materials and produced a finished car. The skill was distributed across the entire process. Discovery, decision-making, and execution all lived in the same hands.

Then Ford changed the model.

The assembly line didn't eliminate skill. It relocated it. The planning became where the expertise lived. How to break the work into steps. What sequence. What tolerances. What quality checks. The execution became standardized, repeatable, and dramatically faster.

Workers on the line didn't need to understand how to build an entire car. They needed to execute their step correctly. The orchestration happened upstream.

The skill moved from hands to planning.

The Uncomfortable Implication

AI-accelerated development is following the same pattern.

When I mapped those 189 access checks before writing any code, I was doing the work that AI cannot do independently. AI can read files and generate changes. It cannot step back and ask: "What's the most efficient way to approach this entire system?" That question requires understanding business context, risk profiles, and relationships between components that aren't visible in any single file.

But once that map exists? The execution becomes mechanical. AI handles it in seconds per file. A less experienced developer could review and deploy the changes with clear guidance. The "figuring out" part, which used to be a significant part of a mid-level developer's value, has been absorbed into the planning phase.

This is uncomfortable to say out loud:

The execution skill is being commoditized.

Not eliminated. Commoditized. There's still work to be done. But the premium shifts upstream. It shifts to whoever can see the whole system, identify the patterns, and create the plan that makes AI execution trivial.

80% Autonomy. 20% Taste.

I recently saw a post about a company called Polsia. One person, 2,710 active businesses, $2M annual run rate, no employees. The founder describes his model as "80% autonomy, 20% taste." AI handles 80% of operational work. The human provides 20% of judgment, curation, and direction.

When I read that, it caught my attention immediately. That ratio is my theory. It's the rule I follow.

Interestingly, I believed this long before AI entered the picture. If you invest in planning and design upfront, development time compresses. That was true when humans did all the work. What's changed is that AI now compresses both sides of the equation. The planning and design phase gets faster. The development phase gets even faster, kind of like the assembly line where tools and automation moved implementation at a fraction of the speed versus manual installation. The ratio holds, but the absolute time shrinks across the board.

In the CMS project, the planning was maybe 15 to 20 percent of the total timeline. But it determined everything else. Without it, the AI would have churned through files, generating technically correct changes that missed the architectural point. With it, AI execution was nearly mechanical. And fast.

The 20% isn't just oversight. It's the work that makes the 80% worth doing.

What This Means for Developers

Here's where it gets real.

If you're a developer whose primary value is "I can figure out what needs to change and then change it," that job is being split in two. The "figure out" part is becoming more valuable. The "change it" part is becoming faster and cheaper.

This isn't a layoff prediction. It's a skill shift.

The developers who move upstream, who can map systems, identify patterns, sequence work, and define test criteria, will have enormous leverage. One senior architect with AI support can do what used to require a team.

The developers who stay downstream, waiting for tasks to be handed to them, executing without understanding the system, are competing with AI on execution speed. That's not a winning position.

The Honest Take

I don't think this is good or bad. It's a shift.

The assembly line didn't destroy the automotive industry. It transformed it. New roles emerged. The total output exploded. Some skills became less valuable. Others became essential.

The same thing is happening in software development right now.

The question isn't whether AI will change the work. It's whether you'll be the one creating the plan or the one executing it.