Vibe coding

Where the term comes from

The phrase was introduced by Andrej Karpathy in a post on X on 2 February 2025. He described a way of working in which you "fully give in to the vibes" and "forget that the code even exists": you tell the AI what you want, accept its changes without reading the diffs, paste error messages straight back in and work around problems the model cannot fix. By his own account this was fine for throwaway weekend projects, as summarised in Simon Willison's write-up.

The term then spread to cover almost any app built mainly by prompting an AI tool. That wider use is why it matters for security. A prototype that only you will ever open is one thing. A public product that stores other people's data is another, and the same habits are much riskier there.

Vibe coding versus AI-assisted programming

Using an AI assistant is not automatically vibe coding. Simon Willison draws the line at review: building software with an LLM without reviewing the code it writes is vibe coding, while code you have read, tested and could explain to somebody else is ordinary software development that happens to use a helpful tool.

For a beginner there is a simple test. Could you explain what this change does, which data it touches and which secrets it needs? If the answer is no, you are vibe coding, and the safety net has to come from somewhere other than your own reading: a checklist, automatic scanners, a server account with few rights and a small blast radius. The least privilege and containment entries explain the last two ideas.

Why unreviewed code is a security problem

Nobody reads the parts that fail quietly. Five places to look first:

• Secrets. Keys pasted into source files end up in git. See secrets management and the guide on what to do after a leaked API key.
• Data access. Supabase warns that a table in an exposed schema without RLS is readable and writable by any role with a grant. See row-level security.
• Dependencies. Models can invent package names, which attackers can register: slopsquatting.
• Queries. SQL built from strings is open to SQL injection.
• Agents. Tools that read untrusted text can be steered by prompt injection.

None of these is exotic. Each is a basic check that code nobody reads never gets, and each can be done in minutes before launch rather than after an incident.

How to ship a vibe-coded app more safely

You do not have to stop using AI to build. You have to add checks the AI will not add for you:

1. Go through the vibe coding security checklist before every launch.
2. Give the assistant written rules, as in AI coding assistant security rules, and limit what an agent may run, as in the AI coding agent safety guide.
3. Keep keys out of the repository and out of the browser code.
4. Deploy to a server with an unprivileged user, a firewall and TLS: deploy an app to a VPS securely.
5. Plan for failure with a 3-2-1 backup and an incident response plan.

The risk grows with the number of users and the sensitivity of their data, so the review should too. For a personal prototype the first three steps are a reasonable minimum, while a product with payments or personal data needs all five.

Related terms: Secrets management, Row-level security (RLS), Slopsquatting, Prompt injection, Least privilege.