Every delivery metric I watch got better after my team started building with AI. Throughput up, time from open to merge down, review latency flat under load. If you only looked at the delivery dashboard, the story was unambiguous, and I want to be clear that the improvement is real. I’m not about to argue the gains are fake.
I’m going to argue something less comfortable. The dashboard went green, and that made it harder to see the two things that got worse.
What a delivery dashboard is actually measuring#
The standard delivery metrics measure motion through a pipeline. How often you ship, how long a change takes to get from written to running, how often it breaks, how fast you recover. They’re good metrics. I’ve used them for years, I still do, and the DORA framing that popularized them was a genuine step up from counting story points.
But look at what they have in common. Every one of them measures a change that already exists. They start counting at the moment someone decided what to build and started building it. Everything upstream of that, the deciding, the arguing, the discarded option, is outside the frame. A pipeline metric cannot tell you whether the thing moving through the pipeline was worth building. It can only tell you it moved quickly.
That’s fine when the constraint is the pipeline. For most of my career it was.
The two things that got worse#
Neither of these was on a chart, which is exactly the point. I noticed both the way you notice anything unmeasured, which is late and by accident.
Confidence in the plan thinned out. Not the plan itself. The team’s belief in it. Planning conversations got shorter, partly because building got cheaper, and cheap building quietly changes the calculus of a planning meeting. When a spike costs three days you argue about which spike. When it costs an afternoon you run all three and sort it out later, which feels like pragmatism right up until nobody can say why the roadmap is what it is.
Production debugging didn’t improve, and I think it got slightly worse. Every other capability on the team went up. That one flatlined. It’s the skill that depends most on having built the thing yourself, on remembering which corner you cut at 4pm on a Thursday, and it’s the skill AI does least to help with, because the debugging you’re doing is on code whose construction you never watched. I’ve written about reviewing a diff you didn’t watch grow, and this is that problem showing up at 2am with a customer on the other end of it.
The mechanism, as best I can reconstruct it#
Throughput goes up. More work is in flight. More work in flight means more context switching and more compressed planning, because the planning has to serve more parallel threads with the same amount of human attention. Compressed planning and heavy switching are exactly the conditions under which judgment gets worse. Not knowledge. Judgment: the thing that tells you this plan is thin, or that this bug smells like the auth path.
So the same motion produced both effects. AI raised throughput, and the friction that came with the throughput ate into the judgment layer. It didn’t trade one for the other in some grand bargain. It just did both at once, and only one of them had a chart.
That’s the amplifier thesis at team scale. It’s also the same shape as the cost of cheap starts, one altitude up. What was individual context-switching tax becomes, across a team, a planning process that got quietly thinner while every delivery number improved.
Why this is a leadership problem specifically#
Here’s the trap, and it isn’t subtle once you see it.
The delivery dashboard is what a leader reports upward and what a leader steers on. When it goes green, the rational move is to add scope. That’s what green means. So you add scope, on top of a planning process that’s already thinner than it was and a debugging capability that’s quietly flat, and none of that shows up until an incident makes it show up. You’ve banked operational debt and the instrument you trust is telling you things are better than they’ve ever been.
I don’t think this is an argument against the metrics. It’s an argument that the metrics got more dangerous as they got easier to move. When throughput was hard to improve, a green dashboard was evidence of a lot of things going right. Now throughput is the cheapest thing on the board to improve, so it’s the weakest signal on the board, and it’s still the one sitting at the top of the deck.
The honest counter#
The thing I keep turning over is whether I’m reading a real decline or a shift in expectations. When a team ships twice as fast, the same planning process feels worse relative to the pace, even if it didn’t change. Some of what I read as eroding confidence might be a team holding itself to a bar that moved. I can’t fully separate those, and I’d be overclaiming if I said I could.
I’ve landed on this: it doesn’t change what to do about it. Whether the planning process got worse or merely got outgrown, it’s now the weakest part of how the team works, and it’s the part nobody is measuring.
What I’d watch instead#
Not more metrics. The failure here was trusting instruments that only pointed at motion, and the fix isn’t three more instruments pointed at the same place. It’s a handful of questions asked on purpose, out loud, at a regular cadence:
Can someone on this team debug a production issue in code the team didn’t write by hand? When we commit to a plan, does anyone actually believe it, or are we shipping fast enough that being wrong feels cheap? What did we decide not to build this quarter, and can we say why?
Those don’t produce a number, which is the problem with them and also the point. The things AI made worse on my team were the things nobody had a chart for. Adding a chart isn’t the answer. Noticing what the charts were never looking at is.
