The peril of laziness lost

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:

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.