Agent pull requests force plan review's four bundled jobs into separate controls

The reviewer at the end of the queue is reading a module that no one on the team wrote. Human review is mostly recognition, the devops.com article argues. A reviewer who has read a module before knows its normal shape and can spot when it deviates ^[4]. Generated modules offer no baseline to compare against ^[4]. So the reviewer judges unfamiliar code that looks valid, with a few seconds to do it ^[4].

Teams tell themselves an approval event means someone evaluated the change. The log only shows that someone approved it ^[7]. A careful review and a queue-clearing approval leave the same record, with the same actor and event type, because the log captures the action and not the evaluation ^[7]. "A saturated control emits the same signals as a working one," the article says ^[13].

Making review slower so it can be careful costs coverage ^[6]. In the article's example of a two-day pipeline beside a 90-second console, the governed path is about 1,920 times slower, since two days is 172,800 seconds ^[1].

Nobody designed the four-job bundle. According to the article, a required reviewer was added after an outage and a checklist after an audit, and each was attached to the approval step already in the workflow ^[5].

In my view the article's split is right for policy and blast radius. Compliance checking is a matching operation, and once the rules are written and exceptions are routed, most of it needs no further judgement ^[8]. The article would run that check when the plan is generated, and reject at apply any plan whose state has since moved so the replan gets checked again ^[8]. The tradeoff is that auto-approving everything outside the deny-by-default classes lets some wrong changes ship without anyone looking at them ^[8].

Blast radius was the weakest of the four jobs before volume grew. It asks for a probability judgement, made in seconds, from a plan that lists intended changes and not their downstream effects, and it is the first to fail on generated code ^[9]. If a change is limited in how much damage it can do, nobody has to predict that damage ^[10].

I would sort each change by two facts. The first is which of the two paths it is on. The second is whether it touches IAM, networking or data, the classes the article treats as expensive and hard to reverse ^[8]. Production changes in those classes are denied by default and go to a reviewer only when policy routes them there ^[8][15]. Other production changes are checked at plan time and auto-approved ^[8]. Experimental changes run in non-production accounts with no path to production data, under an expiry date and a budget cap ^[10]. On that path I would also use the article's resource-type restrictions to keep the sensitive classes off the list an agent may create ^[10]. In every cell, the reviewer's attention goes to intent, meaning whether the change does what was actually requested. The article says a policy engine cannot perform that check ^[12].