The gatekeeping reflex

An AI governance committee adds three days of review to something that took two hours to build.

Nobody on that committee thinks of themselves as the problem. They were asked to make sure nothing bad happens, and review is the tool they have, so they use it. The architecture review board that used to meet monthly now meets weekly (same reason), and a new approval workflow appears for anything an agent touched. Each one arrives with a memo explaining why it's prudent. Read on its own, every memo is reasonable.

Add them up and you get a picture most of us have seen by now: teams adopt the tools, individual output spikes, and organisational delivery stays flat.

The claim

When the pace of possible change exceeds what a team can absorb, the natural human response is to create friction. Not because friction is useful, but because people need somewhere to put the anxiety of infinite possibility.

A good part of the gap between individual output and organisational delivery is gatekeeping invented specifically to slow things back down to a pace that feels manageable. The gates do not improve quality. They reduce anxiety.

A fear response dressed up as process.

Why it doesn't look like fear

Fear inside an organisation almost never announces itself, it arrives as diligence. Nobody stands up in a leadership meeting and says "this is moving too fast for me and I'd like it to stop." What you hear instead is "we need a review step," or a request for visibility, or someone asking to make sure legal has seen it. All of it sounds like responsibility, which is exactly why it gets approved without argument and exactly why nobody goes back six months later to ask what the step caught.

That's the tell.

A control exists to catch something, while a gate built out of anxiety exists to be passed through. Ask the owner of any new review what it has stopped in the last quarter, and ask them to name the things. Then watch how often the answer is a description of the process instead of a list of things it caught.

Where the friction actually lives

Coding was only ever fifteen to twenty-five percent of shipping software. The other three quarters is review, testing, deployment, integration and monitoring, which is where the real friction sits, so when generation gets five times faster the pressure lands on everything downstream of it.

Some of that pressure is legitimate. Review capacity really is the new bottleneck, and a pipeline built for forty pull requests a week doesn't cope with two hundred. Systems problem, systems answers.

The gatekeeping reflex is the other response. Instead of making validation a property of the pipeline, the organisation adds a room full of people to the path and calls it governance. It feels safer because a human is looking. It isn't, or not for long: reviewer capacity is fixed while generation keeps climbing, and the humans stop reading long before anyone admits it. I made the longer version of that argument in nobody has to approve the agent's merge: the signature at the bottom of the pull request was never the thing gating the change.

Why good organisations do it most

You'd expect the sloppy organisations to be the worst offenders here. In my experience it runs the other way. A team with a strong quality culture has more to lose and more instinct for protecting it, because they built careers on being careful, and when a flood of change arrives careful people reach for the tool that made them good. Review. So the reflex is strongest exactly where the old way worked best.

Worth naming out loud, since the people adding the gates are usually the ones you'd least want to lose. They aren't obstructive. Not really. They're scared in a way they have learned to express through process, and telling them they're obstructive only makes the gate taller.

What I'd do instead

Treat every new gate the way you would treat a new service: someone has to own it and say what it catches.

Before a review step goes in, write one sentence naming the failure it exists to prevent, then ask whether the pipeline can catch that failure instead. If it can, fix the pipeline. If it can't yet, fine, the gate is temporary and gets an end date tied to when the pipeline will. And if nobody can name the failure at all, there is no gate. Just a feeling.

Borrow the rule of two-or-three while you're at it and don't build the structure before the failure repeats. A new approval workflow built in advance of any incident is process debt taken on with nothing to show for it, and it compounds the same way every other kind does.

Classify by how expensive it is to be wrong, not by who or what wrote the change. One-way doors still earn a person. A reversible change behind a flag, with a rollback measured in seconds, does not need a committee whatever authored it.

Name the anxiety

Most leaders skip the honest conversation (it's the uncomfortable part).

People aren't wrong to feel the ground moving, not when the thing you built on Tuesday can be rewritten three times by Friday. It's disorienting, and pretending otherwise won't make the reflex go away. It pushes it underground, where it comes back as a new checklist.

So say it. Out loud. The pace is uncomfortable and the discomfort is real. A gate doesn't fix discomfort, it hides it inside a queue, and the queue has a cost everyone pays whether or not they were anxious to begin with.

Organisations that can't see the reflex for what it is will build elaborate bureaucracies around AI output and wonder why they got slower. The ones that can see it get to keep the speed and deal with the fear directly, which was always the actual job.