{
  "id": 9637734,
  "title": "Why Plan Review Stopped Working",
  "url": "https://urgent.news/2026/09/24/why-plan-review-stopped-working",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-24T21:42:02.000Z",
  "source": {
    "name": "DevOps.com",
    "slug": "devops-com",
    "url": "https://devops.com/why-plan-review-stopped-working/"
  },
  "original_language": "en",
  "account": "Plan review was once the cornerstone of infrastructure control, relying on human reviewers to read code differences and decide whether to approve changes. However, an influx of pull requests overwhelmed this system, with agents opening 40 pull requests before lunch. Reviewers approved them to keep the queue moving, but this approval requirement was still embedded in the workflow file, continuing to block merges and write audit events. The control's saturation made it appear still functional, even though it no longer served its intended purpose.\n\nThe approval action had four distinct functions: policy compliance, blast radius estimation, intent implementation, and record-keeping. These functions relied on the same finite resource - reviewer attention. As review volume surpassed capacity, all four functions simultaneously stopped working. The increase in change count scaled review costs, making human review largely a recognition task. Generated modules, lacking a baseline, required reviewers to evaluate unfamiliar but valid-looking code within seconds.\n\nAs review latency displaced changes into the console path, governance coverage decreased, and the audit log could no longer differentiate between careful reviews and queue-clearing approvals. Compliance checking became a matching operation, requiring no additional judgment once rules were written, but its execution slowed as volume increased. To address this, compliance checks should be moved into the run, evaluating changes against policy when plans are generated and rejecting plans whose state has moved. Deny-by-default for high-risk resources, such as IAM, networking, and data resources, while auto-approving the rest.\n\nEstimating blast radius proved ineffective due to the time constraints and familiarity required. Instead, constraints should be assigned to experimental infrastructure, such as a time to live (TTL) and budget caps, restricting which resource types can be created. This approach, combined with a two-path deployment model, ensures production changes are traceable to commits while experimental work runs on a governed fast path. However, intent verification remains a human function that cannot be performed by a policy engine. Agents generating changes need a governed execution path with limited identities, policy evaluation, an audit trail, and denial responses for correction.\n\nFinally, the audit record should reflect system enforcement rather than human attention, documenting policy evaluations with content, rule names, inputs, decisions, and timestamps. This change ensures drift detection catches console edits to already managed resources and measures mean time to repair (MTTR) instead of just drift count.",
  "summary": "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 […]",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}