What Is Vibe Coding, Really?

The term "vibe coding" spread fast in 2024-2025 because it names something a lot of developers were already doing quietly: describing what they want in plain English to a model like GPT-4, Claude, or a tool like Cursor or GitHub Copilot, and letting it generate most of the actual code. The programmer stays in the loop, but the loop looks different from traditional coding.

The actual definition

Andrej Karpathy coined the phrase, describing a workflow where you "fully give in to the vibes" — you prompt, accept suggestions, run the code, see what breaks, and prompt again. You're not reading every diff line by line. You're steering by outcome: does the app do the thing, does the test pass, does the page render correctly. The skill shifts from writing syntax to describing intent clearly and recognizing when output is wrong.

This is different from just using autocomplete. Copilot-style inline suggestions still assume you're writing the function yourself with some help finishing lines. Vibe coding assumes the model writes the function, the file, sometimes the whole feature, and you're reviewing and redirecting rather than authoring from scratch.

What a real session looks like

A typical vibe-coding loop with a tool like Cursor or Replit's Agent mode goes something like this:

1. Prompt: "Add a rate limiter to this Express API, 100 requests per 15 minutes per IP, return 429 with a JSON error body."
2. The model edits middleware/rateLimit.js, wires it into app.js, maybe pulls in express-rate-limit.
3. You run npm test or hit the endpoint with curl in a loop to check the 429 actually fires.
4. Something's off — the limiter resets on every deploy because it's in-memory. You say so.
5. The model swaps in a Redis-backed store, adds the ioredis dependency, updates the docker-compose file.
6. You re-test, it works, you commit.

No line of that middleware was typed by hand. But six or seven judgment calls were made by a human: what the limit should be, that in-memory storage was wrong for production, that the docker-compose file needed updating too.

Where it works well

Vibe coding is strong for boilerplate-heavy work: CRUD endpoints, form validation, test scaffolding, config files, glue code between two APIs you already understand. It's also good for prototyping — spinning up a working demo of an idea in an hour instead of a day, then deciding if it's worth building properly.

It's genuinely fast for solo devs and small teams shipping internal tools or MVPs where the cost of a bug is low and iteration speed matters more than architectural purity.

Where it breaks down

The failure mode people don't talk about enough: models produce code that runs but is subtly wrong in ways that don't show up until later. A generated SQL query might work for the happy path but be vulnerable to injection because string concatenation looked fine to the model. A generated auth check might pass tests but skip a role check on one route. If you're not reading the code, you won't catch that — you'll just see the tests pass and ship it.

This matters more in security-sensitive code than almost anywhere else. Simon Willison and others have pointed out that vibe-coded projects with real user data need the same review rigor as any other code, arguably more, because the person who "wrote" it may not be able to explain what it does line by line.

Complex systems with a lot of implicit state — concurrency, distributed transactions, anything with subtle timing bugs — are also a bad fit. Models tend to generate plausible-looking code for these cases that fails in ways that are hard to debug precisely because nobody, human or model, fully modeled the edge cases up front.

The skill that actually matters now

If you're vibe coding, the valuable skill isn't typing speed, it's specification. Vague prompts get vague, buggy code. Specific prompts — with exact library names, error-handling expectations, and edge cases called out — get much better output. The second most valuable skill is reading code fast enough to catch what's wrong, which means you still need to understand the language and the domain even if you're not typing every character.

Treat AI-generated code the way you'd treat a pull request from a junior dev who's fast but occasionally overconfident: useful, often correct, but worth an actual review before it touches production.

Want to go deeper on writing code with AI tools without losing control of quality? Check out Korra Studio's AI and Python segments for hands-on walkthroughs.