Three months. That is how long it takes a vibe-coded codebase to start eating itself.
For a while nothing looks wrong, and that is the trap. The pull requests merge. The tests pass. The velocity dashboards stay green, and green is the only color anyone upstream ever checks. Then a senior engineer picks up a change that should be routine, a change that touches something real, and discovers that the system underneath has quietly rotted while every indicator said it was thriving. The work of the next two weeks is no longer the change. It is archaeology.
This is the same shape of problem that skill atrophy has, one level down. The cost is deferred and invisible while the benefit is immediate and legible, and an organization measures what is legible. But the earlier worry was about people, about the judgment that thins when the tool does the thinking. This one is about the artifact itself, the code your company actually owns and eventually has to stand up in front of an auditor, a customer, or a court. The people can be sharp and the review can be diligent, and the artifact can still be rotting, for reasons that have nothing to do with anyone being careless.
Four signatures of a rotting system
The decay is not mysterious once you know what to look for. It arrives in four recognizable forms.
The first is patches behind patches. A tool generating code cannot see the system it is editing; it sees the prompt and the file in front of it. So it fixes the symptom in front of it, cleanly and plausibly, and three sprints later the same defect resurfaces wearing different clothes, because the thing that actually caused it was never in view. Each fix is locally correct. The accumulation is a system nobody understands.
The second is tests that pass without verifying behavior. When the tests are generated alongside the code, they tend to assert whatever the code happened to do, not what it was supposed to do. The suite goes green. Coverage numbers climb. And none of it is evidence of anything, because the test and the code were written by the same hand telling the same story to itself. You have a smoke detector wired to confirm there is no smoke.
The third is the loss of any record of why. Ask why a particular function exists, why it handles that one edge case, why it was built this way and not the obvious other way, and increasingly there is no answer. The reason was a prompt, spoken once, and the prompt is gone. The code remains, unexplained, and unexplained code is code no one can safely change, because no one knows what it was quietly protecting against. An audit trail is not a compliance nicety here. It is the difference between a system you can reason about and a pile of decisions you have to reverse-engineer under deadline.
The fourth, and the most expensive, is integration drift. Each module, read on its own, is reasonable. The parts were produced in isolation, each locally plausible, and they were never made to agree with one another. So they don't. The seams hold under the demo and give way under load, and the failure lives in the space between components, where no single file looks wrong.
Where a nuisance becomes a liability
You might reasonably think the answer to all of this is more review, or better review. It is worth being precise about why that does not save you, because the instinct is so natural and so wrong.
Review, at its core, reads a change. A diligent reviewer looks at the diff in front of them and asks whether it is correct. But three of the four signatures above are not visible in any single diff. Integration drift lives in the relationship between changes, not in any one of them. The missing record of why is an absence, and absences do not show up in a diff. Tests that assert the wrong thing look, on the page, exactly like tests that assert the right thing. The reviewer can be fully attentive, fully skilled, entirely undulled, and still approve every individual change while the system as a whole loses its structure, because the thing being lost was never contained in a single change to begin with.
That is the uncomfortable core of it. The artifact rots even when review happens, because line-by-line review is the wrong instrument for this failure. It inspects the trees with real care while the forest quietly rearranges itself.
Coherence is made, not inspected
Which points at what coherence actually is. Coherence is not a feature you can bolt on at the end, or a property an inspector can certify back into a system after the fact. It is a property of how the work was produced: whether the parts were built with the whole in view, whether each piece was made to answer to a shared design, whether the reasons were kept as the thing was assembled. You cannot review coherence into a system any more than you can proofread structural integrity into a building that was already framed without a plan.
This is the message that needs to move upward from the engineering team. A system assembled without coherence cannot have coherence restored by looking harder at its output. The discipline has to live in how the work is produced, not in the inspection that comes after, and every process that pins its hopes on end-of-line review is quietly betting otherwise. That bet is the one coming due.
The bill
None of this lands on the developer who moved fast. The developer got the velocity, took the win, and moved on. The bill arrives later, and at a different desk. It lands on the ops team that cannot keep the thing running and cannot say why. It lands on legal and compliance when someone has to explain, on the record, why the system does what it does, and no one can. It lands on the board when a system everyone assumed was defensible turns out not to be. The people who pay for artifact decay are almost never the people who produced it, which is exactly why the incentive to prevent it is so faint.
So the honest way to read a green velocity chart is with a quieter question underneath it. If your AI output is compounding faster than your ability to understand it, you are not accelerating. You are accumulating, and the two feel identical right up until they don't.
None of which the codebase chose. A system does not decide to rot; it is rewarded into it. The four signatures are symptoms, and symptoms have a cause that sits upstream of the code, in what the organization actually pays for and what it quietly lets slide. That is the more uncomfortable question, and it is the one worth turning to next. Not why the codebase is decaying, but what keeps rewarding the thing that decays it.