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. He also found that a local model’s default reasoning imposed a long wait on a drawing task.
What he gets right, and where it’s incomplete
Willison’s output comparison depends on code quality staying constant. More lines alone do not establish a productivity gain. 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 about the limit on understanding that output. “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 argues for sharing responsibility across a team: “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.”
The observations come 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
Willison separates the quantity of output from the capacity to maintain it. 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 agent output increases, check who can explain and maintain the changes. For a solo builder, keep changes small enough to review before adding more. 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. Lower implementation cost does not remove the decision about whether a feature belongs.
End of article