AI-Assisted Infrastructure Engineering›06 · AI-assisted PR review

Lesson 06 of 14 · Modules

AI-assisted PR review

Add AI to pull-request review for infrastructure repos: run deterministic checks first (lint, policy, deprecation and security scanners), then an AI reviewer focused on upgrade risk, security and intent-vs-diff, posting suggestions that humans decide on.

Practitioner → Advanced
Key wordsAI code reviewpull requestsdeprecated APIssecurity reviewdriftdeterministic checks firstreview promptsCI integrationfalse positiveshuman approval

Two layers of review

PR opened
  ├─► deterministic checks: fmt, validate, lint, schema, policy, deprecations, secrets
  │        (block merge on failure)
  └─► AI review: intent vs diff, risk, blast radius, edge cases, rollout/rollback
           (comments/suggestions only)
                  └─► human reviewer decides (CODEOWNERS)

Before a school play, a checklist robot checks the obvious things: costumes on, microphones working, props in place. Then a thoughtful helper watches a rehearsal and says: "In scene 3, if the curtain sticks, what's the plan?" The teacher still decides whether the play goes ahead.

What AI reviewers are good at (for infra)

  • Intent vs diff: does the change do what the PR description says, and nothing else?
  • Blast radius: shared values, base overlays, global config; which clusters/environments are affected?
  • Upgrade risk: combined with pluto/kubent output, explain what breaks at the target Kubernetes version and how to fix it.
  • Security smells: privileged pods, hostPath mounts, wide RBAC, public buckets, missing encryption, secrets-like strings (with gitleaks as the authority).
  • Operational gaps: no timeouts, no PDB, no resource requests, no rollback note, missing alerts for a new component.

A review prompt that works

You are reviewing an infrastructure pull request. Inputs: the PR description, the diff,
and outputs of: terraform plan (summary), kubeconform, pluto, checkov, gitleaks.

Report, in order:
1. Mismatches between the description and the diff (files or behaviours not mentioned).
2. Blast radius: which environments/clusters are affected, and whether rollout is staged.
3. Risks the tools can't see (ordering, data loss, downtime, dependency changes), each with
   file:line, why it matters, and a concrete suggestion.
4. Findings from the tool outputs that need human attention, explained briefly.
Rules: do not restate formatting/lint issues; say "no findings" rather than inventing issues;
mark uncertain points as questions.

"Say no findings rather than inventing issues" and "mark uncertainty as questions" reduce noise and false confidence.

Wiring it into CI

  • Run AI review as a CI job on PRs (for example, Anthropic's Claude Code GitHub Action, or a headless claude -p step with the prompt above; other vendors have equivalents).
  • Give the job read-only repository access plus permission to comment; no deploy credentials.
  • Feed it tool outputs as inputs, so it reasons about facts.
  • Keep CODEOWNERS and required human approval unchanged.

Measure and tune

  • Track accepted vs dismissed AI comments; tune the prompt to cut categories that are mostly noise.
  • Collect misses (issues found later that AI review didn't flag) to improve prompts or add deterministic checks.
  • Keep reviews short: a few high-value comments beat a wall of text.

Try it: two-layer review on a sandbox repo

  1. Create a repo with a small Helm chart and Terraform module; add CI running kubeconform, pluto, checkov and gitleaks.
  2. Open a PR that upgrades an Ingress to an old extensions/v1beta1 apiVersion (to see pluto flag it) and adds a privileged container.
  3. Run an AI review with the prompt above (headless CLI or a GitHub Action) using the tool outputs as input.
  4. Compare which issues each layer found; note false positives.
  5. Adjust the prompt once and re-run; record whether signal improved.

Going deeper: review programmes

  • Use different prompts per repo type (Terraform, Helm, app code); specific beats generic.
  • Add AI review to post-merge audits of risky areas (RBAC, network policies) on a schedule.
  • Be explicit in policy that AI review is advisory; accountability stays with human reviewers.

Recap

  • Deterministic checks first (fmt, validate, lint, schema, policy, deprecations, secrets), blocking.
  • AI review second: intent vs diff, blast radius, upgrade and operational risk, as suggestions.
  • Feed the AI tool outputs, ask it to avoid inventing issues, and keep humans accountable.
  • Measure accepted/dismissed comments and misses; tune continuously.

This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.