The Pace Doesn't Ship

I argued recently that a borrowed constraint binds nothing. I stopped there, and I shouldn't have, because it says something uncomfortable about every system I hand to somebody else. On why handing over an AI-built platform means handing over failures, and what it costs to leave room for theirs.

By Jason Waldrip November 4, 2026 21:30 8 min read

You finish the engagement on a Friday. The repo is clean, the pipeline is green, the agent guides in it are current, and the runbooks are better than the ones you inherited. You walk the team through all of it and they ask good questions. Three months later their first real change takes eleven days. Nothing is broken. Nobody is lost about where the code lives. They just can’t drive the thing at the speed you drove it, and nothing you left behind explains the gap.

I’ve been on the receiving end of that handoff more than once, and I’ve written about what it leaves behind: per-customer bundles, backends stranded in a visual builder. Both times I read the problem as architecture, because architecture is the part you can see in a repository. The architecture was downstream. Every one of those customizations was a fast yes, arrived at honestly, by someone solving the problem in front of them. Not one of them came with a way for the next person to deliver the next one.

I’d like to look at that straight now, because I’m the one delivering fast.

go count what actually transfers

Take the platform I’m building at Phoneware and sort it into two piles.

The first pile ships. A TypeScript monorepo is a repository, and a monorepo is a context boundary that a new team can load as easily as I can. Terraform and GitOps mean the infrastructure and the deploy path are files in that repo. Canary targeting is configuration. The agent guides are checked in. The workboard the fleet tracks has a URL the client owns. All of it conveys on the last day, and most of my case for doing the work this way is that it does.

The second pile is a folder of 36 rules that my fleet loads before it does anything, and 25 of them have a dated failure recorded next to them. I wrote that up recently and the conclusion was that you can’t use mine: a constraint adopted out of somebody else’s incident report has no weight behind it, so the first time following it costs you an afternoon you’ll make an exception, and you’ll be right to.

I published that and stopped. Read it one more step and it says something I didn’t go looking for. The asset that makes me fastest is the one I’m structurally unable to deliver.

Picture the alternative honestly. I hand a team 36 files. They read them, agree with all 36, and nod at the two that sound like hard-won wisdom. Then a release is late and rule 14 is in the way, and nothing in anyone’s memory is attached to rule 14. What I actually handed over was a document.

the amplifier conveys just fine

This isn’t a theory I need to defend alone. DORA’s 2025 report puts it in four words under a heading called AI, the great amplifier: “AI doesn’t fix a team; it amplifies what’s already there.” Strong teams get better. Struggling teams find their existing problems intensified.

Two more findings from the same report, and they matter in this order. AI adoption now shows a positive relationship with delivery throughput, which reverses the 2024 result I built an essay on. And it still shows a negative relationship with delivery stability, for a reason stated plainly: an increase in change volume leads to instability unless there is a control system underneath it. DORA’s own recommendation is to invest in the internal platform, and they report a direct correlation between platform quality and getting any value out of AI at all.

So the amplifier conveys. The rails convey, because rails are files. What doesn’t convey is the judgment that tells somebody when the amplifier is about to make their week worse.

That reflex is the whole thing, and it has exactly one supplier.

the part you can’t pre-buy

The deliverable was never the platform. It’s the team’s capacity to keep making calls at that pace once I stop making them, and that capacity gets built the way mine did: by being wrong in a specific way on a specific afternoon and writing it down while still annoyed about it.

Which means a handoff plan has to include room for them to be wrong. Not a tabletop exercise, not a postmortem of my incident. A real failure with real consequences on their watch, while I’m still close enough to help them read it.

The grind was the teacher ended on a question I didn’t answer: if the fleet now does the boring painful work that used to manufacture judgment, where does the next engineer’s judgment come from? This is the closest I’ve got. Somebody has to decide which grinding to keep. Not the parts that only taught patience. The parts that taught you what breaks, and who it breaks on.

this reads like malpractice until you price the alternative

A client is paying me for speed, and I’ve just described a plan where I knowingly don’t prevent something I can see coming. That’s a hard sell and it deserves to be. Two things make it defensible.

The blast radius is a design parameter, so set it. Canary targeting means a bad change reaches one domain instead of every reseller. Feature flags mean a bad release dies by toggle instead of by rollback. Autonomy is infrastructure, not trust: the same rails that let a fleet move without asking are what make a team’s first real mistake survivable. I’m not arguing for letting anybody get hurt. I’m arguing for letting them get the lesson at a price I capped before they paid it.

And some failures never go on the table. Anything that leaks a person, loses money, or can’t be reverted. A credential is a door, not a keyring, and you don’t teach judgment with somebody else’s customer data. That exclusion list is shorter than it feels when you write it out, which is the uncomfortable part. Most of what we instinctively shield a new team from is survivable, and we shield them from it because watching is harder than doing.

what I’d actually do

1. Rails before features, every time. At CommercialTribe I shipped features I’ve since forgotten. What I’d defend now is moving to GCP and Kubernetes and collapsing a weeks-long release cadence into hours, across onsite engineers and a remote team in Argentina. That’s the only part of that job a team could still use after I left, and it made everything after it cheaper to hand off.
2. Let their incidents stay theirs. The instinct when the page fires is to take it. Take it and you’ve bought the outcome and sold the lesson. Unblock, don’t carry is easy to say in a one-on-one and genuinely hard at 2am.
3. Make them write the rule, in their words, in their repo. My sentence in their rulebook is decoration. Theirs is a constraint. At Brandfolder the durable thing wasn’t the Go zip pipeline; it was that the reason it was in Go got written down where the next person would find it.
4. Measure the month after you stop. What they shipped without you, and what they caught without you. Not what we shipped together. The second number flatters everyone in the room and predicts nothing.

back to the Friday

The repo is clean and you should be proud of it. That was never the question.

The question is what happens the first time something breaks and you aren’t in the channel. If the only honest answer is that somebody calls you, then you didn’t finish. You became load-bearing somewhere nobody can see it, inside a company that isn’t yours, and you did it while shipping the best work of your career.

So before the next engagement ends: which failure are you planning to let them have?