The AI-Ready Infrastructure Playbook

More code means more infrastructure

Every feature drags infrastructure along with it: the tables, queues, secrets and permissions a change depends on are not application code, and most of them only surface late, once the feature is already being built.

A single instruction such as "add signup emails with a retry queue" turns into one reviewable diff of business logic plus roughly nine infrastructure objects: a topic, a dead-letter queue, a subscriber role, a provider secret, an egress rule, retry configuration, a delivery-state table, environment variables, and alerting. Only the first of those is covered by a test.

Until now, the rate of infrastructure change was capped by how fast humans could write the features in front of it, and that cap is now gone. 93% of organisations report at least one AI-caused infrastructure incident, and 67% report that development has moved ahead of infrastructure.¹

Figure 01 — where the work accumulatesDesign → Operate

Code generation was one stage of the lifecycle, and AI compressed it. Validation, provisioning and deployment still run at their previous speed, so work accumulates in front of them. Illustrative, not to scale.

The broader data points the same way: two thirds of software firms have rolled out generative AI tooling, and those that have report a 10 to 15% productivity gain, since writing and testing code accounted for only 25 to 35% of the path from idea to launch.² Compressing that one stage pushes the constraint downstream instead of getting rid of it: AI-authored pull requests wait 4.6 times longer for a first review,³ and 45% of deployments containing AI-generated code lead to problems.⁴

Why infrastructure code resists review

A common objection to the previous section is that AI reviews code well, so AI-assisted review should be able to absorb the extra volume, and for application code it can. Infrastructure is different, because a change to it is easy enough to read but hard to judge from the diff alone.

A change to application code can be checked locally in seconds, by the compiler and its tests or by just running it. A change to infrastructure is a claim about a system that is not there at review time, and whether it is correct depends on the live state of the target account and on conditions that only appear under load, neither of which the diff shows.

Model performance follows the same split. On EvalPlus, the standard Python benchmark, GPT-4 passes 86.6% of tasks; on IaC-Eval, its Terraform equivalent, it passes 19.4%.⁵ This is not about HCL syntax either: on Amazon's SWE-InfraBench, which uses AWS CDK instead, the best model still gets only 34% of single attempts right.⁶

Take a change an agent might open, a new service that needs a database, a security group and an IAM policy. It reads cleanly and terraform plan succeeds, but neither says much about whether it is safe.

# infra/main.tf
+ resource "aws_db_instance" "users" {…}
+ resource "aws_security_group" "svc" {
+   ingress { from_port=0 to_port=65535 }
+ }
+ resource "aws_iam_role_policy" "svc" {
+   Action="s3:*"  Resource="*"
+ }
validate ✓ plan ✓ 6 to add

A reviewer can read the intent here and still not know the outcome, and the only thing that answers these questions is running the change somewhere first.

The feedback loop

AI does well on application code because of the loop it works inside. When an agent gets something wrong, it finds out in seconds and can try again at almost no cost, and none of the failed attempts leave a mark.

Infrastructure has nothing like that loop, because the only way to run a change is to apply it to a real cloud account. The loop closes between staging and production, hours later, with users already exposed to the result.

10:02:04 run tests
10:02:06 2 failing
10:02:19 edit · run tests
10:02:21 1 failing
10:02:44 edit · run tests
10:02:46 passing
10:03:10 open pull request

10:02:04 terraform validate
10:02:07 valid
10:02:12 terraform plan
10:02:41 6 to add, 1 to change
10:04:00 open pull request
14:20:00 merged, applied
02:14:31 paging on-call

The left session iterates because the environment gives back a verdict the author can act on. The right one cannot, since validate and plan pass whether or not the change is right, so the only real verdict comes from production.

The industry data shows the same pattern, with DORA finding that every 25% increase in AI adoption came with a 7.2% decrease in delivery stability and concluding that AI amplifies whatever system it is dropped into.⁷ Where the infrastructure loop only closes in production, what gets amplified is incidents.

None of this is fixed by a better model. Even one that wrote flawless Terraform would be working blind, because the file it writes cannot contain the live state that its correctness depends on.

The IaC ecosystem has not addressed this

You might reasonably expect the tooling ecosystem to be working on this, but the record of the last three years does not really bear that out.

That is three years spent on licence changes, acquisitions and forks. None of it touched the feedback loop, and the fork now has AI tooling generating two diverging dialects where there used to be one.

