Last week I was on the Talking Postgres podcast with Claire Giordano discussing how AI is reshaping software development. One conversation thread stuck with me: whether lines of code is actually a useful productivity metric when coding agents enter the picture.
Most engineering wisdom says LOC is a meaningless measure. I used to agree. But I’ve changed my mind, and here’s why: there’s a hard physical limit to human code output.
Before AI agents, a solid engineer could produce 200 lines of production-ready, debugged code on a really good day. Most days? Maybe 50 to 60. That’s not laziness - that’s the reality of thinking through logic, handling edge cases, writing tests, and reviewing your own work.
Now agents can produce a thousand lines of debugged code in the same time frame. If that code maintains the same quality standards - if it’s maintainable, tested, architecturally sound - then that’s a genuinely meaningful improvement. It’s not just a different metric; it’s a different order of magnitude.
The Cognitive Bottleneck Nobody Talks About
Here’s what I find most interesting: this productivity explosion actually proves why you still need teams of engineers, not just one person with an agent.
Obviously there’s the bus factor - never put your company’s code on one person. But the real constraint is cognitive capacity. I can churn out code a hundred times faster with agents. I absolutely cannot stay on top of a hundred times the amount of code.
The limiting factor has shifted. It’s no longer “how fast can I type and think through logic?” It’s “how much complexity can my brain manage?”
That’s exactly why distributed teams matter more now, not less. You load balance cognitive capacity across engineers who each specialize in different domains, who can review each other’s agent-generated code, who collectively hold the architectural vision.
The Winchester Mystery House Problem
But there’s a darker side to cheap code generation, and Claire nailed it with an analogy to the Winchester Mystery House - that California mansion with 140 rooms built over 40 years by a rifle widow with OCD.
Back Brooks wrote about conceptual integrity in The Mythical Man-Month: well-designed software has an internal coherence, a sense that everything fits together naturally. Adding features doesn’t create surprises; it extends the existing logic.
With coding agents, that integrity collapses fast. You get an idea for a feature, you run a prompt, and five minutes later it’s built. Your software grows weird little bumps in random directions.
The cost enforcement that used to help you make good decisions is gone. Before, you’d think “cool feature idea, but that’s a week of work - I can’t justify it” and you’d move on. When that feature takes an hour, suddenly it’s trivial to justify. So you build it.
After a hundred of those decisions, you have a Winchester Mystery House - technically functional, but with no coherent design, contradictory patterns, and an architectural nightmare.
Discipline is the New Currency
The uncomfortable truth: success with coding agents requires more discipline, not less.
You need strong conventions. You need code review that isn’t rubber-stamping agent output but actually evaluating whether a feature belongs in your domain. You need to say no to features that don’t fit your architectural vision, even when they’re cheap to build.
Senior engineers become more valuable in this world, not less. What makes a senior engineer isn’t speed - agents destroy that as a differentiator. It’s judgment. It’s the ability to look at agent output and a feature request and say “this is good code, but it doesn’t belong here because it violates our conceptual model.”
The engineers who thrive with AI will be the ones who treat their agents like junior developers that need direction and review, not code generators to be squeezed for maximum output.
This connects directly to broader questions about software engineering practice in the AI era. We’re not moving to a world where individual productivity soars infinitely; we’re moving to a world where the constraint shifts from execution to judgment.
The question isn’t anymore “how much code can we write?” It’s “how much coherent, maintainable code can we write while staying true to our architectural principles?”