Why Programmer Laziness Still Matters in the Age of AI

The three virtues of a great programmer are laziness, impatience and hubris. Those sound like terrible qualities, but the joke has a serious point: impatience makes you want to fix a recurring problem, confidence makes you think you can, and laziness pushes you to solve it so you do not have to keep doing the work.

As the way we write code changes, the meaning of laziness changes too. A programmer can now produce a great deal by throwing prompts at a model, but that is not necessarily the kind of effort-saving design these virtues describe. Bryan Cantrill’s essay “The Peril of Laziness Lost” made me want to revisit the distinction.

The formulation comes from Larry Wall’s Programming Perl. Its playful definitions connect laziness with building labor-saving tools and documenting them, impatience with making software anticipate needs, and hubris with the pride that drives someone to write and maintain work others can respect. They are lenses for thinking about software, not literal hiring criteria.

Abstraction can replace repeated copying with a loop, a function or another reusable idea. But an ever-growing mountain of abstractions can also be a mistake. The challenge is to remove unnecessary work and complexity without adding more machinery than the problem warrants.

Cantrill argues that meaningful laziness takes work: you turn the problem over, invest effort now and find a simpler abstraction that saves time later. When it works, the benefit extends beyond the original author to people who build on the system. Simplicity is something to design, not an excuse to avoid thinking.

That is why I enjoyed working on the T3 Stack. I wanted the computer to tell me when I made mistakes across the boundary between the frontend and backend. I found some existing approaches too heavy to set up, so the aim was a smaller set of abstractions that made full-stack type safety easier to use.

The origin story also fits the three virtues. I wanted to explain the stack once instead of repeatedly answering the same questions. A community member, Nexile, originally built create T3 app as a quick way to set it up; other contributors joined, including Julius, who later became deeply involved in our projects.

Seeing other developers use that work is satisfying because a good abstraction lets more people build things with less friction. Cantrill hopes people who benefit from abstractions will carry that effort forward by improving their own systems. But as more people create software, the original, ironic meaning of programmer laziness can get lost.

Cantrill contrasts this with a culture of appearing busy and celebrating how much code one produces. Language models can amplify whatever disposition their users bring to them. If the goal becomes the feeling of productivity, a rapidly growing code count may be mistaken for an improvement in the software.

The essay cites Garry Tan’s post claiming 37,000 lines of code a day across five projects and contrasts it with a rough count for DTrace. I agree that treating lines written as the headline achievement is a poor way to judge engineering. These counts use different contexts and do not by themselves establish the quality of either project.

I remember reducing a friend’s example full-stack application from several thousand lines to under 500 using the T3 Stack. My point is that a better abstraction can reduce the amount of code people must maintain. Fewer lines do not automatically prove correctness or remove the need for appropriate testing.

Cantrill cites another engineer’s inspection of a newsletter site that reportedly loaded unnecessary artifacts, including test harnesses and multiple logo variants. He treats those fixable issues as an illustration of a broader risk: unchecked generation can add layers of material without asking whether they simplify the system. The example is his cited account, not my independent audit.

I worry that models may make it easier for difficult codebases to persist: they can keep adding changes to a system a human team would struggle to maintain. That is a concern about incentives and outcomes, not proof that every AI-maintained project will become unmaintainable. Human review and deliberate cleanup still matter.

Cantrill’s argument is that finite human time and attention push us toward clear abstractions. A model has no personal stake in the future cost of maintaining what it generates; the team must set that objective and evaluate the result. Running a model consumes resources, but it does not experience maintenance effort the way a human does.

This is not an argument to reject LLMs. Cantrill describes them as tools that can help address technical debt and improve engineering rigor. I agree: use the model for the difficult work, but direct it toward a simpler, more powerful system that future maintainers can understand.

I am glad to see a middle ground between people who value clean code but dismiss AI and people who celebrate huge volumes of generated code. Robert C. Martin, known as Uncle Bob, argues that spending less attention on syntax can free us to think about more important problems.

I have criticized some clean-code patterns for over-abstraction, and I still think that is a real danger. The balance is to make the system as simple as it can be without hiding essential complexity. If AI handles more syntax, we still need to care about unnecessary bloat and the design of the whole system.

Theo plays a clip from a Bryan Cantrill talk about Oracle and OpenSolaris. Cantrill uses a deliberately sharp lawnmower analogy to argue against attributing human feelings or concern to the company’s behavior. It is his rhetorical characterization of that history, not a factual account of anyone’s inner motives.

I bring the analogy back to language models: we cannot rely on a tool to care about software quality on our behalf. People must decide what matters, guide the work and inspect the result. Otherwise the output may appear to work while accumulating complexity that erodes the system over time.

The goal is to stay lazy in the productive sense: use automation and thoughtful abstractions to save future effort, while remaining responsible for the quality of what we build. Keep prompting, but keep trying to make the software better too.