The AI Leak Vanishes for One Person and Reappears for a Team. That Tells You Where It Lives

The gains don't disappear in the pipeline. They disappear in the space between people, which is the one place your delivery metrics can't see.

A clue hiding in a non-answer

I asked a senior staff engineer where AI gains leaked on his teams, and his answer was that they didn't. Not evasively, he genuinely wasn't seeing our 14-to-6 gap. He works almost entirely through AI now: he specifies the task, generates the code and tests, reviews the output, refines the prompt, and ships. Faster on every axis, no obvious leak.

For a moment that looks like a counterexample. It's actually the most useful data point I collected, because of why the leak doesn't appear for him.

He described a single loop, run by one person. The same human writes the specification, generates the code, and verifies it: all in one head, with no handoff. And that's the tell. Our leak isn't a property of AI-generated code. It's a property of the handoff: one person generates quickly, a different person has to review it and reconcile it with how the team works, and the value stalls in the gap between them. Remove the second person and there's no gap. Nothing to translate, nothing to coordinate, nothing to wait on.

So the leak didn't vanish because he found a better way to use AI. It vanished because he removed the thing the leak lives in: the space between people. Which means the leak was never really about AI, or about code. It's a coordination phenomenon. It shows up wherever work has to pass between humans, and it disappears wherever it doesn't.

That reframes the entire problem. If the constraint is coordination, then the more AI accelerates the individual, the more the bottleneck relocates to the one thing AI at the keyboard doesn't touch: how a group of people move work between themselves.

The slime mold

An engineering manager at a large hardware company pointed me at a piece I've thought about constantly since: Alex Komoroske's work on why large organizations slow down, framed through the behavior of slime molds. The core move is unsettling: coordination drag is emergent. It appears even when every individual is competent, hardworking, and acting in good faith. As an organization grows, the system starts to dominate the individuals in it. Nobody is doing anything wrong, and it gets slower anyway.

His own summary of the effect was precise: "It's definitely not random, but to the casual observer it looks random." That sentence is worth sitting with, because it's the exact signature of something worth measuring. A thing that looks random but isn't is a thing whose structure is invisible until someone instruments it. Whack-a-mole feels like whack-a-mole right up until you decompose the flow and discover the moles are all coming from the same two holes.

He also said something I want to take seriously rather than argue with: that his organization already has, or could harvest, plenty of metrics about the software lifecycle, and that the real problem is "people, org structure, and other complexities." He's right that lifecycle metrics won't find it. But that's not because the coordination drag can't be measured. It's because it's being measured in the wrong layer. A slime mold is a network. You don't find its structure by timing how long each cell takes. You find it by mapping how the cells connect.

The incentive that quietly degrades the network

Then another person handed me the mechanism that makes this urgent right now, and it comes back to Conway's law.

Some large companies have started rewarding individual AI adoption, engineers who consume more tokens get recognized, sometimes materially. Set aside whether that's wise as a comp decision. Look at what it does to the communication structure. If you pay people to talk to an AI, they talk to the AI instead of to their teammates. Knowledge that used to move between people through conversation now terminates in a private session with a model. The team's internal communication thins out.

And Conway's law says the system you build is a copy of your communication structure. So if you degrade the communication structure (if the network of who-talks-to-whom hollows out because everyone is heads-down with their own AI) you are, in Conway's terms, paying to make your future systems worse. Not because the AI is dishonest or the code is bad, but because the coordination substrate the good systems depend on is being quietly starved.

This is the same shape as the slime mold, arriving from a different direction. The individual optimizes rationally: more tokens, more personal output, more reward. The collective intelligence thins underneath them. Local gain, global loss, and every individual metric looks fine while it happens.

Why the standard dashboard is structurally blind to this

Cycle time. Lead time. Review latency. Deploy frequency. The whole DORA family. Every one of them measures something about work already moving through the pipeline. They are, correctly and by design, flow metrics.

The coordination layer isn't in any of them. Who actually collaborates with whom, where communication load concentrates, which handoffs are load-bearing, whether the network is thickening or thinning as AI adoption rises: none of that is a property of the pipeline. It's a property of the network of people around the pipeline. So it's invisible to the standard toolkit in the most frustrating possible way: your flow metrics can look healthy, your coordination can be silently degrading, and nothing in the data connects the two.

This is the same blind spot we hit from the demand side in an earlier piece: capacity absorbed on the way in, invisible to metrics that only watch what's already flowing. The coordination leak is its sibling: value lost between people, invisible to metrics that only watch the work, not the network moving it.

What you measure instead

A slime mold is a network, coordination drag is a network phenomenon, and a network is a thing you can instrument, just not by timing the pipeline. You measure the network itself: the real patterns of collaboration and communication, where the load concentrates, which connections are carrying the organization and which have gone quiet. This is a different discipline from cycle-time analysis. It's closer to organizational network analysis than to DORA.

I want to be careful not to oversell it, because Komoroske's deeper point holds: some coordination drag is emergent from scale itself, not a bug you can remove. Network analysis doesn't dissolve coordination headwind. But it makes it visible, and the hardware manager's own line is the argument for why that matters: it's not random, it only looks random. Making the not-random visible is the entire job. You can't manage a thing you experience as weather.

What we don't know yet

The honest edge, the part I can't close: measuring the network changes who's watching, not whether watching distorts.

If you surface collaboration patterns to leadership, you've built exactly the kind of surveillance that a lot of thoughtful people are rightly wary of — the observation that changes the thing observed, pressure that pushes people to perform the metric instead of the work. A network metric that flows upward as a scorecard could easily do more harm than the coordination drag it reveals. Whether the answer is structural (teams own their own network view, leadership only ever sees aggregates), or cultural (discipline about what gets looked at and why), or whether the pressure is simply inevitable once the data is cheap enough to collect. I don't have a clean answer, and I'd trust anyone who claimed one less for it.

The practical version

If your flow metrics improved and your delivered outcomes didn't, and you've already ruled out the demand-side leak, the next place to look is the one your dashboard can't reach: the coordination layer.

Three questions worth asking, none of which cycle time can answer:

• Is your AI adoption thickening or thinning the internal network? If people are increasingly solving problems with a model instead of with each other, knowledge is siloing even as individual output rises. That's a Conway problem wearing a productivity costume.
• Where does coordination load actually concentrate? The "random" slowdowns usually aren't. Decompose who depends on whom, and the whack-a-mole tends to resolve into two or three specific handoffs carrying the whole organization.
• Are your incentives rewarding individual output at the network's expense? Paying for personal AI usage optimizes exactly the metric that erodes the collective. The local gain is real. So is the global loss, and only one of them is on your dashboard.

The uncomfortable version of all this: an organization can make every individual measurably faster with AI, watch its flow metrics improve across the board, and deliver no more than it did before — because the gains are being lost in the space between people, and that space isn't on any chart the industry currently agrees to keep.

The work moves through a pipeline. But it's carried by a network. Everyone is measuring the pipeline.