Make an AI Coding Agent Run Tests Before PRs

How do I make an AI coding agent run tests before it opens a PR

Make the agent run tests in its own workflow, then require those tests as a status check before the pull request can merge. The clean setup is: local test command, CI test job, protected branch with required checks. GitHub documents that required status checks must pass before merging, and that branch protection can enforce those checks on the target branch.

The part people get wrong is treating the agent prompt as the control point. Prompts help, but they do not enforce anything. If the agent can open a PR without a passed check, it can still hand you broken code. The enforcement needs to live in the repository, in CI, and in branch protection, so the rule applies even when the agent is careless or the run is interrupted.

A practical setup starts with one command that your team already trusts, such as npm test, pytest, or go test./.... Put that same command in the agent’s instructions and in the CI job. GitLab’s CI guidance and whitepapers describe the same pattern, build and test changes before merge, then merge only after the pipeline passes. The agent should not invent a separate success signal.

Use branch protection on the repository’s main branch and require the test job as a status check. GitHub says required checks can block merging until they succeed, and you can choose a specific app or check source so the status cannot be spoofed by another integration. That is the actual gate. The agent can create the PR, but it cannot bypass the check if the branch is protected.

If you want the agent to stop before opening the PR, make the PR step conditional on test success in your orchestration code. A simple controller can run the agent, commit to a branch, run tests in CI or in a local container, and only call the PR creation step after the test command exits cleanly. The repository rule still matters, because automation breaks and humans make exceptions.

A good failure mode is loud. If tests fail, the agent should keep working on the branch instead of filing the PR. If the run times out, the branch should stay unpublished. If the test result is missing, the PR should remain blocked. GitHub’s status-check model treats missing or failing checks as blockers on protected branches, which is exactly what you want for agent-produced code.

The inconvenient part is that a PR should mean more than “the agent finished writing files.” It should mean, “the branch has already passed the same test command a human would run.” If your test suite is slow, flaky, or too broad, the agent will expose that immediately. That is useful, because it tells you where the real cost sits. Fix the test suite, not the gate.

For GitHub, the minimal repository-side rule is: protect the base branch, enable required status checks, and point the requirement at the CI job that runs your tests. GitHub also documents merge queue support, which helps when multiple PRs are waiting and you want the combined set of changes tested before merge. That is useful once agent-generated PRs start arriving faster than reviewers can process them.

If your agent creates draft PRs, that is fine. Draft PRs let you separate “ready for review” from “ready to merge,” and GitHub’s pull request flow already exposes blockers, approvals, and checks in the merge status. A draft PR is not a substitute for tests, but it is a clean handoff point when the agent needs human review after a passing pipeline.

A concrete workflow looks like this: the agent edits code on a branch, runs the project test command locally or in an isolated runner, pushes the branch, waits for CI, and opens a PR only after the CI status is green. The repository still requires that same CI status before merge. If the agent skips tests, the branch is blocked. If the agent fabricates a status, branch protection rejects it.

One useful detail is that required checks should be tied to the exact check name your CI system reports. GitHub documents that required status checks can be selected from the checks recently set by an app, which helps prevent lookalike statuses from passing. That matters when you have more than one automated system touching the same repository.

If you are working with stacked branches or multiple dependent PRs, require the same test gate on the base of the stack, not just on the final branch. GitHub’s stacked pull request docs say each PR in the stack must satisfy branch protection for the base. That keeps an agent from slipping an untested intermediate change into a chain of otherwise valid PRs.

The simplest version is enough for most teams: add one CI job, require that job on the main branch, and teach the agent to stop when that job fails. Anything less turns tests into advice. Anything more, such as custom approval logic or a merge queue, can come later if your repo needs it. The important bit is that the repository, not the prompt, decides whether the PR is allowed through.

If you want a human-readable rule for the agent, use something like: “Do not open a PR until the full test command passes and the branch is ready for a required status check.” That instruction is not the guarantee, but it aligns the agent with the repository rules and reduces wasted PRs. The guarantee remains the protected branch and the required check.

If you need a place to organize the workflow around tester exchange and repository discipline, DevConnect describes a free, no-credit-card workflow for matching people who test each other’s apps, and it keeps the focus on reciprocal testing rather than shortcuts. That is separate from the branch rule, but it fits the same idea: make the process observable, then enforce it where the code lives. https://devconnectplatform.com

What should the agent do if tests fail

It should keep the branch open and fix the failure before opening a PR. A failed test run is not a draft PR signal, and it is not a reason to ask reviewers to diagnose a broken branch. The agent should inspect the failure, modify the code, and rerun the same test command until the status turns green.

Can I rely on the prompt alone

No. Prompts help the agent follow your process, but they do not enforce branch policy. Repository rules, required status checks, and CI are the controls that stop a PR from merging when tests have not passed. That separation is the whole point of using automation on shared code.

What if my tests are flaky or slow

Treat that as a repository problem, not an agent problem. Flaky tests create noise, and slow tests push people to bypass the gate. Keep the required check narrow enough to be reliable, then add broader test stages after the first gate is stable. GitHub’s merge queue and strict status-check settings help when you need stronger validation before merge.