On 2 February 2025, Andrej Karpathy, a founding member of OpenAI and former head of AI at Tesla, posted a few lines on X about how he'd been building small projects lately. He called it "vibe coding": a kind of coding where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." He'd describe what he wanted, accept what the AI wrote, paste error messages back in when something broke, and mostly stop reading the code.
He later described it as a throwaway shower-thought post. It became the name for a whole way of building. By November, Collins Dictionary had chosen "vibe coding" as its Word of the Year for 2025, citing a huge rise in use since it first appeared in February.
What it means in practice
Vibe coding is building software by describing it in plain language to an AI tool and judging the result by whether it works, rather than by reading the code.
For a founder that might mean opening Lovable, Bolt, Replit or Base44, typing "a booking app for dog groomers with Stripe payments and a calendar", and iterating in conversation until it does what you want. For a developer it might mean letting Cursor or Claude Code write whole features while they review the behaviour instead of each line.
It works, which is why it spread so quickly. In March 2025, Y Combinator managing partner Jared Friedman said a quarter of the startups in its Winter 2025 batch had codebases that were about 95% AI-generated. He was careful to add that these founders were highly technical and could have written the code themselves. They chose not to, because the AI was faster.
What it skips
When software took weeks to write, it went past other people before it shipped. A colleague reviewed the pull request. Someone asked "wait, can any user call this endpoint?" Not every team did this well, but the slowness created room for a second look.
Vibe coding removes that room. One person, one afternoon, one working feature. The feature is judged on whether it works, and it nearly always does.
Security problems are exactly the kind that don't show up that way. A missing check on who can read a record has no symptom. The page loads, the test passes, the demo goes fine. It only shows up when someone who isn't you changes an ID in a request, and by then it's in production.
There's research on this. A Stanford study published at the ACM CCS conference in 2023 found that people using an AI assistant wrote significantly less secure code than people without one, and were more likely to believe their code was secure. Veracode's ongoing tests of 150+ models find AI picks the insecure option in about 45% of tasks, a number that hasn't improved as models got better at writing code that runs.
What that looks like when it goes wrong
The most common failure in vibe-coded apps is a plain one: the database answering questions it shouldn't. Apps built on Supabase or Firebase talk to the database straight from the browser, and they're only safe when access rules on each table are written correctly. The AI writes the features you ask for. The rules are the part nobody asked for.
That's the root of the 170 leaking Lovable apps found in 2025, and of Moltbook's exposed database in 2026. The second most common is a paid API key left where the browser can read it, which is how one founder's fully AI-built SaaS was drained two days after launch.
So should you vibe code?
If it gets you to a working product, yes. The speed is real, and waiting until you can afford a team is often the worse risk.
Just put back the step it removes. Before real users and real data arrive, have someone, or something, look at the app the way a stranger would. That can be you with our pre-launch checklist and an afternoon. It can be your AI tool, asked specifically to review access control rather than to "check security". Or it can be an independent check of the live app. What matters is that somebody looks, since the AI won't do it unless you ask.