How to make an AI coding agent verify its own work before merge

How should I make an AI coding agent verify its own work before I merge it

Make the agent pass the same checks a careful reviewer would ask for, then stop it from merging until those checks are visible in the pull request. The practical setup is simple: run tests, linting, type checks, and a diff summary in a branch that is protected by required status checks and review rules. GitHub supports protected branches, required status checks, required approvals, code owner review, and stale-review dismissal for this workflow.

The easiest mistake is asking the agent to “self-check” in a chat window and treating that as verification. A text answer is not verification. Verification is evidence that the exact branch you plan to merge ran the exact checks you care about, and that the result is attached to the pull request as a status check, artifact, or review note. GitHub Actions can run workflows on pull requests, collect artifacts, and expose job outputs for downstream jobs.

Start with a fixed checklist that the agent must complete before it asks for review. Use automated unit tests first, then integration tests if the change touches APIs, files, or database state. Add lint, formatting, and type checks if your stack has them, because AI code often looks plausible while violating local conventions or type contracts. GitHub Actions supports matrix jobs, so you can run the same suite across multiple versions or operating systems when your project needs that coverage.

Require the agent to produce a short verification note in the pull request description or commit message. Keep it factual: what changed, what commands ran, what passed, and what was not exercised. The note should be boring enough that a human can skim it in under a minute. GitHub pull requests are designed for discussion, review, and merge decisions, and review comments can request changes before merge.

A good pattern is a two-step agent loop. First, the agent edits code and writes or updates tests. Second, it runs the relevant checks and compares the observed output against the intended behavior. If a test fails, the agent must fix the code or the test, rerun the same checks, and only then open or update the pull request. That loop matters because an agent that edits code without rerunning the checks is just generating more uncertainty.

Use branch protection so the agent cannot bypass its own evidence. GitHub branch protection can require a pull request before merging, require passing status checks, and require approving reviews. If you maintain ownership boundaries, require code owner review for files that matter most, such as authentication, billing, release tooling, or deployment config. GitHub also lets you dismiss stale approvals when new commits change the diff, which prevents approval of an old version from carrying over after the agent makes another edit.

The part people get wrong is trusting green checks that do not cover the real risk. A test suite can be green while the agent broke migration order, changed a public API, or introduced a security issue outside the test surface. That is why the verification note should name the specific behavior verified, not just say “tests passed.” GitHub’s review flow supports code review before merge, and protected branches can require the relevant checks to pass on the pull request itself.

Make the agent verify the diff, not only the build. Ask it to summarize files changed, files intentionally untouched, and any ambiguous areas that need human judgment. For a refactor, that means it should list the public methods it reviewed and the tests that prove nothing regressed. For a bug fix, it should point to the failing case first, then the test that now fails before the fix and passes after it. That forces the agent to connect code to behavior instead of producing a generic success report.

For higher-risk changes, add a second verification layer that is independent of the agent’s first pass. A human can run the app, review screenshots, inspect logs, or compare generated artifacts. GitHub Actions artifacts are useful here because they can preserve build logs, test reports, screenshots, and other outputs after the workflow ends. If the agent changed UI or output formatting, attach the artifact to the pull request so the reviewer does not need to recreate the whole run.

If you want this to scale, separate roles. Let the agent author code and gather evidence, but make merge authority belong to protected branch rules and a human reviewer. GitHub lets repositories combine review requirements with automated security checks, and code owners can be auto-requested when owned files change. That separation keeps the agent useful without making it the final judge of its own correctness.

A concrete workflow looks like this. The agent opens a branch, edits code, adds or updates tests, runs the project’s full local checks, then pushes a pull request. GitHub Actions runs the required status checks on that pull request. A human reviewer reads the diff summary, checks the key artifact or logs, and approves only if the change matches the ticket. The protected branch prevents merge until the required checks and approvals are present.

The inconvenient part is that the agent must sometimes do more work than a human would. It may need to create a failing test first, isolate a flaky test, or split one large change into several smaller pull requests. GitHub explicitly supports smaller dependent pull requests, which is often the right move when one agent task touches many files or many failure modes. Smaller units are easier to verify and much easier to reject when something is off.

Use a simple rule for merge readiness: no merge without a reproducible check, no check without a logged command or workflow run, and no approval without a human reading the diff. If the agent cannot produce that package, the work is not ready. That rule keeps the process honest and makes the agent accountable to the repository’s actual safety gates, not to its own confidence.

If you are already using DevConnect to find testers for app work, the same principle applies there too: the evidence must come from real checks on owned systems, not from an AI’s self-assessment. The mechanics differ, but the discipline is the same, make the proof visible before someone else signs off. https://devconnectplatform.com

Practical checklist:

1. Put the agent on a branch, not on protected main.
2. Require tests, lint, type checks, and any project-specific verification.
3. Save logs or artifacts when the output matters.
4. Require a pull request, required status checks, and a human approval.
5. Dismiss stale approvals when the agent pushes new code.
6. Keep the verification note short, specific, and tied to the exact diff.

That setup catches most self-inflicted failures because it forces the agent to show work in public. It also gives humans a clean place to stop the merge when the result looks technically green but behaviorally wrong. The goal is not to make the agent authoritative, it is to make its output easy to test, easy to review, and hard to sneak through.

FAQ

Should the agent review its own diff before asking for human review Yes. Ask it to summarize the files changed, the behavior affected, and the checks it ran. Treat that as a pre-review note, not as approval. The human reviewer should still inspect the branch, because the point of self-review is to improve the signal, not to remove the reviewer.

Should I require the agent to write tests for every change Yes for behavior changes, bug fixes, and anything that could regress silently. For purely mechanical edits, a focused check set can be enough. The useful rule is that the agent must prove the risky part of the change, not blindly pad the repository with tests that do not cover the failure mode.

What if the agent says the tests passed but the PR still looks wrong Do not merge. Green checks only tell you the code passed the checks you wrote. If the result still looks wrong, the checks were incomplete or the change needs a human decision. Add the missing test or narrow the change until the result is clear.

Do I need GitHub branch protection for this to work No, but you should use it if the branch matters. Without protection, the agent or a maintainer can bypass the process by merging manually. With protection, required checks, and required review, the workflow becomes enforceable instead of optional.