Vibe Coding Needs Larry Wall's Three Virtues More Than Perl Did

Vibe Coding Needs Larry Wall's Three Virtues More Than Perl Did

The Perl book lists three virtues of a programmer that look like vices. Once the machine does the typing, you have to supply them yourself.

By Geordie Everitt

The glossary of the Perl book lists three virtues of a programmer, and all three look like vices: laziness, impatience, and hubris. Larry Wall wrote them with a wink. Programmers have been quoting them back to each other for decades, with a straighter face each time, because they work as a job description.

Written for people who sweated the details

Wall's readers wrote their own loops, argued about idioms, and knew what the machine was doing, step by step. The virtues describe a person deep in that work who wants less of it.

Laziness is the quality that makes you "go to great effort to reduce overall energy expenditure." The effort comes first. The savings come later, in the hours of reading, fixing, and explaining that you no longer spend. Impatience is "the anger you feel when the computer is being lazy," and it produces programs that anticipate your needs. Hubris is excessive pride, the kind Zeus zaps you for, and also the pride that makes you write programs "other people won't want to say bad things about."

All three assume the cost was yours. You typed the code, so you felt each wasted keystroke, and the pain taught the virtues for free.

Then the typing moved

Vibe coding hands the typing to machinery. You describe what you want, and the syntax, the boilerplate, and the half-remembered API call arrive on the other side of a prompt, usually before the coffee cools. That removes what taught Wall's readers. Code stops costing hours and starts costing a sentence, and a cost you can't feel is a cost you stop managing.

So the virtues move. A programmer used to be lazy because the work hurt. A vibe coder has to be lazy on purpose, and impatient on purpose, and proud on purpose, because the process won't do it for them.

Laziness: the machine will write anything for free

A model that produces four hundred lines pays nothing for them, and a model that pays nothing has no reason to prefer twenty. Bryan Cantrill made this case about laziness in April 2026: the machine lacks it because generation is free, so systems grow larger instead of better.

The laziness has to come from the person, and it has to be Wall's kind, the effort you spend now to avoid effort later. In a vibe coding session that effort is review, and the review is mostly deletion. Among the standing instructions I give my own coding assistant is this one: "assume a battle-tested library already exists and find it before writing your own." Left alone, the model will write a currency formatter from scratch. The lazy answer is that somebody already did. The lazy question to put to any generated file is what the smaller version of it would be.

Impatience: say it once

Wall's impatience builds programs that anticipate you. The version that applies to a machine that follows instructions is the instruction you write down so you don't have to give it again. The third time you correct the same habit is the signal.

One of mine reads: "Do not give time estimates for planning. This is all going to be AI Assisted coding, so estimates in "weeks" is dumb." A model trained on decades of project plans writes plans the way they were written, in weeks, and I got tired of reading them.

A file of standing instructions is impatience in plain text. Each line marks a place where someone got angry once and decided to stay angry only once. A model doesn't tire of repeating itself, so it can't notice when it is.

Hubris: sign it

Wall's definition has two halves, the pride that makes you maintain programs other people won't criticize and the excess that gets you zapped. Vibe coding gives you both. It lets a person attempt systems far past what they could have typed in a year, which is hubris of the zappable kind and a large part of the appeal. The other half decides whether the attempt survives, and it comes down to reading what you ship as if the person who inherits it will read it back to you.

My rule on that: "ABSOLUTELY NO placeholders, mock data, dummy data, or failover data. These mask real problems…" Code that fakes success is code you would be embarrassed to have examined, and a model will produce it on request.

The machine has neither half. It has no reputation to protect and nothing to be zapped for, and it will call the code perfect in the same tone whether it is or not. That is a clinical description, not an insult, and I argued it at length in Every AI Is a Sociopath. By Design.

Three questions before you accept the code

  • Laziness: What is the smaller version of this?
  • Impatience: Have I told it this before? If so, write it down where it will find it.
  • Hubris: Would I sign this, knowing who has to maintain it?

Wall called them virtues, and a virtue is a habit you keep up on purpose. For most of programming history the typing kept it up for us.