The Reviewer Trap: The Hidden Cognitive Overhead of Coding Agents

Simon Willison’s piece on the cognitive cost of coding agents touches on something that anyone who has spent serious time with Claude Code, Cursor, or Aider recognizes: the productivity gain is real, but the mental experience of using these tools is strange in ways that don’t fully resolve with practice.

I’ve been using coding agents to build Discord bots and miscellaneous systems work for the better part of a year. The speed improvement is not subtle. Tasks that would have taken an afternoon sometimes finish in twenty minutes. I’ve also noticed that I end up tired in a different way after agent-heavy sessions, and that I sometimes feel less certain about my own codebase than I would be if I’d written more of it myself. That’s worth examining carefully.

Writing Code and Reviewing Code Are Not the Same Mental Task

When you write code, you build a mental model of the problem incrementally. Each function you add extends a structure that exists in your working memory. You encounter friction at the boundaries of your understanding, and that friction forces resolution. You cannot write a function you don’t understand, at least not without noticing the gap.

Reviewing code is a verification task. You’re checking whether the code matches an intended behavior, looking for edge cases, spotting structural problems. This is cognitively demanding in its own right, but it’s different from constructive understanding. The risk is that reviewed code feels understood when it isn’t. You can follow each step of a function without having the kind of deep familiarity that comes from having made those choices yourself.

Cognitive load theory, developed by John Sweller in the late 1980s and extended substantially since, distinguishes between intrinsic load (the inherent complexity of the material), extraneous load (overhead from how information is presented), and germane load (the effort that builds lasting mental schemas). Writing code, at its best, is high on germane load. You’re constructing schemas under the pressure of making something work. Reviewing AI-generated code is often high on extraneous load: you’re following someone else’s structure, mentally translating their choices into your model, tracking what you’ve verified and what you haven’t.

This isn’t a reason to stop using agents. It’s a reason to understand what kind of cognitive work you’re actually doing when you use them.

The Meta-Cognitive Layer Nobody Budgets For

There’s a layer of cognitive work specific to coding agents that has no real parallel in solo development or traditional pair programming. You have to decide what to ask for, and in enough detail that the agent can do something useful with it.

Writing a good prompt for a non-trivial feature requires you to have already thought through the requirements, the constraints, the edge cases, and the desired interface, all before the agent writes a line. If you haven’t done that thinking, the agent fills the gaps with assumptions, some of which will be wrong in ways you won’t catch immediately.

This front-loaded design work is genuinely valuable. It forces clarity that you might have skipped if you were writing the code yourself, incrementally, letting the structure emerge. But it’s also real cognitive effort that doesn’t show up in time-to-working-code measurements. You’re thinking before you write the prompt, reviewing after the agent responds, then evaluating whether the output matches what you wanted, then deciding whether to iterate or accept. The loop is faster than with a human collaborator, but it’s not free.

GitHub’s research on Copilot and subsequent productivity studies consistently show improvements in task completion speed. Those studies measure less well the quality of understanding developers retain after the task is done, or how that understanding degrades over repeated sessions of agent-assisted work.

Automation Bias and the Confidence Problem

Automation bias is the well-documented tendency to over-trust automated systems, particularly when those systems are usually correct. Coding agents are usually correct in the narrow sense: they produce syntactically valid, structurally reasonable code. That high base rate of surface correctness makes it easy to underweight the cases where the logic is subtly wrong.

I’ve caught bugs in agent-generated code that I wouldn’t have introduced myself, not because of any general superiority, but because the specific mistake required a misunderstanding of my system’s semantics that I couldn’t have had. The agent didn’t know that a particular function would be called in a context where a lock was already held. I knew that, but I was in review mode rather than construction mode, and I nearly missed it.

The more comfortable you become with agent output, the more tempting it is to skim. That comfort is earned by the agent being right most of the time, which makes the tendency epistemically understandable, but it means the errors that do occur are more likely to pass through precisely because your attention level is calibrated to the average case, not the edge.

Robust code review has this problem generally. Studies on code review effectiveness show that reviewers find substantially more defects when they’re engaged in the design process, as opposed to receiving code for post-hoc review. Agent-assisted development moves you firmly into post-hoc review territory for everything the agent writes.

Codebase Comprehension Over Time

The longer-term question is what happens to your understanding of a system you’ve built substantially with agent assistance. If you write a thousand lines of authentication middleware yourself, you know exactly why each decision was made. You chose the session expiry duration; you understand why the refresh logic works the way it does; the mental model is yours in a way that has real practical value when something breaks.

If an agent wrote it and you reviewed it, you know what the code does, but you’re less likely to have strong recall of why those particular values and patterns were chosen, because you didn’t make the choice, you evaluated someone else’s. That distinction has consequences for debugging, for extension, and for the kinds of architectural intuitions you develop about the system over time.

Andrej Karpathy’s framing of “vibe coding” describes the low-friction end of this: accepting agent output without deep inspection, leaning into the flow. That approach is appropriate for throwaway scripts or rapid prototyping. For systems you intend to maintain and extend, the cognitive engagement level needs to stay higher than vibe coding encourages, and that means deliberately treating agent output as a first draft rather than a deliverable.

What This Looks Like in Practice

Working on Discord bot infrastructure with agent assistance, I’ve developed a rough heuristic: anything affecting state management, concurrency, or data persistence gets written or heavily rewritten by me. Agents are capable in those areas; the issue is that subtle misunderstandings in concurrency and state carry the largest blast radius, and those are the areas where I need my own mental model to be authoritative, not derived from reviewing someone else’s output.

For boilerplate, command scaffolding, test fixtures, and repetitive structural code, agents are straightforwardly the right tool. The cognitive overhead of delegation is proportional to the stakes of being wrong about what was produced.

The useful reframe that Willison’s piece points toward is moving past the productivity question entirely. The question isn’t whether agents make you faster, because they do. The question is what kind of cognitive work you’re doing in the time they save, and whether that work adequately compensates for the comprehension and verification overhead the tool introduces. In most cases it does. In some cases, particularly for core architectural decisions and anything with subtle concurrency or security implications, staying in the driver’s seat is not a concession to nostalgia. It’s appropriate risk management.