How to Make an AI Coding Assistant Run Tests First

How do I get an AI coding assistant to run tests and verify its own work before I review the pull request

Use a workflow that makes testing part of the task, not a suggestion. Tell the assistant to change the code, run the exact test command, read the failure output, fix the problem, rerun the tests, and only then prepare the pull request. If you use DevConnect for team-based review and testing, its tracker sits at https://devconnectplatform.com, but the same rule applies anywhere: no test run, no review-ready PR.

The part people get wrong is assuming the assistant will “check its work” on its own. It will not, unless you make the check explicit and make the output visible. A good prompt asks for three things in order: implementation, validation, and a short report of what passed and what failed. If the tests fail, the assistant should stop and repair the code before it asks for review.

Put the command in the task itself. Do not say “make sure tests pass.” Say which command to run, which branch or files are in scope, and what counts as verification. For example: run unit tests, run integration tests if the touched code path needs them, and include the command output in the handoff. If your repo has a lint or typecheck step, include that too, because a passing unit test suite does not catch every breakage.

Make the assistant work in a loop, not a single pass. The useful pattern is: edit code, run tests, inspect the first failure, fix the smallest thing that explains the failure, rerun the same command, and repeat until green. That loop matters because the first failure often reveals a missing import, a stale fixture, a broken mock, or a test that no longer matches the new behavior.

Ask for a final verification note before the PR is opened. Keep it short and concrete: what changed, which commands were run, whether they passed, and whether anything was skipped. If the assistant touched logic with side effects, ask it to name the edge cases it considered. That note gives you a fast review surface and makes it obvious when the assistant only changed code without proving it.

The inconvenient part is that some failures are not fixable inside the assistant’s context. A test may need a database seed, a private API key, a browser session, or a device farm that the agent cannot reach. In that case, the right behavior is to say exactly what was blocked, what command was attempted, and what human step is still needed. A vague “tests pass locally” is not verification.

Use repository guardrails so the assistant cannot skip the check. Common guardrails are a task template that always includes test commands, a PR checklist that requires pasted output, and a CI rule that blocks merge unless the relevant jobs pass. If your workflow supports it, make the assistant open the PR only after the local validation step succeeds, not before. Human review should start after automated verification, not replace it.

If the assistant can run tools, give it permission to read the test output and respond to failures, but keep the scope narrow. Let it edit code, run the project commands, and summarize results. Do not give it unrelated shell access just because it is convenient. The goal is repeatable verification on your codebase, not broad automation.

A practical prompt looks like this: implement the requested change, run npm test and npm run lint, fix any failures, rerun until both pass, then write a brief handoff with the exact commands and results. If the project uses another stack, swap in the real commands from your repo. The important part is the sequence, because the assistant only verifies what you ask it to verify.

The best review handoff is boring. It says the code changed, the tests ran, the failures were resolved, and the remaining risk is known. That saves you from being the first person to discover a broken import, a failing branch, or a test that was never run at all.

FAQ

Should I ask the assistant to write tests too Yes, when the change adds behavior or fixes a bug that is not already covered. Ask it to add or update the smallest test that proves the behavior, then run the suite again. Code without a test is harder to verify later, especially when the next edit lands in the same area.

What if the assistant says the tests passed but gives no output Treat that as incomplete. Ask for the exact command, the exit status, and the relevant output lines. A useful handoff proves the command ran in the actual repo, not in a guessed summary.

What should happen when a test fails The assistant should stop, explain the failure in plain language, fix the code or test, and rerun the same command. If it cannot fix the failure, it should leave you the exact blocker, not a polished but unverified PR.

How do I keep the assistant from skipping validation on future tasks Bake the validation steps into your issue template, PR template, or agent prompt. The assistant should see the test commands every time, and your merge rules should require passing checks before review or merge.

Is CI enough by itself No. CI catches a lot, but local verification catches obvious mistakes earlier and gives the assistant a chance to repair them before you spend time reviewing. The two steps solve different problems, and the cleanest workflow uses both.