Why “It Works” Isn’t Proof It’s Safe

nero — Sat, 31 Oct 2026 08:40:52 +0000

The happy-path trap almost every vibe coder falls into — usually once, the hard way

You know that moment.
You click the button.
The thing happens.
The data shows up exactly where it should.

Your chest does that little relieved-proud thing. It works!

Here’s the uncomfortable truth: that feeling is proof of exactly one thing.
It works when you — the person who built it — use it the way you intended, logged in as yourself. That’s it. That’s all it proves.

You’ve seen this movie before, just in a different building

If you’ve spent time in IT, you already know this trap.
It just wore a different uniform.

A firewall rule that “works” because traffic from your own laptop sails through tells you nothing about what happens from somewhere you didn’t expect. Testing an office door lock with your own keycard tells you nothing about whether it actually refuses a card that shouldn’t work.

You wouldn’t sign off on either of those based on one clean test from your own seat. So why would your app be any different?

The mindset shift, in one sentence

Stop asking “does this work?”
Start asking “what happens when someone tries to make it not work, on purpose?”

That single sentence is the difference between an app that feels done and an app that actually is. And it’s a shift, not a skill — you don’t need to learn anything new to make it. You just need to remember to ask the second question.

Happy-path testing vs. the test that actually matters

Happy-path testing is you, logged in as yourself, clicking through the app the way you built it to be clicked through. Expected inputs.
One request at a time. It always looks great, because you designed it to look great for exactly this path.

Adversarial testing is different. It’s logging in as a second, unprivileged account and trying to see what you shouldn’t. It’s editing a request directly — the same instinct as testing an ACL. It’s throwing blank fields, huge inputs, and wrong values at it on purpose, just to see what breaks.

You don’t need to write a single line of code for this.
A second free email address and your browser’s built-in developer tools — already sitting there, no install required — are the entire toolkit.

Why your AI tool won’t catch this for you

Here’s the part that catches people off guard.
Ask your AI tool for a feature, and it builds exactly that feature.
Nothing more.

It won’t volunteer “you should probably check who else can see this,” any more than a brand-new help-desk hire thinks to ask “should there be a limit on reset attempts?” unless someone already wrote that into the process. AI is fast, capable, and confident — and completely silent about the door it left wide open on the way out.

That’s not a flaw you fix by reading more code.
It’s a follow-up question you have to remember to ask, every single time.

The one tool that does 80% of the work

Every browser has a panel showing every request your app makes, and exactly what comes back. Right-click, Inspect, Network tab. That’s it.

Do the thing you’re testing. Read the number that comes back.
200 means it worked.
401 means you’re not logged in.
403 means you’re logged in, but blocked — usually a good sign.
500 means something broke on the server.

Open it, click the thing, read the number. That’s the whole skill. It’s the same instinct as checking a ping result or a packet capture — just pointed at a browser instead of a network.

The quick, honest gut check

Have you ever logged in as a second test account and tried to view the first account’s data? Have you opened the Network tab and actually watched a request happen? Have you asked your AI tool “who’s allowed to call this, and how would you check that?” — not just “does this work?”

If most of those are unchecked right now, that’s completely normal.
It’s also exactly the gap worth closing before you tell anyone the link is live.

The version of you on the other side of this

Picture shipping something and actually meaning it when you say “it’s solid.” Not crossed fingers. Not “it worked when I tried it.”
Actual, tested, I-tried-to-break-this-myself confidence.

That’s the difference between someone who got lucky and someone who builds like they know what they’re doing. The tools are the same either way. The only thing that changes is whether you remember to ask the second question.

Ship it. Then go try to break it yourself, before someone else does it for you.

Why Every Vibe-Coded App Breaks the Same Way

nero — Thu, 20 Aug 2026 20:40:34 +0000

You know that feeling when a change sails through testing, everything’s green, and it still gets stopped at change advisory board because someone asks the one question testing never checks?

That’s not bureaucracy being difficult. That’s the system catching something functional testing was never built to catch. Vibe coding has the exact same blind spot, and almost nobody’s built the CAB step for it yet.

Passing the Test Isn’t the Same as Passing Review
UAT tells you a change does what it’s supposed to do. It says nothing about what happens when someone pokes at it sideways.

An AI-built app is the same story. It ran. The button worked. None of that is proof it’s safe. It’s proof it works when you, the person who built it, use it exactly as intended.

Nothing in the vibe coding workflow forces that second review. You have to build the CAB step yourself.

The Seven Things That Keep Showing Up
I went looking for patterns across the vibe-coded apps I reviewed while writing my security handbook. Different founders, different ideas, different stacks in the details. Same seven problems, in some combination, every single time.

None of these require you to read a line of code to catch. They require knowing which questions to ask, and where to look for the answer. A dashboard. A browser panel. A log. The same way you’d check a switch config without reading the vendor’s source.

I’ve already gone deep on two of these on this profile, the key exposure and RLS specifically, with the exact fix for each. This piece is the map. That one’s the terrain.

This Isn’t a Hypothetical
Veracode’s 2025 GenAI Code Security Report tested over 100 AI models across 80 coding tasks. AI-generated code introduced a real vulnerability 45% of the time. Worth being straight about what that stat actually is: it’s from curated benchmark tasks, not a direct study of vibe-coded apps in the wild. It’s a strong signal, not a precise match.

The real-world incidents are more concrete. In February 2026, a researcher auditing a Lovable-built app found an inverted authentication check, one that blocked real users while letting anyone else straight in. It exposed records for over 18,000 people.

A separate app, Moltbook, was breached three days after launch. A misconfigured database with no row-level security exposed 1.5 million API tokens and 35,000 email addresses.

You Don’t Need to Learn to Code for This
Here’s the part that surprises people, and it’s worth saying plainly because it cuts against the usual advice. You don’t need to become a developer to catch any of the seven findings above.

Don’t go buy a computer science course. Don’t assume the fix is “learn to read code properly.” That’s the expensive, trendy answer, and it’s not the one that actually closes the gap.

What closes the gap is knowing what to ask your AI tool for, and knowing what “correct” looks like on a screen. If you’ve ever triaged a ticket, reviewed an ACL, or sat through a CAB meeting, you already have the instinct. You just haven’t pointed it at your own app yet.

Seven problems, same shape, every time — which means catching them — -isn’t a mystery. It’s a checklist you run once and reuse forever.

If that clicked, that checklist is the whole spine of the handbook I built around it. Seven core findings, plain-English checks, and a prompt for each one so you’re never stuck reading a diff to feel confident shipping. Worth a look if you want the full system instead of just the map.
Find it here “The Vibe Coders Security Handbook”

The Rule of Thumb
If nobody’s specifically asked “is this safe,” assume the answer is no.

DEV Community: nero

Why “It Works” Isn’t Proof It’s Safe

Why Every Vibe-Coded App Breaks the Same Way