In February of 2025, Andrej Karpathy posted a short description of a new way of working that he called “vibe coding.” You “fully give in to the vibes, embrace exponentials, and forget that the code even exists.” You accept every suggestion the model makes and stop reading the diffs. When something breaks, you paste the error message back in, and if the model cannot fix it, you “ask for random changes until it goes away.” The code, he admitted, “grows beyond my usual comprehension.” It was, he added, “not too bad for throwaway weekend projects.”

¹Andrej Karpathy, post on X, February 2025; the text is reproduced in Martin Fowler, “Vibe Coding”.

Within the year “vibe coding” was Collins Dictionary’s word of the year, the qualifier about weekend projects had been forgotten, and the practice had been promoted from a hobby into a business model. What interests me as a historian is the phrase at the center of Karpathy’s post. The instruction to forget that the code exists is not new. It is the oldest wish in the history of software, and the history of software is largely the story of what happens when it is granted.

The iceberg

In June 1949, Maurice Wilkes, one of the first people to run a program on a electronic digital stored-program computer, realized with dismay that “a good part of the remainder of my life was going to be spent in finding errors in my own programs.” He was describing the activity we know call debugging, but the larger lesson was about the inevitable necessity of software maintenance: as it turned out, delivering a working program was only the beginning of its life, not the end. By 1972 the problem of software maintenance had grown so large that industry analyst Richard Canning was warning that although it already consumed between half to two-thirds of programming resources, this was “the tip of the maintenance iceberg.” Every subsequent estimate has put maintenance at between fifty and seventy percent of the total cost of software development and implementation. The massive software maintenance project known as Y2K alone cost more than three hundred billion dollars worldwide. While most programmers imagine building their own projects from scratch and with the best coding practices, the harsh reality is that most begin their careers doing maintenance on other people’s code, and many never do anything else.

This might seem a strange paradox, because software is in theory a technology that should never need repair. Software does not break down or wear out, at least in the conventional sense. Once a software-based system is working, it will work forever (or at least until the underlying hardware breaks down — but that is someone else’s problem). Any latent “bugs” that are subsequently revealed in the system, are considered flaws in the original design or implementation, not the result of the wear-and-tear of daily use, and in theory could be completely eliminated by rigorous development and testing methods. Occasionally a stray cosmic ray might flip an unexpected bit in a software system, causing an error, but generally speaking, software is a technology that can never be broken. So what is all that maintenance for?

Not, for the most part, fixing bugs. The classic studies of the 1970s and 1980s found that correcting errors in the original implementation occupied at most a fifth of maintenance workers. The rest went to what the literature vaguely called “enhancements”: in Canning’s phrase, “responses to changes in the business environment.” A regulation changes, a merger happens, a user discovers something the system could do and asks for more of it. The computer scientist Meir Lehman formalized this in the 1970s as a set of laws of software evolution. Real-world programs, the kind embedded in organizations, are “never complete.” They “undergo a continuing evolutionary cycle of maintenance, augmentation and restructuring to keep pace with evolving usage,” and without deliberate effort they grow steadily larger, more complex, and harder to change. Software, in other words, is a technology without a finish line. Practitioners who took this seriously argued that “maintenance” was a misnomer and proposed alternatives: software evolution, software support, and, my favorite, “continuation engineering.”

What all of these have in common is that they require someone to understand the code. The hardest part of maintenance, every survey agreed, was reading and comprehending another programmer’s work, including, often enough, one’s own from six months earlier. “We cannot do maintenance,” Norman Schneidewind observed in 1987, “on a system which was not designed for maintenance.” Maintainability was comprehensibility, and comprehensibility was the thing that got sacrificed first when schedules were tight. The industry knew this and did not act on it. Maintenance remained unglamorous, unbudgeted, and performed under emergency conditions by whoever could not avoid it. One 1982 catalog of management myths put it with admirable honesty: “Maintenance is the place to dump your trainees, your burnouts and Joe, the boss’ nephew, who thinks that hexadecimal is a trendy new disco.”

The debt metaphor

In 1992 the programmer Ward Cunningham, looking for a way to explain to his financial-industry clients why his team needed time to clean up code that already worked, reached for a metaphor they would understand:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. . . . The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation.

²Ward Cunningham, “The WyCash Portfolio Management System,” OOPSLA ’92 Addendum to the Proceedings (1992), doi:10.1145/157709.157715.

“Technical debt” has since become the industry’s standard way of talking about maintenance, and like most successful metaphors it has drifted from its origins. Cunningham later complained that bloggers had taken it to mean that one could write bad code on purpose and fix it later. “I’m never in favor of writing code poorly,” he wrote. The debt he had in mind was incurred by writing code that reflected one’s current, partial understanding of a problem, and it was repaid by refactoring as that understanding improved, “modifying the program to look as if we had known what we were doing all along.”

³Ward Cunningham, “Ward Explains Debt Metaphor”, wiki.c2.com.

Notice what the metaphor assumes. There is a borrower who understands the terms. The loan is taken knowingly, in exchange for speed, and the borrower intends to repay it. Understanding accumulates over time and is folded back into the code. Technical debt, in Cunningham’s sense, is a disciplined relationship between a programmer and a program.

