You typed "write tests for this," and the agent handed back a wall of green. Every check passed. You're staring at the commit button right now, and the question in front of you is whether that green means "this is safe to ship."
It doesn't. Not by itself. And the reason why is worth understanding, because once you see it you'll never read a green suite the same way again.
What the agent actually did
When you ask a coding agent to write tests "for this," it does the only thing it can do: it reads the code you gave it and infers what that code is supposed to do from what the code actually does. If your function has a bug, the agent doesn't know that — it has no separate copy of your intent to check against. So it writes a test that asserts the code's current behavior, bug included, and that test passes. Cleanly. Every time.
This isn't a guess on my part. There's a paper behind it: "Evaluating and Mitigating the Misguidance Effect of Buggy Code in LLM-Generated Unit Tests," by Junda Zhao, Shurui Zhou, and Eldan Cohen at the University of Toronto, accepted to ISSTA 2026 (arXiv 2607.22883). Their finding, in plain terms: handing a model buggy code to test from does two things at once. It inflates the number of tests that assert the wrong behavior — the misguidance effect the title names — and it suppresses the tests that would have actually caught the bug. Both effects push the same direction: toward a suite that agrees with you.
Think of it like a home inspector who only reads the wiring you already installed. He can tell you honestly whether the wires he sees are connected to each other. He cannot tell you the outlet in the nursery was supposed to be on a different circuit, because nobody handed him the blueprint — only the wiring. A test suite generated from your code, and only your code, is that inspector. It will certify the house exactly as wired, bug included, and it will do it in good faith.
You've probably seen this problem described elsewhere as "the model is marking its own homework," which is a fine one-liner and also where most of the writing on this stops — asserted, not shown. I want you to actually watch it happen, on code small enough to hold in your head, so the mechanism stops being a vibe and starts being something you can check yourself the next time it matters.
Watch it happen
Here's a function with a bug in it. Small, realistic, the kind you'd actually write:
def apply_discount(total, threshold=100, discount=0.1):
# Bug: should be >= threshold, not > threshold
if total > threshold:
return round(total * (1 - discount), 2)
return total
The rule this is supposed to implement: "orders of $100 or more get 10% off." Read the code instead of the rule and you'd write it exactly like this — '>' feels natural, nobody types '>=' by instinct. That's the bug: an order of exactly $100 should discount and doesn't.
Now ask an agent to write tests for this function, the way most people actually phrase it — no spec, just the code. It writes something close to this:
from discount import apply_discount
def test_above_threshold_gets_discount():
assert apply_discount(150) == 135.0
def test_below_threshold_no_discount():
assert apply_discount(50) == 50
def test_at_threshold_no_discount():
# This test was written by reading the code, not the requirement.
# It just restates the bug back at you.
assert apply_discount(100) == 100
I ran it — plain Python, no test framework, just three functions and an assert (Python 3.11.15, though none of this is version-specific; any recent Python reproduces it):
=== tests written against the code === PASS test_above_threshold_gets_discount PASS test_below_threshold_no_discount PASS test_at_threshold_no_discount
Three for three. That third test isn't wrong, exactly — it's an accurate description of what the function does. It just isn't a check on what the function should do, and nothing about a green checkmark tells you which one you're looking at.
The near-miss fix that doesn't work
Before you get to the real fix, it's worth ruling out the one you'll probably try first, because it's the intuitive move and it doesn't touch the actual problem. If you ask the agent to "add some edge case tests" for 'apply_discount', it will dutifully add a test for zero, a test for a negative number, maybe a test for a huge number. All useful. None of them will catch this bug, because "edge case" as the agent understands it still means "a boundary of the code I'm looking at" — and the boundary in the code is '> threshold', not '>= threshold'. It will happily write a very thorough test suite around the wrong line and never once suspect the line itself. Asking for more tests against the same source of truth just gets you a bigger version of the same mistake.
The fix is one sentence, asked first
Here's the move: before you ask for tests, ask for the spec. Literally say to the agent, "what should this function do, in plain English, based on the name and how it's used?" — not "explain this code," which just walks the implementation back at you. Then say: "now write tests against that description, not against the code."
I wrote the plain-English version myself — "orders of $100 or more get 10% off" — and asked for tests against it instead of the function:
from discount import apply_discount
def test_above_threshold_gets_discount():
assert apply_discount(150) == 135.0
def test_below_threshold_no_discount():
assert apply_discount(50) == 50
def test_at_threshold_gets_discount():
# The spec says "$100 or more." $100 is "or more."
assert apply_discount(100) == 90.0
Same function, same two easy cases. But that third test now checks the boundary against the rule, not against the code, and:
=== tests written against the spec === PASS test_above_threshold_gets_discount PASS test_below_threshold_no_discount FAIL test_at_threshold_gets_discount
One red. That's not a worse result than the first run — it's the first result that told you anything. The suite went from confirming the code to disagreeing with it, and the disagreement is where the bug was hiding the whole time.
Why this matters
A green suite generated the first way isn't neutral information — it's actively reassuring you about the exact thing most likely to be wrong. The paper's whole second half is about the fix that worked in their evaluation: replace the code under test in the prompt with a generated specification — a docstring describing intended behavior — before asking for tests, which is the same move I just did by hand with one sentence. You don't need their tooling to get the benefit. You need to stop letting the code describe itself to the thing grading it.
This isn't an argument against AI-generated tests. It's an argument against treating "the tests pass" as a finished sentence. The tests pass against what, is the actual question, and the code itself is the one answer that can't be trusted to grade its own homework — it's graded by the code, using an answer key written by the code, and a bug doesn't disqualify you from writing your own answer key.
One next step
Pick a function in whatever you're building right now — one you already have tests for, agent-written, currently green. Don't touch the code. Ask the agent one question: "what should this function do, in plain English, independent of how it's currently written?" Then ask it to write one new test against that sentence and run it alongside the ones you have. If everything's still green, you've earned some real confidence. If one goes red, you just found out what your existing suite was actually protecting — which was the bug, not you.