The problem is that LLMs inherently lack the virtue of laziness
Bryan Cantrill argues that LLMs lack human laziness, which forces us to create elegant abstractions—and without this constraint, AI will make systems larger, not better.
Key Points
- LLMs lack the natural constraint of laziness that human programmers have
- Humans, with limited time, are forced to develop crisp abstractions; LLMs have no such pressure
- Without the laziness constraint, LLMs will keep adding layers, leading to bloated systems
- This trait can lead to 'vanity metrics' — larger systems rather than better ones
- Understanding this helps developers use LLMs more effectively in practice
Analysis
Bryan Cantrill's quote perfectly captures the frustrations many feel when coding with LLMs: you ask it for a function, and it spits out an entire framework; you ask it to solve a problem, and it throws a pile of "potentially useful" utility functions at you.
Why does this happen? The core reason is that LLMs operate with "zero cost." For human programmers, writing code means investing time, dealing with debugging, and shouldering the burden of future maintenance. This forces us to be "lazy" – to solve problems with the least amount of code possible and to abstract reusable modules. This "laziness" isn't a flaw; it's a core driver of engineering elegance.
But LLMs are different. Their computational costs are borne by someone else. They don't have to maintain the code in the future. They don't even understand what it means for "this code to give another engineer a headache six months from now." So, they tend to "over-deliver," figuring that "under-delivering" might make the user think it's incomplete.
This observation reveals a profound trend: AI-assisted programming is changing the incentive structure of software engineering. Traditionally, there's been an invisible constraint between code volume and workload – you don't want to write too much because you're the one who has to deal with the consequences. But LLMs break this closed loop: they produce code but don't bear its weight.
What does this mean for engineers? First, you still need that "lazy" person – to tell the LLM what not to do, what to delete, and what abstractions are unnecessary. Second, when evaluating LLM-generated code, "conciseness" should become a new quality signal – if something can be solved in two lines, don't generate twenty.
Cantrill said, "LLMs highlight the indispensability of human laziness." This is a statement every developer in the age of AI programming should remember. Laziness isn't incompetence; it's our last line of defense against entropy.
Analysis generated by BitByAI · Read original English article