AI doesn't remove bottlenecks, it moves them
TL;DR
The agent types code faster than I do. That was never the bottleneck. Across my tracked sessions, most last under ten minutes, half go down the wrong approach, and a small minority end in a commit. The blocker didn't disappear — it moved, from writing to framing.
There’s an implicit promise behind every agent demo: “you’ll code faster.” It’s true, and it misses the point. Writing the code was never the slow part.
When I look at my own sessions instead of marketing screenshots, the picture is less glorious and far more useful.
What the numbers say (mine, not a keynote’s)
Across 267 tracked sessions: 62% last under ten minutes. The long, immersive session with the agent — the one we picture — is the minority. Real agentic work is a lot of short interactions.
Across the sessions I score, 53% carry a “wrong approach” friction — the agent (or me, briefing it) heads down a path that doesn’t hold, and most of the session goes into realizing it and course-correcting. And roughly one session in seven actually produces a commit. The rest is exploration, framing, back-and-forth.
These numbers come from a single dev, a specific stack, over a span that smooths out isolated cases (certainty level: measured, not felt). Yours will differ. What generalizes isn’t the percentage — it’s the direction.
The bottleneck moved
The slow point used to be writing: producing correct code, line by line. The agent obliterated that. So the blocker shifted to three places nobody puts on a slide:
- Framing. Stating the problem precisely enough that the agent doesn’t wander off. Half of my failed sessions are decided there, in the first thirty seconds.
- Context management. Deciding what the agent should see, and above all what it shouldn’t. Too much context drowns it, too little blinds it.
- The pivot. Recognizing that a run is going wrong and abandoning it — instead of grinding to rescue a bad approach because you’ve already sunk ten minutes into it.
None of these is a typing-speed problem. They’re judgment skills. That’s where the hard work went.
One deliberately generic example: a refactor where the agent picks a plausible but wrong abstraction. The session isn’t about writing — it’s about understanding why it’s wrong and redirecting it. Code comes out fast; discernment takes the time. That’s the verification tax: reviewing code that looks dangerously like correct code.
Why “give everyone Claude” isn’t enough
This is the bridge to team adoption, and it matters. If the bottleneck were writing, handing everyone a subscription would fix it. But the bottleneck is judgment — framing, contextualizing, knowing when to quit. Access doesn’t grant that; it’s learned, passed on, documented.
That’s exactly why most AI rollouts disappoint: we solved the part that wasn’t the problem, and left untouched the part that was. Enablement that works isn’t “here’s the tool” — it’s “here’s how we frame, how we decide a run is dead, how we avoid drowning in our own context.”
What it changes in practice
Stop measuring your AI productivity in lines generated or hours “spent with the agent” — those are vanity metrics. Measure what correlates with shipped work: how many of your sessions land, how many go wrong and why. The day you track that, you stop optimizing typing speed (already solved) and start working on framing (the real subject).
The agent made me faster at writing code. That’s precisely the part that mattered least.