A developer writes the same forty-line function for the third time. By the fourth, something revolts. Not intellectually — physically. The tedium accumulates until the only tolerable response is to make it stop. They write a helper. Then a module. Then an abstraction that handles every case.
Their AI pair programmer would have written it a fortieth time without flinching. Token number 1 costs the same as token number 10,000. There is no boredom, no accumulating sense of waste, no pressure to compress. And — less discussed — no commercial incentive to develop one. Verbosity is not a failure mode for a system that bills by the token. It is the business model working as designed.
Bryan Cantrill, who has spent thirty years writing operating systems, named this: the virtue of laziness. Not laziness as character flaw. Laziness as engineering force. Every elegant abstraction in the history of software exists because a human got tired of doing the same thing twice.
The problem runs deeper than incentives. AI models optimise for the most statistically probable next token. The most probable code across millions of repositories is not an elegant abstraction — it is boilerplate. The same function signature, the same error handling, the same pattern repeated with minor variation. That is what the training data looks like. The model reproduces it faithfully.
To write an abstraction, the model would have to break the statistical pattern and establish a higher-order rule — sacrifice local probability for global coherence. That is precisely what human laziness forced us to do. It is precisely what a probability engine is least inclined to attempt.
Yes, you can prompt for it. You can instruct the model to refactor, to extract common patterns, to prefer compression. System prompts, coding standards injected into context, memory overlays that carry architectural rules between sessions — all of these help. They work. But they require someone who already knows what good abstraction looks like to write those instructions. The model does not arrive at compression on its own. It must be directed there by a human who has internalised the pattern.
Since the earliest days of programming, the ability to abstract — to see the shape beneath repetition and name it — was how engineers developed. Junior developers wrote the boilerplate. The good ones felt the friction. The friction taught them to compress. Not a lecture, not a book — the lived experience of repetition creating the pressure to find a better way.
Across the industry, those junior roles are disappearing. Companies are hiring fewer entry-level developers, augmenting smaller teams with AI instead. The apprenticeship — the period of friction that produced the instinct for abstraction — is being removed at the same time that the need for people who can direct AI toward good structure is growing.
This is not a Luddite argument. AI-augmented teams produce more, faster, at lower cost. That is real and valuable. The question is what happens to the pipeline. The people who can look at AI-generated output and see the sixty lines hiding inside four hundred — who can write the system prompts that enforce coherence — learned that skill through friction that no longer exists for the next generation.
The write-only code problem is one layer. The question of who writes the constraints — and where they learned to — is the layer beneath.
Unix pipes, Git, REST — each emerged because someone lived with the pain of the un-abstracted state long enough to see the compression. McIlroy wanted to stop writing custom programs to chain operations. Torvalds needed version control that could handle thousands of distributed contributors. Fielding was trying to bring architectural coherence to the early web.
None of them set out to build an abstraction. They set out to stop hurting. The instinct to compress came from the lived experience of the un-compressed state — and that instinct is the thing that no model will produce on its own.
The practical question for any team operating with AI is not whether to use it — that question is settled. It is who on the team still carries that instinct. Not what is wrong with the code — AI is getting very good at generating code that runs. What is missing: the load-bearing architectural choice that was never made because the model had no reason to make it.
That role — part architect, part editor — is becoming the most critical in an AI-augmented engineering organisation. And the pipeline that produces those people is the thing being quietly eroded.
Cantrill surfaced the mechanism. We thought our constraints were limitations. We built entire philosophies around overcoming them — faster machines, better languages, more abstraction.
Now we have a tool with no constraints at all. What it produces is a world where craft has relocated to the people who remember what friction felt like — and who can teach a machine to care about something it will never feel.
The practical response is to hire differently and structure teams around the gap. Test for the ability to compress, not the ability to produce. Make the architect-editor explicit — the person who sees sixty lines inside four hundred. Named, resourced, defended in budget conversations.
That costs velocity now. There is no way around it. Maintaining the capacity to see sixty lines inside four hundred means keeping people whose immediate output is not more code but better structure — and that is a difficult line to hold when the pressure is to ship. The alternative is discovering the deficit in three years, when the people who could see it have moved on and nobody remembers what was lost.
The virtue was never laziness. The virtue was the constraint that made laziness productive.
References and further reading
Cantrill, B. (2026, April 12). The Peril of Laziness Lost. Bryan Cantrill's Blog. bcantrill.dtrace.org
Ruscio, J. (2025). Write-Only Code. josephruscio.com
McIlroy, M.D. (2019). Oral History. Computer History Museum. archive.computerhistory.org
Git — A Short History of Git. git-scm.com
Fielding, R.T. (2000). Architectural Styles and the Design of Network-based Software Architectures. University of California, Irvine. roy.gbiv.com