Not on their own. Tests an agent wrote for its own code can pass for the wrong reason, because the same model made the same assumptions twice. Trust them after you check that they fail when the code is broken, assert real behavior, and were reviewed by a person who knows the requirement.
Why self written tests are weaker
If an agent misreads a requirement, it writes code that matches the misreading and a test that matches the code. Both pass, and the bug ships with a green check. Reviewers see passing tests and relax, which is the real risk.
Four checks that work
1. Break the code on purpose. Change a condition or return value in the function and run the tests. If they still pass, they are not testing that behavior. This is a manual version of mutation testing, and even three or four deliberate breaks tell you a lot.
2. Read the assertions. Weak assertions look like this: the result is not null, the function does not throw, the output has some length. Strong assertions state the expected value from the requirement, not from running the code.
3. Check the test inputs. Did it test the edge cases: empty input, boundary values, bad types, large input, and an unauthorized user? Agents tend to test the happy path.
4. Write the expected result first. For critical logic, a human writes the expected outputs from the spec, then lets the agent write code to satisfy them. The test now comes from outside the model's own reasoning.
What to watch for in the diff
| Red flag | What it suggests |
|---|---|
| Tests changed in the same commit that fixed the failure | The test was bent to fit the code |
| Mocks of the exact function under test | The test checks the mock |
| Assertions copied from the output | Tests lock in current behavior, bugs included |
| Skipped or commented out tests | Inconvenient failures removed |
| Coverage rises but assertions are few | Lines run, behavior not checked |
Coverage alone proves lines executed, not that behavior is verified. Pair it with the breaking exercise above.
Security tests need a human author
For access control, input validation, and cryptography, do not let the agent define the expected behavior. Write the negative cases yourself: the user who should be refused, the input that should be rejected. Then let the tool help fill in the rest. A static analysis scan and dependency checks add independent evidence, since they do not share the model's blind spots.
Make it a team habit
Add one line to your review checklist: has anyone shown this test fail? Link it to the AI written pull request review checklist. Over time reviewers learn which suspicious patterns recur in your codebase.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a code scan reports findings the tests never asked about, an independent check that does not share the agent's assumptions.
Safeguard offers pull request gates, policies, and a free scan that add checks outside the agent's own reasoning.
Quick check
Is high coverage proof that the tests are good?
No. Coverage shows which lines ran. It says little about whether assertions would catch a wrong result.
Should agents be banned from writing tests?
No. They are useful for scaffolding. Just do not accept them without the checks above.
Last reviewed: 19 October 2026.
