A system does not decide to rot. It is rewarded into it.
That was where the last piece left off, with a codebase quietly decaying and a question hanging over it: if the code did not choose to degrade, what kept rewarding the thing that degraded it? This is the answer, and it is less comfortable than a bug, because it is not in the code at all. It is in what the organization measures.
Start with the people who can see it. The developers know. They told a reporter what was happening in their own shops, and they did it anonymously, because saying it under their own names would have cost them something at work. That detail is not incidental. It is the whole story. When the people closest to the artifact can see the rot clearly and still cannot say so out loud, something upstream of them is preventing the correction. It has a name, and the name is velocity addiction.
What the dashboard counts
Look at what leadership actually watches. Lines shipped. Pull requests merged. Features per sprint. Story points burned down. Every one of those is a measure of motion, and not one of them can tell the difference between a feature that works and a feature that will fail in production six months from now. Dashboards count what left the building. Most dashboards don't have a column that counts what comes back.
A metric that cannot distinguish durable work from fragile work does not stay neutral about the difference. Over time it chooses. Fragile is faster to produce, so fragile scores higher on every chart that measures production, and the people who produce it are rewarded a little more, promoted a little sooner, held up as a little more effective than the colleague who spent the extra day making the thing hold. You did not decide to prefer fragile work. You built an instrument that cannot see durability, pointed all your incentives at it, and let it prefer fragility on your behalf.
How it becomes normal
None of this arrives as a crisis, which is exactly why it is dangerous. Each shortcut that ships without blowing up makes the next shortcut feel a little more ordinary. The corner cut last quarter and survived becomes the baseline this quarter, and the new corner is cut from there. This is the ordinary way a standard erodes: not through a decision to lower it, but through a long series of small exceptions that never cost anything, until the exception is the standard and no one can point to the moment it changed. It is the normalization of deviance, and it does not feel like decline from the inside. It feels like getting faster. The drift is not catastrophic until it is, and by then the practice is institutional, defended, and expensive to reverse.
This is a leadership problem, not a discipline problem
It is tempting to read all this as a workforce that needs to try harder, and that reading is both flattering to leadership and wrong. The developers shipping fast and fragile are not being lazy or careless. They are being rational. You have told them, through the only signal that reaches them reliably, that what you value is volume, and they are giving you volume. The one who slows down to make the work durable looks worse on the exact chart that decides their review, so the incentive quietly punishes the behavior leadership claims to want. Reward implementation volume and you will get implementation volume, in enormous quantity, whether or not any of it lasts. People optimize for the number that is watching them. That is not a flaw in the people. It is the design working as built.
The adoption you actually bought
Here is the part that should concern an owner most, because it reframes what these tools were supposed to do for you. You adopted AI to go faster, and you are going faster, and you have measured that speed carefully. What you did not adopt, and did not budget for, and are not measuring, is any way to keep what that speed produces durable. So the dashboard shows adoption climbing, more output, more velocity, more shipped, while the actual worth of that output quietly turns negative under the weight of the symptoms the earlier pieces described.
That is the trap hiding inside the word. Velocity metrics measure adoption as sheer output volume, and volume is motion, not value. You can be adopting a tool faster every quarter by that measure and getting less from it every quarter in reality, because the thing you scaled was production and the thing you skipped was everything that makes production worth keeping. Real adoption of one of these tools was never how much it lets you generate. It is whether what it generates survives contact with the actual world. Measure the first and call it the second, and you will fund your own decay and put it on a chart labeled progress.
The move, and the person it lands on
The first move is not a better tool, and it is certainly not more speed. It is smaller and harder than that. It is admitting, out loud and at the top, what the dashboard is actually counting, and what it has been quietly counting all along.
But naming the metric is the owner's move, made from a comfortable distance. There is someone much closer to this than the board is, and it is worth ending with them. Picture the developer caught in the middle of it: able to see the rot as clearly as anyone, unable to say so without cost, and measured all day, every day, on precisely the throughput that is producing it. Told to go faster by the chart, and to be careful by their own judgment, and left to reconcile the two on their own time. What is that person's day actually like? That is the next question, and it is not a comfortable one.