Deciding What to Test: Letting AI Write the Tests So You Can Decide What’s Worth Testing

You’ve built a feature and you know you’re supposed to test it. Say you’re building a tool that lets small food trucks take pre-orders so customers can skip the line. You just finished the checkout flow, and testing it by hand every time you change something is already getting old. So you ask your AI assistant to write tests for the checkout code, and a minute later you’ve got a stack of them. Twenty, thirty green checkmarks marching down the screen. The cart total adds up, the discount code applies, the order object gets built with the right fields. Everything passes. It looks like the responsible thing a real developer does, and you feel like you just bought yourself some safety.

And that green wall of passing tests is doing something sneaky. It feels like proof that your feature works, when really it’s proof that your code does what your code does. AI read your checkout function and wrote tests that confirm it behaves the way it currently behaves. If your discount logic has a bug that lets a code stack on itself, AI didn’t catch it; it wrote a test that expects the buggy behavior, because that’s the behavior it saw. The tests all pass, and they’ll keep passing right up until the day a customer stacks three codes and pays four dollars for forty dollars of food. The careless version of this job isn’t asking AI to write tests. It’s letting AI decide what’s worth testing, and getting back a suite that guards the code you have instead of the promises you actually need to keep.

What this job actually is

Deciding what to test is two jobs crammed into one word, “testing.” The first is writing the tests: taking a thing you want verified and turning it into actual test code that sets up the scenario, runs it, and checks the result. That’s mechanical, fiddly work, and AI is genuinely good at it. It knows the testing tools, it can mock out the parts that are hard to set up, it can write the boilerplate faster and more patiently than you ever will, and it won’t get bored on test number nineteen. Handing AI the writing is smart; it’s exactly the kind of tedious, pattern-heavy work it does well.

The second job is deciding what deserves a test in the first place. Out of everything your feature does, which behaviors actually matter enough to guard? Which failure would be a quiet disaster (money lost, data corrupted, a user locked out)? Which edge case is the one that’ll actually happen and actually hurt? And which of the hundred things you could test are trivial checks that pass forever and prove nothing? That’s not mechanical. It’s a judgment call about what your feature is really promising and what it would cost you if that promise broke.

Here’s the distinction that matters: AI can generate the tests, but deciding what’s worth testing is yours. A hundred passing tests is not a safety net; it’s a hundred passing tests. The value of a test suite comes entirely from whether it would scream when the thing that matters breaks, and that means knowing in advance which behaviors are load-bearing. AI can’t know that, because it can’t feel the difference between a test that protects your business and a test that just re-describes a line of code. It’ll write both with equal confidence and mark both green, and leave you believing you’re covered on exactly the failures it never thought to check.

How to delegate the writing

So lean on AI for the part it’s good at, which is turning a scenario you care about into working test code. The move that makes this delegation good is reversing the usual order: you bring the list of what matters, and AI writes the tests for it, instead of AI both choosing and writing and you rubber-stamping the result.

Once you’ve decided which behaviors are worth guarding, hand them to AI plainly. Tell it the specific things that must always hold true (a discount can never be applied twice, an order total can never come out negative, a customer can never check out with an empty cart) and ask it to write tests that would fail loudly if any of those stopped being true. Ask it to test the ugly inputs, not just the clean ones: the empty cart, the expired code, the quantity of zero, the two-orders-at-once collision. Ask it to write the test so that the thing being checked is obvious from the test’s name, so future-you can read the suite and see what it actually protects. AI is excellent at all of this once you’ve pointed it at the right targets.

What you don’t do is ask “write tests for my checkout code” and take what comes back. That open phrasing is what produces the wall of green that guards nothing, because with no idea what matters to you, AI does the only thing it can: it tests that the code does what the code does. Keep the ask on execution. Here are the behaviors that must never break; write me tests that fail hard the moment any of them do. You’re handing AI a list of promises and asking it to build the alarms. Choosing which promises are worth an alarm is the part you bring.

The judgment you keep

