Passing tests, open database: critical thinking for vibe coders

AI agents now produce work that is well written and mostly correct. That sounds like pure good news, and most of the time it is. The catch is that nothing in your day forces you to look twice anymore. Wharton researchers Steven Shaw and Gideon Nave have a name for where that can end: cognitive surrender, the point where an answer quietly becomes yours and you feel no need to check it.

For engineers this is a quality problem. For people who build with vibe coding (describing an app to an AI and shipping what it generates) without a background in engineering, it is often a security problem, and the ones who end up paying are third parties, the app's users.

When the bug is an open door

Agents make tests so cheap that everything looks covered. A test written with the same mistake as the feature will still pass. A passing test proves one thing. It's easy to assume it proves everything.

For most bugs, that gap costs you a broken feature and a bad afternoon. Security bugs are different. A test that confirms a logged-in user can see their own orders says nothing about whether a logged-out stranger can see everyone's orders. The app works, the demo works, the tests pass, and the data is public.

We saw exactly this pattern recently with apps built on Lovable. Many of them left the database access rules in Supabase misconfigured, so anyone could read data without logging in. Lovable's terms put that responsibility on whoever builds the app. Because these integrations follow the same patterns everywhere, one mistake like this can show up in many apps at the same time.

That's cognitive surrender at scale. Nobody decided to leave the door open. Each builder accepted output that looked done, and even safe.

Cheaper to launch, cheaper to attack

I keep coming back to one belief. Vibe coding makes launching a product much easier. It also makes attacking that product much easier, so the total cost doesn't always go down.

The same tools that let one person ship an app in a weekend let an attacker scan thousands of those apps for the same misconfiguration in an afternoon. When everyone generates code from similar prompts on similar stacks, the mistakes repeat too. A flaw in one app is probably a flaw in hundreds of others, and anyone can go looking for it.

So the bill arrives later, and your users are the ones who pay it.

Five questions before you ship

You don't need to be a security engineer to ask these.

What would have to be true for this to be wrong? Ask it about access. Who should never see this data? Then try to see it as that person. Open the app in a private window without logging in and call the same endpoints.

When the tests pass, what did they actually prove? Then ask what they didn't. If every test runs as a logged-in user, nothing has tested the logged-out case.

Read the decisions behind the summary. Ask the agent to list the decisions and assumptions it made. For security, ask for the specifics: which tables can be read without a session, which keys are exposed in the browser, and which defaults it left unchanged.

Define "safe" up front. Before you ask for a feature that touches user data, write down what "safe" means for it. If you write it after the fact, it's too easy to rationalize whatever came out.

Would you defend this in front of the person whose data it holds? For an app with real users, they are the ones with the most to lose.

Accountability doesn't get generated

You can hand an agent the work and a good part of the checking. The responsibility stays with you.

Agents could take on more of this work over time. Picture an agent that watches your projects, checks them against known vulnerabilities and opens a pull request with the fix. That would help a lot. It still wouldn't change who answers when user data leaks.

Back in August I wrote that you should never tell your AI agent your password. The same instinct applies here. Delegate the work, keep the keys, and keep the responsibility.

So if you expect the budget to build software to drop because AI is helping, you're probably wrong. Going from an idea to a product got easier. Finding and exploiting flaws got easier too, for anyone, and that is why the value of engineering and security is clearer today than ever.