Coding Is Solved. So Why Is Everything Slower?

If you saw the claim that Anthropic engineers now write roughly 8x as much code per quarter as they did in 2025, and you're trying to decide whether "coding is solved" is true, here's the short version. The 8x is probably real as a volume number and close to meaningless as a productivity number. Writing code got cheap. That's the only thing that happened. And once writing code gets cheap, the thing that limits how fast you ship doesn't disappear. It moves downstream — to review, to CI, and above all to your ability to say precisely what you want.

The framing to argue with comes from Fiona Fung, who said on Lenny's Podcast that "coding is no longer the bottleneck" and that AI has "lifted the ceiling" of what people can do. Both lines are half-true in a way that matters. This walks through the mechanism so you can tell the hype from the real change, and gives you three things to do this week.

Start with the dumb question: 8x of what?

Before you reason from the 8x, ask what it counts. "Code per engineer per quarter" is a fraction: attributed diffs divided by engineer count over a window. Both halves of that fraction quietly broke.

Here's the part most people get backwards. AI coding agents don't hide behind the human by default — they tend to do the opposite. Tools like Claude Code and GitHub's Copilot coding agent commonly create commits and PRs under their own identity, or auto-append a trailer crediting the AI, e.g. Co-Authored-By: Claude <[email protected]>. So the raw attribution often points at the agent, not the person. Getting it to count as human work usually takes deliberate configuration or trailer rewriting. Which means every dashboard has made a choice — fold agent diffs into the human, keep them separate, or split them — and that choice, not any engineer, decides what "code per engineer" means. One agent session can open dozens of PRs a person never hand-typed. So the unit of measurement changed underneath you, from "code a human typed" to "code a human's fleet of agents produced." The engineer didn't get 8x faster. The engineer got a factory.

That one change can produce a step jump that looks exactly like a breakthrough. And the tell is almost always the same: the date the line hooks upward lines up with the date the internal tool rolled out.

Why the hockey-stick curve is a red flag

A real capability improvement usually shows a smooth ramp, because adoption spreads gradually across people. A line that stays flat for a long time and then suddenly hooks straight up is the classic fingerprint of a definitional change, not a real-world one.

Three usual suspects behind that shape:

• Numerator inflation — agent-authored diffs get counted under the human's name.
• Denominator shift — "engineers" versus "active committers," or a hiring wave that dilutes the count and then re-concentrates it.
• Rebased baseline — the 2025 starting number was set low.

You can't tell "we got 8x better" from "we changed the ruler" by looking at the chart. That's the whole problem with the chart.

Volume isn't value: the churn mechanism

Here's the step most takes skip. Agents work by a generate-test-revise loop. Without an external check, that loop leaks straight into your repo: code lands, then gets deleted or rewritten within days.

Track churn — lines removed or rewritten within about two weeks — and under agent workflows you'd expect it to climb, because the model tries several drafts against your codebase instead of one. Gross additions balloon. But net durable code — what still exists and works a month later — grows by much less. Take the multiples as intuition, not benchmarks: if gross volume goes up 8x, the durable, net-of-churn number underneath it can be a small fraction of that. The gap between the two is the whole point.

So gross lines of code is a vanity axis. It isn't one of the DORA metrics for a reason: it's trivially gameable. DORA started as the "Four Keys" and has since grown to a five-metric model in the official reporting, but volume was never one of them at any point — because you can inflate it without shipping anything. The axes that survive contact with reality are change-failure-rate — did the extra volume break more in production — and mean-time-to-recovery — when it breaks, how fast do you recover.

The bottleneck didn't vanish. It moved.

Now follow the logic one step past the comfortable stopping point. "Coding is no longer the bottleneck," Fung's line, gets treated as good news. But a pipeline's throughput is set by its slowest stage that can't stretch. Authorship just became elastic — near-infinite supply. The stages right after it did not get 8x capacity: human review, CI compute, the merge queue.

So the constraint doesn't disappear when you make coding cheap. It relocates to the first thing downstream that can't stretch. In practice that's human review attention. Widening the on-ramp doesn't help if the highway is jammed. You just get more cars arriving at the same jam, faster.

Little's Law: why more input can make you slower

There's a hard rule here, not a vibe. Little's Law: queue length equals arrival rate times wait time. If PRs arrive 8x faster and review capacity is flat, the queue explodes and the lead-time tail blows out.

On the ground that looks like merge queues serializing into multi-hour tails, CI bills tripling because every speculative branch triggers a full pipeline, and reviewers rubber-stamping under load — which quietly raises change-failure-rate. End-to-end time from idea to production can get worse even as code volume goes up 8x. That's the trap. The metric that went up and the outcome you care about are pointing in opposite directions.

The one move that actually raises the ceiling

The escape isn't hiring more reviewers. Human attention doesn't scale, and reviewing lines faster just means reviewing them worse. The move is to change what a human does at all.

