You asked your LLM to write tests. It gave you 47 of them. CI is green. Coverage is at 94%. You feel productive.

Then something breaks in production that every single one of those tests should have caught.

This isn't a hypothetical. Research from the MutGen project found that some LLM-generated test suites achieve 100% code coverage but only a 4% mutation score. That means they miss 96% of potential bugs. Your tests execute every line of code and verify absolutely nothing.

The tautological test problem

When you prompt an LLM with "write unit tests for this function," it does exactly what you'd expect from a pattern-matching system. It reads your code, mirrors your logic, and writes assertions that confirm your implementation does what your implementation does.

Here's what that looks like in practice:

def calculate_discount(price, tier):
    if tier == "gold":
        return price * 0.8
    return price

# AI-generated "test"
def test_gold_discount():
    assert calculate_discount(100, "gold") == 80.0

This test passes. It will always pass. It tells you nothing you didn't already know by reading the function. It won't catch the bug where negative prices produce negative discounts, or where tier is None, or where floating-point arithmetic creates a rounding error on real currency values.

A postmortem on DEV Community documented this exact failure pattern. A team let AI scaffold their test suite, CI stayed green for months, and then a well-covered endpoint started returning silently incorrect data. The AI had patterned its tests after the code's own assumptions instead of challenging them.

Why "write tests" is the wrong prompt

The problem isn't that LLMs can't write good tests. It's that "write tests for this" gives the model zero constraints on what the tests should actually verify.

A study of 609 developers by Qodo found that 65% cite "missing context" as the top cause of bad AI output. That tracks. When you don't tell the model what behaviors matter, what inputs are dangerous, or what invariants must hold, it defaults to the happy path. That's rational behavior from a model optimizing for plausible-looking output.

There's a subtler problem too. When AI writes code and then AI writes tests for that code, you get circular validation. The tests validate the AI's assumptions, not your intent. Cortex's 2026 Engineering Benchmark found that while AI boosted PR throughput by 20%, incidents per pull request climbed 23.5%. More tests, more speed, more bugs.

The constraint-based prompt structure

The fix is to stop asking for tests and start specifying what the tests must prove. Here's the structure that works.

The Prompt:

You are writing tests for the function below. Do NOT read the implementation 
to determine expected outputs. Use ONLY the specification I provide.

Function signature:
{paste signature and docstring only, not the implementation body}

Specification:
- Accepts a price (float) and a membership tier (string)
- Gold tier gets 20% off, silver gets 10% off, all others pay full price
- Prices must be non-negative; raise ValueError for negative input
- Result is rounded to 2 decimal places

Write tests that cover:
1. Each tier at a normal price
2. Boundary: price of 0.00
3. Boundary: price of 0.01 (check rounding)
4. Error path: negative price
5. Error path: None as tier
6. Error path: empty string as tier
7. Property: output is always <= input for non-negative prices

Use pytest. Each test gets one assertion. Name tests after the behavior 
they verify, not the implementation detail they touch.

Why This Works: You've separated specification from implementation. The LLM can't mirror code it hasn't seen. You've enumerated the boundaries and error paths explicitly, so the model can't skip them. And the property-based test (output <= input) catches a class of bugs that example-based tests miss entirely.

Expected Output:

A pytest file with 7+ test functions, each named descriptively (like test_negative_price_raises_value_error), each with a single focused assertion. The boundary tests will catch rounding issues. The error path tests will catch missing input validation. The property test will catch sign errors and overflow bugs.

Notice what changed. You're not asking the model to figure out what's worth testing. You already know that. You're using the LLM to translate your testing intent into executable code.

Mutation-guided prompting: the next level

Constraint-based prompts handle the cases you can anticipate. Mutation-guided prompting catches the ones you can't.

The idea: take your existing test suite, run a mutation testing tool against it, and feed the surviving mutants back to the LLM. A surviving mutant is a specific code change that your tests didn't catch. That's the most precise possible prompt for "write a test that catches this bug."

Meta deployed this approach across 10,795 Android Kotlin classes in Facebook, Instagram, and WhatsApp. They generated 9,095 mutants and 571 privacy-hardening tests. Privacy engineers accepted 73% of the generated tests. The key detail: they never asked the LLM to "write tests." They fed it surviving mutants and asked it to kill them. (Meta ACH, FSE 2025)

The academic results back this up. MuTAP's mutation-guided prompting hit a 94% mutation score on HumanEval, compared to 66% for Pynguin, a leading traditional test generator. The prompt template is specific:

The Prompt:

The test function {test_name} cannot detect the fault in the following 
mutated code:

{original code with specific mutation highlighted}

The mutation changed: {description of what was changed}

Write a new test case that would PASS on the original code but FAIL on 
this mutant. The test must specifically target the changed behavior.

Why This Works: You're giving the LLM a concrete adversarial target. It's not guessing what might go wrong. It's looking at a specific fault and engineering a test to expose it. This is the difference between "test this function" and "prove this specific bug would be caught."

Expected Output:

A single focused test that exercises the exact code path where the mutation lives, with an assertion that distinguishes the correct behavior from the mutated behavior. For example, if the mutant changed >= to >, the test would use the exact boundary value where those operators differ.

Breaking the circular validation loop

Even with good prompts, there's a structural problem when the same AI writes both your code and your tests. The QTRL analysis identifies this as the root cause of most AI-introduced production bugs.

Three ways to break the loop:

Separate the specification from the generation. Write your test specifications (what to test, what the expected behaviors are) by hand. Let the AI generate the executable test code from your spec. This is what the constraint-based prompt above does.

Use adversarial agents. The AdverTest framework (Feb 2026) uses two LLMs in competition. One generates mutants trying to evade detection. The other generates tests trying to catch them. The bidirectional feedback produces up to 8.56% improvement in fault detection over single-agent approaches.

Run mutation testing as your quality gate. Don't trust coverage numbers. A mutation score tells you what percentage of injected faults your tests actually catch. If your AI-generated suite hits 95% coverage but 30% mutation score, you know exactly how much of it is theater.

One more thing to watch

The MAPS study found something counterintuitive: the prompt that performs best on ChatGPT performs worst on Llama-3.1. The spread between best and worst prompts on a single model was only about 2.5% for line coverage. This means the specific phrasing matters less than the structural approach. Whether you use "You are a QA engineer" or "Write pytest functions" is almost irrelevant. Whether you provide specifications, constraints, and adversarial targets is everything.

Stop prompting for tests. Start prompting for specific fault detection. The LLM is capable of writing tests worth keeping. It just needs you to define what "worth keeping" means.

If your team is generating tests with AI and wondering whether any of them actually catch bugs, Kief Studio runs hands-on training on prompt engineering for software testing workflows. Connect with us on Discord or schedule a session.

software development

Test Generation Prompts That Produce Tests Worth Keeping