The Rise of AI Vanity Metrics: Why Lines of Code are Returning as a Productivity Proxy

The software engineering industry is currently experiencing a resurgence of volume-based metrics—specifically lines of code (LoC)—to justify the adoption and impact of AI coding assistants. While the industry spent decades moving away from LoC as a measure of developer productivity, current claims from AI vendors and tech executives focus almost exclusively on the volume of code generated rather than the business outcomes delivered.

Volume Claims vs. Outcome Claims

Modern AI productivity claims have shifted from outcomes (what was achieved) to volume (how much was produced). Early claims for tools like GitHub Copilot focused on task completion speed, such as the claim that developers completed tasks 55% faster. In contrast, 2026 industry claims focus on the percentage of code written by AI:

  • Google: Reports that 75% of new code is AI-generated.
  • Anthropic: Claims ~80% of merged production code is authored by Claude, with engineers shipping "8x more code per quarter."
  • OpenAI: Similarly claims ~80% of its code is AI-generated.
  • Cursor: Reports "100M+ lines of enterprise code written per day."

These volume metrics are effectively "vanity metrics" because they can increase regardless of whether the software's quality, reliability, or business value improves. A high percentage of AI-written code does not inherently correlate with faster delivery, fewer incidents, or higher revenue.

The Complexity of AI Productivity Evidence

Measuring the actual impact of AI on productivity is complicated, and research often yields contradictory results. This inconsistency is why many organizations have reverted to simple volume counts.

Conflicting Research Findings

  • Positive Gains: Some studies, such as Cui et al., indicate a 26% increase in task completion, with the most significant gains seen among junior developers.
  • Quality Concerns: GitClear research suggests that as Copilot adoption deepens, code churn is rising while refactoring is collapsing.
  • Performance Paradoxes: A METR study initially found that experienced open-source developers were 19% slower with AI in their own codebases, though they believed they were 20% faster. METR later updated these findings to suggest a speedup, though they noted that developers now refuse to work without AI, making clean measurement nearly impossible.
  • Organizational Impact: An NBER survey of ~6,000 executives found that while 69% of firms use AI, roughly 90% reported no measurable productivity impact, with a general consensus suggesting organizational gains sit around 10%.

The Comprehension Gap

Even when volume increases, comprehension may decrease. An RCT conducted by Anthropic found that AI-assisted developers scored 17% lower on comprehension of the code they had just shipped, with no statistically significant productivity gain.

AI as a Justification for Workforce Reduction

Volume-based metrics are being used to justify significant headcount reductions. For example, Jack Dorsey reduced Block's workforce by over 40% (4,000+ people) in February 2026, citing AI as the core thesis that a smaller team using AI tools can do more and do it better. Similarly, Atlassian cut approximately 10% of its staff, acknowledging that AI changes the required skill mix and number of roles.

Critics argue that if AI truly provided a massive productivity boost, companies would use that "free headcount" to accelerate their roadmaps and deliver more value to customers (increasing MAU or revenue) rather than simply reducing staff. The use of AI as a justification for layoffs suggests that productivity claims may be serving as PR for decisions driven by other factors, such as over-hiring during the pandemic or investor pressure.

Synthesis of Community Perspectives

Technical discussions regarding the return of LoC metrics highlight several systemic risks:

The Liability of Code

Many engineers argue that lines of code should be viewed as a liability rather than an asset. As one community member noted, the goal should be to implement features with the minimum amount of code necessary to reduce the long-term maintenance burden.

The "Diesel Keyboard" Fallacy

Some argue that LLMs act as a "diesel powered keyboard," increasing the speed of typing but not the speed of problem-solving. Because only a small fraction of programming is actual typing, the overall impact on the software development life cycle (SDLC) is limited by bureaucratic layers and the need for human review.

The Review Bottleneck

As AI generates more code, the human review process becomes the primary bottleneck. The risk is a shift toward "trading quality for quantity," where the volume of code increases but the percentage of code actually understood or reviewed by humans decreases.

Conclusion: Measuring What Matters

Adopting AI tools is a practical necessity for modern developers, but adoption is the starting line, not the scoreboard. To avoid the pitfalls of vanity metrics, organizations should return to battle-tested engineering metrics:

  • DORA metrics (Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore Service).
  • Reliability and stability of the production environment.
  • Rate of meaningful change (features that drive business value).
  • Revenue and customer value (the ultimate measure of success).

When evaluating AI productivity claims, the critical question is whether the metric provided is an outcome (a measurable improvement in value) or a volume (a measure of how much was produced).

Sources