Stop reviewing every diff: the AI bottleneck is your span of control, not the model
A principal engineer who says he ships dozens of AI-written PRs a day argues the people stuck at ‘cool demo’ aren’t waiting on a smarter model. They’re still working like a coder, even though the job has quietly become managing a crew.
There’s a video going around in which a former Meta and Microsoft principal engineer, Kun Chen, walks through how he works with AI coding agents. He says he ships 40 to 50 well-tested, production pull requests on a typical day. The internet’s takeaway is predictable: look how good the models have gotten. That’s the wrong lesson. Watch closely, and the thing doing the heavy lifting isn’t the model at all. It’s that he stopped working like a coder and started working like a manager, and built the machinery that makes managing safe. Here’s the workflow and the one principle underlying it.
The demo everyone watches for the wrong reason
Chen frames the whole thing as captaining a ship with a crew of agents: you set the destination, the crew does the rowing. He runs everything in the terminal for hands-on keyboard flow, keeps his setup deliberately agent-agnostic across Claude Code, Codex, and others, and onboards each fresh agent with memory files and reusable skills. All of that is real and useful. But it’s downstream of one decision: he treats getting more out of AI as a management problem rather than a typing problem. The productivity prize that makes this worth doing is genuine (in a controlled study, developers with an AI assistant finished a task about 56% faster than those without one), but speed is not the interesting part. The interesting part is how one person absorbs that much output without drowning.
Example: The tell is what he does when an agent says it’s finished: he does not open the diff. For most engineers, that sentence sounds reckless. The rest of the workflow is what makes it not.
Why can't he stop reading the diffs?
The intuitive explanation is that the model is now good enough to check its own work. The evidence points the other way. Left to itself, with no external signal, a language model cannot reliably self-correct its own reasoning, and prompting it to ‘reconsider’ can turn a correct answer wrong. So delegation is not safe because the agent is trustworthy. It’s safe only when you wrap the agent in something that grades it against reality. That’s exactly what his review pipeline is: it runs an adversarial review in a fresh context, an end-to-end test that records evidence the change actually works, a documentation pass, and a lint check — all before a human ever looks, and it babysits the pull request through CI. It works for the same reason the research keeps finding: iterating against feedback and retrying beats answering in one shot. The agent is not the source of quality. The loop is.
Example: Concretely, when low-risk work clears the pipeline, he merges it without reading. When the risk assessment flags something, that’s where his attention goes. The pipeline isn’t replacing his judgment; it’s rationing it.
The same move, repeated at every level.
Once you see that the leverage is the loop, the rest of the workflow stops looking like a bag of tricks and starts looking like one idea applied over and over. Voice input, which he says is roughly three times faster than typing, isn’t about speed for its own sake. It’s about spending a human’s scarce bandwidth on direction instead of transcription. Designing tools for agents (he reports that his own token-efficient formats cut costs sharply compared to JSON, and that calling GitHub through the CLI costs a fraction of what a heavier integration does) broadens how much an agent can accomplish before it has to come back to you. Running several agents in parallel across isolated git worktrees and letting one grind overnight on a verifiable goal is the same move yet again: keep more loops closing while your attention is elsewhere. None of the compounding happens inside the model. It happens in the process you build around it.
Example: His most advanced step is a ‘first mate’ agent that orchestrates the others — spinning up worktrees, dispatching tasks, running the review pipeline — so he talks to one manager instead of juggling ten workers.
The part of the video undersells
A fair analysis has to name where the story is softer than it sounds. First, the speed-of-voice argument quietly assumes faster equals better. It doesn’t always: even when dictation wins on raw speed, people often return to typing for privacy, social context, and the friction of editing by voice. The honest lesson is ‘remove the input bottleneck where it actually pays,’ not ‘switch to voice.’ Second, and more importantly, the whole ‘stop reading diffs, only inspect high-risk changes’ move rests on two assumptions the demo never tests: that the automated check is good enough to catch what matters, and that you can reliably tell which changes are high-risk in the first place. Both get shakier as the work gets messier. On a benchmark of real GitHub issues, even strong models resolve only a small fraction unaided, which is the gap between a clean personal project and a production codebase. Skipping review isn’t free. It’s a bet that your signal is strong and your risk-triage is accurate.
Example: On a polished solo project, those bets pay off. On shared, security-sensitive, or stateful code, a missed defect doesn’t announce itself, and ‘I shipped a wall of PRs’ can quietly become ‘I merged a stack of changes I can no longer account for.’
Where this breaks
So the real boundary of the approach is the quality of the signal you can give the loop, and that boundary is uneven. Where feedback is immediate and unambiguous (does it compile, does the test pass, does the screen look right), delegation scales beautifully, and the director model is exactly right. Where the signal is weak, delayed, or expensive (a subtle security regression, a race condition in shared state, a correctness property no quick test captures, anything touching money or other people’s data), the external oracle that made delegation safe isn’t there. The same workflow that produced a steady stream of clean PRs will confidently produce a broken one. The role shift is real, but it isn’t a license to stop thinking. It relocates the thinking: from ‘write correct code’ to ‘design the feedback and judge what the automated check cannot.’ That’s a harder skill to teach than syntax, not an absent one.
The practical move, then, is not to wait for a model smart enough to trust unquestioningly, and not to keep working like a typist who happens to have autocomplete. It is to build the loop and step up a level. If you are an individual engineer: front-load the signal (write the end-to-end test first, wire up types and lint, run changes in a sandbox so failures are loud), automate the path from first-pass code to a reviewed PR, and then spend the bandwidth you just freed on intent and on reviewing only what the automation provably can’t cover. If you lead a team: notice that this is the job you already know — directors don’t read every diff, they set the culture, the process, and the bar, and trust the system to carry it out. The leverage was never the model or the prompt. It is how much honest, automated feedback you can put between an agent and ‘done,’ and how well you spend the attention that buys back.
Why this matters
The bottleneck in working with AI is quietly moving. It used to be the model’s capability and your prompt. Increasingly, it’s your span of control: how many honest, automated feedback loops you can put between an agent and ‘done,’ and how well you spend the attention that buys back. That favors people who can design a process and hold a quality bar over people who can only type fast, and it turns ‘engineering manager’ from a career off-ramp into a core technical skill.
What to do next
Pick one project and build the loop before scaling volume. Front-load the signal: write the end-to-end test first, wire up types and a linter, run changes in a sandbox so failures are loud. Then automate the path from first-pass code to a reviewed pull request, and only after that let yourself stop reading every diff — starting with the lowest-risk changes. Spend the bandwidth you just freed on stating intent precisely up front and on reviewing exactly the high-stakes changes your pipeline can’t fully validate. If you lead a team, notice you already know this job: directors don’t read every diff; they set the process and the bar and trust the system to carry it out.
---
If this was useful, subscribe for more grounded breakdowns of how serious practitioners actually work with AI: the mechanisms underneath the demo and where it breaks down. Then hit reply: which change would you never let through unread?