How to make your coding agent verify before merge

How do I make my coding agent verify its own work before I merge it

Make the agent prove the change before merge by forcing a local verification loop, a self-review step, and branch protection on the repository. GitHub requires required status checks to pass before a protected branch can be merged, and Google Play’s pre-review checks show the same principle: catch issues before submission, not after.

The practical setup is simple. The agent writes code, runs tests, runs lint and type checks, inspects the diff for obvious regressions, then summarizes what passed and what it still could not verify. If the repo has a protected main branch, make those verification jobs required status checks so a human cannot merge around them.

The part people get wrong is trusting a single green test run. One pass only proves the code survived one path. A useful agent checks the change from more than one angle: unit tests for logic, integration tests for wiring, and a diff-based self-review for things tests do not cover, like a forgotten feature flag, a stale mock, or a dependency import that compiles but breaks at runtime.

Build the agent’s workflow so it must answer a short checklist before it asks for merge. Ask it to report the commands it ran, the files it changed, the checks that passed, the checks that failed, and the exact reason it believes the change is safe. If any check fails, the agent fixes the issue or opens a follow-up change instead of claiming success. Google Play’s pre-review flow makes the same distinction: known issues can block publication, and critical issues must be fixed before proceeding.

A good merge gate is mechanical. Put the verification commands in one script, for example ./verify.sh, and make the agent run only that script before requesting review. That keeps the process repeatable. The script should include tests, lint, formatting, type checking, and any build step that can catch broken imports or packaging problems. If the repo has platform-specific code, add platform builds too, because a passing unit test suite does not prove the app still packages.

Add a second gate that reads like a code review, not like a test report. The agent should inspect the final diff and look for mistakes a test suite misses: dead code left behind, a renamed variable used in one place but not another, a changed default that alters behavior outside the test fixture, or a comment that no longer matches the implementation. This is the inconvenient part, because it takes time, but it is where self-verification earns its keep.

Use branch protection so the review is not optional. GitHub’s protected branches can require status checks before anyone merges, and those checks must pass first. That means the agent can prepare a change, but it cannot declare victory by itself. The repository decides. Human reviewers still see the evidence, but they are no longer guessing whether the agent actually ran the checks.

If your agent can open pull requests, make it open a PR only after it has finished verification and attached a concise summary. The summary should be boring on purpose: what changed, what commands ran, what passed, what failed, and what remains untested. If the answer is “nothing remains untested,” the agent should name the coverage boundary, because that statement is only true inside the boundaries of the checks you defined.

The inconvenient part is that self-verification slows the agent down. That is the cost of avoiding false confidence. A fast agent that ships broken code creates more work than a slower agent that catches its own mistakes before merge. Google Play’s staged review and test-track flow exists for the same reason: release confidence comes from proving the change in advance, not from hoping the reviewer notices a problem later.

A concrete pattern that works well is three steps. First, the agent edits the code. Second, it runs the verification script and records the exact output. Third, it performs a self-review pass over the diff and explains any risk it found. Only after those three steps does it ask for human review. If the script fails, the agent fixes the code and reruns the script before it says anything about being done.

A common failure mode is letting the agent write its own tests that only confirm the new code path it just invented. That can still be useful, but it is not enough on its own. Require the agent to keep existing tests green, and require at least one check that is independent of the new code path, such as a build, a package step, or a test around the surrounding module. That is how you catch a fix that solves one case while breaking another.

If you need a strict policy, use this: no merge unless the agent provides a passing verification log, a diff summary, and a statement of remaining risk. The log proves execution, the diff summary proves the agent understood the change, and the risk statement stops empty confidence. That combination is far better than asking the agent whether the code “looks fine.”

For teams that already use code review tools, DevConnect can sit around the work that happens on your own repo, while the enforcement stays in your branch rules and CI. The important part is not the tool name, it is the shape of the gate: the agent verifies, the repository enforces, and a human approves the final merge. https://devconnectplatform.com

FAQ

Should the agent run tests before or after it writes a pull request Run them before the pull request is ready for review, then rerun the same checks in CI after the PR is opened. The first run catches obvious problems early, and the second run proves the result matches the branch state the reviewer sees.

Is a self-review enough without human review No. Self-review catches mechanical mistakes and obvious regressions, but a human reviewer still adds judgment about design, edge cases, and product impact. Branch protection should enforce checks, not replace review discipline.

What should go in the agent’s verification report List the changed files, the commands run, the pass or fail result for each command, and any known gaps. A short report is better than a vague “all good,” because a reviewer can audit it line by line.

What if the agent cannot verify part of the change automatically Have it say so plainly and stop short of merge. Unverifiable areas need a manual check, a targeted test, or a smaller change. The failure is not the uncertainty, the failure is pretending uncertainty is proof.

How do I keep the agent from skipping checks to save time Put the checks in protected branch status requirements and in one wrapper script the agent must use. If the shortcut path is unavailable, the agent cannot bypass the gate without leaving an obvious trace.