The Drift Between Intent and Execution
The promise of AI agents automating complex tasks, like managing infrastructure-as-code, is immense. However, a critical gap exists between the plan an AI agent generates and the actual changes applied to a production system. This disconnect arises because the state of the infrastructure can change between the agent's planning phase and the final application of those changes. The result: a reviewed plan that looks safe and accurate can lead to unexpected and potentially harmful modifications in production.
Consider a scenario where an AI agent modifies Terraform code. The process typically involves the agent proposing changes, generating a plan that outlines these changes, and then a human or another automated system reviewing this plan. If the plan looks good – clean diffs, sensible resource names, and an output matching the user's request – it gets approved. The problem emerges during the `apply` phase. By the time the changes are actually implemented, the infrastructure's state might have shifted due to other concurrent operations or external factors. The `apply` command, when executed, re-evaluates the desired state against the *current* state, effectively generating a *new* plan. This new, unreviewed plan is what then touches production. The diff that was approved in the review phase is not necessarily the diff that is executed.
This isn't a hypothetical edge case; it's a recurring challenge in automated infrastructure management. The core issue is that the review process is decoupled from the final execution environment. We're reviewing a static snapshot of intent, not the dynamic reality of its application. This is akin to approving a detailed architectural blueprint for a building, only to find out during construction that the ground conditions have changed, requiring significant, unapproved alterations to the foundation. The blueprint was correct for its time, but it didn't account for the evolving environment.
The Need for a Universal Harness
To address this, a robust mechanism is needed – a harness that acts as a compiler and SDK for the AI era of infrastructure management. This harness sits between the entity proposing a change (whether a human, an AI agent, or a CI/CD pipeline) and the system that actually deploys those changes to production. Its primary function is to ensure that what is reviewed is precisely what will be applied, mitigating the risk of plan drift.
Such a harness must manage the entire lifecycle of an infrastructure change. It needs to capture the initial intent, generate a plan based on the current state of the infrastructure, allow for a thorough review of that specific plan, and then execute *that exact plan* without re-planning against a potentially altered state. This implies a multi-stage process:
- Intent Capture: The system must reliably record the desired changes, whether they originate from a natural language prompt to an AI agent, a commit to a Git repository, or a direct API call.
- Pre-Application Planning: Before any changes are made, the system generates a precise plan. This plan is a snapshot, detailing exactly which resources will be created, modified, or destroyed, and how. This is the artifact that should be reviewed.
- Immutable Review: The reviewed plan must be immutable. Once approved, the system should commit to executing that specific plan. Any subsequent changes to the infrastructure state should not alter the approved plan's execution, but rather be handled in a new, separate planning and review cycle.
- Controlled Application: The execution phase must apply the *exact* changes outlined in the reviewed plan. If the infrastructure's state has changed, the system should either alert the user to the discrepancy and require a new review, or roll back the apply attempt.
This approach transforms the review process from an abstract validation of code to a concrete review of the action that will be taken. It provides a verifiable link between the human or AI's intent and the final outcome, significantly enhancing the safety and reliability of automated infrastructure deployments.
Beyond Code: Reviewing Actionable Plans
The fundamental shift required is to move from reviewing code to reviewing plans. Code is a statement of intent; a plan is a statement of action. While reviewing code can catch logical errors or stylistic issues, it cannot guarantee that the code will result in the same outcome when applied in a dynamic environment. The plan, generated just before application, reflects the precise actions to be taken against the current infrastructure state. This is the artifact that requires scrutiny.
This paradigm shift has profound implications for how we build and deploy infrastructure. It necessitates tooling that can orchestrate this plan-centric workflow. For developers and operations teams, it means adapting their review practices. Instead of just approving pull requests containing Terraform or CloudFormation files, they must approve the output of `terraform plan` or `aws cloudformation plan`. This requires better integration of planning tools within CI/CD pipelines and review workflows.
For AI agents, it means their output must be structured not just as code, but as a clear, actionable plan that can be fed into such a harness. The agent's performance should be measured not by the elegance of the code it writes, but by the accuracy and safety of the plans it generates and the successful, predictable application of those plans.
The core problem is that the current tooling and workflows often treat the AI agent's output as the final word, without acknowledging the critical re-planning step that occurs before application. By building a harness that enforces an immutable review of the *applied plan*, we can bridge this gap and unlock the true potential of AI in infrastructure management, ensuring that automated changes are both efficient and safe.