When You Become the Bottleneck: The Human Role in the Claude Code Era

Last week I read a line in Satoshi Nakajima’s weekly newsletter that stopped me cold.

“AI only handles steps 5 and 6. The time AI spends waiting for my instructions and feedback has grown longer than the time I spend waiting for AI to finish.”

Nakajima is a veteran Microsoft engineer who now builds open-source AI tools. He’s been developing a project called MulmoClaude, and writes that code which used to take two or three days now gets written in ten minutes — productivity, he says, has gone through the roof. And yet he has become the bottleneck. That’s the part that stuck with me.

I’ve been feeling the same thing since I started using Claude Code. Raw coding speed has gone up dramatically. But I keep noticing moments where I’m the one stuck — and Claude is just waiting.

Moving to the “Conductor” Role

The workflow for AI-assisted development looks roughly like this:

1. Decide what to build
2. Define the design approach
3. Ask the AI to produce an implementation plan
4. Review and revise the plan
5. AI writes the code (AI’s turn)
6. Review the code and issue correction instructions (AI’s turn again)
7. Verify behavior

AI actually writes code in steps 5 and 6. Everything else stays on the human. AI can run multiple tasks in parallel; humans can’t.

I’ve come to think of this shift as moving from craftsman to conductor. The engineer of the past was a craftsman who wrote code directly. Today we’re closer to conductors — responsible for the design and judgment that drives the AI.

Where I Get Stuck

Using Claude Code every day, three things consistently become my bottleneck.

1. Translating requirements into language
I often have a clear sense of what I want to build, but turning that sense into something precise enough for AI to act on takes time. Vague instructions produce vague results. Getting precision out of the AI requires deep understanding first.

2. Code review quality
Reading what the AI wrote and judging whether it’s actually right. There’s a real concern that if I stop writing code myself, my ability to read it will atrophy. So far that hasn’t happened, but I stay conscious about reading carefully.

3. Architecture decisions
I can’t yet hand off “how to structure this system” entirely to AI. I can ask for a design, but whether that design is correct is a judgment only a human can make. This is where I think the real value still lives.

The Prisoner’s Dilemma Angle

The same newsletter introduced a paper called “The AI Layoff Trap” that frames AI automation as a prisoner’s dilemma.

The argument: when each company rationally pursues AI automation, workers lose jobs and, as consumers, lose purchasing power — which ultimately hurts those same companies. The only theoretical fix is a Pigouvian tax on automation, but the same dilemma repeats at the national level, making international coordination equally hard.

As one engineer I can’t solve that problem directly. But I want to hold onto the wider frame: how AI changes my work is only half the picture. How it affects society as a whole is a question I don’t want to lose sight of.

What Intellectual Work Should Look Like in the AI Era

The same newsletter pointed to a paper by Terence Tao and colleagues on mathematics. The argument maps cleanly to software.

AI-generated proofs can be formally correct without conveying why they are true. Experienced mathematicians carry what Tao calls a “sniff test” — an intuition for whether something smells right before it’s fully verified. AI doesn’t have that.

The parallel holds in code. An AI-generated function may work correctly, but understanding why this implementation is right lives on the human side. Lose that understanding and you lose the ability to make the next judgment call.

Tao’s team describes short-term AI use as “vanilla essence” — a small amount enhances the dish, too much ruins it. AI in development works the same way: the core understanding must stay with the human.

Keeping Up with the Pace of Change

There’s also the news that Claude Code is pushing users from the Pro plan to the $100/month Max plan. Cost is a real constraint.

The more expensive the tool, the more value you need to extract from it. The mindset shift required moves from “usable is good enough” to “use it well enough to generate real value.”

To reduce the time I spend as AI’s bottleneck, I need to increase the speed and precision of my thinking — the speed of architectural reasoning, of translating requirements into clear language, of reading code and making a call. These are different axes from raw coding speed.

The value of being an engineer is shifting from “can write code” to “can judge and design.” Where should I spend my time? Reading Nakajima’s newsletter gave me a fresh prompt to work it out.

Directing the AI while keeping my own understanding and judgment intact — getting that balance right is the work in front of me.

Are you using AI development tools and hitting moments where you turn out to be the bottleneck?