Part 1 — Where You Stand

The tireless coworker

Imagine you are given a colleague with the properties the industry has been describing for three years.

They never tire. They work through the night and the weekend. They have read essentially everything and can recall it instantly. They write code faster than you can read it, and they will take on the tedious parts you have been avoiding since March.

Now hand them a project that represents ten years of your own effort. Suppose — conservatively, relative to how this is marketed — that they work at one hundred times your rate.

You would expect that project finished in about five weeks.

That is not a strawman of the pitch. That is the pitch, stated as an arithmetic consequence. And it produces an obvious, checkable prediction, which almost nobody seems to be checking:

Where is the wave of finished projects?

Projects are supposed to end

This is the part that gets lost, so it is worth saying plainly.

Anyone who has worked on software for a while has watched a project mature. The feature set stops growing. The bug rate drops and the architecture settles. Eventually there is genuinely not much left to do, and the team moves to something else. That is not failure. That is what done looks like, and it is the normal terminal state of a well-run piece of software.

So if a technology multiplies engineering output by a large factor, the first-order observable consequence is not that people write more code. It is that more things reach that terminal state, sooner. Backlogs burn down. Long-open issues close. The research gets finished and the thing ships and stops needing you.

That is the claim on the tin. It should be visible from orbit.

I cannot measure whether it is happening — which, after Chapter 7, you will recognize as a specific and damning kind of statement. But the intuition is that it is not, and the available evidence does not contradict the intuition.

If the capability is real, why does nothing seem to finish?

What would count as evidence

Chapter 7’s discipline applies to this question before anything else, because an unfalsifiable complaint is worth nothing.

If the pitch were true at scale, we would expect to observe project cycle times falling sharply, backlogs shrinking rather than being reprioritized, long-standing open issues in major repositories closing, and research output per researcher rising. The cleanest signal would be a rising ratio of projects completed to projects started.

Most of those are not measured anywhere in a form you could check. That absence is itself one of the findings of this chapter. An industry making an extraordinary productivity claim has largely declined to instrument the outcome the claim predicts, and has instead instrumented the activity: tokens generated, lines accepted, pull requests merged.

Those are measures of motion. None of them is a measure of arrival.

What the data does show

Three sources, none decisive, pointing the same direction.

Delivery metrics. Google’s DORA research is the longest-running serious measurement of software delivery. Its 2024 report estimated that every 25% increase in AI adoption was associated with roughly a 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability. A year later the picture changed: in the 2025 report the throughput sign flipped positive — teams got faster — while stability remained negative (DORA, 2024; DORA, 2025).

Report both years, because the shift matters and because a book that quotes only the 2024 number is doing the thing Chapter 2 warned about. The durable finding across both is the stability one: more code arrives, and more of it comes back.

Developer time. METR’s randomized trial, from Chapter 2: experienced developers were measured 19% slower with AI on real tasks in their own repositories while believing they were 20% faster — a result METR itself later qualified after finding selection bias, with newer estimates suggesting speedup but crossing zero (METR, 2025; METR, 2026).

What happens to the code. GitClear analyzed 211 million changed lines from 2020 to 2024 across private repositories and 25 large open-source projects. They report that code blocks with five or more duplicated lines increased eightfold during 2024; that churn — lines revised or reverted shortly after being written — rose from 4.5% to 5.7%; that the share of changed lines tied to refactoring fell from 25% in 2021 to under 10% in 2024; and that 2024 was the first year in which copy-pasted lines exceeded moved lines (GitClear, 2025).

That last source needs a clear label: GitClear is a developer-analytics vendor publishing its own research, not a peer-reviewed study, and it has a commercial interest in the topic. The dataset is large and the methodology is stated, which is more than most industry research offers. Treat the direction as suggestive and the specific multiples as unverified.

Put together, the composite picture is not “nothing is happening.” It is stranger than that: more code, arriving faster, less of it converging. Churn is the tell. Churn is work being redone, which is the precise opposite of work being finished. A codebase where refactoring collapses and duplication multiplies is accumulating rather than maturing — moving away from the terminal state, not toward it.

Five explanations

The natural reading offers two possibilities, and both are live: either the intelligence is not what it is sold as, or it is being used wrong. Neither is more comfortable than the other, and this book takes both seriously.

