AI Code Review for Infrastructure as Code: Past What Terraform Plan Tells You

Infrastructure pull requests get less review than application pull requests, and they are the ones where a mistake is hardest to walk back. A bad function ships a bug. A bad security group ships an exposure that nobody notices until something else finds it.

The usual defence is a pipeline of terraform validate, terraform plan, and a policy scanner, plus a human approval. That stack is good at what it does and has a specific, well-defined blind spot. This is about where that blind spot is, and what an AI reviewer can and cannot do about it.

What the existing tooling already handles

Be clear about this first, because the failure mode in this space is buying a second tool to do a job the first one already does.

Syntax and schema are solved. terraform validate catches malformed configuration. Drift and blast radius are solved: terraform plan tells you precisely what will be created, changed and destroyed. Known misconfiguration patterns are solved by policy scanners — Checkov, tfsec, Trivy, Kubernetes admission policies. A public bucket, a missing encryption block, a wildcard IAM action: a scanner finds those faster and more reliably than any language model, and it does so deterministically.

If you do not have that layer, add it before you add anything else. An AI reviewer is a poor substitute for a rules engine on rule-shaped problems.

The gap: plan tells you what changes, not whether it should

Here is the distinction that matters. terraform plan is a statement of mechanical consequence. It will tell you, accurately and without judgement, that a database instance will be replaced. It will not tell you that replacing it drops the data, that the replacement was triggered by an attribute change somebody made for unrelated reasons, or that this resource is the one thing in the module with no backup configured.

A scanner has the same shape of limit. It evaluates each resource against a rule. It does not reason about the relationship between resources, which is where most genuinely dangerous infrastructure changes live: a security group that is fine in isolation attached to a subnet that makes it reachable; a role whose permissions are defensible until you notice which service assumes it; a Kubernetes network policy that is correct and is silently made irrelevant by another policy in the same namespace.

Those are not rule violations. They are reasoning failures, and they are exactly what a human reviewer is for — which is a problem, because infrastructure changes are the ones humans review least carefully.

Where an AI reviewer earns its place

Four things it does that the deterministic layer structurally cannot:

• Cross-resource reasoning. Reading the whole diff and noticing that two individually-acceptable changes combine badly.
• Intent versus implementation. Comparing what the PR description says it does against what the configuration actually does. Infrastructure PRs are unusually prone to a stated goal and a broader change.
• Destructive-change surfacing. Pulling the replacements and deletions out of a long plan and putting them where a reviewer will see them, rather than at line 400 of scrollback.
• Convention drift. Noticing that a new module ignores the tagging, naming or module-structure conventions the rest of the repository follows. No scanner encodes your conventions; the repository does.

The AI-generated infrastructure problem

This has changed the shape of the review load over the past two years. Coding agents are now writing a substantial share of infrastructure code, and they are noticeably weaker at it than at application code — there is simply less public IaC than there is Python, and provider schemas move faster than the training data tracking them.

Security researchers looking at AI-generated Terraform keep finding the same four patterns: permissive defaults, missing security blocks, hardcoded values that should be variables or secrets, and stale provider patterns that no longer match the current schema. The last one is particularly awkward because it often still applies cleanly.

The important property of all four is that they are plausible. The configuration looks idiomatic, plans without error, and is wrong in a way that reads as a deliberate choice. That is precisely the failure mode human reviewers are worst at catching, and it is the argument for reviewing generated infrastructure more carefully rather than less. Our piece on reviewing AI-generated code covers the general case; infrastructure is the sharp end of it.

Making review of IaC actually work

A few things that matter more here than in application review:

Give the reviewer the plan output. A reviewer reading only the diff is guessing at consequence. A reviewer that can see the plan knows what will be destroyed. This is the single largest quality difference available, and it is a pipeline decision rather than a tooling one.

Include the modules, not just the changed file. A three-line change to a module call is a large change to the infrastructure if the module is large. Review that cannot see the module is reviewing three lines of nothing — the context problem in its most concentrated form.

Separate advisory from blocking. Convention drift should be a comment. A public storage bucket should stop the merge. Mixing the two is how teams end up clicking through both — the blocking versus advisory distinction is worth getting right before rollout rather than after.

Keep the scanner authoritative on rules. If Checkov and the model disagree about a rule-shaped question, the scanner is right. The model is there for the questions the scanner cannot express.

Where this does not help

Two honest limits. An AI reviewer reads configuration, not reality — it cannot know that the subnet you are opening is the one with the legacy host on it, or that a resource is load bearing for something undocumented. Environment-specific knowledge stays with the people who have it.

And it will not catch a change that is dangerous only because of timing. Nothing in the diff indicates that this is the wrong Friday to replace the load balancer. That judgement is not available in the code, and pretending otherwise is how teams end up trusting a review that was never in a position to have an opinion.

The realistic target is narrower and still worth having: infrastructure PRs get the same quality of attention as application PRs, destructive changes stop being buried, and generated configuration stops being merged on the strength of looking right. PURA reviews Terraform and Kubernetes changes alongside application code in the same pass, with custom rules for the conventions that are specific to your repositories.