When did we decide lines of code was a measure of productivity? | by MooseyAnon | Jun, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

When did we decide lines of code was a measure of productivity?

MooseyAnon

10 min read·<br>1 hour ago

Listen

Share

Press enter or click to view image in full size

async for loop is crazyThere currently seems to be a kind of psyop going on across the tech industry. AI labs are pushing the idea that their tools are increasing worker productivity and the core case study for this thesis is, “look at how AI can generate so much more code, so much faster than human SWE’s”. Implicit in this thesis is the assumption that lines of code (LoC) written, or in this case generated, are a viable and appropriate measure of software engineering productivity. It’s a thesis that downstream CEOs and company leaders around the world have all seemingly bought into.<br>Now, I don’t think I’m the first to have noticed but this is very weird.<br>I have absolutely no qualms with the AI labs pushing this narrative, they’ve got code-generating machines to sell after all. What surprises me the most is that many of the same people who spent years arguing that LoC was a terrible metric now seem perfectly happy to use code generation as evidence of productivity gains.<br>For those of you not in the know, LoC have long been considered a useless metric. So much so that Bill Gates once remarked that measuring programming progress by LoC is akin to measuring the progress of aircraft building by its weight.<br>But what if old Billy boy and everyone else is wrong? What if LoC is actually the best proxy for measuring programmer productivity? Well, lets explore that question with another: what would need to happen for the baseline thesis presented by the AI labs to be considered true?<br>Hypothesis<br>Productivity: LoC written over some unit of time<br>More LoC → more software delivered<br>More software delivered → more value created<br>Therefore: More LoC → More Productivity → More Value<br>Or put more simply, if writing more code per unit time is what drives productivity, then increasing code output should increase value in a proportional and predictable way.<br>It’s difficult to test this hypothesis directly, so instead we’ll examine its implications. If the hypothesis is true, then the following predictions should hold:<br>Developer scaling : Small teams rival large orgs purely via LoC amplification<br>Ideas unlocked : Large backlog of latent ideas gets executed<br>Execution becomes cheap : Idea quality becomes dominant bottleneck<br>Bug reduction : More code written faster means faster fixes and fewer production defects<br>Developer Scaling<br>This one should be relatively straightforward to reason about:<br>Given one SWE produces Y amount of value<br>Then N coding agents per SWE should produce (N × Y) value<br>Given the above constraints we should see the speed at which teams ship new products go up linearly with the amount of AI they use. We should also see small teams that use AI create more value, more quickly than larger headcount teams who do not use AI.<br>So are we seeing these things?<br>Firstly, let’s ask a question: is writing code the sum total of work a SWE does during their day?<br>Of course not.<br>Writing code is only one part of the software development process. Code still needs to be reviewed, tested, integrated, deployed and maintained. In many industries it also needs to satisfy various security, regulatory or compliance requirements before it can ever make it into production.<br>None of these activities scale linearly with code generation. In fact, a lot of them get slower. The more code that exists, the more code there is to review. The more code there is to review, the more code there is to test. The more code there is to test, the more opportunities there are for bugs and regressions to slip through the cracks.<br>So instead of the system speeding up proportionally with code output, what often happens is that you’ve simply moved the bottleneck somewhere else.<br>But I think there is a more interesting assumption underneath this argument: that the speed of writing code has historically been the bottleneck to creating value. If that were true, we wouldn’t have needed to wait for AI, the market would have already solved this problem.<br>Software engineering has existed as a profession for decades. During that time we’ve built IDEs, debuggers, source control systems, CI/CD pipelines, cloud platforms, testing frameworks and every productivity tool under the sun. Companies have spent billions of pounds trying to squeeze more output from developers.<br>Yet somehow nobody concluded that typing speed was the thing holding us back. We don’t hire developers based on words-per-minute. Interview loops don’t contain typing tests. The highest-paid engineers are rarely the fastest typists. In fact, many of the most valuable engineers spend surprisingly little time writing code at all. Their value comes from making good decisions,...