But I think there are five, and I think the third is doing most of the work.

One: it is not as capable as sold. Partly true and increasingly less so. Benchmarks move fast; the frontier is real. This explanation gets weaker every year and it cannot account for the shape of what we observe, which is high activity rather than low capability.

Two: it is being used wrong. Certainly true — this is the premise of the entire book. But “used wrong” needs a mechanism, or it is just scolding.

Three: coding was never the bottleneck. This is the mechanism, and it is arithmetic.

Four: scope expands to consume the capacity. Real, uncomfortable, covered below.

Five: the complements have not been built yet. Also real, well-studied, and it has a name.

The arithmetic of the disappointment

Amdahl’s law was written about parallel computing in 1967 and it answers this question exactly.

If some fraction p of a task can be accelerated and the rest cannot, then no matter how much you accelerate that fraction — even infinitely — total speedup is capped at 1 / (1 − p).

Now apply it. Suppose writing code is 30% of the elapsed time of a real software project. The rest is deciding what to build and whether it is the right thing, waiting for an answer, integrating with a system nobody fully understands, handling what staging reveals, verifying it works, and getting someone with authority to agree it is finished.

Give yourself the hundred-times coworker. Make them infinitely fast. Amdahl caps your project at:

1 / (1 − 0.3) = 1.43×

Not one hundred. Not ten. A shade over forty percent faster, in the limit of an infinitely fast programmer.

The structure of the cap, as a flow:

    flowchart TD
    PR["project elapsed time"] --> G["generation · share p<br/><i>100× faster → ~zero</i>"]
    PR --> S["serial remainder · share 1−p<br/><i>intent · authority · verification · frontier judgment</i>"]
    G --> F["finished"]
    S --> F
    F --> CAP["speedup capped at 1/(1−p)<br/><i>p = 30% → 1.43×</i>"]
  

The shape of the cap is worth seeing once. These shares are illustrative, not measured — supply your own p from step 4 of the exercise below:

Coding share p (illustrative)	Cap 1 / (1 − p)
10%	1.11×
20%	1.25×
30%	1.43×
50%	2.00×
90%	10.00×

Two readings fall out directly. Even if half of elapsed project time is writing code, an infinitely fast programmer only doubles the project — the remaining half still arrives at human speed. And if faster generation enlarges review and integration so the remainder grows from 70% to 80%, the cap falls from 1.43× to 1.25×: the ceiling drops where the intervention adds work to the part it cannot accelerate.

That is the whole puzzle, resolved in one line. The intuition — they do 100× my work, so it takes a hundredth of the time — silently assumes the project is made of one kind of work. It is not. It never was. And if the accelerated fraction is smaller than 30%, which for many projects it is, the ceiling is lower still.

The same arithmetic governs cost, and this book eventually measures a small instance of it. Chapter 28 runs forty extraction items two ways under a declared scenario of $5 for every question put to a person. One arm spent about half a cent on models, the other about three cents — a sixfold difference. Yet the totals were $35.01 and $45.03, and almost all of that gap came from two fewer questions to people. Making the model work six times cheaper barely moved the bill, because the model work was never most of it.

Worse: the 70% is not constant under the intervention. DORA’s stability finding and GitClear’s churn finding both suggest that accelerating generation increases the non-accelerated fraction — more code means more review, more integration surface, more places for defects to hide. If generation gets faster while review and integration get larger, the two effects partly cancel. DORA’s 2024 throughput decline, beside GitClear’s rising volume and churn, is consistent with that; the 2025 throughput recovery is a reminder that “consistent with” is as far as this evidence goes.

And now the part that matters for this book. What is the 70% made of?

The unaccelerated work	Chapter 2’s name for it
Deciding what should be built, and what done means	Intent
Agreeing that this is the right thing, and permitting it	Authority
Establishing that it actually works	Verification
Knowing when the model is the wrong tool	Frontier judgment

The bottleneck consists, almost entirely, of the four jobs Chapter 2 argued cannot leave the human. That is not a coincidence and it is the thesis of Part 1 arriving from a different direction: we accelerated the one part of the work that was never the constraint, and the constraint is made of exactly the things that cannot be delegated.

