In his classic Programming Perl — affectionately known to a generation of technologists as "the Camel Book" — Larry Wall famously wrote of the three virtues of a programmer as laziness, impatience, and hubris:
If we’re going to talk about good software design, we have to talk about Laziness, Impatience, and Hubris, the basis of good software design. We’ve all fallen into the trap of using cut-and-paste when we should have defined a higher-level abstraction, if only just a loop or subroutine. To be sure, some folks have gone to the opposite extreme of defining ever-growing mounds of higher level abstractions when they should have used cut-and-paste. Generally, though, most of us need to think about using more abstraction rather than less.
Of these virtues, I have always found laziness to be the most profound: packed within its tongue-in-cheek self-deprecation is a commentary on not just the need for abstraction, but the aesthetics of it. Laziness drives us to make the system as simple as possible (but no simpler!) — to develop the powerful abstractions that then allow us to do much more, much more easily.
Of course, the implicit wink here is that it takes a lot of work to be lazy: when programmers are engaged in the seeming laziness of hammock-driven development, we are in fact turning the problem over and over in our heads. We undertake the hard intellectual work of developing these abstractions in part because we are optimizing the hypothetical time of our future selves, even if at the expense of our current one. When we get this calculus right, it is glorious, as the abstraction serves not just ourselves, but all who come after us. That is, our laziness serves to make software easier to write, and systems easier to compose — to allow more people to write more of it.
Ideally, you would want those that benefit from abstractions to pay the virtue of laziness forward — to use their new-found power to themselves labor on the abstractions they make. But a consequence of the broadening of software creation over the past two decades is it includes more and more people who are unlikely to call themselves programmers — and for whom the virtue of laziness would lose its intended meaning.
Worse, the extraordinary productivity allowed by modern abstractions has given rise to an emphasis on a kind of false industriousness. Pejoratively, this was the rise of the brogrammer, with the virtue of ironic laziness and hammock-driven development displaced by hustle porn about crushing code.
Onto this dry tinder has struck the lightning bolt of LLMs. Whatever one’s disposition is to software creation, LLMs allow that to be applied with (much) greater force, so it should be of little surprise that LLMs have served as anabolic steroids for the brogrammer set.
Elated with their new-found bulk, they can’t seem to shut up about it. Take, for example, brogrammer-of-note Garry Tan, who has been particularly insufferable about his LLM use, bragging about his rate of thirty-seven thousand lines of code per day (and "still speeding up"):
If laziness is a virtue of a programmer, thinking about software this way is clearly a vice. And like assessing literature by the pound, its fallacy is clear even to novice programmers.
As for the artifact that Tan was building with such frenetic energy, I was broadly ignoring it. Polish software engineer Gregorein, however, took it apart, and the results are at once predictable, hilarious and instructive: A single load of Tan’s "newsletter-blog-thingy" included multiple test harnesses (!), the Hello World Rails app (?!), a stowaway text editor, and then eight different variants of the same logo — one of which with zero bytes.
The problem here isn’t these issues per se (which are all fixable!), and it isn’t even the belief that the methodology that created them represents the future of software engineering (though that is certainly annoying!).
The problem is that LLMs inherently lack the virtue of laziness. Work costs nothing to an LLM. LLMs do not feel a need to optimize for their own (or anyone’s) future time, and will happily dump more and more onto a layercake of garbage. Left unchecked, LLMs will make systems larger, not better — appealing to perverse vanity metrics, perhaps, but at the cost of everything that matters. As such, LLMs highlight how essential our human laziness is: our finite time forces us to develop crisp abstractions in part because we don’t want to waste our (human!) time on the consequences of clunky ones. The best engineering is always borne of constraints, and the constraint of our time places limits on the cognitive load of the system that we’re willing to accept. This is what drives us to make the system simpler, despite its essential complexity. As I expanded on in my talk The Complexity of Simplicity, this is a significant undertaking — and we cannot expect LLMs that do not operate under constraints of time or load to undertake it of their own volition.
This is not to say, of course, that LLMs won’t play an important role in our future: they are an extraordinary tool for software engineering, but — as outlined in our guidelines for LLM use at Oxide — they are but a tool. We can put them to use tackling the non-ironic (and non-virtuous!) aspects of programmer laziness — helping us take on thorny problems like technical debt — or use them to promote our engineering rigor, but it must be in service of our own virtuous laziness: to yield a simpler, more powerful system that serves not just ourselves, but the generations of software engineers to come after us.