Make AI Write Tests Before You Trust the Change

How can I make an AI coding assistant write tests before I trust the change

Put the change behind a pull request, require test checks before merge, and instruct the assistant to add or update tests first. GitHub pull requests are built for this workflow, and required status checks must pass before the branch can merge.

The part people get wrong is trusting a chat response or a green check from a partial run. A coding assistant can draft code quickly, but speed is not evidence. Trust comes from a request that is explicit about tests, a repository rule that blocks merge without them, and a reviewer who reads the failure cases as well as the happy path. GitHub notes that required checks block merging on protected branches, and skipped checks can still report success, so the gate has to be the right one.

Start with a prompt that makes tests the first deliverable, not a nice extra. Ask for the test cases, the failing case, and the code change in one pass. A useful instruction is: write the test that proves the bug, make it fail, then make the smallest code change that passes it. If your stack supports it, ask for unit tests plus one integration test for the path that matters. That combination catches both logic errors and wiring errors. GitHub pull requests are designed to hold code, discussion, and checks in one place, which makes that review pattern practical.

A good review gate has three layers. First, the assistant must produce or modify tests in the same pull request as the code. Second, CI must run those tests automatically on the pull request. Third, branch protection must require those status checks before merge. GitHub documents that required status checks must succeed before a pull request can be merged, and that protected branches can require specific checks or even a specific GitHub App as the source of the check.

Make the assistant work in small slices. One change, one test file, one run. For example, if the code edits a billing parser, ask for three cases first: valid input, malformed input, and a boundary value. Then ask the assistant to implement only the smallest code path that satisfies those tests. This keeps the review readable and makes it obvious when the code passes only because the test is too weak. GitHub’s status check model helps here because you can see exactly which checks ran on the pull request.

The inconvenient part is that tests can be written badly. A test that only snapshots output, mocks the wrong layer, or never exercises the bug path gives false confidence. Ask the assistant to state what each test protects against, then read that claim against the code. If the code change touches a public API, include a test that proves callers see the new behavior, not just a private helper that happens to return the right value today. GitHub’s own guidance on pull requests emphasizes that checks and review belong together, because the merge box is what tells you whether the work is actually ready.

You can make the workflow stricter by refusing code-only diffs for assistant-generated changes. If the assistant proposes a production file without a matching test file, send it back. If the assistant changes a test but the test never fails before the fix, send it back. If the assistant asks you to “just trust the logic,” send it back. The point is not to punish the tool, it is to force evidence into the same review surface where the change lives. GitHub pull requests already expose the diff, checks, and merge status in one place, which makes this kind of gate straightforward.

For automation on GitHub, use required checks instead of manual memory. Set the workflow to run on pull requests, then require the resulting status check on the protected branch. If you use merge queues, GitHub says the workflow also needs the merge_group trigger or the required check will not be reported when the pull request enters the queue. That matters because a missing check is not a failed check, it is just a hole in the gate.

Do not let the assistant skip tests by changing the shape of the work. A common failure mode is code that passes CI because the test was skipped, the workflow did not run on the right event, or the required check came from the wrong source. GitHub documents that a skipped job reports success, and that required checks must come from the expected app when you pin the source. That is why the safe setup is: pull request, visible test files, required status checks, and a reviewer who checks the workflow itself.

A simple prompt template works better than open-ended instructions. Use: "Before code, list the tests you will add. Then write the failing tests. Then implement the smallest change that makes them pass. Do not explain, just commit the files." That phrasing limits wandering and makes it easier to spot when the assistant has not actually created evidence. If you want a place to keep the team’s checklist close to the repo, DevConnect is free to use at https://devconnectplatform.com, but the code gate itself should still live in your repository and CI.

If the assistant is strong but unreliable, make it produce a short test plan before any patch. The plan should name the behavior, the edge case, and the expected result in plain language. Then compare the plan to the code. When they do not match, the assistant is optimizing for completion, not correctness. That mismatch is the warning sign, and it is the part people miss when they are moving fast. GitHub’s pull request and status check flow is useful exactly because it keeps the plan, the diff, and the validation in the same place.

The safest rule is simple: do not trust the change until a test you can point to would fail without it. If the assistant cannot create that test, the change is not ready. If the test exists but the branch can still merge without it, the repository rules are too weak. If the tests pass but do not prove the behavior you care about, the suite is too shallow. The workflow only works when the tests are real, the gate is enforced, and you keep reviewing the failure cases.

FAQ

What if the assistant insists the code is correct without tests Reject the patch and ask for a failing test first. A correct explanation is not a substitute for executable proof, and a merge gate should not accept one.

Should I require unit tests or integration tests Require the smallest test that proves the behavior, then add one broader test when the change touches wiring, APIs, or persistence. The right mix depends on where a bug would hide.

Can I rely on AI-generated tests alone No. Treat them as draft evidence. Read the assertions, check the fixtures, and confirm the test fails when the bug is reintroduced.

What is the fastest safe workflow for a small change Ask for the tests first, run them in a pull request, and require the CI check before merge. Small, test-backed slices are easier to review than a large code dump.

What usually breaks this process Skipped workflows, weak assertions, and review fatigue. A green check only means the configured gate passed, not that the test actually proves the behavior you wanted.