Require tests that try to break the code, not only tests that show it working. When an assistant writes the function and its tests together, the tests often confirm whatever the code does. Ask for abuse cases, boundary cases, and a regression test for any bug fixed along the way.
The problem with matching tests
A test generated next to the code it checks shares its assumptions. If the code forgets an ownership check, the test will not ask for one. Green checks then give false comfort.
This is one reason a Stanford user study mattered: participants with an assistant wrote less secure code and believed it was more secure. Passing tests can feed the same belief.
Tests worth requiring
Authorization tests. For each endpoint that returns or changes a record, one test where the caller is the wrong user, and one where the caller is unauthenticated. Both must be refused.
Input abuse tests. Feed the handler a very long string, an empty value, unexpected types, and a few classic injection strings. The expected result is a clean rejection, not an error trace.
Boundary tests. Zero, one, maximum, one past maximum, negative numbers, dates at limits.
Failure path tests. Make the database or downstream call fail and check what the user sees and what gets logged.
Regression tests. If the change fixes a bug, the test must fail before the fix and pass after. Ask for evidence of the failing run.
Dependency tests. If a new package was added, one test that exercises the way you actually use it, so a later upgrade or swap is noticed.
A review habit that works
Read the test names before the code. Ask what is missing. Then ask the assistant, in a separate session, to write tests that try to break the function, without showing it the original tests. Differences between the two sets are informative.
Mutation as a spot check
Change a condition in the code, for example flip a comparison, and see if any test fails. If none does, the suite is not protecting that line. Do this by hand on the riskiest function; you do not need a tool for a first pass.
What to say in review
Make the request specific. Instead of asking for more tests, write: add a test where user B requests user A's record, and a test where the input is 10,000 characters. Specific requests are easy for an assistant to fulfil and easy for you to check. They also teach the author which kinds of tests matter for this codebase.
Quick check
Should AI be allowed to write the tests at all?
Yes, as a draft. The point is that a human decides what behavior must be refused, and checks that the suite actually enforces it.
Sources
Last reviewed: 19 October 2026.
