"The AI wrote tests for this feature, so it must be solid." I hear some version of that every week now. Someone builds a login flow, a file upload, a checkout form, an admin panel, whatever, using an AI coding tool, then asks the same tool to write tests for it. The tests pass. Green checkmarks across the board. That becomes the whole security review, start to finish.
The tests aren't lying to anyone. They're just answering a much narrower question than most people think they're answering.
What the tests actually check
Ask an AI coding assistant to write tests for a login form and you'll get something like: correct email and password logs you in, wrong password shows an error, empty fields get flagged. Reasonable tests. All happy path, or close to it, because they check the form doing its job for someone using it the way it was meant to be used.
What you almost never get, unless you ask for it by name, is the other list: what happens when the token is expired, forged, or just missing. What happens when one user's session somehow gets used to pull up another user's data. What happens with a 40 MB "profile picture," or a filename that's actually a path traversal string in disguise, or an ID in the URL swapped out for someone else's record.
That second list is the unhappy path: the malicious, careless, or just plain weird input. It's a different kind of correctness question, and it needs a different kind of test to catch it.
Two different questions, not one
Functional correctness asks: does the feature do what it's supposed to do. Security correctness asks: does the feature refuse to do what it's not supposed to do. A test suite can nail the first question completely and never come near the second, and that's what I find in most AI-generated test suites once I actually go looking.
The public incidents from last year made this concrete for me. The Supabase row-level-security flaw that hit a run of Lovable-built apps in 2025 wasn't a case of broken functionality. Signup worked. Login worked. Dashboards rendered. Every demo looked clean, and every happy-path test would have gone green. The actual problem was that with row-level security missing or inverted, one user's session could reach another user's rows. No functional test was ever going to catch that, because "can user A read user B's data" isn't a functional question. It only surfaces if someone specifically goes looking for it.
Same shape with the Base44 authentication-bypass case reported that same year. The app did exactly what it was built to do for the person it was built for. The flaw was that anyone else could get in too, using nothing more than a public app ID.
That's not "the code was buggy" in the sense most people mean it. A lot of that code ran fine and would sail through whatever functional checks it was handed. It just also left a door open, and nothing in a standard test run was built to notice.
What to actually ask for
If a feature touches user data, authentication, money, or file uploads, functional tests are not enough on their own, and the AI isn't going to add the security-shaped tests unless you ask for them by name. Be specific about it:
- What happens if the auth token is missing, expired, or belongs to someone else
- What happens if a user ID in the URL or request body gets swapped for someone else's
- What happens with an oversized file, the wrong file type, or a filename built to escape its folder
- What happens if the same request fires hundreds of times in a second
- What happens if a field that should be a small positive number shows up negative, huge, or not a number at all
Ask for those tests by name and the AI will write them without complaint. It just won't volunteer them on its own, because nothing in "write tests for this feature" tells it to think like someone trying to break in rather than someone trying to use it.
A green test suite tells you the feature works for the person it was built for. It says nothing about the person it wasn't built for, and that second person is the one who decides whether it was actually safe to ship.