The Scope Compression Hypothesis

For years, software teams measured work with the same buried assumption: more scope means more time.

We dressed it up. Story points. Epics. Engineering hours. Complexity estimates. Sprint capacity. Underneath every planning ritual sat one equation.

More work equals more people, more time, or both.

AI has quietly broken that equation. Not because software suddenly became easy to build, but because the constraint moved.

Working faster was the wrong explanation

The first few times I built products with AI agents, I assumed I was simply working faster. After enough projects, that explanation stopped holding.

A feature that would have taken a week now took hours. An entire sprint’s worth of implementation stopped feeling materially different from a single feature. Expanding the scope barely changed the delivery date. Instead of asking “can we fit this into the sprint?” I kept asking “why not build the whole thing?”

That question forced me to rethink what scope actually means.

The old model was linear

Traditionally, software delivery was constrained by production capacity. Every additional feature was additional engineering effort. More code meant more implementation time. Scrum, Kanban, and most delivery frameworks were built on that reality. Story points became rough proxies for engineering hours because human effort was the dominant variable.

You can write the old model as a sum. Delivery was the total of the work:

delivery time ≈ Σ (task time)

Double the scope and, give or take, you doubled the time. Linear scaling. The central warning of The Mythical Man-Month — that you cannot simply add people to make a late project ship sooner¹ — is a story about the friction hiding inside that sum.

AI made implementation parallel

AI changes the relationship. Implementation has become massively parallel.

Instead of one engineer moving through tasks one after another, dozens of specialized agents work at once across the system. Authentication, APIs, frontend components, database migrations, documentation, tests, infrastructure, all progressing simultaneously.

So generation stops behaving like a sum and starts behaving like a maximum:

generation time ≈ max (task time)

If ten agents each take one feature, they finish around the same wall-clock moment. The limiting factor is no longer the amount of work. It is the longest branch of work.

That is a very different optimization problem, and it is not a new one. It is the mathematics of parallel execution: critical-path analysis, Brent’s theorem, the difference between the total work and the longest dependent chain.²

The human didn’t disappear. The human moved.

Here is the catch the speed story misses. You don’t remove the person. You relocate them.

No matter how many agents generate code, a senior engineer still reviews the architecture. Someone still validates the business logic. Someone still performs user acceptance testing. Security still signs off. Product still decides whether the implementation solves the problem.

Those activities refuse to scale at the rate generation does. So the equation becomes something like:

delivery ≈ AI generation + human verification

where generation trends toward a near-constant and verification dominates.

Ironically, the faster AI becomes at producing software, the more valuable human judgment becomes. Anthropic’s study of roughly 235,000 Claude Code users found exactly this shape: domain expertise, not a software-engineering background, predicted who got good outcomes, and when a session hit trouble novices abandoned it about three times as often as experts.³ The bottleneck didn’t vanish. It moved to the person who knows what “correct” looks like.

This is Amdahl’s Law wearing a new hat

If you have ever studied parallel computing, this will feel familiar. Amdahl’s Law says a system speeds up only as much as its sequential bottleneck allows.⁴ You can parallelize the parallel part all you want; the serial remainder sets the ceiling.

Coding became parallel. Review did not. Testing partially did. Architecture partially did. Acceptance did not at all.

So throughput stops being a function of total work and becomes a function of the sequential work:

speed ≈ 1 / sequential work — not 1 / total work

Google’s own research on scaling agent systems lands in the same place from the other direction: piling on more agents hits a ceiling and can even degrade results, because coordination — merging, reconciling, and validating parallel output — carries its own tax.⁵ More agents is not more delivery. Past a point, it is just more to verify.

Delivery is starting to look like a distributed system

This reminds me less of traditional software engineering and more of distributed computing. Distributed systems rarely spend most of their time executing work. They spend it coordinating, synchronizing, validating, and merging parallel execution.

AI-generated software increasingly behaves the same way. The hard part is no longer generating code. It is merging confidence.

Which is why the 2025 DORA report reads the way it does. AI adoption is nearly universal and most developers feel faster, yet a large share still don’t trust the code the models produce, and the teams that actually benefit are the ones with strong internal platforms, clear workflows, and real review discipline.⁶ AI amplifies the system it lands in. If your verification is weak, faster generation just gets you to the bottleneck sooner.

Scope compression

Put it together and you get something worth naming. Call it the Scope Compression Hypothesis:

As software implementation becomes parallelized by AI agents, delivery time becomes increasingly independent of implementation scope and increasingly dependent on fixed human verification cycles. Productivity shifts from being creation-limited to approval-limited.

Scope is compressing. Not in the sense that projects get smaller, but in the sense that ambitious projects converge toward similar delivery timelines. Whether the backlog holds three features or thirty, the dominant cost is often no longer writing the software. It is building enough confidence to release it.

Our planning systems haven’t caught up. Sprint planning, estimation ceremonies, capacity planning, resource allocation, all of it still assumes implementation is the expensive part. That is why so many AI-assisted teams report that estimation has gone strangely unreliable. Estimation isn’t getting worse. The variable we spent decades measuring is simply no longer the one that determines delivery. This is the same lesson the SPACE work taught about productivity: the moment you collapse a multidimensional reality onto a single proxy, you start making decisions on the wrong number.⁷

What the best teams will optimize for

If this holds, software organizations will eventually stop optimizing for engineering capacity and start optimizing for verification throughput. The question moves from “how much can we build?” to “how much can we responsibly approve?”

The highest-leverage engineers will not be the fastest builders. They will be the fastest validators. The best engineering organizations will not be the ones that generate the most code. They will be the ones that approve the most change with the highest confidence.

That feels like a subtle distinction today. I suspect it becomes one of the defining characteristics of software engineering in the AI era.

A reading list

A friend sharpened most of this thinking while we argued about it, and he handed me a syllabus on the way out. Here it is, roughly the order I’d read it in.

Foundations

• The Mythical Man-Month, Frederick Brooks — why adding people doesn’t linearly shorten a project.¹
• Peopleware, DeMarco & Lister — productivity as a human system, not a coding-speed problem.⁸
• Accelerate, Forsgren, Humble & Kim — the DORA research on what actually drives delivery performance.⁹

Parallelism

• Amdahl’s Law and Gustafson’s Law — the ceiling on parallel speedup, and the counterargument.^{4 10}
• Critical Path Method and Brent’s theorem — total work versus the longest dependent chain.²
• Fork-join parallelism and MapReduce — how systems split work, then merge it.¹¹

Modern AI engineering

• DORA, 2025 State of AI-assisted Software Development.⁶
• The SPACE of Developer Productivity.⁷
• Google, Towards a Science of Scaling Agent Systems.⁵
• Anthropic, Agentic Coding and Persistent Returns to Expertise.³

If I had to compress the whole argument into one line: AI turned estimation from a production problem into a verification problem, and most of our planning is still answering the old question.

---

References