The layer was under strain before any of this: 89% of organisations use IaC, but only 6% report full coverage of their cloud, roughly a third of codified resources have drifted from their definitions, and 48% of teams make out-of-band production changes several times a week.¹⁰ Definition and reality routinely disagree, and that is exactly when a plan tells you the least.

What AI-ready infrastructure requires

The feedback loop implies a narrow requirement, that whoever changes infrastructure, whether a person or an agent, can run the result and see what it did before it reaches production. Four conditions make that possible.

An infrastructure change can finally be checked before it ships, and review becomes what it already is for application code, a second opinion on something that has already run. It also helps with governance, because the platform holds the credentials and state, so an AI tool only ever sees business logic and typed declarations.

Infrastructure derived from code

These four conditions point to a category of platform, not one specific product, defined by deriving infrastructure from the application code itself rather than maintaining it alongside. Encore is a concrete example here, because its model is public and specific.

In this model the developer, or the agent, declares what the service requires in ordinary TypeScript or Go, next to the code that uses it.

// the database and the queue are declarations, not YAML
const users = new SQLDatabase("users", { migrations: "./migrations" });
const signups = new Topic<SignupEvent>("signups", { deliveryGuarantee: "at-least-once" });

The platform reads those declarations by static analysis and works out what to provision in each environment, with which permissions, and what to trace. Sensible defaults cover what the declaration leaves unsaid, from instance sizing to IAM scope, and each can be overridden in the dashboard without editing the code. The same definition runs on a developer machine, in a preview environment created per pull request, and in the organisation's own AWS or GCP account. Because that same definition is what runs locally, getting a change working on your machine tells you how it will behave in production, and the loop from figure 04 closes two stages earlier.

Figure 06 — one implementation of the modelEncore

The developer’s tools on the left, the platform that turns declarations into running environments in the middle, and the organisation’s own cloud on the right. Nothing in the developer’s path is a separate infrastructure codebase. See how Encore provisions infrastructure in your own cloud →

An agent can then work on infrastructure the way it already works on application code, declaring a resource, running the service against it, and reading back the trace to correct. The environment that returns the verdict is created for the change and discarded with it, so the number of attempts carries no operational cost. Running the change also settles the five questions Figure 03 left open, because it has actually run, not just been planned.

What the repository stops holding

Most of what an AI tool can read and edit in a Terraform-based service is configuration that cannot be run without a cloud account, the same material a reviewer cannot verify. Deriving infrastructure from declarations takes it out of the repository altogether.

Because the platform holds the credentials and deployment state, an AI tool reading the repository finds business logic and typed declarations, never production keys.

The cloud account, the security model and operational responsibility all stay with the organisation. The second codebase describing them goes away, and with it a class of error that used to surface only in production.

Deleting infrastructure carries a risk that adding it does not. Whether an existing firewall rule or IAM grant is still needed is hard to tell from the code, and removing one that turns out to be load-bearing causes an outage, so the safe choice is to leave it in place. Permissions and network rules pile up, and the estate drifts steadily towards over-permissive. When each resource exists because a line of application code asks for it, removing that code removes the resource and its access with it, so the question never has to be asked.

Where to start

Two questions tell you whether this report is describing your organisation, and you can answer both without a vendor. First, where does an infrastructure mistake actually get caught today? Second, what would it be worth to catch it a stage or two earlier?

For the second question, put one upcoming service on the model from chapter 6 while everything else keeps running, and read the four numbers below before and after. Nothing migrates, and the comparison is against your own baseline.

About Encore

Encore is a development platform for teams whose code output has outgrown their infrastructure. Developers and AI agents declare the infrastructure a service needs, from databases and queues to cron jobs and secrets, as typed resources in ordinary TypeScript or Go, and Encore provisions and runs them in your own AWS or GCP account, with tracing, metrics and logs generated automatically.

Because the infrastructure lives in the application code, there is nothing separate to review or keep in sync, and a change can be run and checked before it reaches production. That is the loop this guide argues for, available by default rather than as a programme to stand up.

“Encore is our foundation for all new development. Since adopting it, we've seen a 2–3x increase in development speed and 90% shorter project lead times.”

Josef Sima, Engineering Director

“We're saving $200k+ annually compared to additional hiring. The ROI is outstanding, easily 10x.”

Daniel Stocks, CTO