What is vibe coding? Meaning, examples and what to check before launch

Vibe coding is building software by describing what you want to an AI tool in plain language and accepting the code it generates, often without reading it line by line. You steer by testing the result and asking for changes, not by writing the code yourself.

The term comes from AI researcher Andrej Karpathy, who posted on Feb 2, 2025 (external): "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."

By Gary, Greenlight · Last checked: Oct 19, 2026 · Drafted with AI tools and reviewed before publishing.

How vibe coding works

A typical loop looks like this:

1. Describe it. "Build a booking page with a calendar and email confirmations."
2. Let the AI build it. The tool writes the files, installs packages and often sets up a database.
3. Try it. Click around in the preview.
4. Ask for fixes. Paste the error or describe what's wrong, and let the AI change the code.
5. Repeat until it feels right, then publish.

The key difference from normal coding: the person usually judges the app by how it behaves, not by reviewing the code.

Vibe coding vs. AI-assisted coding

Many people move along this line: they vibe code a first version, then start reviewing the parts that handle logins, data and payments.

Tools people use for vibe coding

Common examples include app builders like Lovable, Bolt.new and Replit, and AI code editors like Cursor. Many of these apps store data in Supabase and deploy to hosts like Vercel. (Examples only; we're not affiliated with any of them and this isn't a ranking.)

What vibe coding is good at

• Speed to a first version. An idea can become a clickable app in an afternoon.
• Non-developers can build. Founders, designers and operators can make their own tools.
• Cheap experiments. You can try an idea and throw it away without much cost.

Where vibe coding falls short

• You may not know what's in the code. That's the point, but it also means you can't easily tell what the app exposes.
• Fixes can break other things. Each new prompt can change code you didn't ask about.
• Preview settings aren't always launch settings. A setting that's fine while you experiment, like a database table without access rules or a key placed in frontend code, can stay that way when you publish.

None of this means a builder is unsafe. These are settings the person building the app controls, so the person publishing it owns the final check.

Is vibe coding safe for a real launch?

It can be, if you check the basics before real users and real data arrive. The most common gaps are settings that were left off, not exotic attacks:

• Database access rules off. If you use Supabase, Row Level Security (RLS) needs to be on, with policies, for every table holding private data. See what Supabase RLS is.
• Secret keys in the frontend. Anything shipped to the browser can be read by anyone. The Supabase anon key is public by design; a service role key is not (what to do if it leaked).
• Files that shouldn't be public. .env files, .git folders and source maps sometimes end up on the live site.
• Missing HTTPS or security headers. Easy to fix, easy to forget. Check with our security headers checker.
• Out-of-date frameworks. Keep dependencies current; see our Next.js security update post.

A quick pre-launch checklist

1. Run your builder's own security scan, if it has one, and fix critical findings.
2. Turn on RLS for every table with private data, then test with two of your own accounts that one can't see the other's data.
3. Move every secret key to server-side settings (secrets or environment variables that never reach the browser).
4. Make sure logins and permission checks happen on the server, not only in the UI.
5. Check the live site from the outside: HTTPS, headers, exposed keys and files.

If you code with an AI agent in your terminal, see Claude Code permissions and sandboxing.

FAQ

What is vibe coding in simple terms? Building an app by telling an AI what you want in plain language and accepting the code it writes, judging it by how it works rather than by reading the code.

Who coined the term vibe coding? Andrej Karpathy, in an X post on Feb 2, 2025.

Do you need to know how to code to vibe code? No, to get started. Knowing a little helps when something breaks, and someone should understand how logins, data access and keys are set up before a public launch.

Is vibe coding the same as using an AI coding assistant? Not quite. With an assistant, a developer usually reviews the code. In vibe coding, the code often isn't reviewed at all.

Can a vibe-coded app go to production? Yes, but check the launch basics first: database access rules, secret keys out of the frontend, server-side permission checks, HTTPS and headers.

What does Greenlight's free scan check? From the outside only: HTTPS, security headers, exposed .env and .git files, public source maps, and secret keys in your homepage's scripts. If it finds a Supabase project and its public key there, it counts which tables return rows to that public key (it reads no row data). It doesn't log into your builder or Supabase, read your code repository or RLS policies, or test logins and app logic.