From Author to Director: The Cognitive Shift That Coding Agents Force On You

Simon Willison wrote this week about the cognitive cost of coding agents, and it sits in a long tradition of developer hand-wringing about tools making us dumber. IDEs were supposed to rot our ability to remember APIs. Stack Overflow was supposed to hollow out our problem-solving instincts. GitHub Copilot was going to turn us all into context-pasting zombies. The discourse is familiar.

But I think there’s something genuinely different happening with coding agents, and it’s worth being precise about what it is, because the usual framing misses it.

The Role Shift Is the Thing

Every previous tool — autocomplete, Copilot, even Stack Overflow — left you in the author role. You were still the one writing the code. The tools assisted you: they completed tokens, surfaced examples, caught syntax errors. But the generative act, the translation from intent to implementation, was still yours.

Coding agents remove you from that act. You describe what you want, the agent produces code, and you shift into a reviewer and director role. That sounds like a subtle distinction, but cognitively it isn’t. Generating code and evaluating code use different mental processes, and only one of them reliably builds the mental model you need to maintain the system later.

There’s a well-established phenomenon in cognitive psychology called the generation effect, documented by Slamecka and Graf in 1978. Information you generate yourself — even if you generate it incorrectly and then get corrected — is encoded more durably in memory than information you passively receive. The act of generation is itself a learning event. When you wrestle with how to implement something, even inefficiently, you build a richer representation of the problem domain than when you read a correct solution someone else produced.

Coding agents short-circuit this. You get the output without the struggle, and the struggle is where the encoding happens.

What Working Memory Does While the Agent Is Running

When you write code yourself, your working memory is continuously loaded with the problem structure. You’re holding the state machine, the data shape, the edge cases, the constraints — all in active tension as you type. That tension is uncomfortable, but it’s also the process by which you build a coherent mental model of what you’re building.

When you hand a task to an agent, your working memory goes idle on that problem. You switch attention elsewhere, or you watch the output stream in, or you context-switch to another task. When the agent finishes and you return to review the output, you’re doing reconstruction rather than continuation. You have to re-load the problem context from scratch to evaluate whether the code is right. That’s harder, slower, and produces a shallower representation.

Sophie Leroy’s research on attention residue adds another layer here. When you switch away from a task and then return to it, you don’t fully return. Part of your attention remains on whatever intervened. With coding agents, the agent’s execution time becomes an interruption window. The longer agents take, the more thoroughly attention residue degrades your ability to re-engage with the original problem on return.

The Deliberate Practice Problem

Anders Ericsson’s work on expertise development identified deliberate practice as the key mechanism: improvement comes from working at the edge of your current ability, with focused attention and immediate feedback on errors. The difficulty isn’t incidental — it’s what causes adaptation.

If you consistently delegate the parts of a task you find hard to an agent, you’re precisely avoiding the practice that would build competence in those areas. The agent optimizes for task completion, not for your learning. Those two objectives are in tension, and agents resolve it entirely in favor of completion.

This is particularly sharp for people earlier in their careers. A junior developer using agents to handle the hard parts isn’t just missing practice opportunities; they’re building a workflow that depends on the agent to compensate for skills they’re not developing. That creates a compounding problem over time.

The Trust Calibration Paradox

One underappreciated consequence of agent-assisted development is what it requires of you to use agents well. Knowing when to trust agent output, where to probe it, what to verify — that judgment requires the same deep domain knowledge as writing the code yourself. The better you are at reviewing agent output, the more you could have written it yourself.

For senior developers, this is mostly fine. They can spot when the agent has misunderstood the requirements, chosen a naive algorithm, or missed a thread-safety concern. The agent accelerates work they understand.

For developers earlier in their expertise, the paradox bites harder. They’re most likely to accept agent output uncritically, least equipped to notice subtle errors, and least likely to have the mental models that would let them maintain the resulting code. GitHub’s 2022 study showed Copilot users completing tasks 55% faster, but task completion speed and code quality are different measurements, and the study didn’t track long-term maintainability or what developers actually understood about the code they shipped.

This Is Not the Calculator Argument

The standard counter to all of this is the calculator argument: we said the same thing about calculators, and the result was that people stopped memorizing multiplication tables and started solving harder problems. The tool raised the floor of what was achievable and freed up cognitive capacity for higher-level work.

That argument is correct for some uses of coding agents, and I don’t want to dismiss it. When an experienced developer uses an agent to handle boilerplate they understand well — test fixtures, configuration files, repetitive CRUD code — the cognitive cost is low and the productivity gain is real. They’re not missing learning opportunities because there’s nothing to learn there.

The calculator analogy breaks down when the agent is handling code you don’t understand, or code in a domain where you’re still developing intuitions. A calculator doesn’t prevent you from learning arithmetic. An agent that writes your concurrency primitives for you does prevent you from learning concurrency, because the learning only happens when you have to do it.

What Changes in Practice

None of this is an argument against using coding agents. It’s an argument for using them with some awareness of what you’re trading.

A few things that have shifted in how I approach this: I try to be explicit with myself about whether I’m in a domain where I want to preserve learning pressure. For systems I understand well, I let agents run freely. For areas I’m actively trying to develop, I write first and use the agent to review or suggest improvements afterward, which keeps me in the generative role while still getting the benefit of a second pass.

When I do let an agent write something substantial, I treat the code review as a teaching exercise rather than a correctness check. The question isn’t just “is this right” but “do I understand every line of this well enough to explain why it’s right.” That’s a higher bar, but it partially restores the encoding that the generation step would have provided.

There’s also something to be said for reading agent-generated code as if you’re going to have to maintain it without the agent later, because at some point you might. The mental shift from “is this output acceptable” to “could I own this” changes what you notice.

The cognitive cost Willison writes about is real. The question is whether you’re spending it on things worth the cost, or ceding ground you’d rather keep.