What Is Vibe Coding? A Security-First Explainer

The phrase was popularized in early 2025 by Andrej Karpathy, a well-known AI researcher, in a short post describing a style of programming where you give in to the flow, accept what the model produces and paste error messages back until things work. He framed it as fine for throwaway weekend projects.

The term then escaped that narrow meaning. Today people use it for anything from a prototype built in a browser-based builder to a paying product assembled with an AI editor. Those are very different risk situations, which is why the definition matters less than the question of what your app actually holds.

Most setups follow the same loop. You describe a feature. The tool generates or edits files, often across the front end, a database and a few server functions. It runs a preview. You click around, notice something wrong, and describe the fix. Repeat until it looks right.

The tools differ in where they sit. Browser builders such as Lovable, Bolt and Replit generate and host the whole thing for you. AI editors and agents such as Cursor, Windsurf and Claude Code work inside a code repository on your machine. Component generators such as v0 produce interface code you paste into a larger project. What they share is that the feedback signal is visual: does it look and behave correctly?

Security failures are quiet. A missing permission check does not break a page, so the preview looks perfect while the hole sits open. Here is how the loop maps to risk.

The most important mechanism is the third row. When you test your own app you are logged in as the person who created everything, so every rule that should block someone else stays invisible. An open database table returns exactly the same rows to you as a correct one does.

The same effect shows up in iteration. If a request fails because a database policy is too strict, the fastest way to make the error disappear is to remove the policy. A model asked to make the error go away will sometimes do exactly that, and the app then works for everyone, including people you never intended.

It helps to separate two habits. In AI-assisted engineering, an experienced developer uses a model to write code faster and still reads, tests and owns what ships. In vibe coding proper, the person may not read the code at all. Both use the same tools. The difference is whether a human with the relevant knowledge reviews the output.

That is the core security question: not whether AI wrote the code, but whether anyone who understands access control, secrets and data exposure looked at it before real users arrived.

It is a poor fit, without added review, for anything that holds payment details, health records, identity documents or private messages. The next question, whether that is actually safe, is covered in our guide on whether vibe coding is safe.

• Founders validating an idea with a prototype that holds no real customer data.
• Internal tools used by a handful of trusted people, behind a login the company controls.
• Marketing sites, landing pages and simple content pages where nothing sensitive is stored.
• Experienced developers who use it as an accelerator and review the result.
• Learners exploring how software works, provided they treat the output as unreviewed.

You do not need to stop working this way. You need one extra step before real users. Test the app as a logged-out visitor and as a second ordinary account, and check that neither can see the first account's data. Then look for secret keys in the browser and confirm that every private table has access rules turned on.

For a Supabase-backed app, this query lists tables in the public schema that have Row Level Security switched off.

select tablename
from pg_tables
where schemaname = 'public'
  and rowsecurity = false;