The Peril of Laziness Lost: Why LLMs Need Human Constraints

Larry Wall's concept of laziness as a programming virtue encourages the development of abstractions that simplify systems. Modern LLMs lack the human constraints that drive this simplicity, often resulting in bloated and inefficient codebases. To remain useful, LLMs must be guided by human engineering rigor to prioritize quality and abstraction over sheer volume.

Key Points

• Virtuous laziness motivates programmers to build abstractions that make systems simpler and more composable.
• Modern 'hustle culture' and LLMs have shifted the focus from elegant design to the quantity of code produced.
• LLMs lack the inherent human constraints of time and cognitive load that force the creation of crisp abstractions.
• Unchecked LLM usage leads to bloated software containing redundant components, such as multiple test harnesses and unused assets.
• LLMs should be used as tools to support human engineering rigor rather than as autonomous generators of unconstrained complexity.

Sentiment

The community is strongly supportive of Cantrill's thesis. Most commenters agree that removing coding friction is dangerous, LOC metrics are meaningless, and human oversight remains essential. The few contrarian voices — arguing the author is just grieving commoditization or that LLM limitations are fixable — are outnumbered and receive pushback from multiple respondents including the article's author himself.

In Agreement

• LLM-generated tests are superficial and miss domain-critical verification, giving false confidence in code correctness
• Bragging about lines of code was always meaningless, and AI-generated LOC makes it even more absurd — Garry Tan's deployed app contained bundled test harnesses and a stowaway text editor shipped to users
• LLMs lack the human constraint of finite time and effort, so they produce bloated solutions where a lazy programmer would seek simplicity
• The friction of writing code serves as a critical regularizer — it forces engineers to think before building and to internalize the cost of every abstraction
• LLMs don't maintain a mental model of the codebase, making them unable to find good cross-cutting abstractions the way experienced engineers do
• Inexperienced engineers now ship massive PRs before lunch without the natural feedback loop that would previously have made them realize their approach was wrong

Opposed

• The article's author may be grieving the commoditization of hard-earned expertise rather than making a purely objective argument
• LLMs' lack of laziness may be a fixable tooling issue — review agents, CI/CD simplification steps, and better prompting could compensate
• LOC and code quality are largely irrelevant metrics if the end product delivers value — judging by code output rather than value generation makes the same error in the opposite direction
• Token usage may be a better proxy for productive AI use than lines of code generated, as it represents thinking offloaded to the machine