In the LLM Era, the Programmer's Virtue of Laziness Is Disappearing
Introduction
Have you had this experience too: you use an LLM to write code, produce thousands of lines in a day, and then look back only to realize that the truly valuable part may be no more than a few hundred lines?
It sounds absurd, but it is becoming normal. Bryan Cantrill, CTO of Oxide and co-creator of DTrace, recently wrote The Peril of Laziness Lost, aiming directly at the heart of the problem: LLMs are killing one of the programmer’s most important virtues: laziness.
The article is short, sharp, and worth reading carefully if you write code with LLMs.
1. The Three Virtues of a Programmer: Do You Really Understand Laziness?
In Programming Perl, the classic book affectionately known as the Camel Book, Larry Wall described the three great virtues of a programmer:
Laziness, Impatience, and Hubris
All three words sound negative, but Wall used them ironically. Among them, Cantrill argues that laziness is the deepest one.
Why? Because this kind of laziness is not about being unwilling to work. It is a positive force, a kind of drive.
Real laziness pushes programmers to build elegant abstractions. When you do not want to write the same code again, you extract a function. When you do not want to handle the same category of logic again and again, you design a reusable framework. In Cantrill’s words:
Laziness drives us to make systems as simple as possible, but no simpler; to develop powerful abstractions; and to enable ourselves to do more with less effort.
But there is a hidden contradiction here: to be truly lazy, you first have to be very diligent.
Think about the code you are most proud of. Wasn’t it usually the result of long thinking, repeated refinement, and finally a solution that looked extremely simple? Cantrill mentions hammock-driven development. A programmer lying in a hammock may look like they are slacking off, but they may actually be turning the problem over in their head, searching for the most elegant solution.
The essence of laziness is using deep thought now in exchange for ease later.
2. The Rise of False Industriousness
Cantrill then points to a trend: over the past two decades, the population of software developers has expanded dramatically, and more people no longer call themselves programmers. That is not a problem by itself, but it has brought a side effect: the rise of false industriousness.
What does that look like? The so-called brogrammer culture.
Brogrammer combines brother and programmer. It refers to a subculture that measures output by lines of code, proves effort through overtime, and posts about “crushing code” on social media. In that culture, quantity beats quality, and busyness beats thought.
The kind of laziness that makes you stop, think, and search for a better design gets pushed aside.
Cantrill compares this culture to dry tinder, waiting for a spark.
3. LLMs: Steroids for False Industriousness
That spark is the LLM.
Whatever your attitude toward software creation is, LLMs let you apply that attitude with far greater force.
This is one of the key insights in the article. LLMs are neutral tools, but they amplify the user’s existing tendencies. If you already care about simplicity and elegance, an LLM can help you get there faster. If you already believe that more is better, an LLM will push you further in that direction.
Cantrill uses Garry Tan as a representative example.
Garry Tan, the current CEO of Y Combinator, has repeatedly shown off his LLM coding “efficiency” on social media, even claiming that he writes 37,000 lines of code per day and is still accelerating.
37,000 lines. Per day. Let that number sink in.
If laziness is a programmer’s virtue, this mindset is obviously a vice. It is as absurd as measuring literary value by weight. Even a beginner programmer can see the problem.
4. Dissecting an “Efficient” Product
The interesting part is that someone actually dissected Tan’s LLM-built “newsletter-blog” project. Polish software engineer Gregorein did the work, and the result was both expected and funny:
- Multiple test harnesses stuffed into the project
- A complete Hello World Rails application
- A hitchhiking text editor unrelated to the project
- Eight different versions of the same logo, one of them a zero-byte file
You might say these are small problems and can be fixed. Cantrill’s response is: the problem is not the bugs themselves.
The problem is that LLMs naturally lack the virtue of laziness.
5. The Core Point: Without Constraint, There Is No Elegance
This is the core passage of the article, and it is worth reading carefully:
Work has no cost for an LLM. It does not feel the need to optimize for its own future time, or anyone else’s. It will happily pile more and more junk together. Without constraint, LLMs make systems bigger rather than better, perhaps satisfying distorted vanity metrics at the cost of everything that actually matters.
Cantrill further explains the relationship between constraint and elegance:
Our limited time forces us to develop clear abstractions, partly because I do not want to waste my human time living with the consequences of bad abstractions. The best engineering always comes from constraint.
This resonates with me. Think about your own experience:
- When you have plenty of time, are you more likely to write code that merely “works for now”?
- When delivery pressure is strict, are you sometimes forced into a simpler design because you know a complex one will destroy you later?
This is exactly how constraints shape design. The finiteness of human time is the fundamental force that pushes us toward simplicity and elegance.
Cantrill also refers to his talk The Complexity of Simplicity, emphasizing that pursuing simplicity is hard work. We should not expect an LLM, which is not constrained by time or cognitive load, to do that work on its own.
6. Cantrill’s Position: Not Anti-LLM, Anti-Misuse
It is important to note that Cantrill is not opposing LLMs.
He says clearly:
LLMs will play an important role in our future. They are extraordinary tools for software engineering, but, as we outline in Oxide’s LLM usage guide, they are tools.
The key is that LLMs must serve human virtuous laziness.
More specifically, Cantrill believes LLMs should be used to:
- Attack technical debt, the issues we know should be fixed but keep delaying
- Improve engineering rigor, helping us do the careful work we often lack time for
- Ultimately produce a simpler and more powerful system
Instead of:
- Chasing lines of code
- Using bloated feature lists to prove “efficiency”
- Treating “it runs” as the only standard
7. My Thoughts
After reading the article, my strongest feeling is this: constraint is exactly what drives us to pursue elegance.
It reminds me of shooting with a film camera or an instant camera. A roll may only have twenty or thirty frames. Each press of the shutter consumes one. Because of that limitation, you compose more carefully and choose light and timing more cautiously. When you value each chance to press the shutter, the photos often turn out better than expected.
Software engineering is similar. Lines of code are one of the worst metrics, because they measure effort spent, and sometimes even useless effort. A programmer who spends three days thinking and finally writes 50 lines of elegant code creates more value than someone who writes 5,000 repetitive, redundant lines in a day.
LLMs are powerful tools. I use them heavily for programming too. But Cantrill’s article is a reminder: when using LLMs, do not give up your human laziness. Stop and ask whether the abstraction is good enough, whether the code is simple enough, and whether the design is elegant enough.
An LLM can help you reach the destination faster, but you must still choose the destination.
Summary
| Point | Explanation |
|---|---|
| Laziness is a core programmer virtue | Laziness drives elegant abstractions |
| LLMs naturally lack laziness | Work has no cost for them, so they do not optimize by default |
| Constraints shape design | Limited human time forces simpler designs |
| LLMs amplify existing tendencies | Quality-focused users improve; quantity-focused users get worse |
| LLMs are tools | They should serve human virtuous laziness |
In one sentence: the finiteness of human time is the force that produces elegant design. LLMs do not have that constraint, so they tend to make systems bigger rather than better, unless humans use their own laziness to guide them.
Reference: The Peril of Laziness Lost — Bryan Cantrill
Related video: The Complexity of Simplicity — Bryan Cantrill