Deciding what’s worth testing is the call, and it’s yours because it turns on something AI can’t see: which behaviors, if they silently broke, would actually cost you something you can’t afford.

This is hard because almost everything looks worth testing in the abstract. Every function could have a test; every branch could be covered. Coverage numbers make it worse, because they reward testing everything equally and say nothing about whether you tested the right things. The judgment is in looking at a feature and deciding that this specific behavior, the one where money changes hands or a promise gets kept, is the one that has to have a test with your name on it, while these other twenty behaviors are either too trivial to break or too harmless when they do. For the food-truck app, a test proving a discount can’t stack on itself is protecting real dollars, while a test checking that the “thanks for your order” text renders exactly right is polish that’ll pass forever and warn you of nothing that matters.

AI can’t make this call because it doesn’t know what’s load-bearing in your product. It can see that a function exists; it can’t feel that this function is where your revenue lives and that one is cosmetic, because that weighing depends on what your users trust you with and what breaks that trust, and that’s context AI doesn’t have. Get this wrong and you end up in the worst spot in testing: a big, green, confident suite that gives you the feeling of safety without the substance, so you ship boldly on top of it and get blindsided by the one failure nobody wrote a test for. A suite that tests the wrong things is more dangerous than no suite at all, because no suite at least keeps you nervous. Knowing which behaviors are worth guarding is the entire point of testing, and it’s the one part AI can’t hand you.

Before you ship this job

Here’s what good delegation looks like, and the line it can’t cross.

The sample prompt. Something real you might send:

I’m building QueueJump, an app that lets customers pre-order from small food trucks so they can skip the line. My main user is someone like Sofia, who runs a taco truck and can’t afford to lose money to checkout bugs or hand out free food by accident. I’ve already decided which behaviors I care most about protecting, and I want you to write tests for exactly these: a discount code can never be applied more than once to the same order; an order total can never come out zero or negative; a customer can never check out with an empty cart; and when two customers order the last available item at the same time, only one order succeeds. For each one, write a test that fails loudly the moment that behavior stops holding, test the ugly inputs (expired codes, quantity of zero, already-used codes) as well as the clean path, and name each test so it’s obvious from the name what promise it’s guarding. Don’t add coverage for cosmetic things like message text or styling; I want the alarms pointed at the failures that cost me money or trust.

Use this and you get tests aimed at what you actually can’t afford to break. Copy it as-is and you’ve let me pick what’s worth testing, not you; those are Sofia’s load-bearing promises, built around a taco truck’s risks. Your feature’s money-and-trust behaviors sit somewhere else, and the suite only protects you if you’re the one who named them.

The part you can’t hand off is the choosing: which behaviors matter enough to guard with a test, sorted out from the ones that are trivial or harmless, judged against which silent failure would actually cost you money, data, or a user’s trust.

How to check AI did its part: don’t count the passing tests; break the code on purpose and see if a test notices. Take one of the behaviors you said you care about, deliberately introduce the bug (let the discount stack, allow the empty-cart checkout), run the suite, and confirm a test goes red. Then undo the break and watch it go green again. If breaking the thing you care about turns a test red, that test is really guarding it, and you can trust the alarm. If you sabotage a load-bearing behavior and every test still passes, then your suite is decoration; it’s testing around the thing instead of the thing, and all that green was telling you nothing. A test that stays green while the behavior it names is broken isn’t a test, it’s a comment that runs.

What you get for doing it this way

Go back to that wall of green checkmarks and the safety you thought you’d bought. The difference between letting AI decide what to test and deciding it yourself is the difference between a suite that reassures you and one that would actually catch you when you fall. When you bring the list of what matters and let AI write the alarms around it, you get tests that stay quiet until something you genuinely care about breaks, and then go off loudly, in time to fix it before a customer finds it for you.

AI can write every test you could ever want, faster and more thoroughly than you’d write them yourself. Which behaviors are worth testing in the first place was always going to be your call, because only you know what your feature is really promising and what it costs you when that promise breaks. That’s the job: let AI write the tests, but decide for yourself what’s actually worth testing.