Make a coding agent run tests and return ship-ready changes

How do I make my coding agent run tests and hand me ship-ready changes

Make the agent work inside a branch, make tests part of the branch’s required checks, and only accept output as ship-ready when the pull request is green and reviewed. GitHub’s pull request flow, draft state, and required status checks are the cleanest way to force that discipline.

Start by telling the agent to change one branch, not the main branch. The agent should commit its work, open a draft pull request, and keep that pull request open until the change passes. GitHub supports draft pull requests for work in progress, and draft pull requests cannot be merged. That is the right default for agent output.

The part people get wrong is leaving test execution as a vague instruction like “run tests if you can.” That produces code that looks done but has no proof. A better instruction is concrete: run the project’s test command after each meaningful change, stop immediately on the first failure, and report the failing command, the first error, and the file that caused it. GitHub Actions workflows can run on pull requests, and status checks can surface whether those tests passed.

Use CI as the source of truth, not the agent’s own summary. An agent can say the tests passed, but a required status check is what blocks merge when the checks fail. GitHub’s branch protection settings let you require status checks before merging, and required checks must pass before collaborators can merge into the protected branch.

If you want the agent to hand you a change that is actually ready, make it prepare the pull request as if another engineer will review it. That means a short description, the commands it ran, what changed, and any known tradeoffs. GitHub pull requests are designed to show what still needs to happen, such as required reviews or checks, before the change can be merged.

A good workflow is simple. The agent edits code on a feature branch, runs the relevant test command, opens a draft pull request, and waits. If the tests fail, the agent fixes the failure on the same branch and reruns the same tests. If the tests pass, it marks the pull request ready for review and asks for human review. GitHub lets you convert a draft pull request to ready for review when you want feedback.

Keep the test scope tight enough that the agent can finish. Large suites are fine in CI, but the agent needs a fast local loop. Most teams use a small command for the quick pass, such as unit tests or lint plus unit tests, then rely on CI for the full matrix. GitHub Actions workflows can be triggered by pull request events, so the same branch can get a lightweight local check and a heavier remote check.

The inconvenient part is that the agent will not know when to stop unless you tell it. It needs a hard rule: no pull request is complete until the test command exits cleanly and the branch protection checks are green. Required status checks can be configured as strict or loose, and strict checks require the branch to be up to date with the base branch before merging. That matters when your code changes quickly.

If the agent uses GitHub Actions, have it inspect the check results, not just the logs. Status checks carry the pass or fail signal, and GitHub distinguishes checks from commit statuses. GitHub Actions produces checks, and those checks are what reviewers and protected branches read when deciding whether a change is mergeable.

A practical setup looks like this: the agent makes a branch, edits the code, runs the smallest relevant test command locally, then opens a draft pull request. CI runs on the pull request. When CI passes, the agent updates the pull request body with the commands it ran and the exact result, then marks it ready for review. If you use a tool like DevConnect to coordinate work across builders, keep that coordination on your own owned surfaces, then hand the agent the branch and the test gate. https://devconnectplatform.com.

A ship-ready change also needs one more guardrail: the agent should not invent completion. If a test command was skipped, the pull request should say so plainly. If a test failed once and was fixed, the pull request should show the failure and the fix. GitHub’s checks history and pull request review flow make that kind of traceable handoff visible to humans.

The fastest way to get reliable output is to make the agent follow the same checklist every time. Edit on a branch. Run the relevant tests. Fix failures. Open or update a draft pull request. Wait for required checks. Mark the pull request ready only after the checks pass. That sequence turns an AI coding assistant into a change-producing system instead of a code-dumping system.

If you want the strictest version, require status checks and reviews on the target branch, then only merge from a pull request that passed CI. GitHub’s protected branches support both required reviews and required status checks, which is the mechanism that keeps the agent from shipping something untested or half-finished.

In practice, the answer is not “make the agent smarter.” It is “make the workflow harder to fake.” Put the tests where merge eligibility depends on them, make the agent report the exact command it ran, and keep the branch draft until the evidence is there. That is how you get changes that are ready to ship instead of changes that only look finished.