The page
I asked an agent to tidy up a Terraform module: consistent naming, a couple of deprecated arguments replaced. The diff was clean and the explanation was good. The plan was not:
# aws_lb.public must be replaced
-/+ resource "aws_lb" "public" {
~ name = "public-alb" -> "svc-public-alb" # forces replacement
A rename that forces replacement on a production load balancer means a new DNS name and dropped connections.
Triage
terraform plan -out=tfplan
# anything being replaced (delete + create) in this plan
terraform show -json tfplan \
| jq -r '.resource_changes[] | select(.change.actions == ["delete","create"] or .change.actions == ["create","delete"]) | .address'
Root cause
The agent made a reasonable change for the code and didn't know (or wasn't
told) that the name of an aws_lb can't be changed in place. The diff was
fine. Only the plan showed the effect on real infrastructure.
The fix
Reverted the rename and kept the rest. The more useful change was to the instructions agents get for this repo: "never rename resources that force replacement; show the plan's replace list in the PR description."
What I learnt
Agents write plausible code fast, and plausible is where the risk is. The guardrail that worked was the same one I'd use for a person: an agent can plan, a human reads the plan, a human approves the apply.
What I do now
- Agents can run
plan. Only a human can approveapply. - The PR shows the plan's replace and delete list, not just the code diff.
- Write repo-level instructions for agents, including the things that bit you.
if you're bringing AI agents into infrastructure work → page me