Category: DevOps Practice

The control that held your infrastructure together was plan review, meaning a person reading a diff and deciding whether to approve it. Not the policy document and not the pipeline configuration. It worked because change arrived at human speed.

That condition no longer holds. An agent opens 40 pull requests before lunch. Reviewers approve them to clear the queue. The approval requirement is still declared in the workflow file, still blocking the merge, still writing an audit event, and no longer doing its job.

Nothing removed plan review. Change volume saturated it. A saturated control emits the same signals as a working one.

What Plan Review Was Actually Doing

The approval action performed four distinct functions. Nobody designed that bundle; it accumulated over time, with a required reviewer after an outage and a checklist after an audit, each attaching to the action already in the workflow.

Policy compliance: Does the change conform to the rules the organization agreed to?

Blast radius: If the change is wrong, what is the scope of the failure?

Intent: Does the change implement what was actually requested?

The record: Evidence that the change was evaluated before it shipped.

All four draw on the same finite resource, reviewer attention, so they degrade together rather than independently. When review volume exceeds review capacity, all four stop working at the same point.

Why Plan Review Saturated

Review cost scales with change count, and change count is now unconstrained. That mechanism produces three effects.

Generated code defeats pattern recognition. Human review is largely recognition. A reviewer who has read a module before knows its normal shape and spots deviation from it. Generated modules provide no baseline, so the reviewer evaluates unfamiliar but valid-looking code under a time budget measured in seconds.

Approval latency displaces changes out of the pipeline. When the pipeline path costs two days and the console path costs 90 seconds, a proportion of changes take the console path, and those changes are never planned, reviewed, or recorded. Governance coverage decreases as governance latency increases.

The audit log cannot separate the two cases. A careful review and a queue-clearing approval produce the same record, with the same actor, event type, and shape. The log captures the action, not the evaluation.

Compliance Checking Moves Into the Run

Compliance checking is a matching operation. It takes a proposed change and a rule set and returns a decision. Much of that checking requires no additional judgment once the rules are written and the exceptions are routed. Human evaluators can perform it slowly and inconsistently, with accuracy degrading as volume increases.

Move it into the run. Evaluate the change against policy when the plan is generated, and reject at apply any plan whose state has since moved, so the replan is evaluated again. Configure deny by default for the resource classes where errors are expensive and hard to reverse, which means identity and access management (IAM), networking, and data resources. Auto-approve the remainder.

Rule authorship and ownership are a separate problem worth settling first. The effect here is on reviewer load. Human approval stops being the default path and applies only to the cases policy explicitly routes to a person.

Bound the Blast Radius Instead of Estimating It

Blast radius estimation was the weakest of the four functions before volume became a problem. It requires a probability judgment, under a short time budget, from a plan that describes intended changes rather than downstream effects. It is also the function most sensitive to code familiarity, so it degrades first on generated code.

Replace the estimate with a constraint. Assign experimental infrastructure a time to live (TTL) and destroy it on expiry. Apply budget caps. Restrict which resource types can be created. Place it in non-production accounts with no path to production data.

This is the reasoning behind a two-path deployment model. Infrastructure as code (IaC) and GitOps remain the system of record for production, where every change is traceable to a commit. Experimental work runs on a governed fast path where the controls are constraints rather than review.

A change that is constrained from causing damage does not require a prediction about whether it will.

The One Job That Stays With Humans

Intent verification is the function a policy engine cannot perform. Policy evaluates resource types, fields, and values. It has no access to the requirement the change was written to satisfy. That function stays with reviewers, and it depends on attention the other functions currently consume.

Agent authorship adds a second problem. When an agent generates the change, no human held the intent. The request moved from a ticket to a prompt to a pull request without passing through a person accountable for the outcome.

An agent therefore requires a governed execution path. That means a scoped identity limiting what it can act on, policy evaluation on the same basis as any other change, an audit trail naming the agent as the actor, and denial responses structured enough to correct against.

The Record Has to Produce Itself

An approval action was evidence that a change had been evaluated. Its evidentiary value decreases as the proportion of approvals issued to clear queues increases.

Replace evidence of human attention with evidence of system enforcement. A policy evaluation that emits its own record produces an audit trail with content in it, naming the rule that ran, the input, the decision, and the time. Documenting is a byproduct of enforcing, so it cannot be skipped.

Pair it with scheduled drift detection, which catches console edits to resources already under management. Measure drift mean time to repair (MTTR) rather than drift count. Drift count measures how often the boundary is crossed. MTTR measures how long the environment stayed in an unintended state.

Policy engines that evaluate agent operations before execution are one shape of this. Spacelift Intelligence is one place where this exists. Intent lets developers and their agents provision infrastructure by describing what they need under Intent policies, with the same state management and audit trail as everything else on the platform. Infra Assistant’s Build mode does the same from the Spacelift UI.

Attached Intent policies are evaluated on every create, update, delete, import, and refresh before the operation runs, returning explicit denial reasons when a deny rule matches and holding the operation for review when no rule matches.

Guardrails That Hold When Nobody is Reading

Plan review did not fail as a design. It was asked to perform four functions at a volume that broke all four.

Three move into the system. Compliance checking becomes policy evaluation in the run, blast radius becomes a set of constraints, and the record becomes a byproduct of enforcement. The fourth, whether a change implements what was intended, stays with reviewers.

Governance without speed produces a queue that engineers route around. Speed without governance produces unconstrained change. The workable configuration is enforcement that operates without requiring anyone to read.