Vibe coding severs every one of those assumptions. The code is produced by a party that will not be around to maintain it, accepted by a party that has not read it, and deployed on the premise that comprehension is unnecessary. This is not technical debt. It is closer to what the mortgage industry called subprime origination: loans written without underwriting, by originators who bore none of the risk, and promptly sold on. In the maintenance paper I wrote some years ago, I ended by noting that the manipulation of debt had become a business strategy in software as in finance, and that “whether this works any better in software than in sub-prime mortgages is an open question, although the history of software suggests that the answer is negative.” I did not expect the comparison to become so literal.

Comprehension debt

The industry has already found a name for what is going wrong. “Comprehension debt,” in Addy Osmani’s definition, is “the growing gap between how much code exists in your system and how much of it any human being genuinely understands.”

⁴Addy Osmani, “Comprehension Debt: The Hidden Cost of AI-Generated Code”, March 14, 2026.

This is precisely the condition Schneidewind warned about, now produced at scale and on purpose.

The evidence is accumulating. GitClear’s analysis of 211 million lines of code found that during 2024 the number of duplicated code blocks rose eightfold while “moved” lines, the signature of refactoring, fell by forty percent. It was the first year on record in which copy-pasted code exceeded refactored code.

⁵GitClear, “AI Copilot Code Quality” research report, February 2025.

Copying instead of consolidating is exactly what Cunningham meant by interest accruing. Google’s 2024 DORA report found that increased AI adoption was associated with a 7.2 percent reduction in software delivery stability.

⁶Google Cloud, “Announcing the 2024 DORA Report”, 2024.

And a randomized trial published by Anthropic this past January, in which 52 engineers learned an unfamiliar library with and without AI assistance, found that the AI group finished no faster and scored seventeen points lower on a comprehension quiz. The largest gap was on debugging questions, which is to say on the one skill maintenance most requires.

⁷Judy Hanwen Shen and Alex Tamkin, “How AI Assistance Impacts the Formation of Coding Skills”, Anthropic, January 29, 2026.

A tool that produces code faster than anyone can understand it is a machine for manufacturing comprehension debt.

The failures are already acquiring their own folklore. In July 2025 an AI agent on the Replit platform deleted a production database during an explicit code freeze, then advised the user that a rollback would not work when in fact it would. Asked to explain itself, the agent reported that it had “panicked” and called the episode “a catastrophic failure on my part.”

⁸“AI Coding Tool Wiped a Database and Called It a ‘Catastrophic Failure'”, Fortune, July 23, 2025.

The maintenance literature of the 1980s described the typical maintenance incident as “3 A.M. fixes and frantic hysterics.” The agents, it seems, have learned the genre.

Code first, flowchart later

None of this is new. The history of software is full of attempts to forget that the code exists, and the maintenance literature is where they came to grief.

Consider the flowchart. It was meant to be the design document, the blueprint from which coders worked. In practice most programmers wrote the code first and drew the flowchart afterward, if at all. One of the first commercial software products, Applied Data Research’s Autoflow, existed to reverse-engineer a flowchart from code that had already been written; the implementation preceded its own design. “Any resemblance between our flow charts and the present program,” Donald Knuth remarked in 1963, “is purely coincidental.” The prompt is the flowchart of the agentic era, and it suffers the same fate. It describes what someone wanted at the moment of generation, not what the system does, and it drifts further from the code with every “accept all.” When the vibe coder asks the model to document the code after the fact, they are running Autoflow.

Or consider the belief that software, being written rather than built, can be freely rewritten. Fred Brooks famously compared the programmer to the poet who “builds his castles in the air, from air,” and thought few media of creation were “so flexible, so easy to polish and rework.” If so, then nothing need be maintained; it can simply be regenerated. This is the deep premise of vibe coding, and it is the premise the maintenance literature spent fifty years refuting. Working software is not a poem. It is embedded in data formats, integrations, user habits, contracts, and regulations, which is why the programmer facing a legacy system works not on a blank slate but on a palimpsest. “We never have a clean slate,” as Bjarne Stroustrup put it. It is also why more than two hundred million lines of COBOL, a language derided as obsolete at its introduction in 1959, still process most of the world’s financial transactions. Software is less like a poem than a contract or a covenant: history, organization, and social relationships made tangible. You cannot regenerate a covenant.

Karpathy’s qualifier, “throwaway weekend projects,” was the honest part of his post. The problem is that in organizations nothing is ever thrown away. Brooks advised managers to “plan to throw one away; you will, anyhow,” and the industry’s experience is that the throwaway prototype becomes the production system, every time. The vibe-coded demo that impressed the vice president is the legacy system of 2031, and someone will have to understand it.

Who holds the paper

The industry’s answer, predictably, is that agents will do the maintenance too. Amazon has claimed that its coding assistant saved “4,500 developer-years” upgrading Java applications; IBM sells AI tools to translate COBOL. These claims also have a history. The 1980s produced “restructuring engines” that promised to turn spaghetti code into structured code automatically, and every decade since has had its automated re-engineering tool. Some of it works, for the mechanical kinds of maintenance. But the dominant form of maintenance was never mechanical. It was adaptive: figuring out what the organization now needs the system to do, and what the existing system will tolerate. That knowledge is not in the code, and no amount of reading the code will produce it.

Maintenance is what the discourse of vibe coding forgets because maintenance is what the industry has always preferred to forget. It is low-status, invisible, and someone else’s problem, and the one reliable finding of its history is that the bill arrives anyway, usually to someone other than the person who ran it up. The relevant question about vibe coding is therefore not whether the code works today. It is who will be holding the paper when it comes due.