The Peril of Laziness Lost

Bryan Cantrill's April 2026 blog post builds on Larry Wall's "three virtues of a programmer" (laziness, impatience, hubris) from Programming Perl to argue that LLMs fundamentally lack the most important one: laziness. Not sloth — the productive laziness that drives programmers to build clean abstractions so they don't waste future time on clunky systems.

The virtue of laziness

Wall's joke was that laziness makes you write labor-saving programs and document them well so you don't have to answer questions. Cantrill reads it as something deeper: laziness is an aesthetic and economic constraint. Programmers have finite time, and that finitude forces them to simplify. You develop crisp abstractions because you can't afford the cognitive load of bad ones. The hard intellectual work — what Rich Hickey called "hammock-driven development" — happens precisely because you're optimizing for your future self.

When this calculus works, the abstraction serves not just you but everyone who comes after. Laziness cascades: you save time, the next person saves time, the system stays composable. The broadening of software creation over the past two decades brought in people who wouldn't call themselves programmers, and for whom Wall's ironic framing loses its bite.

False industriousness

Modern abstractions enabled so much productivity that a culture of raw output volume displaced the laziness ethic. Cantrill traces this to the "rise of the brogrammer" and hustle porn — measuring software by quantity rather than quality. LLMs are steroids for this mindset. Garry Tan bragging about 37,000 lines of code per day is the reductio ad absurdum: assessing software by the pound.

Cantrill mostly ignored the artifact Tan was building until Polish engineer Gregorein dissected it publicly. A single page load of Tan's "newsletter-blog-thingy" included multiple test harnesses bundled into production, the Hello World Rails app, a stowaway text editor, and eight variants of the same logo (one zero bytes). The predictable output of unconstrained generation.

The core thesis: LLMs lack laziness

Work costs nothing to an LLM. It has no future self to optimize for, no cognitive load to manage, no impatience with its own output. Left unchecked, LLMs make systems larger, not better — layercakes of garbage that satisfy vanity metrics while increasing complexity. Human time constraints are what force simplicity. The best engineering comes from constraints, and the constraint of finite human attention limits the cognitive load we'll accept. Remove that constraint (by letting an LLM generate unchecked) and systems bloat.

Cantrill connects this to his talk "The Complexity of Simplicity" — making a system simple despite essential complexity is significant work, and we can't expect machines that face no time or load constraints to do it voluntarily.

LLMs as tools, not replacements

Cantrill isn't anti-LLM. Oxide has published guidelines for LLM use (RFD 0576) and discussed promoting engineering rigor in the LLM age on the Oxide and Friends podcast. His position: LLMs are an extraordinary tool, but a tool. Use them to tackle the non-ironic laziness — technical debt, tedious migrations, the unglamorous work humans actually avoid. But that use must serve virtuous laziness: yielding simpler, more powerful systems for the engineers who come next.

Connections

This essay sits at the philosophical center of the wiki's LLM-skeptic thread, supplying the why behind observations others make empirically:

• no-silver-bullet-llms — Bennett's quantitative case that the bottleneck is essential difficulty, not code generation speed. Cantrill's "laziness" is the human mechanism that attacks essential difficulty; LLMs skip it.
• cult-of-vibe-coding — Cohen's audit-discuss-execute loop is exactly the virtuous laziness Cantrill describes: hard upfront thinking that makes execution fast.
• building-syntaqlite-ai — Maganti's two-phase experience is a case study in laziness lost (phase 1: vibe-coded spaghetti) and laziness restored (phase 2: human-led architecture).
• clean-code-coding-agents — The practical side: agents navigate clean code efficiently, so structural simplicity pays off mechanically (less context burn) as well as cognitively.
• ai-great-leap-forward — Corporate AI mandates producing metric-satisfying garbage parallel Tan's 37k lines/day.
• llm-as-average-democratizer — The optimistic mirror: when average output is free, the floor rises, but the scarce resource shifts from production to filtering. Cantrill's warning is what happens when the filter fails.
• agentic-coding-fatigue — 0xsid's operational complement: the human filter has a 4-5 hour daily ceiling under agent supervision, so even with the will to be lazy you run out of judgment before you run out of work.
• agentic-coding-is-a-trap — Faye's structural complement: the supervisor role consumes the skills it requires; the skill-atrophy-supervision-paradox is the circularity by name.
• good-tools-are-invisible — Ginger Bill's toolmaker-side version: measure a tool by human cost, not by the "fun puzzle" of working around its friction.
• notes-on-software-quality — Hobday's parallel claim that quality erodes when the org generating it lacks a constraint forcing care, the same missing-virtue shape.