AI lets one engineer write 100x the code. They still can't review it.

Simon Willison, an independent developer and longtime AI-tools commentator, wrote this week that agents have not made engineers 100x more productive. They have made their attention 100x more valuable.

Before coding agents, a strong day for a senior engineer was a few hundred lines of working, debugged, production-ready code. Willison calls 200 lines an "incredibly good day"; 50 to 60 is more typical. With an agent doing the typing, a thousand lines of debugged code in a day becomes a "very meaningful improvement" if the code is maintainable and tested. Willison says he can now produce code roughly 100x faster, which sounds like a productivity story until the same sentence says he cannot keep up with 100x the amount of code in his head.

The agent has moved the bottleneck from typing and syntax to review, design, and integration, the parts of the job that were never about how fast a person could produce a keystroke. The new limiting resource is the engineer's ability to hold the whole system in mind, decide what belongs in it, and notice when something does not.

Fred Brooks called this property of well-designed software conceptual integrity in The Mythical Man-Month: a good system has no surprises, no extraneous features, and exactly the right coverage of its problem domain. Willison's worry is that agent-driven coding makes that harder, not easier. On his recent Talking Postgres podcast appearance with Claire Giordano, Willison summarized the problem as "little weird bumps in funny different directions": each prompt-driven feature is a small architectural decision nobody fully made.

Giordano's image is the Winchester Mystery House, the famously sprawling San Jose mansion that grew room-by-room for decades under the direction of Sarah Winchester, with no master plan and a corridor that opens onto a wall. An agent-built codebase, in her analogy, becomes the same thing: 140 rooms of unplanned additions rather than a coherent design. The failure mode is not bad code line by line. The code can be clean, tested, and reviewed in isolation and still produce a system nobody fully understands.

If the new bottleneck is cognitive bandwidth, the productivity gain from a coding agent is bounded by the bandwidth of the engineers reviewing its output, not by the speed of the agent. (Bus factor: how many people on a project could be hit by a bus before the project stalls.) A team of ten senior engineers with a good agent can plausibly out-ship a team of ten senior engineers without one. A single engineer with a good agent is still one engineer, and no agent fixes the problem that the project rests on one person's head.

The standard "AI 10x developer" framing gets the trade wrong. The trade is not keystrokes for keystrokes. It is agent speed for human attention, and human attention is the resource the team is already short on. The right question for any team that has adopted a coding agent is not how much the agent wrote this sprint. It is whether a senior engineer can still hold the whole system in their head, and whether the codebase is getting more coherent, not less.

The industry has treated LOC as a vanity metric, and the live counter-positions — including the argument that coding itself is no longer the bottleneck and the broader industry conversation about what changes when writing is cheap — are all part of the same argument. Willison's post sits inside that conversation rather than outside it.

What is worth taking from the post is the test. Treat lines of code as a signal because it is bounded by something the agent cannot fake: the time it takes a human to read, understand, and integrate that code. The number stops being a productivity scoreboard and starts being a proxy for whether the team is keeping up with its own output. If the Winchester Mystery House is the visual for what conceptual-integrity loss looks like, LOC is the canary. Watch whether the rooms are getting bigger or smaller.