AI Coding Agents
Infrastructure
Safer infrastructure as code changes with agents
September 24, 2026 - 2 minute read
Infrastructure as code changes can alter networks, identities, storage, and production capacity from a small diff. A coding agent can prepare those changes, but the pull request must show more than valid syntax. Reviewers need the proposed resource graph, the provider plan, policy results, and a controlled path to application.
The terraform plan command previews the changes Terraform proposes for the current configuration and state. That plan is evidence, not an approval. Values can remain unknown until apply time, and the result depends on the selected workspace, variables, provider versions, and current remote state.
Scope infrastructure as code changes
Give the agent a narrow outcome and name the allowed modules, accounts, regions, and environments. Include the expected resource changes and state whether deletion, replacement, or privilege expansion is allowed. A request such as “add the staging queue and its alert” is reviewable. “Improve the cloud setup” leaves the blast radius undefined.
Pin the toolchain before editing. The task should identify the Terraform or OpenTofu version, provider lockfile, backend, workspace, variable source, and formatting and validation commands. Factory’s remote delegation guidance recommends providing the desired outcome, acceptance criteria, verification steps, and repository links. For infrastructure work, those instructions should also forbid apply commands unless the run is explicitly authorized.
Review infrastructure as code plans
Ask the agent to produce a fresh plan from the target environment after it changes the configuration. Review the human-readable plan and retain the machine-readable output when policy tooling consumes it. Check counts of resources to add, change, replace, and destroy. Inspect changes to IAM, public access, encryption, retention, network paths, and data-bearing resources separately.
A clean plan can still encode the wrong intent. Compare it with the request and architecture boundary. Confirm that names, tags, ownership, and lifecycle settings match local conventions. If a provider reports unknown values, identify which checks must wait for apply rather than treating the plan as complete proof.
Factory’s automated code review can run repository-specific review guidance on pull requests. Infrastructure guidance can require a checked-in plan summary, block unapproved destructive changes, and flag modifications outside the named modules. Keep deterministic policy engines and provider validation in CI because an AI review complements those controls rather than replacing them.
Keep application separate from preparation
Separate the identity that proposes a change from the identity allowed to apply it. Pull request automation should use read-only or planning credentials where the provider supports them. Production application should remain behind the existing approval and deployment path. Do not copy credentials into prompts, logs, plan artifacts, or repository files.
The pull request should include the requested outcome, changed modules, plan summary, policy results, rollback considerations, and any values that remain unknown. It should also state the exact environment used to generate the plan. Reviewers can then distinguish a code-only check from evidence tied to current infrastructure.
Stop when state access fails, the target workspace is ambiguous, or the plan includes an unexplained replacement or deletion. A blocked report protects infrastructure better than a speculative edit followed by an unverified plan.
