Here’s a thought experiment. Take the best, most productive engineering team you can imagine, and parachute them into a large, heavily regulated enterprise. What happens to their output?
It drops. Not because they forgot how to write code, but because the organization around them has a different risk tolerance. That’s the part of the AI productivity conversation we’re missing. We keep talking about developer velocity, but rarely talk about compliance velocity. But if you want to increase one, you have to increase the other.
It’s not a code-writing problem
The constraint on large software teams hasn’t been how fast engineers can write code. Most engineers could ship a weekend project to production in an afternoon. Put those same engineers inside a mid-sized or large company, and the same change takes days or weeks. That’s not because the tooling is worse, but because the risk and compliance process around every change is doing exactly what it was built to do.
That’s why an initiative that seeks to “generate changes faster with AI” fails to solve our problem. It was already possible to write code quickly; what we struggled with was managing the risk of shipping changes.
Every action has a reaction
This is where physics is a useful metaphor. For every increase in the volume of change, especially in a risk-averse environment, there’s an equal and opposite reaction from the organization’s risk and compliance functions.
Here’s an example. A team is making 100 changes a day. They introduce AI and increase this to 200 changes per day, but production starts falling over twice as often, even though the change failure rate is the same. That causes risk and compliance to take an interest and introduce processes and policies to reduce the failures.
Within a few weeks, the team is back to 100 changes a day. Half of them are AI-authored, but there’s no productivity gain to show for it. The system has found its new equilibrium, and it looks a lot like the old one, except for all the new processes that compliance wrapped around it.
There’s a second version of this reaction, and it’s less about infrastructure and more about experience. Small teams build up deep, shared context about the problem they’re solving and the customer they’re solving it for. Most software has many authors but one user at a time living through the whole journey. As a team grows, holding that cohesion gets harder, but at least the humans on the team still talk to each other.
Now give every one of those engineers their own AI coding assistant. Each engineer becomes far more productive individually, but each assistant has even less shared context than the humans did. The result is the same pattern: a high volume of change, but a more disjointed product experience, with the end-to-end story getting lost.
The equal-and-opposite reaction to that fragmentation is usually a heavy-handed swing back toward centralization. We saw that a decade ago, when “let every team choose its own tools” gave way to standardized platforms, because nobody could move between teams without relearning their entire stack.
These reactions are rational. They are the result of a system correcting for risk that increases faster than anyone can account for.
The one-way ratchet
There’s something even more crucial than the equilibrium problem. Compliance only ever ratchets up; it never ratchets down.
Once a new rule shows up, like a mandatory review step, an extra test suite, or a new sign-off, it rarely gets removed, especially once it’s on a regulator’s radar. Velocity can go up and down as the team changes. Compliance doesn’t work that way. It accumulates.
Imagine a team gets excited about AI and starts generating twenty changes a day instead of one per engineer. Production instability goes up. A data leak that used to happen once a year now happens twenty times. New compliance requirements get bolted on to stop the bleeding. Eventually, the team realizes the strategy isn’t working and reverts to its old habits, but the compliance burden doesn’t go away with them. They’re now doing less, with more overhead, than when they started.
This is also how bad global solutions get applied to local problems. If one engineer had production access they shouldn’t have had and made a mistake, the right fix is local: work out why they had that access and fix it. The wrong fix (but the one organizations reach for when they’re not being deliberate) is global: nobody gets production access, ever, for anything. It solves the immediate problem and creates a dozen new ones.
Sometimes it goes even further than the company. A handful of businesses misuse a technology, a regulator responds with a blanket rule, and now everyone on the internet has to click through a cookie banner. That’s what happens when a few actors are irresponsible with something new, whether that’s self-driving cars, AI, or otherwise. Regulators aren’t looking for a reason to step in, but companies force them to through irresponsible decisions.
Ship safer, not just faster
If your company has a new initiative to boost AI-driven productivity, here’s the thing worth saying out loud before it starts: We already know risk and compliance will find equilibrium with whatever volume of change you produce. So plan for that from day one.
If every engineer on the team is using AI purely to generate more code, faster, you will accelerate the compliance ratchet. The healthier split is roughly half and half. Half the team should focus on how to make changes faster, and the other half on how to make those changes safer, more compliant, and less risky, with AI doing some of that work, too.
That second half of the work is genuinely interesting, and it’s underrated. AI is well-suited to reasoning about risk, not just generating change. It could review a pull request and decide whether a one-line CSS tweak needs a human reviewer at all, while flagging any change that touches the payments pipeline for real scrutiny. It could review the build and decide which of the three hours of automated UI tests are relevant to a README update, rather than running the whole suite, which is what the pipeline does.
None of that reduces the volume of change getting shipped. It reduces the risk associated with it, which is what’s actually been holding teams back.
The foundation of every software business is customer trust, and trust is not built by shipping more. If AI makes you ship faster without making you ship safer, you’re not getting more productive, you’re just winding the compliance ratchet a little tighter, and that one doesn’t wind back.
Tags:
