12 Ways AI Makes Infrastructure Code Reviews Better
AI Reviews the Code. Engineers Review the Risk.
Most IaC pull requests get one of two reviews.
The rushed one: someone skims 400 lines of Terraform, sees the plan didn’t error, and types “LGTM.”
The slow one: a senior engineer reads every resource, traces every depends_on, mentally runs the blast radius, and burns 40 minutes they didn’t have.
AI doesn’t replace the second review. It kills the first one. It handles the mechanical, repetitive scanning so the human reviewer spends their attention on the thing only a human can decide: is this change safe to ship?
What AI Should Review vs What Humans Should Review
AI is excellent at scanning for patterns: security misconfigurations, cost increases, destructive changes, policy violations, inconsistent tagging, and provider best-practice issues.
Humans are still responsible for the decisions that matter: architecture trade-offs, business risk, operational impact, compliance requirements, and whether a change is actually safe to ship.
A useful rule of thumb:
Let AI review the implementation. Let engineers review the intent.
Here are 12 concrete ways I plug AI into Terraform, CloudFormation, and Pulumi reviews. These aren’t theoretical. Each one is something you can wire into a PR today.
Whether you're using ChatGPT, Claude, Gemini, GitHub Copilot, Cursor, or another LLM-powered assistant, the workflow is largely the same: feed it the diff, the plan output, or the module code, and let it surface risks for human review.
1. Security misconfig scan
This is the highest-value use, full stop. Open security groups, public S3 buckets, unencrypted volumes, IAM policies with "*" on actions and resources — the classics that end up on a breach postmortem.
Static scanners catch a lot of this. AI catches the stuff that looks fine in isolation but is wrong in context. A security group rule referencing a variable that resolves to 0.0.0.0/0 two modules away won’t always trip a linter. It will trip a model that reads the whole diff.
Prompt it like this:
Review this Terraform diff for security misconfigurations. Flag any resource exposed to the public internet, missing encryption at rest or in transit, overly permissive IAM, or hardcoded credentials. For each finding, give the file, the line, the risk, and the fix.
2. Explain the diff
Half of review fatigue is just figuring out what a PR does. Someone refactored a module, renamed three variables, and now the diff is 600 lines of noise hiding two real changes.
Feed the diff to AI and ask for a plain-English summary. “This PR moves the RDS instance to a new subnet group, bumps the instance class from db.t3.medium to db.r6g.large, and removes the read replica.” Now your reviewer starts from understanding instead of archaeology.
This one change alone has done more for my team’s review speed than any tooling we’ve added in a year.
3. Cost impact preview
terraform plan tells you what’s changing. It doesn’t tell you what it costs.
Pipe the plan output into AI and ask for a rough cost delta. It won’t be penny-accurate - use Infracost for that — but for a quick “wait, this PR adds a NAT gateway per AZ and three r6g.4xlarge nodes, that’s real money” gut-check before merge, it’s instant.
Here is my terraform plan output. Estimate the monthly cost delta of the new and modified resources. Call out anything that looks expensive or accidental.
4. Policy as code assist
Writing OPA, Sentinel, or Checkov rules from scratch is tedious. You know the standard you want to enforce. Translating “all S3 buckets must have versioning and block public access” into working Rego is the annoying part.
AI is good at this. Describe the policy in English, give it your provider, and let it draft the rule. Then you test it. The draft gets you 80% there; the testing is non-negotiable.
5. Catch hardcoded secrets
Secret scanners match patterns. AI reads intent.
A scanner sees password = var.db_password and moves on. It also sometimes misses a token that’s been base64-ed, split across a string concat, or stuffed into a locals block that doesn’t look like a secret. A model reading the actual code catches the ones that hide in context. Run both — regex scanners and AI are complementary, not redundant.
6. Best-practice linting
Naming conventions. Consistent tagging. Module structure. Pinned provider versions instead of floating >= 4.0. Remote state configured and locked.
None of this is hard. All of it gets skipped under deadline. AI is a tireless nitpicker that never gets tired of saying “you forgot to pin the provider version again.” Let it own the boring consistency checks so your humans don’t have to play tagging police in every review.
7. Blast-radius analysis
This is the one that saves you from a 2 a.m. incident.
plan will happily tell you it’s going to destroy and recreate your production database because someone changed an immutable field. Buried in 200 lines of green and red, that one -/+ is easy to miss.
Hand the plan to AI and ask the direct question:
Read this terraform plan. List every resource being destroyed or replaced. For each one, tell me if it holds state or data that would be lost, and rate the risk.
When it flags aws_db_instance.main for replacement, you stop, you breathe, you check for prevent_destroy, and you do not merge.
8. Drift reasoning
State drifted. The console says one thing, your state file says another. Why?
AI is genuinely useful at reasoning through drift: someone clicked in the console, an autoscaling event changed a count, a tag got added by a separate automation. Describe what drifted and let it suggest safe reconciliation steps — import the change, update the code to match, or revert. It turns “ugh, drift again” into an actual plan.
9. Module refactor suggestions
When you’ve copy-pasted the same VPC block across four environments with slightly different CIDRs, AI will spot the duplication and propose a reusable module with variables. It’s a competent pair-programmer for the “this should really be DRY” conversation that nobody has time to start.
Treat its suggestions as a draft refactor, not a mandate. The structure it proposes is usually sound; the variable names and defaults need your judgment.
10. Generate test cases
Terratest and policy tests are the things everyone agrees they should write and nobody writes. AI lowers the activation energy: give it a module, get back a Terratest skeleton and example tfvars covering edge cases you’d have forgotten — empty lists, max-length names, the disabled-feature path.
The tests it writes need review like any other code. But a reviewed AI-drafted test beats the zero tests you actually had.
11. PR review bot
Wire all of the above into CI. A GitHub Action or GitLab CI job that runs the diff through an LLM and auto-comments findings directly on the PR. The reviewer opens the PR and the security flags, cost notes, and blast-radius warnings are already sitting there as comments.
The trick is tuning it to be useful, not noisy. Scope it tightly — security, cost, and destructive changes — and suppress the low-signal nitpicks, or people will start ignoring the bot entirely. A review bot everyone mutes is worse than no bot.
12. Keep humans in the loop
This is the one rule you don’t break.
AI suggests. Engineers approve. You never, ever auto-merge infrastructure based on an AI review. The model is a fast, thorough, occasionally confidently-wrong assistant. It will miss things. It will sometimes hallucinate a risk that isn’t real, or wave through one that is.
Its job is to surface signal. The decision to ship a change that can take down production stays with a person who owns the pager.
The actual point
AI reviews the noise so humans decide the risk.
That’s the whole philosophy in one line. The wins are real and measurable: faster PR reviews, fewer production misconfigs, consistent standards across every repo and every engineer regardless of how tired they are on a Friday afternoon.
But the value isn’t that AI reviews for you. It’s that it clears the mechanical 80% — the scanning, the summarizing, the consistency checks — so your senior engineers spend their limited attention on the 20% that actually requires judgment.
Start with one. Pick blast-radius analysis or the diff explainer, wire it into a single repo this week, and see how much review time you get back. Then add the next.
If this was useful, subscribe — I write practical DevOps, cloud, and AI engineering breakdowns like this regularly.
— Tech Fusionist