The Human-in-the-Loop Is Tired: Practical Guardrails for Reviewing AI Agent Work
A widely-shared essay from Pydantic, “The human-in-the-loop is tired” by Laura Summers, names something a lot of developers have felt but not articulated: coding with AI agents is often more productive and less satisfying at the same time. The reason isn’t the code — it’s the supervision.
The bottleneck moved, and nobody adjusted for it
For decades the scarce resource in software was writing correct code. Agents largely automated that. What they did not automate is attention and judgment — deciding whether the output is right, coherent, and worth keeping.
The essay describes a colleague receiving 30 AI-generated PRs a night, each needing a snap judgment. Another stayed up until 2am obsessively re-prompting to get a spec “right.” The failure mode isn’t the model producing garbage; it’s the model producing plausible output with subtle “errors of coherence” — code that looks correct and compiles but quietly does the wrong thing. Reviewing that is far more tiring than reviewing obvious garbage, because you can’t skim it.
That’s the trap: output volume went up, so the volume of things demanding human review went up with it, while the satisfying part — solving the problem yourself — shrank.
The fix is structural, not more willpower
The instinct is to review everything more carefully. That doesn’t scale, and it’s what burns people out. The better move is to change where the human checkpoint sits, not how hard you push on it.
Move the checkpoint from actions to outcomes. Approving every individual Bash or Edit call is the most tiring possible loop. Instead, let the agent work autonomously inside a boundary that makes mistakes cheap — a dedicated git branch, a worktree, or a sandbox — and put your real attention on two things: the plan before it starts, and the diff when it’s done. If you’re constantly clicking approve/deny, you’re doing supervision at the wrong altitude.
Gate merges behind machines, not eyes. Tests, type checks, and linters are tireless reviewers. The more of your correctness criteria you can express as an automated gate, the less you have to hold in your head during review. Human review should focus on intent and architecture — the things a test suite can’t judge.
Distill repeated feedback into rules. If you correct the same class of mistake twice, that’s a signal to write it down, not to keep catching it manually. Moving it into a CLAUDE.md / AGENTS.md / rules file turns an endless manual correction into a one-time investment. (This is also why bloated instruction files are worth pruning — see our note on Claude Code’s token overhead.)
Batch, don’t stream. Reacting to output the instant it appears is the Skinner-box pattern the essay warns about — “just one more prompt.” Let a task run to a natural stopping point and review the whole result, rather than babysitting each step. Fewer, larger review passes are less fatiguing than a constant trickle.
Know when to close the loop entirely
Not every task needs an agent. The essay’s healthiest recommendation is workflow maturity: the confidence to switch between AI-assisted and hands-on-keyboard coding without guilt. Small, well-understood changes are often faster to just write. Reserve the agent for work where its speed actually pays for the review cost it creates.
If you want a fully local setup where the review-vs-cost math is different — no per-token pressure nudging you toward “one more prompt” — we walked through running a free local coding agent in a separate post.
The takeaway
The productivity gains from coding agents are real, but so is the supervision cost, and pretending it’s free is how people burn out. Don’t try to review harder. Move the checkpoint to the plan and the diff, let tests and branches absorb the risk, and write down feedback instead of repeating it. Human judgment is the scarce resource now — spend it deliberately, not on approving one command at a time.
Source: The human-in-the-loop is tired by Laura Summers (Pydantic), discussed on Hacker News.