Lines of code got a better publicist
AI-generated code is reviving lines-of-code as a management metric, despite decades of experience showing LoC mostly measures future maintenance burden, not real productivity. Commenters argue that typing isn’t the bottleneck—figuring out what to build, reviewing and testing changes, and maintaining simplicity are—so celebrating “millions of LoC” or high percentages of AI-written code mainly produces slop and technical debt. Many see current AI layoff and productivity claims as PR for over-hiring and investor pressure rather than evidence of genuine efficiency gains, and warn that organizations chasing LoC metrics will ship more fragile, unwanted features rather than better products.
Return of Lines-of-Code Metrics
- Commenters note a resurgence of LoC as a success metric in the AI era, despite long-standing criticism.
- OpenAI’s “million lines of code by agents” blog post is cited as emblematic: heavy emphasis on LoC with little clarity on product value.
- Comparisons to Linux, Chrome, and large monorepos highlight that huge LoC counts are not inherently impressive or desirable.
AI Slop, Technical Debt, and Maintainability
- “AI slop” is contrasted with traditional “technical debt” and seen as more concrete: large volumes of code few people understand, often far larger than necessary for the purpose.
- Some argue every line of code is a liability; LoC should be spoken of as a “cost” rather than an asset.
- Concerns that LLM-written codebases have recognizable patterns: plausible code, thin or fake tests, unclear abstractions.
Productivity and Bottlenecks
- Many say “writing code is no longer the bottleneck”; real constraints are deciding what to build, code review, testing, and organizational process.
- Individual developers often feel faster, especially for tests, boilerplate, and legacy-code comprehension, but team‑ or company‑level gains are modest due to unchanged downstream bottlenecks.
- There’s debate over claims like “1M LOC per engineer per month”; some see it as about automated porting, others as unrealistic and easily gamed.
Metrics, Gaming, and Goodhart’s Law
- Examples: lines-of-code-based performance reviews, PR-count-driven evaluations, code-coverage quotas gamed by generated junk.
- Commenters repeatedly invoke Goodhart’s Law: when LoC, PRs, or “% code written by AI” become targets, they cease to measure real productivity.
Adoption Pressure and Cultural Split
- Some insist every engineer must use AI daily to remain employable and competitive; others reject this as hype or “gun-to-the-head” adoption.
- Mixed field reports: nontechnical or junior users initially impressed, but often disappointed when using AI for tasks they know well.
- HN itself is perceived by different participants as both “AI fanboy” and “AI hate” territory, reflecting a polarized community.
Safety-Critical and “Real” Products
- Safety‑critical and embedded sectors are described as largely not adopting LLM codegen; one cited study finds major guideline non‑compliance.
- A broader contrast is drawn between sectors that must ship working, profitable products and those seen as focused on “faux productivity.”