AI-Generated Tests Need to Earn Your Confidence

The terminal was green. The agent had added the feature, written the tests, run them, and reported everything passing — faster than I could have wired the first version myself. The summary sounded confident.

Then I opened the application and used it.

A feature that had worked before no longer did. Another completed the first step and failed on the next. The suite had passed. The product was still broken.

Generating code and tests had gotten faster. Confidence hadn't come along for the ride.

AI-generated tests are useful evidence, but only when they can fail for the right reason. A green result should be the end of a verification process, not a substitute for one.

A Passing Test Can Prove Almost Nothing

We tend to treat a passing test as a fact. Something ran, the check turned green, and the work appears safer than it did before.

But a test proves only what its assertion actually checks.

A test can open a screen without confirming that the right content appeared. It can click a control without checking that the intended state changed. It can call a service, receive the wrong response, and still pass because nobody defined what the correct response needed to contain.

In the least useful version, the test proves that the test ran.

AI makes this problem easier to miss because it can produce the complete shape of quality: organized test files, realistic names, setup code, mocks, and a polished summary. The output looks substantial. Reviewing it can feel like reopening work the agent already completed.

That feeling is the risk.

Generated code can be plausible without fitting the system around it. Generated tests can be plausible without protecting the behavior that matters. Volume does not close that gap. Clear expectations and inspection do.

Define the Behavior Before You Generate the Check

A test becomes more meaningful when the team can finish this sentence:

> If this behavior breaks, the test will fail because ________.

That blank should describe something a person, product, or connected system depends on—not an implementation detail that happens to be easy to inspect.

For a form, the important behavior may be that invalid information remains visible and the person can correct it. For a save action, it may be that the interface confirms persistence only after the server accepts the change. For a design-system component, it may be that keyboard focus moves to the right place when a dialog opens and returns when it closes.

Those statements give the AI a better target. They also give the reviewer a standard for judging what it produced.

I would write the behavioral contract before asking for the test:

• Starting condition: What must be true before the action?
• Action: What does the person or system do?
• Observable result: What should change in a way that matters?
• Failure condition: What should the product do when the expected path cannot complete?
• Protected behavior: What existing capability must remain intact?

This is not a long specification. It is a small agreement about what working means.

Make the Test Fail on Purpose

The simplest test of a test is to prove that it notices a known problem.

Temporarily change the expected result. Disable the state update. Return the wrong value. Remove the label the test claims to protect. Then run the test and watch what happens.

If it stays green, it is not protecting the behavior you thought it was.

This small step changes the review from “Did the agent create tests?” to “What failure can these tests detect?” That is a much more useful question for engineers, designers, and product leaders working with AI-assisted implementation.

It also exposes weak assertions quickly. A generated test may verify that a button exists while missing that the button does nothing. It may confirm that a request occurred without checking whether the interface handled the response. It may mock so much of the surrounding system that the tested path no longer resembles the product.

Not every test needs deliberate sabotage every time. But new tests around consequential behavior should earn trust at least once. The team should see the red result before relying on the green one.

Keep Human UAT Where the Experience Carries Risk

Automated tests are good at repeating known checks. Human review is still better at noticing when the experience is technically functional and practically wrong.

That distinction matters for design.

A test may confirm that an error message renders. A person can notice that it appears too late, disappears before it can be read, or gives no useful recovery. A test may confirm that a workflow reaches completion. A person can notice that the interface creates uncertainty between steps or makes the primary action difficult to find.

As I wrote in Good Product Design Answers the Next Question, a product can satisfy the immediate requirement and still leave the person carrying the work. Verification should include the transitions around the requirement, not only the final state.

I would keep direct human review for moments where:

• an incorrect result could create meaningful harm or loss;
• timing, sequence, or feedback shapes whether the experience feels trustworthy;
• accessibility depends on more than static markup;
• several systems meet and no single test represents the full path;
• the feature changed something people already rely on;
• the team cannot clearly explain what the generated test proves.

This does not mean manually retesting every detail after every change. It means matching the review method to the risk.

Design Has a Role in Verification

Testing can sound like work that begins after design. AI-assisted development makes that separation less useful.

Designers often know which moments carry the intent of the experience: the confirmation that prevents a duplicate action, the fallback that keeps a person moving, the focus order that makes a dialog usable, or the status change that explains what happened.

Those are testable behaviors.

A designer does not need to write the entire test suite to help define them. They can make important states explicit, identify what must survive a technical compromise, review the working implementation, and help the team decide where automated confidence ends and direct observation begins.

This is part of getting closer to code without becoming an engineer. The goal is not to move every discipline into the same role. It is to keep product intent connected to the implementation and the evidence used to approve it.

A design review of screenshots cannot do that alone. Neither can a test report.

Use a Three-Layer Confidence Loop

The verification practice I'd actually trust:

1. State what working means

Define the observable behavior, failure response, and existing capability the change must protect. Do this before generation when possible.

2. Prove the test can detect failure

Inspect the assertions, introduce a known break, and confirm that the relevant test turns red. Review what the test isolates or mocks away.

3. Use the real experience

Run the consequential path in the product. Check the transition, content, state, recovery, and accessibility—not only whether the last screen appears.

Each layer catches a different kind of false confidence. The contract catches an unclear target. The deliberate failure catches a weak check. Human UAT catches the gap between technical completion and a usable experience.

AI can support all three. It can help turn behavioral contracts into scenarios, generate setup code, suggest failure cases, and automate repetitive paths. That is valuable leverage.

But the team still owns the meaning of the result.

The Bottleneck Moves to Judgment

I still want AI to generate tests. It expands coverage, reduces setup work, and makes small projects more disciplined than they'd otherwise be. Nobody should go back to writing every line by hand.

But generated activity is not earned confidence, and the two are getting easier to confuse.

This matches the broader pattern in The Unsexy AI Work That Will Actually Change Product Teams: AI creates the most value when it reduces operational drag without removing ownership of the decision. Testing follows the same rule.

As generation gets faster, verification becomes more visible. Someone still has to decide what matters, what evidence is sufficient, and which failure the product cannot afford to miss.

The green check is useful. The confidence behind it has to be designed.