AI didn’t make us faster. Trust is why.

At my last company, we put AI everywhere in how we built software. Requirements. Code. Reviews. Tests. Documentation.

And our feature delivery barely got faster.

That bothered me, because by almost every AI productivity story, we should have been flying. Eventually I realized we were optimizing the wrong thing. Coding wasn’t the bottleneck. Trust was.

It was not for lack of enthusiasm. AI spread through the company like wildfire. Every chart, slide deck, dashboard and report carried the aroma of AI generation, and developers used it to write code, check code and even deploy code.

Follow a feature from idea to production.

To see where the time went, follow one feature through the process. AI shows up at every stage. So does a person, checking its work.

AI made one stage faster. Every other stage still waits on a person.

Speed landed where the time wasn’t.

Engineers know this problem as Amdahl’s law: the speedup of a whole system is limited by the part you did not speed up. If writing code is a quarter of the time between an idea and a working feature, making it four times faster saves less than a fifth of the total. Make it infinitely fast and the feature still spends three quarters of its life in the other stages.

We dramatically accelerated coding without accelerating the system around it. Most of the time was never in writing code. It was in the checkpoints, and every checkpoint on that list has a person standing at it.

A 10× engineer does not create a 10× delivery organization. Neither does a 10× AI coding assistant.

The organization still moves at the speed of its architecture decisions, product decisions, security reviews, validation, coordination and trust.

The AI trust bottleneck.

Those people are not there out of habit. Each checkpoint exists because we do not yet trust AI with that decision, and for now that is reasonable.

I think of this as the AI trust bottleneck: AI can perform work faster than an organization can become comfortable delegating decisions to it.

Trust here does not mean confidence or enthusiasm. It means accumulated evidence that lets you safely reduce supervision. That is something a team can build, and something it can measure.

A senior engineer or product manager carries years of systems knowledge, training and onboarding: why a service is shaped the way it is, which policy a design would break, what went wrong the last time someone tried this. AI has little of that context, and without it, expecting AI to do those jobs is naive. Without experience, proof and validation, there is also no basis yet for relying on it to do them at least as well as a person.

We would not give a new senior hire design authority on day one either. We would watch their work, check it, and widen their scope as they proved themselves. In my last essay I argued for keeping a person at the decision points, and expected the pushback that people slow the system down. This is that slowdown, seen from the inside. The answer is not to remove the people. It is to earn the trust that lets them step back.

How a team earns it, one stage at a time.

Right now AI is an assistant that takes on the tedious and undesirable work. It will not move beyond that because someone declares it trusted. It will move the way a new engineer does: deliberately, one stage at a time, on evidence.

At each stage, the person’s role with AI should evolve along the same path:

1. 1 · AuthorThe person does the work, and AI assists.
2. 2 · ReviewerAI does the work, and a person approves every piece before it moves on.
3. 3 · AuditorAI’s work moves on by default, and a person checks a sample.
4. 4 · Exception handlerA person steps in only when a check fails or the AI flags that it is unsure.

Moving a stage one step along that path is a decision, and it should rest on evidence. This is where I would start.

Measure every checkpoint.

One metric I would start tracking is the human intervention rate: the share of AI output that a person materially changes at each stage. If AI drafts 100 requirements documents and people materially change 70 of them, the intervention rate is 70%. If six months later it is 15%, that is evidence that review can move from mandatory approval to sampling. If it stays high, the checkpoint is doing its job. Either way, the decision rests on data instead of a feeling.

Write down what your senior engineers know.

Much of the gap is context. Architecture decisions, infrastructure constraints and design policies often live only in people’s heads. Written down where AI can read them, they close part of the gap that keeps design with people. It is the same habit as writing an agent’s role down.

Turn manual validation into automated checks.

Every contract test or synthetic check in production that replaces a person clicking through a feature does two things. It saves time on every release, and it builds the track record that trust depends on.

Grow AI’s scope like a new hire’s.

Move each stage one step along the path from author to exception handler when its intervention rate supports it, and back when it does not. Different stages will move at different speeds, and that is fine.

Adoption isn’t finished at access.

AI adoption is not finished when everyone has access to an AI tool. It is finished when we have accumulated enough evidence to safely remove work from the human path.

The next productivity breakthrough won’t come from AI writing code faster. It will come from humans needing to check less of what AI does.