In February 2025, Andrej Karpathy posted about a new way he was writing software. He described it as fully giving in to the vibes and forgetting the code even exists. He called it vibe coding. By November that year, Collins Dictionary had named it word of the year.
The term stuck because it named something millions of people were already doing. You open an AI tool, describe the app you want, and it appears. Most people never look at the code. This post explains what vibe coding is, which tools people use for it, where it goes wrong, and how to keep the speed without shipping a mess.
What vibe coding actually means
Vibe coding is building software by describing it to an AI and judging the result by running it, not by reading it.
The loop goes like this. You type "make me a habit tracker with a streak counter." The AI writes the code. You run it. Something is off, so you paste the error back in, or you say "the streak resets at the wrong time." It changes something. You run it again. You repeat until it looks right.
What makes it vibe coding, and not just AI-assisted coding, is that you accept the code without fully understanding it. You are steering by feel. Karpathy was clear that this works for throwaway weekend projects. He was not describing how to build a bank.
That distinction is the whole story. The same tools that build a weekend toy in an hour can also build a production app. The difference is not the tool. It is what you do between prompts.
Why it took off
Three things changed at once.
- Models got good at whole tasks. They can now write a full feature across several files, run it, read the error and fix it, without you pasting things back and forth.
- Tools started acting, not just suggesting. Coding agents can create files, install packages and run tests on their own. You describe the goal, and they work through the steps.
- The barrier dropped to zero. A college student in Chennai with a laptop and a browser can have a deployed app by evening. Two years ago that took a semester of web development.
For students and career switchers, that last point matters most. You can now build things that look like a real product long before you could write them by hand. That is a real advantage, as long as you keep learning what is happening underneath.
The three kinds of vibe coding tools
People say "vibe coding tools" as if they are one category. They are three, and they suit different people.
App builders in the browser
You type a description, and you get a running web app with a preview, often with hosting and a database wired in. These are the fastest way from idea to something you can click. They are best for prototypes, landing pages and internal tools. They get harder to use once your app needs custom logic or you want to move the code elsewhere.
AI code editors
An editor such as Cursor looks like a normal code editor with an AI agent built in. You see every file, every change as a diff, and you can edit by hand at any moment. This suits people who are learning to code, or who already code and want to go faster without losing sight of the code. We compare it with a terminal agent in Claude Code vs Cursor.
Coding agents in the terminal
Claude Code and OpenAI's Codex run in your terminal (and in IDE extensions and desktop apps). You give them a task, and they read your project, plan, edit files, run commands and report back. They shine on real projects with many files, tests and a Git history. If you are choosing between the two, read Codex vs Claude Code.
Most working developers end up using two of these: a fast builder or editor for exploring, and an agent for the heavy lifting.
Where vibe coding goes wrong
The failures are predictable. Almost every messy AI project hits the same five.
- Nobody knows how it works. After fifty prompts the code has three ways of doing the same thing, and neither you nor the AI can say which one is used. Every new change breaks something old.
- Secrets in the wrong place. API keys pasted into front-end code, a database open to anyone with the URL, passwords in a public GitHub repo. AI tools will do this if you do not tell them not to, and you will not notice if you do not read the code.
- It works on the happy path only. The demo works when you type the right input. Empty fields, slow networks, two users at once and wrong passwords were never tried.
- The fix loop. You paste an error, the AI changes something, a new error appears, you paste that. An hour later the code is worse than when you started, and the context is full of failed attempts.
- No history. Without Git, there is no way back to the version that worked yesterday.
None of these are model problems. A smarter model will not fix the fact that nobody planned the app, reviewed the code or tested it.
How to vibe code without shipping a mess
You do not have to give up the speed. You add four habits around it. This is the workflow we teach, and it works with any of the tools above.
1. Plan before you prompt
Before you ask for code, write down what you are building: the screens, the data, what "done" looks like, and what is out of scope. Half a page is enough. Better still, ask the AI to interview you until it can write the spec, then save it as a file. Most agents have a plan mode that researches and proposes a plan without touching your code. Use it for anything bigger than a small fix.
2. Keep a context file
Every coding agent reads a project instruction file at the start of a session: CLAUDE.md for Claude Code, AGENTS.md for Codex and others, rules files in Cursor. Put in what the AI cannot work out by reading the code: how to run the tests, which folders never to touch, decisions you made and why. Keep it short. This is the core of context engineering.
3. Review every diff like an engineer
Read what changed before you accept it. You do not need to understand every line on day one, but ask three questions each time:
- Did it change files I did not expect?
- Did it add a package, a key or a network call I did not ask for?
- Can I explain, in one sentence, what this change does?
If the answer to the last one is no, ask the AI to explain it. That is how vibe coders turn into developers.
4. Test, commit, then ship
Ask the agent to write tests for what it built and run them. Commit to Git after every working step, so you can always go back. Deploy only from a version that passed its tests. If something breaks in a loop twice, stop, start a fresh session and write a better prompt instead of a third correction.
Speed is the AI's job. Judgement is yours. Keep both and you can ship.
When to vibe code and when not to
A simple rule: the more it can hurt someone when it breaks, the less you should vibe.
| Go ahead and vibe | Slow down and review properly |
|---|---|
| Prototypes to test an idea | Anything that takes payments |
| Personal scripts and tools | Login, passwords and user data |
| Hackathon demos | Apps other people rely on daily |
| Learning a new framework | Code you will maintain for months |
| Throwaway data analysis | Anything touching health, money or legal records |
The left column is where vibe coding is a superpower. The right column is where the four habits above stop being optional.
What this means if you are learning to code
Some students ask whether learning to code still matters. It matters more, just differently. You will write fewer lines by hand. You will read, review and direct far more code than any developer did five years ago. The skills that decide whether you ship are planning, reading code, Git, testing and debugging.
Our advice to students in India preparing for placements: vibe code freely to build things, then go back and make sure you can explain every part of what you built. Interviewers will ask. Pick a project from 10 AI projects for students and build it this way. If you want the full path, our AI engineer roadmap puts the skills in order.
If you want to see this workflow done live, come to our free Saturday workshop. We build a small app from a blank folder with plan, context file, review and tests, and you can ask questions as we go. Save a seat for this Saturday.