# Speed Was Never Your Bottleneck

> AI in regulated engineering makes code faster, but speed was never the constraint. Correctness, trust, and sign-off were. Don't optimise what wasn't slow.

AI's most obvious gift is speed. So it's worth asking a question the excitement tends to skip: was speed ever the thing holding your serious work back?

For a lot of teams that move fast and carry little risk, the answer is yes, and AI is transformative for them. But on an accountable team, where the work is consequential and the cost of being wrong is high, the honest answer is usually no. The slow part was never producing the work. It was being sure enough of the work to put your name on it. And making the producing faster does very little for the part that was actually slow.

This is the quiet disappointment waiting for serious teams that adopt AI expecting a step change in delivery. The code arrives faster. The drafts arrive faster. And the throughput barely moves, because the bottleneck was downstream of all of it, and now it's just more visible.

## Why we optimise the wrong stage

We optimise what we can see and measure, and writing is visible. You can watch the code appear, count the hours saved, feel the acceleration. So when a tool makes writing faster, it feels like it's making everything faster, because the part it sped up is the part you were looking at.

The constraint on serious work mostly lives somewhere harder to see. It lives in review, in verification, in the careful thought about edge cases, in the sign-off where someone accountable decides the thing is safe to ship. That work is slow on purpose; the slowness is the diligence, not waste in the system, and it doesn't speed up just because the artefact it's examining arrived sooner. If anything, more artefacts arriving sooner increases the load on the stage that was already the limit.

There's a version of this every experienced engineer already knows. The hard part of a consequential change was never typing it. It was understanding the system well enough to be confident the change was correct and safe. A tool that types faster helps with the part that wasn't hard, and leaves the part that was exactly where it stood.

## The principle: speed up the work, not the judgement

Here is the lens. AI accelerates the production of work. It does not accelerate the judgement that decides whether the work is good enough to be accountable for. On serious teams, that judgement was the bottleneck. So the gains are real but bounded, and the boundary is the judgement stage. Plan around that boundary rather than against it.

Concretely, this means being honest about where AI moves your throughput and where it doesn't. In stages dominated by production effort, it can be a genuine multiplier. In stages dominated by verification and accountable judgement, it changes little, and treating it as though it should is how teams end up disappointed, or worse, how they "find" the missing speed by quietly cutting the verification. That is not a productivity gain. It's risk, relabelled as efficiency, and on an accountable team that relabelling is the most expensive mistake in this whole series.

The teams that get real, durable value from AI are usually the ones that used it to take genuinely low-value work off people, the boilerplate, the first draft, the mechanical transformation, and reinvested the freed time into *more* of the judgement, the review, the careful thought that was always the actual constraint. They didn't try to make the bottleneck faster. They fed it.

## What this looks like

Consider an engineering team in a bank that adopts AI coding assistance expecting a substantial lift in delivery. The assistance is good; code that took hours now takes a fraction of that, and developers genuinely feel faster day to day.

A quarter in, the delivery numbers have barely moved, and the reason is instructive rather than disappointing. This team's throughput was never gated by how fast code got written. It was gated by review, by the security and compliance checks that consequential changes have to pass, by the testing that a regulated system demands, and by the deliberate sign-offs that exist precisely because the cost of a bad change is high. All of those still take what they took. The assistant filled the developers' time with more generated code waiting on the same review pipeline. The real risk now is that someone, under pressure to show the productivity the tool was supposed to deliver, starts treating the checks as the thing slowing everyone down. The checks were never the inefficiency. They were the job.

The teams in similar positions that got value did something less exciting and more useful: they pointed the tool at the genuinely low-stakes drudgery, freed senior people from it, and spent that recovered attention on the review and judgement that was always the limit. Modest, real, and it didn't require pretending the bottleneck was somewhere it wasn't.

## What it means in practice

Before you expect AI to speed up your delivery, find your actual bottleneck and be honest about whether it's a production stage or a judgement stage. If production is genuinely your limit, the gains can be large. Take them. If judgement is your limit, as it is for most accountable work, expect AI to help at the edges and resist the pressure to manufacture the rest of the promised speed by thinning the diligence that was holding your quality up.

The goal on a serious team was never to ship faster for its own sake. It was to ship work you can stand behind, at a sustainable pace. AI can genuinely help with that, by clearing the low-value work away from the people whose judgement is the real constraint, so they have more of themselves to spend on the part that actually decides whether the work is good. That is a smaller and truer promise than the one in the demo, and it's the one that holds up.

Next, the close. With all of it in view, the accountability, the data, the review burden, the audit gap, the real bottleneck, the question is where AI genuinely earns its place on a serious team, and how to decide.

---

Source: https://kads.au/writing/speed-was-never-your-bottleneck/
Author: Kads Aziz