Why every AI change in AI CodeOps has to pass a gate

• Quality gates
• Governance

In AI CodeOps, no AI-written change merges because the AI said it was done: it has to pass a release gate that reads real test runs, review findings and a person's approval. The gate fails closed, so missing evidence holds a change instead of letting it through.

An AI model can write a working-looking change in a minute. That is the useful part. The dangerous part is that it also writes a broken-looking-fine change in a minute, and the two read the same. The code compiles, the summary is confident, the variable names are good. Nothing in the output tells you which kind you got.

So in AI CodeOps, no change an AI writes reaches your main branch because the AI said it was done. It has to pass a gate. This post explains what the gate checks, why we built it the way we did, and the mistakes we found in it along the way.

What happens after a session writes code

A session is a team of agents working on one task in one project. When it has produced a diff, three things happen before anyone can open a pull request.

1. Your tests run on the change. The verify step runs the project's own test suite against the code the session just wrote, in an isolated per-project sandbox, and records the result as a real test run. If the project has no test command, or the dependencies won't install, we record nothing rather than a red result. "We could not verify" should never look like "the change fails".
2. An AI reviewer reads the diff. Not the plan, not the transcript: the diff. Its findings are stored with a severity, and they show up on the session, on the Security dashboard and in the gate.
3. An approval opens. The change waits under Review & Gate → Approvals until a person with approval rights decides. Policies can add more approvals, for example for changes to protected paths.

Then, when the change is about to merge, the release gate looks at all of it together. Your CI can ask the same question over the API: is this pull request, or this commit, ready? The answer is a yes or no with the reasons, and a CI job that asks it can be made a required status check on your Git host.

What the release gate checks

By default, a change is refused if any of these is true:

• An open finding of high severity or above is still on it. A finding stops blocking once it is triaged as fixed, won't fix, false positive or duplicate.
• A test run on it has failures.
• A workflow it depends on failed, or no run for it has finished.
• Its AI review did not complete.

A CI check can ask for more: a minimum coverage percentage, a list of licenses that must not appear in the project's SBOM, workflows that must have passed, and a promotion rule so a change must have deployed to staging before it can go to production. The quality gates guide has the details.

Why AI-written code needs this more than human code

Human code review assumes the author understood what they wrote and will answer for it. With AI-written code, that assumption breaks in two ways.

First, volume. A team that used to review five pull requests a day can generate fifty. Reviewers get tired, and tired reviewers approve. A gate does not get tired.

Second, confidence is not evidence. A model will tell you it added tests and that they pass. Sometimes it did. The gate does not read what the model said. It reads the test run record and the findings table.

That is also why the gate is built to fail closed, the principle OWASP calls failing securely. Every rule is phrased as "refuse unless we have positive evidence", not "allow unless we see a problem". Fail-open vs fail-closed gates goes through the trade-off.

The holes we found

We did not get this right the first time. A few of the gaps we closed this autumn, because they show what "fail closed" means in practice:

• Unfinished counted as passed. A CI check seconds after a push could get "release ready" while the only run was still going. A run that has not finished is not a result, so now at least one run must have completed.
• An unreadable review counted as clean. If the AI reviewer replied with prose, an empty message or a reply cut off at the token limit, we parsed it as "no findings". Since 14 October, anything but a readable list is a failed review, and the gate holds the change.
• Old tests judged new code. If someone edited the AI's code after its tests ran, the gate kept using the old results. Now tests only count for the exact version they ran on, and an edited change reads as untested.
• Edits kept the old approval. An approval approves one specific diff. Editing the code, restoring a checkpoint or filtering hunks now re-opens the approval in the same transaction as the change.
• A failure blocked for two weeks. The opposite problem: the gate blocked on any failed run in its window, so a fixed and re-run change stayed blocked. Now each workflow is judged by its latest finished run.

Each of these was a case where the gate said something the evidence did not support. The changelog has the full list.

Two-person review

The last piece is people. The approval on an AI change used to accept a vote from anyone with approval rights, including the person who launched the session. One admin could start a session, approve it and open the pull request alone.

Since 11 October, once a workspace has a second person who can approve, the launcher's own approval does not count. Someone else has to look. A one-person team keeps self-approval, because otherwise nothing could ever ship, and rejecting is always allowed. Any single rejection stops the change. The approvals and policies guide covers who can approve what.

What it costs you

A gate is friction, and we don't pretend otherwise. Changes wait for a reviewer. A flaky test blocks a merge until you re-run it. A model that returns a messy review costs you another review.

We think that trade is right for code nobody typed. The point of AI CodeOps is not to make AI changes faster to merge. It is to make them safe to merge, and to leave a record of why each one was allowed. If you want to see how the review side works, the multi-agent code review page goes deeper.

Key takeaways

• No AI change merges on the AI's word: the release gate reads test runs, review findings and approvals.
• By default a change is refused for an open high-severity finding, failed tests, an unfinished or failed run, or an incomplete review.
• The gate fails closed: no evidence means no merge.
• Tests and approvals count only for the exact version of the change they saw.
• With a second approver in the workspace, the person who launched a session can't approve it alone.