If your company keeps its infrastructure in Terraform, some version of this conversation probably looks familiar:

This pattern comes up in most conversations we have with backend teams, at every size from ten-person startups to engineering orgs in the hundreds: the application code for a feature is finished and approved in hours or days, while the infrastructure change it depends on waits somewhere between several days and several weeks, usually for one specific person to have time to look at it carefully. Nilkanth Patel, CTO at the logistics platform Pallet, describes what the infrastructure side of a new service costs a team that does it by hand:

That week covers the work itself. At companies where infrastructure changes go through a dedicated reviewer, the wait for review comes on top of it, and that wait is what this post is about.

Why the review is slow

Three things keep infrastructure review slow, and none of them is anyone behaving badly.

The reviewer pool is small and can't easily grow. A typical team has several people who can review application code and one or two who can confidently review an IAM policy or a VPC change, so the infrastructure queue is really a queue for a specific person, and that person is carrying the same load for every other team too. In most of the teams we talk to, that person is also described as the busiest and most trusted engineer in the org, which is exactly why everything routes through them.

The blast radius justifies the caution. A bad code change usually breaks one service and rolls back in minutes, while a bad security group change can take down everything at once, and some infrastructure mistakes (deleted data, leaked credentials) can't be rolled back at all. Careful review of infrastructure is a rational response to that asymmetry, which is also why the queue persists: less careful review of high-blast-radius changes is a hard thing to argue for, and nobody really wants to.

Nothing verifies the change before merge. A code PR arrives with a passing test suite that demonstrates what it does, while most Terraform PRs arrive with a plan output at best, leaving the reviewer to simulate the apply in their head. The review takes as long as that simulation takes, because the reviewer is doing verification work that nothing else in the pipeline does for them.

What AI tools changed

This queue has existed for as long as infrastructure has lived in its own repo. What changed in the last two years is the other side of the comparison: most teams we talk to now use AI coding tools for a meaningful share of application code, and the time to produce a working service has collapsed from weeks to days or hours. The infrastructure review didn't speed up alongside it, and several teams tell us it has slowed down, because agents generate more infrastructure to review and reviewers apply more scrutiny to generated infrastructure than to generated application code.

That extra scrutiny is the correct instinct, since a wrong endpoint returns a wrong response that a test catches, while a wrong IAM policy sits invisible until someone exploits it. The consequence is still that a review queue which used to be a modest fraction of delivery time is becoming most of it, and teams that measure productivity by code throughput (which is where the AI tools genuinely show up) tend not to notice, because the waiting accumulates after the code is done.

The teams that feel this most are the ones shipping fastest, and it shows in who decides to opt out of the queue entirely. Gradient Labs, an AI-agent startup founded by engineers from Monzo Bank, runs without the queue existing at all:

The ways out

Teams deal with the queue in four ways.

Hire more platform engineers. This works, and at the high end it produces something genuinely excellent. It's also expensive (Quiqup puts the DevOps hires it avoided at $180k per year), and teams that have grown a platform function tell us the queue tends to reappear once the org outgrows the new capacity.

Loosen the review. Nobody does this on purpose, for the blast-radius reasons above.

Make infrastructure changes verifiable and self-service. Policy checks, plan tests, constrained modules, and internal developer platforms shrink the simulation work the reviewer does in their head, and the teams furthest down this path see meaningfully faster infrastructure changes. The catch is that a good internal platform is a product in its own right, with years of engineering behind it.

Remove the second change entirely. If the application code declares the infrastructure it needs (a queue, a database, a cron job) and the platform derives the resources from that declaration, there is no separate infrastructure change to review. The feature ships as one PR, reviewed once, with types and tests covering it.

What skipping the queue looks like

The fourth option is the bet we've made with Encore: infrastructure is declared in application code and provisioned from it, including least-privilege IAM, in your own AWS or GCP account, so the shipping-rates service from the thread at the top would have been one pull request instead of two. The resources themselves are ordinary AWS and GCP services running in your account, configurable per environment in the Encore Cloud dashboard and visible in your cloud console like anything else you run. For infrastructure you manage outside Encore, there's a Terraform provider that exposes every Encore-provisioned resource to your existing modules.

The teams running this way mostly arrived from one of the other three options, and their descriptions of the difference are more useful than ours.

Simon Vans-Colina watched the hiring option succeed at Monzo, whose platform team he describes as world class, before co-founding Pave Bank:

Danny Hawkins, CTO at Quiqup, had already built his own version of the self-service option, assembled from Helm and Crossplane:

And Groupon came at it from enterprise scale, with dedicated infra teams and the longest queues, describing the change in the same terms this post started with:

Whether the trade-off fits your team depends on more than review latency, and the docs make the case in more detail than a blog post should. The pattern stands on its own either way: if application code at your company is approved in hours while infrastructure changes wait for days, the person you're waiting on is probably not the problem, and the queue is worth measuring before deciding which way out fits you.