Simon Willison has an answer for the argument that counting lines of code is a meaningless way to measure programmer output. He thinks that argument breaks down once AI coding agents are in the loop.
In a lightly edited transcript from his appearance on the Talking Postgres podcast, Willison said: “A lot of people will tell you it makes no sense to measure productivity in lines of code. I’d actually disagree, because there’s a hard limit.” He put a number on the old limit: “In the before-times, a software engineer could produce a few hundred lines of production-ready code per day, and 200 lines of working, debugged, production-level code is an incredibly good day. Most days you’d produce 50 or 60.” Against that baseline, he argues agent-assisted output is a real jump: “If agents let you produce a thousand lines of debugged code, that really is a very meaningful improvement, as long as the code is the same quality: maintainable, tested, all of that.”
Who Willison is
Willison is an independent open source developer and blogger who created Datasette, a tool for publishing and exploring data, co-created the Django web framework, and built the llm command-line tool for working with language models. His blog is widely read by developers tracking how AI coding tools perform in practice. BuilderWithin covered his finding two days earlier that a new open model’s default settings wasted compute on simple tasks.
What he gets right, and where it’s incomplete
Willison’s throughput math holds up: going from 50 or 60 lines a day to a thousand lines a day is a real order-of-magnitude change, not a rounding error, as long as code quality doesn’t drop. His caveat matters as much as the number. He’s explicit that hitting that pace with agents “takes a huge amount of skill and knowledge and experience,” not something a beginner gets by pointing an agent at a task.
His second point is more interesting than the first: raw output isn’t actually the limit anymore. “I can churn out code a hundred times faster,” he said. “I don’t have the cognitive capacity to stay on top of 100 times the amount of code.” That’s why he thinks agent-assisted engineers still need a team around them: “So you still need a team of engineers, so you can load balance that cognitive capacity across the team.” He draws on the idea of “conceptual integrity” from the software management book The Mythical Man-Month, meaning well-designed software has no surprises and everything fits together, and argues agents erode it by making it too cheap to keep bolting on new features: “it’s very easy to keep adding new rooms, because the cost of adding those rooms is so much cheaper.” His conclusion: “What you end up with is something where the conceptual integrity falls apart, and then it’s harder to make decisions about it.”
Where the argument is thinner is that it comes from a podcast conversation, not a study. Willison offers no data on how many teams actually hold code quality constant while shipping more of it, versus shipping more code that’s also worse. The framework is a useful lens, not a measured result.
Why it’s notable
Most of the AI coding debate splits into two camps: people arguing lines of code is a useless vanity metric, and people arguing agents make one engineer worth ten. Willison rejects both. He keeps the metric but reframes what’s scarce: not typing speed, but the number of people who can hold a system’s design in their head while agents keep adding to it. That turns “should we hire fewer engineers” into the wrong question, and “who reviews and integrates all this new code” into the right one.
What it means for builders
If your team has adopted coding agents and output has jumped, don’t read that as permission to run leaner. Read it as a signal to check who’s actually keeping the system coherent. Assign real ownership over which parts of the codebase should stay simple, and don’t let an agent talk you into a feature just because it’s cheap to add. The cost that used to stop you, the time it took to build it, is gone. The judgment call about whether it belongs still isn’t.
End of article