- Stripped down, an approval is three things: a decision that needs judgment, a named person who carries it, and a record that they made it. Everything else is packaging.
- When agents write most of the diff, human judgment clusters at intent, the merge and the release; the middle of the loop is governed by hooks, managed settings and evals, as Anthropic's AI-native SDLC playbook describes.
- The approval becomes an artifact, the reviewer's job changes, review capacity becomes the ceiling, and exceptions are the part nobody has redesigned.
The approval chain you inherited was built for a cost structure that no longer exists. What an approval is for, where judgment stays when build takes hours, and the questions to put to any vendor or plan. The argument behind our 8 December session.
Ask an engineering leader where governance lives and you get a list of meetings: the change board on Thursdays, the security review before a release, the architecture forum once a month. Ask where approval lives and you get a list of people. Neither answer was wrong when writing the code was the slow part. Both are now answers to a question that has changed.
Anthropic’s AI-native SDLC playbook states the new condition in one line: “Build is no longer the constraint, the human-speed steps around it are.” That sentence is usually read as a throughput problem. Reviews are slow, so speed them up. Gates are in the way, so remove some. Add reviewers. Buy a review tool.
This post takes the opposite route. It strips the approval chain down to what it is for, rebuilds it from that, and shows why the chain is not the bottleneck to be tuned. It is the thing that gets redesigned. The redesign is also the subject of our live session on 8 December, What does AI-native SDLC look like in 2027?, and this is the argument behind one of its ten questions.
Why the standard explanation is unsatisfying
The standard explanation treats approval as a queue. Work arrives, waits for a person, leaves. If the queue is long, add servers or shrink the work. That model is fine for a help desk. It is wrong for governance, because it never asks what the person in the queue is for.
The evidence that something else is going on is already in the telemetry. One May 2026 analysis of AI-assisted teams, published on arXiv, reports 98 percent more pull requests with 91 percent longer review times, and delivery metrics that did not move. Reviewers were not idle. They were doing more of the same job on more material, and the job no longer fit the material. You do not fix that with a faster queue. You fix it by asking what the job was.
What an approval is, stripped down
Take everything away from an approval, the meeting, the ticket status, the email with “LGTM” in it, and three things are left.
- A decision that needs judgment. Not every step does. Some steps need a check, and a check can be a rule.
- A named person who can carry the consequences of that judgment.
- A record that the person made it, at the point where it mattered.
Everything else is packaging. The Thursday meeting is packaging. The sign-off field in the ticket is packaging. Packaging is not bad; it is how a given era delivered those three things at the speed it could afford. The mistake is to confuse the packaging with the control.
The playbook’s own framing is the same in different words: “Humans remain accountable for every decision that requires judgment.” The operative phrase is the last four words. Accountability stays with people. What moves is where judgment is required.
How the old chain was built
The traditional lifecycle placed its approvals where the money was. A requirements sign-off sat in front of weeks or months of engineering because getting it wrong was expensive. A release approval sat in front of production because getting that wrong was visible. In between, line-by-line review was feasible, because a human wrote each line at human speed and another human could read it at roughly the same speed.
That chain had an unstated assumption: the thing being approved was produced slowly enough that a person could inspect it in full. The playbook names what happens when the assumption breaks: reviewing each line by hand “cannot keep up once agents write most of the diff,” and governance cost rises because “exceptions still route through meetings and committees that meet weekly or monthly.”
So the chain did not become slow. It became mismatched. The judgments are in the same places. The material those judgments inspect has changed shape and volume. Three names, one shift covered the six stages this reshapes; here the subject is only the approvals that sit between them.
Rebuilding the chain from the three properties
Start again from the three properties and ask, stage by stage, where judgment is needed when an agent writes most of the code. The playbook is specific about where human approval remains, and the map is worth reading as a whole rather than play by play:
- The product owner approves the intent and the specification.
- An engineer approves the plan, with a tech lead for higher-risk changes.
- A code owner approves the pull request, enforced through branch protection.
- A release manager authorizes the production deploy, enforced by a hook.
- A service owner or on-call triages what production reports back.
Look at the shape. Human judgment clusters at the two ends, intent and release, and at the merge. The middle of the loop, where the code is produced, is governed by enforcement rather than by people in a meeting: hooks that allow, ask or block on every matching action; managed settings that individual engineers cannot switch off; evals that gate a merge on a pass rate. The playbook’s line on the difference is exact: “The skill makes violations rare and the hook makes them close to impossible.”
Two further rules fall out of the rebuild, and both are quoted here because they are checkable.
Separation of duties survives, by construction. “Separation of duties is preserved, because the agent that wrote the code has no way to approve it.” The approver and the author are different identities, and the record shows which did what.
The production boundary is absolute. “The agent may act up to the production gate and cannot pass it.” Branch protection means nothing the agent writes has a direct path to main; the deploy hook blocks a release until a named release manager authorizes it. Approval at the end of the chain is not weakened. It is the one approval that is enforced rather than remembered.
Notice also what the playbook keeps out of the build stage: an approval prompt there “puts a person back on the critical path of all the sessions running in parallel.” A gate that interrupts every session is not stronger governance. It is the old chain, reinstalled at a point where it now does damage.
The implications people miss
The approval is now an artifact. In the old chain the record of an approval was a meeting minute or a ticket field, assembled after the fact. In the rebuilt chain each stage commits what the next stage reads: “Together, the intent, the spec, the plan, the diff and the review findings are the audit trail.” An approval you cannot find in the chain of commits did not, for governance purposes, happen.
The reviewer’s job changes. Automated review produces ranked findings, but “findings do not approve or block a PR on their own.” The code owner still signs. What the code owner reads is no longer every line; it is intent, risk and evidence. That is a different skill from the one most senior engineers were promoted for, and it is the reason the velocity trap closes on review first.
Review capacity becomes the ceiling. Once build is cheap, every agent seat you add produces more material for the same approvers. The constraint does not go away; it concentrates. Teams that scale sessions before they measure reviewer throughput make the approval chain the bottleneck faster, not slower.
Exceptions are the unredesigned part. Hooks handle the rule. The exception, the change that needs a waiver or a decision the policy did not anticipate, still goes to the weekly meeting unless someone designs a route for it. Most organizations have redesigned nothing here, and it is where governance gaps break AI programs before they ship.
Better questions to ask
If the approval chain is the thing being redesigned, the questions to put to any plan, vendor or outsourcer change too. Not “how fast is your review” but:
- Where do the hooks live, who owns them, and what happens when an engineer turns one off?
- Show me the chain of committed artifacts for one real change, with the names on each approval.
- Who signs the production release, and what enforces that signature?
- When a change needs an exception, where does it go, and how long does it wait?
Those are the questions a buyer will be able to answer from git by 2027, which is the argument made in the post on who operates the loop. The playbook specifies the controls and leaves you to build, staff and maintain them. That is one route. The other is to have the chain run for you on the estate you already have, which is what AI-MSL does: a named AI-MSL Engineer signs each gate, an AI Lifecycle Manager scopes the work with you, and every action carries a timestamp, an actor and the reasoning, so the record exists before anyone asks for it.
Either way, the approval chain you inherited was designed for a cost structure that no longer exists. Redesigning it is not optional. The only choice is whether you do it deliberately or let the queue do it for you.
On Tuesday 8 December at 1 PM ET (10 AM PT, 6 PM UK) Nick Chase and Carter Holmes spend sixty minutes on this, including a ten-minute walkthrough of the artifact chain for one real change and live Q&A. Every registrant gets the recording and the ten-question checklist. Register for 8 December.
