{"slug": "using-ai-verification-and-fix-loop-for-iac-terraform-opentofu-pulumi", "title": "Using AI Verification and Fix Loop for IaC (Terraform, OpenTofu, Pulumi)", "summary": "A verification and fix loop lets AI coding agents read Terraform, OpenTofu and Pulumi plan output, compare it against the intended outcome, and correct their own infrastructure-as-code changes before requesting human review, according to a 10.26.2026 article by Yangci Ou. Ou cites Anthropic's Claude Code documentation, which states that without a check the agent can run, \"'looks done' is the only signal available, and you become the verification loop,\" and Anthropic recommends giving agents a pass-or-fail result to test against. Ou's examples include importing a hand-built AWS Application Load Balancer into Terraform, where the loop corrected a target group name and an idle_timeout value until the final plan contained seven expected imports and only agreed ManagedBy tag changes, and refactoring 14 security groups into a shared child module using moved blocks until the plan showed all 14 expected address moves with no live resource changes.", "body_md": "Published: 10.26.2026\nUsing AI Verification and Fix Loop for IaC (Terraform, OpenTofu, Pulumi)\nBy Yangci Ou\nLet AI agents read Terraform, OpenTofu, and Pulumi plans, compare them with what you asked for, and fix unexpected changes before asking for review.\nThe cheapest part of \nInfrastructure as Code (IaC)\n today is the code generation. Agents from frontier AI models are opening pull requests on platforms like GitHub faster than reviewers can keep up. But with infrastructure, even a small change can replace a database or cut off an application’s access to it, so each change needs to do only what we intended.\nCI/CD already runs the plans and posts the results on pull requests. You read them, spot an unexpected replacement that would cause downtime or an error that blocks the plan, and send the output back to the agent. The agent fixes the code and pushes again. You wait for CI, read the new plans, and paste back the next problem.\nA verification and fix loop lets the agent read those same results, compare them with what you asked for, and correct its own mistakes before requesting review. You define the intended outcome; the agent checks each revision against it. As Anthropic’s \nClaude Code documentation\n puts it, the agent “stops when the work looks done. Without a check it can run, ‘looks done’ is the only signal available, and you become the verification loop: \nevery mistake waits for you to notice it\n.” Anthropic recommends giving the agent a pass-or-fail result so it can test its changes, inspect the feedback, and keep correcting the work until the check passes.\nIn application development, we expect a coding agent to run tests, read failures, and fix the code before asking for review. That expectation should carry over to infrastructure work.\nExamples: Verification and Fix Loops for IaC\n\n#\nA verification and fix loop can help with any IaC change that has a clear intended outcome and checks the agent can run or read. Importing existing infrastructure and refactoring modules are two examples: in each, the agent catches unexpected changes, corrects the code, and repeats the check until the plan matches the intended outcome.\nImporting a Hand-Built AWS Application Load Balancer Into Terraform\n\n#\nA common example is bringing \nClickOps\n infrastructure into Terraform. Say I want to manage a hand-built ALB and its related infrastructure with Terraform without changing how it runs. I use \nimport blocks\n and write resource code that matches the live infrastructure on AWS. The only agreed AWS changes are the additional \nManagedBy\n tags. In this example, the first plan proposes replacing a target group because its name in the code differs from the live name, so the agent reads the plan and corrects the name. The next plan would change the ALB’s \nidle_timeout\n because the code leaves it at the default value, so the agent sets it to the existing value. The final plan contains the seven expected imports and only the agreed tag changes, with nothing created or destroyed, so it’s ready for review.\nRefactoring 14 Security Groups Into a Shared Terraform Module\n\n#\nI can also use a loop to refactor a Terraform module without changing live infrastructure. Here, we want to move 14 security groups from the root module into a shared child module. We use \nmoved\n blocks to refactor the modules\n, mapping the old state addresses to the new ones (e.g. \nmodule.security_groups.aws_security_group.this[\"alb\"]\n). In this example, the first Terraform plan proposes recreating some groups because their destination addresses are wrong, so the agent reads the plan and corrects the mappings. The next plan would remove an existing tag, which we don’t want, so the agent preserves it in the module. The final plan shows all 14 expected address moves and no live resource changes, ready for review.\nWhat a Plan Can’t Prove: Applying in a Sandbox Account\n\n#\nA plan can show the expected security group rule and still leave an application unable to reach its database. To verify that behavior, apply the change in a separate sandbox account and run a check from the application environment.\nFor an ECS task timing out against RDS, \nVPC Reachability Analyzer\n can identify blocking network configuration. Create a path between the relevant network interfaces for TCP port \n5432\n, start an analysis, and wait for its status to become \nsucceeded\n. Then inspect \nNetworkPathFound\n and \nExplanations\n.\nA \nfalse\n result with a blocking security group gives the agent a specific failure to investigate. It fixes the HCL, applies in the sandbox, and reruns the analysis within the permitted change scope.\nDefine the Verification and Fix Loop in Repository Instructions and Agent Skills\n\n#\nRun the usual formatting, validation, linting, and security checks first. Our \nCI checklist post\n covers the setup.\nA completed plan can still propose changes outside the request. The agent should compare it with the definition of done, checking both what should change and what must stay the same, so use the planning workflow your organization permits and retrieve the actual plan. Where local planning is allowed, the agent can read Terraform or OpenTofu plans, or Pulumi previews, directly. Some organizations require plans to run through approved CI/CD systems such as GitHub Actions, or infrastructure automation platforms such as Spacelift, HCP Terraform (formerly Terraform Cloud), or Atlantis. In that case, the agent pushes a change, waits for the run, and fetches its output through an available MCP integration, API, or CLI. The \nSpacelift MCP\n provides one way to read proposed runs and their logs.\nThe agent can read the plan as text or use its \nJSON representation\n. If it finds an error or an unexpected change, it uses that feedback to revise the code and check again. The original requirements stay fixed through those retries; the agent should not hide differences or weaken the check to get a passing result.\nPut the shared rules in repository instructions such as \nCLAUDE.md\n or \nAGENTS.md\n, and the reusable loop in an agent skill. A verification and fix loop means making a change, running or waiting for a check, reading the result, and trying again until the result matches the requested change or the agent needs human input. It needs four things:\nA measurable definition of done.\nFor a module refactor, that might be zero cloud resource changes and 14 expected address moves.\nFor a connectivity fix, it might be one new security group rule followed by a successful database query from the application, or a successful \ncurl\n request from within the VPC.\nFor importing live infrastructure into Terraform or OpenTofu\n, expect the imports with no changes to the existing AWS resources, except any explicitly agreed updates, such as tags. The resources become managed through IaC without being recreated or reconfigured beyond those tags.\nOutputs the agent can access and read. The agent fetches the plan output and logs for the current commit through one of the workflows above and compares them with the expected result to decide what needs fixing.\nPermissions & guardrails that block production applies. The agent can read production plans, but any apply needed to validate behavior must run in a separate sandbox account. Its credentials must not allow it to apply changes in production.\nA clear handoff. Require the agent to return the evidence when the checks pass or explain the blocker when it needs human input.\nStop after a number of attempts of the same result (e.g. 5 attempts and still the same bad output) to prevent the agent from burning tokens or working around the problem, such as adding \nignore_changes\n, which tells Terraform to stop reconciling the listed attributes so an unexpected change disappears from the plan without being fixed.\nFor example, with minimal permissions the agent can only open PRs for the code, read runs through the Spacelift (or another infrastructure automation platform) MCP, read AWS, and apply only in sandbox accounts.\nHere’s one way to write these instructions for a repository using Spacelift. Adapt the definition of done, how the agent reads results, and its permissions to your own repository and deployment workflow.\n\n```\n---\nname: tf-verify-spacelift\ndescription: Verify Terraform/OpenTofu changes in this repo through Spacelift.\n---\n\nDefine the intended outcome, what must stay unchanged, and the checks that will\nconfirm success. If any of these are unclear, ask the user before proceeding.\n\nAfter each push, use the Spacelift MCP to find the proposed run for the correct\nstack and latest commit. Wait for the plan, read its output, and compare it with\nthe agreed result.\n\nFix the underlying cause of errors or unexpected differences without skipping\nchecks or hiding changes, then push again. Keep using the Spacelift MCP to check\neach new run until the plan matches the agreed result. Keep the acceptance\ncriteria unchanged.\n\nStop and ask for help if the same error or unintended plan output remains after\nfive attempts, or if you are blocked by something that requires human input.\nExplain the blocker, what you have tried, and link the relevant runs.\n\nWhen the plan matches the agreed result, return the run URL, commit, a short\ncomparison of expected and actual changes, and anything the plan cannot prove.\n\nNever trigger, confirm, or discard runs; never apply; never modify state\ndirectly; never merge; never widen access; never add ignore_changes to make the\nplan pass.\n```\n\nFor GitHub Actions, replace the Spacelift instruction with reading the matching workflow run through \ngh\n, and prohibit edits to workflows or branch protection. Adapt the result-fetching instruction for HCP Terraform, Atlantis, or another platform.\nThis could go into the prompt for anything ad-hoc as well, as long as you give it the definition of done and how to verify against it, with properly scoped least-privilege permissions.\nA \nStop hook\n can also require a verification script before completion, rather than instructions in a skill that could be skipped over.\nWhat the Agent Hands Back and the Human Still Reviews\n\n#\nThe agent hands back a Pull Request with the code and explains the expected versus actual changes and includes any required behavior-test results. It also describes the unexpected changes it found and corrected, along with anything still unverified. If it is blocked, it returns the specific problem, what it tried, and the relevant runs.\nThe human still reviews the code and final plan, confirms that the acceptance criteria cover the intended change, and checks any gaps in runtime verification. A passing sandbox test covers the tested environment; the production deployment still needs its own reviewed plan and checks.\nAt Masterpoint, we expect the agents to review infrastructure plans to ensure they match what we intended and review them ourselves first before asking another engineer / teammate for review.\n👋 \nIf you're ready to take your infrastructure to the next level, we're here to help. We love to work together with engineering teams to help them build well-documented, scalable, automated IaC that make their jobs easier. \nGet in touch!", "url": "https://wpnews.pro/news/using-ai-verification-and-fix-loop-for-iac-terraform-opentofu-pulumi", "canonical_source": "https://masterpoint.io/blog/ai-verification-fix-loop-iac/", "published_at": "2026-10-26 17:34:31+00:00", "updated_at": "2026-10-26 17:41:52.817315+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-infrastructure", "developer-tools"], "entities": ["Yangci Ou", "Anthropic", "Claude Code", "Terraform", "OpenTofu", "Pulumi", "AWS", "GitHub"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/using-ai-verification-and-fix-loop-for-iac-terraform-opentofu-pulumi", "markdown": "https://wpnews.pro/news/using-ai-verification-and-fix-loop-for-iac-terraform-opentofu-pulumi.md", "text": "https://wpnews.pro/news/using-ai-verification-and-fix-loop-for-iac-terraform-opentofu-pulumi.txt", "jsonld": "https://wpnews.pro/news/using-ai-verification-and-fix-loop-for-iac-terraform-opentofu-pulumi.jsonld"}}