How I Review Terraform and Lambda PRs with AI Before They Merge

If my earlier posts were about how I write infrastructure and how I build AI-assisted workflows, this one is about the gate right before merge.

That distinction matters. Writing code with AI is useful. Reviewing production changes with AI is where the real value shows up for me. The problem is not getting a first draft fast. The problem is making sure the change is still safe when it touches IAM, Terraform state, Lambda runtime settings, or anything that can quietly cost money or break production.

So I started using AI as a first-pass reviewer for Terraform and Lambda pull requests. Not as the decision maker. Not as the person who approves the merge. Just as the reviewer that helps me catch the obvious and semi-obvious issues before I spend my own time on the full manual pass.

That keeps the review fast, but it also keeps the final responsibility where it belongs, with me.

This post is the workflow I trust today.

Short version: AI reviews the diff, I review the risk.

Why This Is a Different Post From My Other AI and AWS Articles

I already write about AI in AWS codebases, Terraform workflows, and agentic DevOps routines. This post is not another version of that same story.

The earlier posts focus on one of two things:

• how I use AI to help build infrastructure
• how I structure the workflow around the codebase

This one is narrower. It is about reviewing a production change before it merges.

That narrower scope makes it more useful in practice, because the questions are more specific:

• Did this IAM policy get broader?
• Did someone accidentally make a Lambda slower, hotter, or more expensive?
• Did Terraform replace something that should not be replaced?
• Did we open a networking path we did not mean to open?
• Did the PR forget tests, docs, or rollback notes?

That is the kind of review AI is actually good at helping with.

What I Feed the Reviewer

I do not ask the model to guess from thin air. I give it the actual change surface.

Typically that means some mix of:

• the pull request diff
• the Terraform plan output
• the files touched by the change
• the environment or service context
• any recent deployment or incident notes that matter

The quality of the review depends on the input. If I give it a sloppy prompt, I get a sloppy review. If I give it the real plan and the real diff, it can usually spot the things I want it to spot.

One caution: redact before you paste. Plan output can include values that are not marked sensitive, so I strip anything I would not put in a public issue.

I want the reviewer to answer a simple question: what would make this change risky to merge?

The Checks I Care About Most

For Terraform and Lambda work, I care about a small set of risk categories more than anything else.

1. IAM and permissions

This is the first thing I look at because permission creep is easy to miss in a diff. A policy can go from narrow to broad with one extra wildcard or one extra resource pattern.

I want AI to flag:

• new wildcards in actions or resources
• roles that gained access to more services than before
• policies that look temporary but are actually permanent
• anything that could grant access across environments

2. Lambda runtime and cost impact

Lambda changes can look tiny and still affect cost or reliability.

I want the reviewer to notice things like:

• memory jumps that are probably unnecessary
• timeouts that are too short or too generous
• concurrency changes that might cause throttle or burst issues
• extra cold-start risk from dependencies or packaging changes

3. Terraform replacement risk

This is where production changes can become unpleasant. A harmless-looking refactor can trigger a destroy-and-recreate path if someone changes the wrong attribute.

I want the model to call out:

• resources marked for replacement
• stateful resources with a destructive path
• name changes that can force recreation
• security groups, targets, or buckets that could disappear briefly

4. Networking and exposure

Anything that changes public access, private access, VPC wiring, or routing deserves extra attention.

I want the reviewer to be loud about:

• public exposure that was not there before
• new ingress or egress paths
• load balancer or API Gateway routing changes
• subnet or security group edits with hidden blast radius

5. Missing operational detail

Even if the code is correct, the review is not complete if the PR forgot the operational side.

So I want AI to ask about:

• rollback plan
• testing evidence
• migration order
• monitoring and alert impact
• what happens if this fails halfway through

What I Still Review Manually

AI helps me move faster, but some things should stay human-led.

My manual pass focuses on:

• the actual blast radius
• whether the change matches product intent
• whether rollback is realistic
• what stateful resources are involved
• whether the diff makes sense in the larger release plan

I also sanity-check anything that looks too confident. If the model says a change is safe, that is not enough. I want the evidence behind the claim.

The best outcome is not “AI approved it.” The best outcome is “AI surfaced the right questions before I reviewed it.”

My Review Flow

The flow is pretty simple.

1. Collect the PR diff and Terraform plan.
2. Ask the AI reviewer to summarize the change in plain English.
3. Ask for the top risks, sorted by severity.
4. Ask for anything that looks inconsistent or missing.
5. Do my own manual pass on the flagged areas.
6. Approve, request changes, or split the PR if the risk is too broad.

That sounds basic, but it works because it keeps the review structured.

Here is the kind of prompt I use conceptually:

You are reviewing a production AWS change.

Focus on:
- IAM and permissions
- Terraform replacement risk
- Lambda runtime and cost impact
- networking and exposure
- missing rollback or operational detail

Return:
1. plain-English summary of the change
2. top risks ranked by severity
3. specific lines or resources that look suspicious
4. questions I should answer before merge
5. a merge recommendation: safe, caution, or block

I do not need poetry from the reviewer. I need a compact risk report I can act on.

A Good Review Finds the Questions, Not Just the Bugs

Sometimes the most useful thing the AI does is not catch a mistake outright. It points out that something deserves a question.

Examples:

• Why did this Lambda need double the memory?
• Why is this IAM role suddenly allowed to touch more than one environment?
• Why does this Terraform change replace the resource instead of updating it in place?
• Why is this public endpoint now reachable from a wider range of traffic?

That kind of review is valuable because it slows me down in the right place. It makes the risky bit visible before I merge.

Why This Complements My Other AI Workflow Posts

If I compare this to my other posts, the shape is different.

Earlier posts are about:

• using AI to build faster
• breaking work into specialists
• keeping agents safe in production codebases

This one is about the final gate before the change goes live.

That is why I think it is a good companion piece instead of a duplicate. It belongs in the same family, but it answers a different question.

One post is about the tools that help me work. This post is about the review layer that keeps me honest.

What I Want the Reviewer To Avoid

There are a few failure modes I do not want from an AI reviewer.

• Do not rubber-stamp the diff.
• Do not hide uncertainty behind confident language.
• Do not recommend merge without explaining why.
• Do not ignore infrastructure changes just because the application code looks small.
• Do not treat production Terraform like toy code.

If the model cannot explain the risk, it is not helping much.

Final Thought

AI review works best when it makes the important things easier to see, not when it replaces judgment.

That is the real pattern I keep coming back to in AWS work. I want speed, but I want it inside a review process that still respects the cost of being wrong.

So yes, I use AI to review Terraform and Lambda PRs. But the point is not to automate approval. The point is to catch the risky stuff earlier, ask better questions, and make the human review sharper.

That is the version I trust in production.

---

Originally published at harun.dev. The full interactive version lives there. Follow me on X or read my bio.