Instead of reviewing lines, you author the verifier: executable specs, property and invariant tests, and eval harnesses the agent checks itself against before it ever touches your merge queue. Done right, the agent burns its churn internally against the harness, and only diffs that already pass surface for human judgment. That converts 8x volume from review debt into actual throughput.

Call this the shift from authoring code to authoring the check. The scarce skill stops being "can you write it" and becomes "can you specify what correct means, precisely enough that a machine can enforce it."

Where "lifted the ceiling for anyone" breaks — three places it breaks

Fung's second line — AI has "lifted the ceiling" of what anyone can do — is the one worth pushing on. It rose, but only for people who can specify. Give the same tool to a weak specifier and it amplifies the wrong direction 8x faster. It's a wrongness multiplier, not a uniform uplift. And even for strong specifiers, faster code generation doesn't touch three things that decide whether shipping more helps you.

Product judgment. Deciding what should be built is not solved by generating it faster. The agent will happily build the wrong feature 8x sooner. Cheap code makes the cost of building the wrong thing lower per unit and higher in aggregate, because now you build more wrong things. The bottleneck here is knowing which diff should exist, and no coding agent answers that question. It just executes the answer you already had.

Ownership. Someone stays accountable for agent-generated code over time — the incident at 3 a.m., the regression three releases later, the maintenance nobody scheduled. An agent writes a diff and forgets it. A human owns it for years. If the reported 8x came with no matching increase in who's on the hook when it breaks, you didn't add capacity — you added liability that's cheaper to create than to carry. Ask who owns each agent-authored PR after merge. If the answer is "the agent," the answer is really "nobody."

Deletion discipline. 8x more code also means 8x more code that should be rejected, simplified, or deleted. When generating a change is nearly free, the value of saying no goes up, not down. The scarce act stops being "write it" and becomes "refuse to merge it, or delete it next week." A team that measures lines added will happily drown in code it should have thrown out. The one that measures durable-net-code — see below — is the one that survives.

Put those three together and an org-wide 8x is a composition story, not a uniform-uplift story. The gains concentrate in strong specifiers who also own what they ship and delete what they shouldn't have kept. And the people who leaned in are also the ones still committing, so the reported average is inflated by who's left in the sample. Ask for the median engineer's durable-net-code delta, linked to a shipped outcome, controlled for team mix. Whatever that number is, expect it to sit far below the headline 8x. That gap is the story the average hides.

There's a genuine open fight worth naming here: is all that churn waste to minimize, or cheap exploration to encourage as long as a harness gates it? If your harness is good, churn is free experimentation. If it isn't, churn is debt with extra steps. Which one it is for your team depends entirely on whether the verifier exists yet.

What to measure instead of volume

Stop scoring code produced. Score:

• Change-failure-rate and MTTR (the DORA outcome axes), not lines merged.
• Durable-net-code: additions minus what's deleted or rewritten within 14 days.
• Lead time end-to-end, idea to production — because that's where the relocated bottleneck shows up.
• Merge-queue wait-time tail (p90), your early warning that arrival rate has outrun review.

If your dashboard shows volume climbing while lead time and change-failure-rate get worse, you're looking straight at the trap.

Do these three things this week

• Split agent authorship from human authorship in your metrics. Most agents already tag their work — a Co-Authored-By: Claude trailer, or a commit under the agent's own identity. Stop collapsing that into the human. Pull it out and report agent-attributed diffs as their own line, so "code per engineer" stops secretly meaning "code per engineer plus their agents."

• Add a 14-day churn measurement. Instrument how much of last month's added code was deleted or rewritten within two weeks. The gap between gross and durable code is your real multiplier.

• Move one review criterion into an executable check. Pick the one thing your team eyeballs in every PR and write it as a property test or a lint/CI rule the agent has to pass before opening the PR. That's the first brick of the verifier.

If you've watched this play out: did your merge queue and CI bill spike when agent volume did, or had you already moved review left? That's the split that decides whether 8x helped you or buried you.

FAQ

Is the 8x number fake?

Probably not. It's likely a real telemetry number for code volume. It's just answering "how much code got attributed to humans," not "how much more valuable work shipped."

So is coding solved?

Authorship got cheap. Verification, specification, product judgment, ownership, and end-to-end delivery did not. Fung's "coding is no longer the bottleneck" is true and mostly useless — the constraint moved, it didn't leave.

Does this generalize past Anthropic?

Cautiously. It's single-vendor internal disclosure with no third-party replication. Independent controlled studies of AI dev tools have been mixed — some show modest gains, and at least one (METR's 2025 randomized trial with experienced open-source developers) found the tool actually slowed them down on codebases they knew well, even though they felt faster. Treat 8x as one org's volume metric, not an industry fact.

What actually raises my team's ceiling?

Getting better at writing the check the agent runs against — specs, invariants, eval harnesses — plus deciding what to build and what to delete, so the machine catches its own mistakes before they reach a human or your CI budget.