Contemporary vendor evidence fits the same arithmetic, read with its limits. In September 2026 OpenAI reported that by mid-August its research organization was consuming an estimated 3.1 agent-workdays for every human workday, with the median researcher using over $600/day of inference at API prices; researchers wrote more code and ran more experiments, with experiments per active experimenter at an all-time high — while OpenAI itself noted that “as automation progresses, the tasks which are least automatable will take on a larger share of researcher effort and will become the important bottlenecks” (OpenAI, 2026). That is Amdahl from inside the lab: generation accelerated, the serial remainder dominates sooner. Bound it as the source demands: internal self-report, correlational (compute also grew), no demonstration of whole-project acceleration or a wave of finished research — which is precisely why this chapter insists on measuring arrival, not motion.

Which is also the good news, and the reason to keep reading. If the bottleneck is intent, authority, and verification, then engineering those is where the remaining leverage is. That is what the next five parts build.

The respectable version of “too early”

There is a serious economic explanation that is neither “it’s fake” nor “you’re holding it wrong”, and it deserves its place.

Brynjolfsson, Rock, and Syverson showed that general purpose technologies require large complementary intangible investments — process redesign, new skills, reorganized workflows — and that these investments are costly, take years, and are poorly captured in national accounts. The result is a J-curve: measured productivity looks flat or worse during the investment period, then rises as the intangibles pay off. Adjusting for intangibles related to computer hardware and software put total factor productivity 15.9% higher than official measures by the end of 2017 (Brynjolfsson, Rock & Syverson, 2021).

This fits what we are seeing almost too neatly. Early GPT deployment shows disappointing or negative measured productivity, not because the technology is inert, but because the complements have not been built.

But do not read that as “wait and it will come.” Read the mechanism. The complement is the work. Somebody has to redesign the process, build the measurement, restructure who decides what, and figure out where the model belongs. That does not arrive on a schedule; it is engineering, and it is unglamorous, and it is largely what this book is about. The J-curve is not a prophecy. It is a description of a bill that somebody has to pay.

And nobody may want the project to end

The uncomfortable explanation, stated without moralizing, because it is probably part of the answer.

Completion is not universally desirable to the people doing the completing. A finished product does not need a team. Budgets renew against ongoing work, not against work that ended. Ambition is rewarded and closure rarely is. In most organizations, the forcing function for declaring something done was never satisfaction — it was exhaustion of capacity. There was no more time, so the scope closed.

Remove that constraint and the natural result is not a wave of completions. It is a wave of more ambitious projects that also do not finish. Cheaper capacity gets spent on scope, not on arrival — the same pattern as every cheapening input in economic history, and the same one Chapter 6 flagged when it noted that falling token prices do not produce falling bills.

If you want things to finish, something other than running out of time has to make them finish. Which means somebody has to write down what done means, in advance, and then hold the line — Chapter 4’s acceptance criteria, promoted from ticket scale to project scale.

The same pressure applies to the tools you build for yourself, with less resistance, because nobody else has to agree to the scope. A personal tool that keeps growing is not finished and not failing; it is unbounded. The discipline is the same at a smaller scale: write down what each change is for, check it, and keep it only if it did what you wrote. Chapter 30 turns that into a loop.

Measure arrival, not motion

The actionable version of this chapter is short.

Almost every AI productivity metric in common use measures motion: tokens, suggestions accepted, lines written, PRs opened. Not one of them measures arrival. A team can double every motion metric while finishing strictly less, and the churn and stability data suggest that is not hypothetical.

So instrument the outcome the claim predicts:

• Started versus finished, per quarter, with “finished” defined in writing before the work begins.
• Cycle time from committed to closed — and closed means nobody touched it again, not merged.
• Rework rate: what fraction of work is revisited within thirty days.
• Backlog age, not backlog size. A backlog that stays the same size while its median item gets older is not being burned down.

These are Chapter 7’s ladder applied one level up: the frozen task set becomes the project portfolio, and the mechanical check becomes a definition of done recorded in advance.

Do this now

Thirty minutes with your issue tracker. Count arrivals, not motion.

