What "Vibe Coding" Actually Is
The term vibe coding was coined by Andrej Karpathy in early 2025. He described a style of programming where you describe what you want in plain language and let an AI implement it. You feel the vibes, you do not read every line, you accept and move on. It went viral immediately.
And almost immediately, people started doing it wrong.
The misconception is that vibe coding means typing a sentence, watching code appear, and shipping it to production without thinking. That version produces apps that work for the first ten users and then collapse. It produces code with security holes, race conditions, missing error handling, and "AI slop" that nobody can maintain — including the AI that wrote it.
The reality is that vibe coding done well is a real discipline. It requires more thinking, not less. The thinking just happens at a different layer. Instead of writing every for-loop yourself, you spend that energy on architecture, prompts, verification, and decision-making. The AI does the typing. You do the thinking.
This article is about how to actually do that with Claude Code — Anthropic's official command-line tool for Claude. We have been using it daily for months across multiple production codebases. This is what works.
What Claude Code Actually Is
Claude Code is a CLI tool that lives in your terminal and gives Claude direct access to your filesystem, your git repo, and your shell. It is not a chat window. It does not require you to copy-paste code in and out. When you tell it to fix a bug, it reads the relevant files, makes the changes, runs the tests, and tells you what it did.
The difference matters more than people realize. When you copy code in and out of a chat, the AI is working with snippets and assumptions. When Claude Code works on your project, it sees the whole codebase. It can grep across files. It can read your existing patterns and match them. It can run your build and react to the actual errors. It can commit to your repo.
This is what makes it work for real software, not just toy examples.
The First 30 Minutes Matter Most
The biggest mistake people make with Claude Code is treating it like ChatGPT — open it up, type a request, get a response. That is fine for one-off questions. It is a disaster for multi-day projects.
The first 30 minutes you spend on a project determine the next 30 days. Skip the setup and you will pay for it later. Every. Single. Time.
The CLAUDE.md File
This is the most important file in your repo when working with Claude Code. It is a markdown file at the root of your project (or in any subdirectory) that Claude Code automatically reads at the start of every session. It is your project's instruction manual for the AI.
What goes in it:
- Project context — what is this app, who uses it, what is the business goal
- Tech stack — Next.js 16, Prisma, PostgreSQL, Tailwind, etc. Be specific about versions.
- Conventions — file naming, folder structure, error handling patterns, naming conventions
- What NOT to do — "Never use raw SQL, always use Prisma" or "Do not add new dependencies without asking"
- How to run things — build commands, test commands, deploy commands
- Known gotchas — that one thing you keep tripping over, document it
A good CLAUDE.md file is the difference between Claude understanding your project in seconds and Claude making bad assumptions for an hour. Spend time on it. Update it as the project evolves.
Set Up Your Stack BEFORE Writing Code
Pick your stack and commit to it before you start vibe coding. Do not ask Claude "what should I use?" — Claude will give you a reasonable answer, but it will not be your answer. You should know your tools.
Initialize the project. Set up the folder structure. Get a "hello world" running. Commit it. Then start vibe coding features on top of a known-good baseline.
Why? Because if you start with "build me a todo app from scratch with auth and a database," Claude will make 100 micro-decisions for you. Some will be fine. Some will be subtly wrong in ways you will not notice for weeks. By giving it a foundation, you constrain those decisions to ones you have already made.
Define Conventions Up Front
This is the part most people skip. Pick your conventions and write them down (in CLAUDE.md). Examples:
- Components live in
src/components/, organized by feature, not by type - API routes return JSON with shape
{ success: boolean, data?: any, error?: string } - All database queries go through Prisma — never raw SQL except in seed scripts
- Form validation uses Zod schemas defined alongside the form
- Error messages are user-facing and translatable; never expose stack traces
If you do not define these, Claude will pick reasonable defaults. They will be inconsistent with each other across files. You will end up refactoring later.
The Golden Rules of Vibe Coding
These are the rules we follow on every project. Break them and you will pay for it.
Rule 1: You Read Code Too — Not Just Claude
The temptation with vibe coding is to skip reading the code Claude writes. Resist it. You do not need to read every line, but you need to read enough to understand the shape of what changed. If you do not understand the change, you cannot maintain it later, you cannot debug it, and you have no way to know if Claude did something subtly wrong.
Practical rule: read the diff before you commit. If a change touches more than 200 lines, ask Claude to walk you through what it did before you accept it.
Rule 2: Small Tasks Beat Mega-Prompts
"Build me a complete user dashboard with charts, settings, billing integration, and notifications" is a bad prompt. Even if Claude can technically do it, the result will be a sprawling mess that is hard to verify and impossible to course-correct mid-build.
Break it down. "Add a settings page with these three sections." Then "wire up the email preferences toggle to save to the database." Then "add the billing tab with these three actions." Each task should be small enough that you can verify it in a minute or two. Each task should commit cleanly on its own.
This is how you stay in control. Big tasks remove your ability to course-correct.
Rule 3: Commit Often. Vibe Coding Without Git Is Suicide.
Git is your safety net. When vibe coding, you are accepting changes faster than you can fully verify them. You need to be able to undo. You need to know exactly what changed in the last 20 minutes.
Commit after every working unit of work. Use descriptive commit messages. Branch when you start something risky. If a session goes off the rails — and it will — you should be able to git reset --hard to a known-good state without losing more than 10 minutes of work.
Without this habit, vibe coding produces a tangle of half-working changes that you cannot separate or revert.
Rule 4: Test What Claude Builds — Don't Trust It Blindly
Claude is good. Claude is not perfect. The tests Claude writes for code Claude wrote are of limited value — same blind spots, same assumptions. You need independent verification.
For UI: actually click through the feature. Try edge cases. Try invalid input. Try the unhappy path.
For API: hit the endpoint with curl or a real client. Check the response shape. Check what gets written to the database.
For business logic: write tests yourself, or at least read the tests Claude wrote critically.
The bugs Claude introduces are usually not "the code does not work" — that you would catch immediately. The bugs are subtle: the wrong field gets updated, an edge case is ignored, an assumption gets baked in that breaks for users in a different timezone. You only catch those by exercising the feature.
Rule 5: Plan First, Code Second
For anything non-trivial, use Claude Code's plan mode (or just ask "before you make any changes, walk me through your plan"). Read the plan. Push back on it. Make sure Claude understands the actual requirement before it starts touching files.
This catches the misunderstandings before they become 500 lines of wrong code that you have to revert. Five minutes of planning saves an hour of cleanup.
Rule 6: Be Specific or Suffer
"Add auth" is a bad prompt. It will give you something. It will be wrong in a hundred small ways because Claude had to guess.
"Add JWT-based email/password authentication. Use bcrypt for hashing with 12 rounds. Store sessions in the database (not just JWTs) so we can revoke them. Endpoints: POST /api/auth/register, POST /api/auth/login, POST /api/auth/logout, GET /api/auth/me. Use the existing User model in prisma/schema.prisma. Match the error response shape used in the existing API routes." — That is a good prompt. Claude will get it right the first time.
The general rule: if you can describe it in five sentences instead of two, do it. The marginal effort on the prompt saves multiplicative effort on the cleanup.
Best Practices for Prompting Claude Code
Give Context, Not Just Commands
"Fix the bug in the login flow" is worse than "the login form returns a 500 error when the user enters a valid email but wrong password — I expect a 401 with a friendly message instead." The second tells Claude what you expect, not just what is broken.
Reference Specific Files
If you know where the code lives, say so. "Look at src/lib/auth.ts line 45 — the verifyPassword function" is way better than "find the password verification logic." You save a tool call and you remove ambiguity.
Tell Claude What You Already Tried
If you are iterating on a problem, give the context: "I tried setting CORS headers in next.config.js but it did not work — I think the issue is in the middleware." This prevents Claude from suggesting things you have already ruled out.
Ask for the Plan Before the Execution
"Before you make any changes, tell me how you plan to approach this. Then wait for me to confirm." This single habit will save you hours.
Common Pitfalls (And How to Avoid Them)
Pitfall 1: The "It Works!" Trap
You ask Claude to add a feature. Claude does it. The build passes. The page loads. You move on. Three days later, you discover that the feature only works for users created after a certain date because Claude assumed a database column existed that did not.
Fix: Test with real data. Test with edge cases. Just because something compiles and runs does not mean it is correct.
Pitfall 2: Rebuild/Refactor Loops
Claude makes a change. Something breaks. You ask Claude to fix it. Claude makes another change. Something else breaks. After 20 minutes, you have a tangle of unrelated edits and the original problem is still there.
Fix: When this happens, stop. Revert to the last known-good commit. Read what Claude was actually trying to do. Re-prompt with more context. Do not let Claude pile fixes on top of confused changes.
Pitfall 3: Over-Engineering
Claude loves abstractions. Ask for a simple function and you might get a generic factory class with three layers of inheritance "for flexibility." Ask for a config file and you get a plugin system.
Fix: Tell Claude explicitly: "Keep this simple. Do not add abstractions or extensibility I did not ask for." Put it in your CLAUDE.md so you do not have to repeat it every time.
Pitfall 4: Trusting Claude with Secrets
Never let Claude paste API keys, database passwords, or other secrets into committed files. Even if you tell it not to, it sometimes will. Always check the diff before committing if the change touches config files, .env files, or anything that might have credentials.
Pitfall 5: Vibe Coding a Codebase You Do Not Understand
If you have no idea what the code is doing, you cannot tell when Claude breaks something. You cannot course-correct. You cannot debug when things go wrong. Vibe coding only works when you understand the project well enough to spot when the AI is going sideways.
Fix: Read the code. Spend a session just reading and asking Claude to explain. Do not skip the learning step.
A Real Workflow Example
Here is what a productive session actually looks like — adding a new feature to an existing app.
Step 1: Set Context
I want to add a "saved articles" feature to the blog. Users should
be able to bookmark articles they want to read later and see them
on a dashboard page. Before you make any changes, walk me through
your plan: what files you will create, what database changes you
need, what API routes, and what UI components.Step 2: Review the Plan
Claude responds with a plan. You read it. Maybe you push back on something:
The plan looks mostly good but I do not want a separate
SavedArticle table. Use the existing UserBookmark model which
already supports bookmarks for any content type. Update your
plan accordingly.Step 3: Execute Incrementally
Good. Start by adding the API route to create a bookmark. Just
that one route. We will test it before moving on.Claude makes the change. You hit the endpoint with curl. It works. Commit.
Step 4: Continue, One Step at a Time
Now add the bookmark button to the blog post detail page. It
should toggle between bookmarked and not bookmarked.Claude makes the change. You click the button. It works. Commit.
Step 5: Build the Page
Now create the dashboard page that lists the user's bookmarks.
Match the design pattern from the existing dashboard pages.Claude makes the change. You navigate to the page. It works. You spot one styling inconsistency. You ask Claude to fix it. You commit.
Total time: 30-45 minutes. Result: a working feature that you understand, that follows your existing patterns, and that you can confidently extend later. That is what vibe coding looks like when it works.
Tools That Make Vibe Coding Better
- Plan mode — built into Claude Code. Forces Claude to outline its approach before touching files. Use it for anything non-trivial.
- The TodoList tool — Claude breaks complex tasks into trackable subtasks. You can see progress in real time and catch when something gets skipped.
- Subagents — Claude can spawn helper agents for parallel research or codebase exploration without polluting your main session.
- Hooks — Configure Claude Code to run validators, linters, or custom scripts after edits. Catch problems before they accumulate.
- Git worktrees — Run Claude Code in isolated worktrees for risky experiments. If it goes sideways, delete the worktree without affecting your main branch.
- CLAUDE.md memory files — Project-level, user-level, and global memory. Use them to teach Claude your preferences once instead of repeating yourself.
When NOT to Vibe Code
Vibe coding is a tool. It is not the right tool for everything. Here is when to put the AI down and write code yourself (or get a human to review):
- Production database migrations — these need to be reviewed line by line. A subtle mistake can corrupt data permanently.
- Authentication and payment code — these need a human security review even if Claude wrote them perfectly. The cost of a bug is too high.
- Codebases you do not understand — you cannot course-correct what you cannot read.
- Throwaway scripts — if you just need a 10-line bash script, ask Claude in chat. Do not bother starting a Claude Code session.
- Anything with regulatory implications — HIPAA, PCI, GDPR. Vibe-coded compliance is not compliance.
- Performance-critical code — Claude writes correct code, but not always fast code. If milliseconds matter, write it yourself or profile carefully.
The Bottom Line
Vibe coding done right is the biggest productivity gain in software development since version control. We routinely ship features in hours that used to take days. We build apps in weekends that used to take months.
Vibe coding done wrong is a productivity disaster. It produces code nobody can maintain, bugs nobody can debug, and apps that work demos but break in production.
The difference is discipline. The discipline lives in the setup (CLAUDE.md, conventions, project structure), the process (small tasks, commits, planning, verification), and the judgment (knowing when to use it and when to step back).
Claude Code is the best tool we have for this in 2026. But the tool is not the magic. The magic is in how you use it. Take the setup seriously. Follow the rules. Verify everything. And you will ship more software, of higher quality, faster than you thought possible.
If you are not getting those results, the issue is not the AI. It is the workflow. Fix the workflow.