Otranto.aiAI consulting
← All posts
BuildingMarch 20265 min

If You Haven't Seen the Code Do the Right Thing, It Doesn't Work

As a non-dev vibe coder, this one line hit me hard today:

"If you haven't seen the code do the right thing yourself, that code doesn't work."

Felt like I was personally @'d.

The Trust Trap

Here's what happens when you build with AI: you write a prompt, Claude spits out beautiful code, it generates tests, the tests pass, and you think "great, it works." You commit, you push, you move on to the next feature.

Then three days later, a user hits an edge case that the AI never considered, and the whole thing falls over. And you're staring at code you didn't write, trying to debug logic you don't fully understand, wondering why the tests said everything was fine.

I catch myself doing this more than I'd like to admit. Trusting the unit and e2e tests my LLM writes as proof everything works - without actually clicking through the feature myself, without actually seeing the thing do what it's supposed to do with my own eyes.

TESTSrenders formvalidates emailsubmits payloadshows successhandles emptye2e: happy path0 of 6 passedwritten by the same AITHE BROWSERweird input, very long, émojiSubmitfalls overthe tests said fine
Green on the left. Red in the browser. Then green for real.

Tests Are Not Verification

This is the thing nobody talks about with vibe coding. The AI writes tests that test what the AI thinks the code should do. But the AI wrote both the code and the tests. It's grading its own homework. Of course it passes.

That doesn't mean the feature works the way you intended. It means the code is internally consistent with itself. Those are two very different things.

Grading its own homework
  1. AI writes the code
  2. AI writes the tests
  3. Tests pass
  4. INTERNALLY CONSISTENT
Seeing it work
  1. Open the app
  2. Click the buttons, enter weird inputs
  3. Watch it do the right thing
  4. VERIFIED
Two very different things.

Real verification means opening the app, clicking the buttons, entering weird inputs, trying to break it. If you haven't physically watched the feature do the right thing - in a browser, with real data, as a real user would - you're guessing.

What I'm Changing

I've started a simple rule for myself: before I commit anything, I have to see it work. Not see the tests pass. See the actual feature, in the actual browser, doing the actual thing. If I can't demo it to myself, it's not done.

It's slower. It catches things the tests don't. And it's forced me to actually understand what my code is doing instead of just trusting that the AI got it right.

Credit where it's due - this was my first (and definitely not last) day reading Simon Willison's blog. The man is a treasure for anyone building with AI. If you're vibe coding and you haven't read his stuff, start there.

A.J. OtrantoAI consulting
← PreviousThe Biggest Threat to Large Organizations
Get in touch

Got a reaction to this one?

I read everything, and a disagreement is more interesting than a compliment.

Start a conversation