1. For the last four quarters, count items started and items finished — where finished means closed and not reopened or reverted within thirty days.
2. Plot the ratio. Mark on the same timeline when your team adopted AI tooling.
3. Now compute the same ratio for the four quarters before adoption.
4. Separately: write down your honest estimate of what fraction of a typical project’s elapsed time is writing code. Call it p. Compute 1/(1 − p).

That last number is the maximum speedup available to you from an infinitely fast programmer. Compare it to what you were expecting. If step 2 shows no change, step 4 probably explains most of why — and the gap between them is the part of your process that is actually worth engineering.

Bring the number to whoever is budgeting your AI spend.

Failure modes

• Measuring motion and calling it productivity. Tokens, suggestions, and drafts all rise while completions do not.
• Expecting linear speedup from a nonlinear system. Amdahl caps you well below the coworker’s individual multiplier.
• Ignoring that acceleration enlarges the unaccelerated part. More generated code means more review and integration surface.
• Treating churn as neutral. Churn is work redone. A rising churn rate is the signature of a project moving away from done.
• Quoting one year of DORA. The 2024 and 2025 findings differ; the stability finding is what persists.
• Reading the J-curve as permission to wait. The complementary investment is the work, and somebody has to do it.
• Assuming everyone wants closure. Removing the capacity constraint removes the main historical reason things ended.

What this chapter established

• The sales pitch makes a checkable prediction — more projects reaching completion — and the industry has instrumented activity instead of arrival.
• What evidence exists points to more code, moving faster, converging less: AI adoption associated with reduced delivery stability across two DORA reports, a measured developer slowdown later qualified by its own authors, and vendor data showing rising churn and duplication with collapsing refactoring.
• Amdahl’s law is the arithmetic of the disappointment. If coding is 30% of project time, an infinitely fast programmer yields at most a 1.43× project speedup — and the unaccelerated 70% may grow under the intervention.
• That 70% is composed almost exactly of intent, authority, verification, and frontier judgment: the four jobs Chapter 2 argued cannot be delegated. We accelerated the part that was never the constraint.
• The J-curve is the serious version of “too early”: general purpose technologies need complementary intangible investment, measured productivity dips first, and the complement is the work — not something to wait for.
• Capacity exhaustion was historically what forced projects to close. Removing it removes the forcing function, and scope expands to fill the space.
• Measure arrival: started versus finished, cycle time to genuinely closed, rework rate, and backlog age.

Next

Part 1 is done. It has been argument, because the arguments determine what is worth building: where to stand, which operations may be stochastic, which terrain repays effort, what keeps the reviewer honest, what it all costs, how you would know if it worked, and what the bottleneck actually is.

The answer to that last one decides the shape of everything that follows. If completion is gated by intent, authority and verification rather than by generation, then a runtime for AI work is not a wrapper around a model. It is a machine for making intent explicit, authority enforceable, and verification cheap.

So the next chapter stops arguing and states the system: one that works wherever you happen to be, never loses context, remembers everything it has done, reaches for the best cheapest model it can actually get, and reviews every contribution it makes. Five properties — each one forced by an argument in Part 1, and each one in tension with at least one of the others.

Continue with One Runtime, Many Windows.

References

• DORA / Google Cloud. Accelerate State of DevOps Report 2024. https://dora.dev/research/2024/dora-report/
• DORA / Google Cloud. Announcing the 2025 DORA Report. https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
• Joel Becker, Nate Rush, Elizabeth Barnes, and David Rein (METR). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089, 2025. https://arxiv.org/abs/2507.09089
• Erik Brynjolfsson, Daniel Rock, and Chad Syverson. The Productivity J-Curve: How Intangibles Complement General Purpose Technologies. American Economic Journal: Macroeconomics, vol. 13, no. 1 (2021), pp. 333–372. https://doi.org/10.1257/mac.20180386
• GitClear. AI Copilot Code Quality: 2025 Data Suggests Downward Pressure on Code Quality. Vendor research; not peer-reviewed. https://www.gitclear.com/ai_assistant_code_quality_2025_research
• Gene M. Amdahl. Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities. AFIPS Spring Joint Computer Conference, 1967, pp. 483–485. https://doi.org/10.1145/1465482.1465560
• OpenAI. Research acceleration: The view inside OpenAI. 6 September 2026. https://openai.com/index/research-acceleration-view-inside-openai/ — Vendor self-report of internal usage; correlational.