Should AI Write Its Own Tests?

Should AI write its own tests? Partly. Let it write the boring ones. Never let it write the ones that decide whether its work is correct. When the same agent writes both the code and the test that judges the code, you get a closed loop with no independent check, and it will happily certify its own mistakes. The tests that matter most are exactly the ones the author should not write.

This is not an anti-AI position. Agents are genuinely useful at generating test scaffolding, filling in obvious cases, and covering the tedious permutations a human would skip out of boredom. The problem is narrow and specific: a test written by the same process that wrote the code inherits that process's blind spots. If the agent misunderstood the requirement, it misunderstands it in both the code and the test, and they agree with each other while both being wrong.

The circularity problem

Here is the trap in plain terms. An agent decides what the function should do, writes code that does that, then writes a test asserting the function does that. All three steps share one interpretation. If the interpretation is wrong, every step is wrong and every step passes. Green suite, broken behavior, total confidence.

You see this constantly with edge cases. The agent assumes empty input should return an empty list, codes it, and tests that it returns an empty list. But the requirement was to raise an error on empty input. The test does not catch the bug because the test encodes the same mistake. No amount of coverage saves you, because coverage measures lines touched, not requirements met. This is why I treat coverage numbers with suspicion in my broader test strategy for AI-generated code.

Split tests by who they protect

The clean way to think about it: some tests protect against implementation slips, and some tests protect against misunderstanding the requirement. Let the agent write the first kind. Write the second kind yourself, or generate them from a source the agent did not author.

Implementation-slip tests are things like "does this handle a list of one, does the sort stay stable, does the cache invalidate." These follow from the code and the agent is fine at them. Requirement tests come from the acceptance criteria and the spec, and they must come from outside the agent's interpretation. When I write acceptance criteria before the prompt, those criteria become the independent source that the verifying tests derive from, instead of the agent's own reading of the task.

Write the verifying tests first

The strongest version of this is to write the requirement tests before the agent writes any code. Now the test is not something the agent produced to justify itself, it is a target the agent has to satisfy. The independence is structural: the test existed before the code, so it cannot have inherited the code's blind spots. This is the core of TDD with AI coding agents, and it is the single practice that makes agent-written code trustworthy.

Order matters more than authorship here. A test written by a human after reading the agent's code can still absorb the code's framing. A test written before, from the requirement, cannot. So even for tests you write yourself, write them first. Prompting the agent faster is not the win; planning first beats prompting faster, and the test-first order is that principle applied to verification.

Let the agent help, on your terms

None of this means banning the agent from your test files. Have it generate the permutation coverage, the fixture setup, the mocking boilerplate that eats human hours. Have it suggest edge cases you might have missed, which it is genuinely good at, and then you decide which ones are real requirements versus its assumptions. The agent as a test-writing assistant is great. The agent as its own examiner is not.

The rule I hold to: the test that answers "is this correct" comes from outside the thing being judged. Everything else, the agent can draft. Build your workflow so that separation is automatic rather than something you remember to do, which is how we structure the loop at Bootspring, and running the finished code through an independent quality gate like ReformCode catches what the self-graded suite missed. Let AI write plenty of tests. Just never the one that grades its own homework.