Why Code Review Became the DevOps Bottleneck After AI

Developers have never written code faster. Delivery has never been less stable. Both statements are true at the same time, and most engineering organisations are treating the gap as a temporary problem that better tooling will close. The evidence suggests otherwise. Generating code is close to free now, but everything after code, review, provisioning, approvals and compliance, has not got cheaper at all. The queue did not disappear when AI arrived. It moved downstream. In episode 10 of DevOps Unpacked we sat down with Pavlo Baron and his co-founder Zach from Platform Engineering Labs to work out where it went.

What the research actually shows

The 2024 DORA State of DevOps report put the first numbers on it. A 25% increase in AI adoption was associated with a 1.5% reduction in delivery throughput and a 7.2% reduction in delivery stability. Teams were shipping less, and what they shipped broke more often.

The 2025 report reversed half of that finding. AI adoption now correlates positively with delivery throughput, so teams have clearly adapted to the speed. Delivery instability kept climbing. The velocity problem got solved. The safety problem did not.

Faros AI's AI Engineering Report 2026, built on telemetry from roughly 22,000 developers across more than 4,000 teams, shows where the cost landed:

• Median time in code review up 441.5%
• Median time to first review up 156.6%
• Pull requests merged with no review at all up 31.3%
• Epics completed per developer up 66%
• Code churn ratio up 861%

Those figures only look contradictory until you put them next to each other. Output rose sharply. Review capacity did not move. So review became either a very long wait or something that quietly stopped happening.

Why the queue moved instead of clearing

Pavlo's argument is that the rituals around shipping were never necessary, we just could not see it. "We have accumulated too many rituals," he said. "When you want to ship something, you need to make a fireplace, chant around it, dance, and maybe have a shaman over." His point is that the work upstream used to be slow enough to hide all of it. One application a year gives you plenty of room for the meetings, the checkboxes and the quiet conversations in people's ears. Compress idea to running code down to an afternoon and every one of those steps becomes a visible queue.

Zach framed the same problem from the operations side. There is no standard operational environment. Every organisation glues together its own mix of products, open source and scripting, and a great deal of institutional knowledge lives in the gaps between those pieces rather than in the code itself. "AI tooling responds to structure," he said, "and there is no structured data in these organisations for their operational framework." Coding assistants are effective against code because code is a formalisation. They are far weaker against an undocumented deployment sequence that only three people understand.

Reviewing intent instead of diffs

The most useful shift in the conversation was about what review is for. If an agent produces seventy pages of infrastructure change, a human reading it line by line adds close to nothing. Most people in that position paste the diff into an assistant and read the summary, which means the human review has already stopped happening.

Pavlo's alternative is to move the gate up a level. Given a change that is deterministic, has a small blast radius, has passed validation and follows the rules, the question worth a human answer is not "is line 4,000 correct" but "what does this touch, and is that acceptable". That is a question about intent, and a person can answer it at speed.

Zach drew a clear line around where that logic stops. Security-constrained work still gets purposefully engineered and carefully reviewed by hand. So does anything at the core of a system, where the trade-offs are not negotiable. The rest, the operational plumbing that either passes its tests or does not, does not need line-by-line ownership. Their internal position is that ownership belongs at the edges: the protocols, the interfaces and the shape of the experience.

The infrastructure ceiling

Generating code is nearly free. Environments, provisioning, approvals and compliance are not, and that is where Zach sees the real backlog forming. Business users are now producing working applications, running them on localhost against data behind the corporate firewall, and waiting for someone to deploy them so colleagues can use them. Operations has to take those artefacts, security review them, decide where they belong, package them and ship them into the enterprise.

That queue is measured in months, and it is the part of the pipeline AI has not touched at all. Zach's position is that the primitives to automate it already exist: publish an artefact, run a security scan, collect a sign-off, deploy. The blockage is organisational rather than technical.

The analogy that stuck with me is Formula One. If the pit crew are wandering around the track while the cars are trying to run flat out, the problem is not the cars. Platform and DevOps teams have spent years making themselves part of the system rather than the people who build it. That made sense when the system was slow. It does not now.

What compliance actually asks for

Zach made a point about governance worth repeating, because it gets misremembered as a hard requirement. SOC 2 and ISO/IEC 27001 both require change management: changes to production need to be authorised, documented and reviewed, with more than one person involved. Neither standard specifies how. There was never good tooling for that review process, so teams reached for the version control system they already had, and the pull request became the audit artefact almost by accident.

That matters because the pull request is now the bottleneck. If tests, policy checks and security constraints are satisfied elsewhere, by a pipeline, a model or a human, nothing in either standard says the sign-off has to happen on a diff. Check it with your own auditor before redesigning anything, but the constraint is usually narrower than teams assume.

Where this leaves platform teams

Platform Engineering Labs build formae, an open source infrastructure-as-code platform, so their view of the fix is not a neutral one. It is worth understanding anyway. formae uses Apple's Pkl configuration language rather than HCL, on the grounds that something sitting between a schema and a programming language is a safer target for a model than a fully Turing-complete language where the model has to reason about a resource graph. It maps resources across a cloud estate regardless of how they were created, whether through Terraform, OpenTofu, Pulumi, the console or a legacy script. Their claim is that with a single uniform record of what actually exists, drift stops being a useful concept, because there is no longer a plan for reality to diverge from.

Treat that as a vendor position and test it against your own estate. The underlying diagnosis holds whichever tool you pick. Review is the constraint, the constraint sits downstream of the thing AI made fast, and the fix is a shorter, higher-level path to production rather than more people reading more diffs.

Pavlo's version of the destination is the one we keep returning to: you think of an app, and it shows up in production. That has always been the point of the software delivery lifecycle. If you are the person building the pipelines that make it happen, the useful question now is where you are standing in the way.

We make technical videos for teams working on exactly these problems, from product explainers and demo-led awareness videos to internal AI enablement content. If you have something difficult to explain and want help making it land, get in touch.