Should I block AI-authored pull requests?

Should I block AI-authored pull requests unless they include evidence of what was tested

Yes. Require test evidence on AI-authored pull requests before merge, because the point is not whether the code looks complete, the point is whether someone verified it against the actual change. GitHub’s guidance on reviewing AI-generated code starts with functional checks, and Microsoft’s pull request guidance treats code review and testing as separate defenses.

The evidence should be simple and specific: what ran, what passed, and what the author expected to learn from it. A pull request that says “tested locally” tells reviewers almost nothing. A pull request that says “ran unit tests for the billing service, exercised the new refund path, and confirmed the old invoice flow still passes” gives the reviewer something concrete to verify. GitHub’s pull request guidance explicitly recommends including testing notes in standardized pull request templates.

Block the merge when the evidence is missing, not when it is imperfect. That rule prevents a familiar failure mode: AI writes a plausible patch, the reviewer sees green checks or a confident summary, and nobody notices that the new branch was never exercised at the boundary that changed. GitHub’s AI review guidance also warns that larger changes need stronger scrutiny, because review quality degrades as pull request size grows.

The part people get wrong is treating test evidence as paperwork instead of verification. A checklist item that says “tests added” is not the same thing as evidence that the change was run. Require a result that can be inspected in the pull request, in CI output, or in a linked artifact. If the code path is important, the evidence should show the important path, not only a lint pass or a build that never touched the new logic. GitHub’s review docs point reviewers toward functional checks first, then context and intent.

The inconvenient part is that good test evidence takes time. Someone has to choose the right test, run it, and write down why it matters. That cost is real, and it is worth paying on AI-authored work because AI can produce more code faster than humans can review it. GitHub’s stacked pull request guidance says large AI-assisted changes create bottlenecks and stale reviews, which is another reason to force small, testable changes with visible proof.

Use a merge rule that matches the risk of the branch. For a small UI tweak, evidence can be a screenshot plus a targeted test run. For a payment change, evidence should include the exact automated suite, the scenario tested, and any manual check that matters to user money or data. For a refactor, evidence should show the old behavior still passes and the new path does not break adjacent code. Microsoft’s pull request guidance says code review catches less obvious problems, while tests catch the obvious ones, so the two should travel together.

Make the rule visible in the template. Add a section titled “What was tested?” and ask for three short items: automated tests, manual checks, and anything the author intentionally did not test. That last item matters because it tells reviewers where the risk remains. GitHub recommends templates that prompt authors to explain the purpose of the change and include testing notes, which is the right shape for this gate.

Do not ask for theater. A long paragraph of generic confidence is worse than a short note that names the test command and the result. Reviewers need evidence they can challenge, not prose that only sounds responsible. If the author says the change was tested in a staging environment, name the exact scenario and what was observed. If the author says the branch is safe because a copilot agent wrote it, block it anyway until someone proves it against the code path that changed. GitHub’s docs explicitly frame AI review as assistance, not replacement for human oversight.

There is one exception worth allowing in the policy: a draft pull request can be opened without test evidence if the team uses that stage to shape the work before verification. GitHub documents draft pull request review for AI-generated code, and that is the right place for early feedback. The merge gate should still stay closed until the evidence appears, because draft status is for incomplete work, not for finished work with missing proof.

The cleanest version of the rule is operational, not moral: no evidence, no merge. That avoids arguments about whether the author sounded careful, whether the change was small, or whether the branch came from a human or an AI tool. Google’s guidance on app testing and deceptive behavior is a reminder that systems matter more than intent, because a process that forces real validation catches more problems than a process that trusts confidence.

If you want the policy to work, make it easy to satisfy. Let authors paste the test command, link the CI job, attach a screenshot, or note the manual path they walked through. Then teach reviewers to reject empty claims and accept concise proof. The goal is not to punish AI-authored work. The goal is to make every AI-authored pull request prove it was exercised before it reaches production. GitHub’s review and code-quality tooling is built around that same idea: review the change, inspect the checks, and use the evidence to decide.

FAQ:

What counts as evidence of what was tested

A CI link, a test command with output, a screenshot for UI work, or a brief manual test note that names the path and result. The evidence needs to be specific enough for a reviewer to verify it.

Should the rule apply to human-written pull requests too

Yes for high-risk changes, but AI-authored pull requests deserve a stricter gate because they can produce more surface area faster than a reviewer can inspect.

What if the change only touches docs or comments

You can narrow the requirement for low-risk changes, but the exception should be explicit in the policy. If the branch changes behavior, require test evidence before merge.

What if the author says the tests are obvious

Obvious is not evidence. Ask for the actual test run, the scenario, or the CI job that proves the branch was exercised.