The velocity spike that hid a growing review debt

A VP of engineering at a B2B software company told me about the month their velocity metrics looked incredible and their engineering health quietly got worse. They had rolled out AI coding tools, and by every number the leadership tracked, the team was flying. More pull requests, more commits, more tickets closed. The charts made a great slide. What the charts did not show was that reviews were getting shallower to keep up with the volume, engineers understood the code they shipped less well because they had written less of it, and a backlog of changes that nobody fully grasped was building underneath the numbers. The velocity was real and visible. The debt it was accumulating was real and invisible, and only one of the two showed up in the metrics.

Speed is easy to measure, health is not

Engineering metrics tend to measure output, because output is countable. Pull requests, commits, tickets, lines, deploys, all of these are easy to track and they go up when a team ships more. This is why a velocity spike is so visible. The things that increase are exactly the things the dashboards already count, so adopting a tool that increases output produces an immediately gratifying chart.

The health of the work is much harder to measure, and it moves in the opposite direction under the same conditions. Review depth, how well the team actually understands its own code, whether the changes are maintainable, whether the person who shipped a thing could debug it later, none of these are on the dashboard, because none of them are easy to count. So when AI tools raise output and lower these at the same time, the dashboard shows only the rise. The team looks faster and is quietly getting more fragile, and the fragility does not register until it turns into something countable, like an incident, a stalled review queue, or a feature nobody can safely change. By then the debt has been building for a while, hidden behind metrics that were only ever watching the good half of the picture.

The trap is that the visible metric encourages more of exactly the behavior that grows the invisible debt. Leadership sees velocity up, asks for more, the team leans harder on the tools, output rises further, review and understanding thin further, and the debt compounds while the slide keeps improving. The measurement system rewards the thing that is hurting the team, because it cannot see the harm.

Measure the health under the speed

The lesson is that a team adopting AI tools has to measure the things that erode invisibly, not just the output that rises visibly, or it will optimize itself into a fragile state that looks like a triumph on the dashboard. The health metrics are harder to capture, and that is exactly why they need deliberate attention.

What teams watch to see the debt under the velocity.

Review depth, whether reviewers can actually explain the changes they approve, not just how fast approvals happen.
Understanding, whether the person who shipped a change could debug it a month later without help.
The review queue, whether changes are piling up faster than they can be reviewed well.
Rework and incidents over time, since debt eventually surfaces as things breaking and being redone.
Maintainability signals, whether the code being shipped is something the team can safely change later.

The output metrics are not wrong, they are just half the story, and the half they leave out is the half that determines whether the velocity is sustainable or borrowed.

How we think about it at Density Labs

The velocity spike that hides review debt is one of the most seductive patterns in AI adoption, because the visible metrics all improve while the invisible ones decline, and the visible ones are the ones on the slide. Leadership sees a triumph, asks for more of it, and the team accumulates fragility that will surface later as incidents and rework nobody connects back to the tooling.

When we help a team adopt AI tools well, we insist on watching the health under the speed, so the debt is visible while it is small instead of after it has compounded. The goal is velocity that the team can sustain, not a chart that looks great right up until the backlog of un-understood code catches up.

A velocity chart shows you the output going up. It will not show you the understanding going down, and both are happening.