Where to put human approvals in an AI coding workflow

Human approvals belong at the points where an AI agent's work becomes hard to undo or starts to affect other people: before a change merges into the main branch, before it is deployed to production, and before agents start risky kinds of work such as infrastructure or dependency changes. Everything else can run automatically behind gates. For an approval to mean anything, it has to come from someone other than the person who asked for the change, it has to be made with the evidence in view, and it has to apply to the exact version that ships.

This page goes deeper on the human-in-the-loop section of How do AI agents fit into the software lifecycle?.

In the loop, on the loop, out of the loop

Three levels of human involvement are worth distinguishing, because teams often say one and mean another.

Most AI coding work combines them: agents plan, write and test on their own, people approve at a few defined points, and the whole process is recorded for later review.

Which decisions need a person

A useful test is to ask what happens if the agent is wrong and nobody notices for a week. Where the answer is "nothing much" or "we revert it", automation with gates is enough. Where the answer involves customers, data, money, security or an incident, put a person in front of it.

Decisions that usually need an approval:

• Merging into the main branch. After this point, other people build on the change.
• Deploying to production. Especially when rollback is slow or data migrations are involved.
• Changing infrastructure, CI pipelines or access control. These have reach beyond the application.
• Adding or upgrading dependencies. Each new package is a new supplier.
• Starting expensive or long-running work, such as large refactors or scheduled jobs across many repositories.
• Anything that sends data outside the organisation.

Decisions that usually do not: which files an agent reads, how it structures its plan, which tests it writes, or whether to retry a failed step. Approving these adds friction without adding safety.

Separation of duties when an agent writes the code

Separation of duties is an old control: the person who makes a change should not be the only person who approves it. With AI agents, the question is who counts as the author.

The agent cannot be accountable for anything, so the author is the person who gave it the task. They chose the goal, the scope and often the approach, and they have the strongest bias towards believing the result is right. Their approval adds little independence.

In practice:

• The requester should not be the only approver when someone else is able to approve.
• Approvals should be counted per person, so one person voting twice does not count as two approvals.
• Sensitive paths can name specific approvers, for example a security reviewer for authentication code.
• Solo developers are a real case. A one-person team cannot separate duties, and the process should allow self-approval there rather than force a workaround, while recording that it happened.

What the approver needs to see

An approver asked to decide without context will either block everything or approve everything. Put the evidence next to the decision:

• the task the agent was given, so the approver can judge whether the change does what was asked;
• the diff itself, not a summary of it;
• test results for this exact version, including anything skipped or not run;
• review findings and how each was triaged;
• any policy decisions, such as a protected path that required this approval.

If a piece of evidence is missing, the approver should see that it is missing.

Avoiding approval fatigue

Approvals lose their value when there are too many of them. People who approve dozens of trivial changes a day stop reading, and their approvals become rubber stamps.

• Approve fewer, more meaningful things. Use policy to decide which changes need a person, and let gates handle the rest.
• Keep changes small. A focused change can be read; a sprawling one gets skimmed.
• Make rejection cheap. With agents, a rejected change can be redone with a better task. Approvers should feel free to say no.
• Require a reason for rejection. It improves the next attempt and creates a record of what the team will not accept.
• Let approvals expire. A request that sits for weeks is approved against a codebase that has moved on.

Binding approvals to versions

An approval is a statement about a specific change. If the change is edited after approval, by a person or by a follow-up agent run, the approval should reset. Otherwise a reviewed change can be swapped for an unreviewed one after the decision.

The same applies to evidence. Test results and review findings should belong to the version they were produced for, so that the approver's evidence and the shipped code match.

Recording the decision

Each approval should leave a record: who approved or rejected, when, which version, with what note, and which evidence was available. That record is what an auditor, an incident review or a future maintainer will look for when they ask how a change reached production.

How AI CodeOps does it

In AI CodeOps, every code change from a session needs an approved review before its pull request opens, whatever the workspace's trust posture. The person who started the session cannot approve its change while someone else in the workspace can; a one-person workspace can approve its own work. Owners, admins and security admins can approve by default, a custom role can be given the permission, and a request can name specific approvers. Approvals are counted per distinct person.

One rejection ends the request, and a rejection needs a reason. Code-change reviews expire after 7 days. Editing a change after it was approved resets its approval to pending.

Policy rules add earlier checkpoints. An ask rule on workflow.dispatch holds a session before it starts, for example for every dependency upgrade, and that request expires after 3 days. An ask rule on diff.apply with a path such as infra/** requires an approved review for changes to those files. Each decision is recorded in the audit log, and the approvals and every vote are part of the change's signed evidence pack.

See Approvals and policies for the full rules, the human-in-the-loop glossary entry, and Audit logs, roles and policies for the overview.