Who Understands Code That Nobody Actually Wrote?

A Program Is More Than Its Code

Comprehension debt is the gap between the code a system contains and the understanding anyone holds about it. It accumulates when software is produced faster than it is read, and unlike technical debt it is invisible until someone has to repay it under pressure.

In early 2025, Andrej Karpathy popularized the term vibe coding to describe a style of programming in which the developer leans fully on an AI model, accepts its output, and largely stops reading the code. For prototypes and personal projects, that is a liberating way to work. Ideas become working software almost as fast as they can be described.

The trouble starts when that software becomes something an organization depends on. Code that was accepted without being understood still has to be maintained, debugged, secured, and changed. Someone eventually has to understand it. Often, nobody does.

In 1985, the computer scientist Peter Naur published an essay called “Programming as Theory Building.” His argument was that the real product of programming is not the code but the understanding in the programmers’ heads: a theory of how the program relates to the problem it solves, why it is structured as it is, and how it can sensibly be changed.

Naur observed that when the people holding that theory leave, a program can effectively die even though its code still runs. New programmers can read the code, but they cannot easily reconstruct the theory behind it, so their changes tend to fit poorly and degrade the system over time.

Vibe coding raises an uncomfortable possibility that Naur did not have to consider: a program whose theory never existed in anyone’s head at all.

Comprehension Debt vs Technical Debt

Software teams have long used the metaphor of technical debt, introduced by Ward Cunningham, to describe shortcuts that make future changes harder. Technical debt is usually a known trade-off. The team understands the shortcut and chooses to pay it back later.

Comprehension debt is a useful name for something different: the gap between how much code a system contains and how much of it anyone actually understands. The code may be perfectly reasonable. The problem is that no person can explain why it works, what it assumes, or what will happen if it changes. That debt is invisible until someone needs to repay it, usually under pressure.

The Two Debts Compared

The row that matters most is the fourth. Technical debt is a decision somebody made and can therefore describe. Comprehension debt is a by-product nobody chose, which is why no one is tracking it and why it keeps growing while the dashboards stay green.

It Grows Fastest When Things Are Going Well

Comprehension debt accumulates most quickly during periods of success. A team that is shipping features rapidly with AI assistance feels productive, and in a narrow sense it is. Each new feature works. Each generated change passes its tests, if there are tests.

But each change also adds code that nobody has fully reasoned through, interacting with earlier code that nobody fully reasoned through either. The system grows in complexity faster than anyone’s understanding of it. Because nothing is visibly broken, there is no signal that the debt is building.

Speed also changes how code is reviewed. When a person writes code line by line, understanding comes with the writing. When a model produces hundreds of lines in seconds, review becomes the only point where understanding can form, and review is exactly what fast-moving teams are tempted to skip. The faster code is produced, the more discipline it takes to keep up with it, and the less likely that discipline is to survive a busy quarter.

Why AI-Generated Code Fails in Incidents

The cost of comprehension debt appears when something goes wrong. A report shows the wrong numbers before a board meeting. Some users can see goals they should not. Data from one team overwrites another’s. Diagnosing these problems requires knowing how the system actually behaves, not just what it was asked to do.

In a well-understood system, an experienced engineer can often narrow down the cause quickly. In a system nobody understands, diagnosis becomes trial and error. Asking an AI model to fix the problem may help, or it may produce a confident change that solves the symptom and creates a new problem elsewhere. Under time pressure, with leadership waiting, that is a difficult position.

Security Depends on Understanding

Security is where comprehension debt is most dangerous. Protecting sensitive data requires knowing exactly where it flows, who can reach it, and what checks stand in the way. AI-generated code can contain subtle weaknesses, such as missing permission checks or unsafe handling of input, that look correct at a glance.

Finding those weaknesses requires someone to read the code carefully with security in mind. If the code was accepted without close review, the weaknesses may sit unnoticed until they are exploited. For a system holding strategy and performance data, the consequences of that are serious.

This is the same set of obligations covered earlier in the series as the requirements nobody prompted for. The difference here is that you cannot satisfy them by adding code. You have to be able to read what is already there.

Regenerating Is Not the Same as Maintaining

One response to comprehension debt is to treat code as disposable: if something is hard to understand, ask the model to rewrite it. For a small, isolated tool, that can work. For a system with real users, data, integrations, and history, it rarely does.

A rewrite has to preserve every behavior that people depend on, including the ones nobody remembers asking for. Without an understanding of what those behaviors are, a regenerated component can quietly change how scores are calculated, how permissions apply, or how data is stored. The system looks fresh and works differently, and users discover the difference before the builders do.

For strategy software, those quiet changes are especially damaging. If the way progress is calculated shifts between one quarter and the next, comparisons over time become meaningless. If the logic behind a performance-related score changes without anyone noticing, decisions about people may rest on numbers that no longer mean what everyone assumes. Consistency is not a technical nicety in this domain. It is what makes the data trustworthy.

How a Specialist Vendor Keeps the Theory Alive

A mature software vendor addresses this problem deliberately. Its engineers work on the same platform for years, building and passing on a shared understanding of how it works. Code is reviewed by people other than its author. Architecture decisions are recorded. Tests capture expected behavior so that changes can be checked against it. AI tools are used to speed up this work, not to replace the understanding behind it.

Most importantly, a vendor’s whole business depends on its ability to change its platform safely, over and over, for many customers. That creates strong incentives to keep the theory of the program alive. An internal team maintaining a vibe-coded app rarely has the time, the process, or the incentive to do the same.

Profit.co keeps part of that theory where customers can read it. A help center carries guides for every feature, the Answers library explains how specific capabilities work, and the release updates page records what changed and when. When a number looks wrong before a board meeting, the first step is reading the documentation, not reverse-engineering the code.

AI-assisted development is a powerful tool, and it will keep getting better. But the speed of writing code was never the main constraint on software that lasts. Understanding was. For systems an organization depends on, the question is not only whether the code works today, but whether anyone will be able to explain it the day it stops.

Understanding is one thing an organization must fund to keep an internal system alive. The next article looks at another: the roadmap.