On this page
Key takeaways
- Gate by consequence, not by tool: reading code is cheap, changing production is not.
- Every gate needs a named owner and a time limit, or it becomes a queue nobody watches.
- Log the plan and the diff together so reviewers approve the intent as well as the code.
Coding agents have moved from suggesting lines to doing work: opening pull requests, editing configuration, running scripts against real systems. That is useful, and it changes the question from 'is the code good?' to 'who decided this change should happen?'
Put gates where consequences are
Most teams start by gating everything, which trains reviewers to click approve without reading. A better starting point is to list what an agent can touch and sort it by how hard it is to undo.
- Read-only work (searching code, reading logs, drafting changes): no gate.
- Reversible changes in non-production environments: a lightweight review.
- Production data, infrastructure, permissions, billing or customer-facing config: an explicit approval from a named owner.
Show reviewers the plan with the diff
A diff tells you what changed. It does not tell you why the agent thought it should. Pair every approval request with the goal it was given, the steps it plans to take, what it will touch, and how the change can be rolled back. Reviewers approve intent much faster than they reverse-engineer it.
Named owners and timeouts
An approval routed to 'the engineering team' is routed to nobody. Assign an owner per system, set a response window, and decide what happens when it lapses: usually the agent stops and reports, rather than proceeding.
Keep a complete audit trail
Record the trigger, the plan, the approver, the change and the result in one place. When something goes wrong three weeks later, that record is the difference between a five-minute answer and a two-day investigation.
Frequently asked questions
No. Gate by consequence. Read-only and easily reversible work can run freely; production changes should not.