Vibe coding is building software by describing what you want to an AI in plain language and accepting the code it writes, often without reading it. You judge the result by running it, not by reviewing it.
Andrej Karpathy, an OpenAI co-founder and former director of AI at Tesla, coined the term in a post on X on 2 February 2025. He described a style where you "fully give in to the vibes" and "forget that the code even exists", and he framed it as fine for "throwaway weekend projects". The phrase spread so quickly that Collins Dictionary named it its Word of the Year for 2025.
My view is simple: vibe coding is excellent for prototypes, internal tools and learning, and dangerous for production systems, because unreviewed AI code regularly ships with security holes. The answer is not to give up the AI. It is to put tests, review and small diffs around it, and the second half of this article is a workflow for doing exactly that.
Three things people mean by "vibe coding"
In Karpathy's original sense, vibe coding meant talking to an AI tool, accepting all of its changes, pasting error messages back in when something broke, and never reading the diffs. The term has stretched since, and it now covers three quite different activities:
- The strict sense: you don't read or understand the code. You only check whether the app works.
- The loose sense: any AI-assisted coding where prompts replace most of the typing.
- The product sense: non-developers building apps with prompt-to-app tools such as Lovable, Bolt or v0.
The distinction matters because the risk is completely different. A senior developer who uses an AI agent and reviews every diff is not vibe coding in the strict sense. A founder who ships a payment app without reading a line of it is. AI-assisted coding is the broad category; vibe coding is the end of the spectrum where you stop reading and trust the output.
What the loop looks like
The workflow is short and conversational:
Describe the feature in plain English
↓
AI tool plans and writes or edits the code
↓
Run the app and look at the result
↓
Paste errors back, or describe what to change
↓
Repeat until it "feels right"
↓
Deploy
Modern tools run most of that loop on their own. A coding agent can read your project, edit several files, run the build, read the error and try again before it reports back. That is why vibe coding became practical in 2025: the agent absorbs the fix-run-fix cycle that used to need a human at every step.
The tools, and who each one suits
There are two families. Coding agents work inside a real codebase and suit developers. App builders go from a prompt to a hosted app and suit people who don't want a local setup at all. All of these are actively developed as of October 2026.
Tool | What it is | Where it runs | Best fit |
|---|
Claude Code | Coding agent by Anthropic | Terminal, IDE extensions, desktop and web | Existing repositories, multi-file changes, running tests and commands |
Cursor | AI-first code editor | Desktop editor based on VS Code | Developers who want the agent inside the editor with inline diffs |
GitHub Copilot | Agent mode in the IDE, plus the Copilot cloud agent | VS Code, Visual Studio, JetBrains and others; the cloud agent works from GitHub issues | Teams already on GitHub; the cloud agent turns an issue into a pull request for review |
Replit | Browser IDE with Replit Agent | Browser, with built-in hosting and database | Building and deploying a full app with no local setup |
Lovable | Prompt-to-app builder | Browser; integrates with Supabase for database and auth | Founders and non-developers building full-stack MVPs |
Bolt (bolt.new) | Prompt-to-app builder by StackBlitz | Browser, with the dev environment running in the tab | Fast web prototypes you can export and own |
v0 | Prompt-to-UI and app builder by Vercel | Browser, deploys to Vercel | React and Next.js interfaces, landing pages and front ends |
If you work in an existing codebase, start with Claude Code, Cursor or Copilot. If you are building a new web app and can't or won't code, Lovable, Bolt, v0 and Replit are the usual starting points. Either way, give two of them the same small task and keep the one whose output you can actually maintain. Pricing and model limits change often, so check the vendor's page before committing.
Where it works, and where it falls apart
Vibe coding earns its place when the code is cheap to throw away or cheap to check. A prototype you need to demo this week, a dashboard for five colleagues behind the company login, a script that renames files or scrapes your own data: if any of these is wrong, you notice quickly and nobody gets hurt. It is also a fast way to learn an unfamiliar framework, provided you read the working example afterwards, and a good way to try five UI layouts in an hour instead of one in a day. Boilerplate inside a well-tested codebase is fine too, because the existing tests catch mistakes immediately.
It falls apart in the places where "it runs" tells you nothing:
- Anything touching money, health or personal data, where a bug is a breach or a legal problem rather than an inconvenience.
- Authentication and authorization. The app looks like it works, but any user can read any other user's data.
- Large, long-lived codebases. Each prompt adds code in a slightly different style, and after a few months nobody, the AI included, understands the whole.
- Performance. Code that works for ten rows can make a database call per row and fall over at ten thousand.
- Deep bugs. When the AI can't fix something after several attempts and you can't read the code, you are stuck.
The security record so far
The risks are not hypothetical. Three incidents and studies from 2025 show the pattern.
Generated code is insecure by default
Veracode's 2025 GenAI Code Security Report tested more than 100 LLMs on 80 coding tasks. In 45% of the test cases, the generated code contained a vulnerability from the OWASP Top 10, with cross-site scripting and log injection handled especially badly. The models produce code that runs, and running is the only thing a vibe coder checks.
App builders leave the database open
CVE-2025-48757 described insufficient Supabase row-level security (RLS) in apps generated with Lovable, which could let unauthenticated users read or write data. The CVE is marked as disputed and the platform has since tightened its defaults, but the lesson applies to every app builder: the database rules are your responsibility, not the tool's.
Agents get too much power
In July 2025, SaaStr founder Jason Lemkin reported that the Replit agent deleted a live production database during an experiment, despite instructions to freeze changes. Replit's CEO responded by adding safeguards such as separating development and production databases. The root cause wasn't the model. It was handing an agent write access to production.
Beyond those headline cases, the everyday problems are duller but more common: API keys hard-coded into front-end files or committed to Git, deprecated APIs pulled from older training data, no tests at all, and customer data or proprietary code pasted into tools the company never approved. The nastiest is the invented package, where the AI suggests a dependency that doesn't exist and an attacker registers that name with malicious code.
What comes after vibe coding
By early 2026 Karpathy was describing the next step as "agentic engineering". AI agents still write most of the code, but you act as the engineer who directs, constrains and verifies them. The argument is laid out well in The Death of the Vibe Coding: Why Agentic Engineering Is the New Standard.
Spec-driven development is a close relative: you write a specification first and the agent implements against it. GitHub's open-source Spec Kit and AWS's Kiro IDE are both built around that idea.
Aspect | Vibe coding | Agentic engineering | Spec-driven development |
|---|
Starting point | A prompt | A task with clear constraints | A written spec and plan |
Who reads the code | Nobody, in the strict sense | The engineer reviews every diff | The engineer reviews against the spec |
Verification | "It seems to work" | Tests, CI, code review | Acceptance criteria from the spec, plus tests |
Speed to first demo | Fastest | Fast | Slower start, fewer rewrites |
Fit for production | Poor | Good | Good, especially for larger features |
Skill needed | Low | Real engineering skill | Engineering plus product thinking |
These are stages, not rival camps. A sensible pattern is to vibe code the prototype, then rebuild the version you keep with a spec and proper review.
A workflow that keeps the speed and drops most of the risk
None of these habits is expensive, and together they close the gaps that caused the incidents above.
1. Write a short spec before the first prompt
Five to ten lines is enough: what the feature does, who uses it, what data it touches, and what "done" means. Paste it into the chat or into a file the agent reads. This alone stops most of the wandering.
2. Give the agent project rules
Most coding agents read an instructions file from the repository: CLAUDE.md for Claude Code, AGENTS.md for many other tools, or Cursor rules. Put your non-negotiables there.
# Project rules for AI agents
- Stack: ASP.NET Core 10 API + React (Vite). Do not add new frameworks.
- Never hard-code secrets. Read them from environment variables.
- Every database query must filter by the current user's tenant ID.
- Use parameterised queries only. No string-built SQL.
- Add or update tests for every change. Run `dotnet test` and `npm test` before finishing.
- Do not touch files under /infra or run migrations against production.
3. One change at a time, on a branch
Ask for "add the signup form", not "build the whole app", and commit after each working step so you can always roll back.
git switch -c feature/signup
# ...one prompt, one change...
git diff --stat # how much did it touch?
git add -p # stage only what you understand
git commit -m "Add signup form with validation"
If a single prompt changed twenty files, stop and ask why. Big diffs hide bugs.
4. Let tests do the checking you aren't doing
Ask the agent to write the tests first, then make them pass. For web apps, an end-to-end test proves the feature works the way a user sees it, and Playwright is a good fit; What Playwright Does for Vibe Coders and How to Use It Effectively goes into the details.
import { test, expect } from '@playwright/test';
test('new user can sign up and reach the dashboard', async ({ page }) => {
await page.goto('http://localhost:3000/signup');
await page.getByLabel('Email').fill('[email protected]');
await page.getByLabel('Password').fill('S3cure-Passw0rd!');
await page.getByRole('button', { name: 'Create account' }).click();
await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();
});
Watch test changes closely. A common failure is the AI "fixing" a failing test by rewriting the test.
5. Test access control yourself
"Login works" does not mean "data is protected". Sign in as user A and try to load user B's records. On Supabase, check that the public key cannot read a protected table:
curl "https://YOUR-PROJECT.supabase.co/rest/v1/profiles?select=*" \
-H "apikey: YOUR_PUBLIC_ANON_KEY" \
-H "Authorization: Bearer YOUR_PUBLIC_ANON_KEY"
# Expected: [] or a permission error. Other users' rows = broken RLS.
6. Review the sensitive parts of every diff
At minimum, read the code that touches auth, payments, data access and anything public. If you can't read code, get a developer to review before launch. A second AI session asked to review the diff for security issues catches a surprising amount, but it doesn't replace a human on critical paths.
7. Automate the safety net
- Run tests and a linter in CI on every push.
- Turn on secret scanning and dependency alerts (GitHub offers both).
- Add a static analysis tool such as CodeQL or Semgrep.
- Before installing any new dependency, check that it exists and is maintained.
8. Keep agents away from production
Agents get development databases and test credentials, nothing more. Deployments go through CI, not through the agent. Back up production and test the restore.
When the loop stops working
Two failure modes catch almost everyone. The first is looping on the same error: after two or three failed attempts, stop, revert, and either describe the problem differently or read the code yourself. The second is deploying the prototype. A demo that impressed investors is not production code, so plan a hardening pass before real users and real data arrive.
None of this means developers are about to be replaced. Writing code is getting cheaper, while specifying, reviewing, testing, securing and operating software is becoming a larger share of the job. Treat AI output like code from a fast but careless junior developer: enjoy the speed, then test it, scan it and read the parts that matter.
Join the conversation! Your thoughts help the community grow.