How do you test what the AI writes? Verification is the real vibecoding skill

The hardest part of building with AI isn't getting it to write the code. It's knowing whether the code it wrote is actually right. That's the whole job now, and almost nobody talks about it. So let me talk about it.

Here's the thing that trips people up. The AI is confident the exact same way whether it nailed it or whether it quietly broke three other things. It hands you the finished feature with the same tone either way. No sweat on its brow. It doesn't know it's wrong, so it can't warn you. Which means the "is this actually done" question doesn't come from the machine anymore. It comes from you. Every time.

I said in seven products in that checking the work is the real skill. This is me actually explaining how I do it, because "just verify it" is useless advice on its own.

So — how do I test what the AI writes?

First thing: I don't trust "it runs" as proof of anything. Code that runs is the floor, not the ceiling. Plenty of code runs beautifully and does the wrong thing. So before I even look at the diff, I go back to what I wrote down about what "done" means for this piece — the actual behavior I wanted — and I check the code against that, not against whether the screen loaded without an error.

Second: I run the thing like a suspicious user, not like the person who built it. The builder in me wants to type the happy path and watch it work and feel good. The tester in me types the empty input, the huge input, the emoji in the name field, the thing you're obviously not supposed to do. That's where AI-written code tends to crack — not in the middle of the road, at the edges it didn't think to guard. tab. taught me a lot of this; a social ledger where the money math is even slightly off is a dead product, so I got in the habit of trying to break my own totals before anyone else could.

Third: I read the diff, actually read it, especially the parts I didn't ask about. When you ask for one change and get back edits to four files, the file you didn't mention is the one to stare at. Nine times out of ten it's fine. The tenth time it "helpfully" changed a default somewhere and you'd never have caught it by clicking around.

Fourth, and this is the one that saves me most: I make the AI prove it, not just claim it. Instead of "did you handle the case where the list is empty," which gets you a cheerful "yes," I'll ask it to walk me through what happens step by step with an empty list, or better, get a test in front of the behavior so the machine has to show its work. Confidence is free. A passing test that I actually understand is not.

The uncomfortable truth under all of this is that verification doesn't get faster the way building did. Building collapsed to almost nothing — I can describe a whole app and watch it appear. But checking it still takes real time and real attention, because it's the part that needs a human who knows what right looks like. So the ratio flipped. I used to spend most of my time writing and a little verifying. Now it's the reverse, and the projects that went out clean are the ones where I respected that instead of fighting it.

Who this matters for, plainly: anyone building software with AI — vibecoders, solo devs, people shipping side projects on a weekend — who's felt that little jolt of "wait, is this actually working, or does it just look like it's working?" That jolt is correct. Learn to listen to it.

That's the skill. Not prompting. Doubting the confident thing in front of you, and knowing how to check.

This one's auto-drafted from my project notes on a schedule. No invented numbers here — if a metric isn't in my notes, it doesn't make it into the post.