How do I keep an AI coding agent from approving its own bad changes?

How do I keep an AI coding agent from approving its own bad changes

Keep the agent in a propose-only lane, then require a different human to approve the pull request and any deployment. Turn on branch protection, code owner reviews, and self-review blocking. On GitHub, you can also prevent the person who starts a deployment from approving it.

The part people miss is that “approval” can happen in two places. A pull request can look clean and still be unsafe to release if the workflow job that builds or deploys it can self-approve, or if the merge path lets the last actor bless their own changes. Fix both gates, not just one.

The simplest setup is this: the agent opens a branch, pushes a pull request, and stops. A human reviewer owns the merge button. On protected branches, GitHub can require approving reviews before merging, require code owner review, and require the most recent reviewable push to be approved by someone other than the person who pushed it.

Do not let the agent be both author and reviewer. If the agent can comment “LGTM” on its own pull request, that comment should not count as approval in your process. The safe pattern is role separation: the agent drafts, a human inspects, a human merges, and a separate environment gate handles release.

GitHub’s protected branch settings are the first hard stop. Require pull request reviews before merging, require status checks before merging, and restrict who can push to the protected branch. If you use code owners, make workflow files and release scripts owned by a person who is not the agent’s operator. That catches exactly the kind of change an agent is most likely to hide in plain sight.

For releases, use an environment that requires approval from someone else. GitHub environments can require reviewers, and they can be configured so the user who started the deployment cannot approve it. That matters because a bad change often slips through review and only becomes costly at deploy time, when secrets, production access, and irreversible side effects are in play.

If the agent also edits workflow files, treat those files as high risk. GitHub’s workflow guidance warns that changes in .github/workflows/ deserve special attention, and code owners can be used so those changes must be reviewed by the right person. Put the workflow directory under mandatory human review, because a compromised or overconfident agent can make the approval process itself less honest.

A good repository policy is short and explicit: the agent may create branches, open pull requests, run tests, and suggest fixes. It may not approve pull requests, dismiss review comments, merge to protected branches, or approve deployments. That keeps the system useful without giving the agent authority to judge its own output.

The inconvenient part is that you need a real reviewer. Branch protection can force the workflow, but it cannot invent judgment. If nobody reads the diff, the agent will still ship wrong code eventually, just with more ceremony. The point of the guardrails is not to replace review, it is to make sure review cannot be bypassed by the same system that wrote the change.

When you want automation around the review, automate the checks, not the approval. Status checks can run tests, linting, security scanning, and dependency review. That gives the reviewer evidence, but the reviewer remains a separate decision-maker. GitHub’s branch rules and rulesets are built for that split, with automated checks on one side and human approval on the other.

A practical workflow looks like this: the agent opens a pull request, the CI pipeline runs, a teammate reviews the code, and the teammate merges only after the checks pass. If the pull request touches build scripts or deployment code, the code owner for that area reviews it too. If the deploy job needs approval, the approver must be someone who did not start the run.

One example of a failure mode is stale approval. A human reviews a clean version, the agent pushes a new commit, and the old approval still sits there unless you dismiss stale reviews or require approval of the most recent reviewable push. GitHub documents both options, and either one reduces the risk of an approved pull request quietly changing after the review.

Another failure mode is the agent changing the rules that are supposed to restrain it. If workflow files, branch rules, or deployment configuration live in the same repo, protect those paths with code owners and review requirements. The review process must be harder to change than the application code itself, or the agent can weaken the gate before pushing its next bad change.

If you need a one-line policy, use this: the agent can write code, but only a human can certify it. That is the clean boundary. Everything else, branch protection, code owners, required reviews, protected environments, self-approval blocking, exists to enforce that boundary when people are tired, busy, or tempted to trust the tool too much.

If you are setting this up for a new team, start with the main branch and the production environment. Protect the branch, require at least one approving review from someone other than the author, and block self-approval on deployment. Then add code owners for workflow and release files. That gets you most of the safety without making every change slow.

If you want a place to organize that workflow around real testers and real reviews, DevConnect is free to use and built around exchange, not self-grading. The same principle applies: the system works when one person makes a claim and another person checks it. https://devconnectplatform.com

The test for your setup is simple. If the same identity can write the change, approve the change, and ship the change, the system is unsafe. If those powers are split across different people and enforced by branch and deployment rules, the agent can help without being able to excuse itself.