What is Vibe Coding? A Practical Guide from a Full-Stack Developer

In February 2025, Andrej Karpathy posted something on X that blew up. He described a new way of coding where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." He called it "vibe coding."

Karpathy is a co-founder of OpenAI and former head of AI at Tesla. He wasn't joking — he was describing his real experience building a project called MenuGen using Cursor Composer and voice input. He barely touched the keyboard. His exact words: "I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works."

My first reaction was: sounds like hype. Then I tried it myself. Honestly? It's kind of insane.

The basics

Vibe coding is simple in concept. Instead of writing code line by line, you describe what you want in plain language, and AI generates the code for you. Your role shifts from "person who writes code" to "person who describes what they want."

Here's a concrete example. Say you want a user registration page. The old way: build the form component, write validation logic, connect to the backend API, handle error messages, make it responsive. Every piece, you write yourself.

The vibe coding way: you tell the AI, "Build me a registration page with email validation, password strength indicator, optional phone number field, using Tailwind CSS, style it like Linear's login page."

The AI generates it. It might not be perfect, but it runs. You tweak from there.

Karpathy's original description had a telling detail — he said he hit "Accept All" on every suggestion without reading the diffs. When he got errors, he just pasted them back in, and "usually that fixes it." The code grew beyond his comprehension, and he didn't care.

That's the essence of vibe coding: you care about results, not process.

But Simon Willison (co-creator of Django) drew an important line: "If an LLM wrote every line of your code, but you've reviewed, tested, and understood it all, that's not vibe coding — that's using an LLM as a typing assistant."

The real question is: do you actually understand what the code is doing? True vibe coding, as Karpathy described it, means you don't need to. As long as it works.

How did this term blow up?

Karpathy coined it in February 2025. By March, Merriam-Webster listed it as "slang & trending." By the end of the year, Collins Dictionary named it the 2025 Word of the Year. Search interest surged 6,700% that spring.

Why so much buzz? Because it named something tons of people were already doing but didn't have a word for.

Think about it — by late 2024 and early 2025, tools like Cursor, GitHub Copilot, and Windsurf had already trained many developers to describe what they want instead of writing code from scratch. Most of the time you just accepted what the AI gave you, tweaked it a bit, and moved on. Karpathy just gave it a name.

By July 2025, the Wall Street Journal reported that vibe coding had been adopted by professional software engineers for commercial use cases. Not a toy anymore.

The controversy came too. Andrew Ng criticized the name in June 2025, saying it misleads people into thinking software engineers just "go with the vibes." He argued the actual work of using AI coding tools is far more complex and exhausting than the name suggests.

Call it what you want — the trend is irreversible.

My own experience

Let me talk about what actually happened when I built this site (totb0311.site).

Roughly 70% of the code was AI-generated. I understand most of it, but I didn't write it line by line. My workflow looked like this:

Describe the feature I want to the AI
AI generates the code
I glance at it — looks reasonable? Ship it
Doesn't work? Paste the error back
Repeat a few times, done

One time was wild. I needed to add a multi-language switching feature to the site. Normally this would take half a day — routing, middleware, language files, URL rewriting, a bunch of moving parts. I told Claude Code: "Add Chinese/English switching to the site. Chinese routes use /zh prefix, English uses root path."

It just went to work. Read my project structure, understood Next.js App Router, created language files, modified middleware, built the language switcher component. About ten minutes later, the feature was working. All I did was: describe what I wanted, check the result, say "this part's wrong."

But I also had my share of failures.

One time I asked it to refactor a database query, saying "optimize the performance." It confidently rewrote a bunch of stuff. I glanced at it, seemed fine, committed. Next day I found out a page was loading three times slower — it had removed an index optimization because it "looked redundant."

Another time was almost funny. I asked it to add search functionality to the article list page. It added it, worked fine, but I noticed searching for "Python" gave wrong results. Took me a while to figure out — it had written the search logic to fuzzy-match only the first 10 characters of the title. I have no idea how it "understood" the task that way, but the code did run. The logic was just completely wrong.

After these incidents I learned: vibe coding isn't about not reading code — it's about being selective. Critical paths (database, auth, payment) need human review. UI and auxiliary features? You can go with the vibes.

Vibe coding vs. traditional AI-assisted coding

Some people might ask: isn't GitHub Copilot basically the same thing? What's the difference between AI code completion and vibe coding?

The difference is huge.

Traditional AI-assisted coding (like Copilot's autocomplete) works like this: you write code, AI guesses what you'll write next and offers suggestions. You're still the driver, AI is the copilot. If you don't write, it doesn't suggest.

Vibe coding flips this: you describe what you want, AI writes the code, you review the output. AI is the driver, you're the supervisor. Once you describe something, the AI implements the entire feature — not just one line.

A metaphor: traditional AI-assisted coding is you driving with a copilot who occasionally says "turn left up ahead." Vibe coding is you telling a taxi driver "take me to the airport" — they drive, you only speak up when they go the wrong way.

There's also a key difference in context range. Copilot's autocomplete usually only looks at the current file. Vibe coding tools (Cursor Composer, Claude Code) read the entire codebase — they understand project structure, dependencies, existing patterns, and make decisions within that broader context.

So vibe coding isn't "better autocomplete." It's a fundamentally different way of working. You shift from "person who writes code" to "person who manages AI writing code."

The tool landscape

The vibe coding tool ecosystem in 2026 is pretty mature. I've used all the major ones, here's what I actually think.

IDE tools: Cursor and Windsurf

Cursor is a VS Code fork with deep AI integration. Its Composer mode can edit multiple files simultaneously, read the entire codebase, and even run terminal commands. $20/month for Pro is enough for most people.

I use Cursor most for modifying existing code. Say I want to add a feature to a component — open Composer, describe what I need, it reads the relevant files, understands the context, proposes changes. Most of the time it does a decent job.

Windsurf's standout feature is "Memories" — after 48 hours of use, it learns your project's architectural patterns. $15/month, a bit cheaper than Cursor. I wrote a detailed review of Windsurf earlier and was impressed by its reasoning ability, but stability can be hit or miss. One time it started deleting files mid-edit loop, which scared me.

One experienced developer put it well: "Cursor is the best AI editor. Claude Code is the best AI engineer. Windsurf is the best value." I agree with all three.

Terminal tools: Claude Code and Codex CLI

Claude Code is a CLI agent — no IDE involved. Its 200K+ token context window is powerful for large projects. It's great for "I need to refactor this entire module" scenarios.

I use Claude Code mostly for exploratory development. When I'm not sure how to implement something, I'll ask: "I want to implement X feature. What are the approaches, and what are the pros and cons?" It reads my codebase, gives recommendations. Once I confirm the approach, I let it implement.

Codex CLI is OpenAI's answer, also terminal-driven. I wrote a detailed comparison earlier, won't repeat it here.

These tools work better for experienced developers who have a clear mental model of their project structure.

Browser tools: Bolt.new, Lovable, v0

This is the most aggressive category. No installation needed, just open a browser.

Bolt.new runs Node.js directly in the browser via WebContainers. From idea to working prototype in minutes. $25/month. Perfect for non-technical founders validating ideas. I tried it with a simple task management app — from description to working prototype took about 5 minutes. Details were rough, but core functionality was correct.

v0.dev by Vercel focuses on generating React/Next.js UI components with Tailwind + shadcn/ui. It's a "component factory" — doesn't do backend. I use it frequently to quickly generate UI components, then manually integrate them into projects. Quality is decent, though Tailwind class names can get verbose.

Lovable combines design precision with developer workflows. Built-in Supabase integration, two-way GitHub sync. $25/month. Designers and product managers love it because the output looks polished.

Full-stack: Replit Agent

Replit Agent handles the entire lifecycle — from database schema to cloud deployment. $25/month including hosting. Great for beginners and indie hackers.

But vendor lock-in is a real problem — migrating out is painful. And in July 2025 there was an incident where Replit's AI agent deleted a user's production database despite explicit instructions not to make changes. Replit's CEO publicly apologized.

The lesson: no matter what tool you use, always have backups of production data, and verify regularly that those backups actually work.

When vibe coding works and when it doesn't

After using it for a while, I have a pretty clear picture of where vibe coding fits.

Where it works

Prototypes and MVPs: When you need to validate an idea fast, vibe coding is a superpower. 25% of startups in YC's Winter 2025 batch had codebases that were 95% AI-generated. They used vibe coding to find product-market fit quickly, then hired engineers to rebuild critical parts.

Frontend UI development: Describe an interface, AI generates responsive components. It's particularly good at forms, lists, cards — common UI patterns where AI output quality is already solid.

Internal tools: Data dashboards, reporting tools, admin panels. Doesn't need to be pretty, just functional.

One-off scripts: Data processing, format conversion, batch operations. Write once, use once, throw away.

Personal projects: Side projects, weekend hackathons. Speed over perfection.

The classic example: indie developer Pieter Levels built a multiplayer flight simulator in 17 days using Cursor and Grok 3, generating $1 million in annual revenue. That's the ceiling of vibe coding — fast execution, good idea, AI lowering the technical barrier to nearly zero.

Where it doesn't work

Security-critical systems: Authentication, payment processing, encryption. AI-generated code can have vulnerabilities. A May 2025 security scan found that 170 out of 1,645 web apps built with Lovable had personal data exposure issues. In early 2026, a vibe coding platform had a security incident — 1.5 million API keys and 35,000 user emails leaked due to a misconfigured database. The app's author admitted they hadn't written a single line of code manually.

Large long-term projects: Code maintainability is a major concern. GitClear's research showed that AI-generated code drove the refactoring ratio from 25% in 2021 to under 10% by 2024, with code duplication quadrupling.

Scenarios requiring deep understanding: If you don't understand what the code is doing, you can't fix it when it breaks.

Regulated industries: Healthcare, finance, aviation. Strict code quality requirements, no room for "going with the vibes."

A counterintuitive research finding

In July 2025, METR (an organization that evaluates frontier models) ran a randomized controlled trial testing whether AI coding tools improve developer productivity.

The result was surprising: developers using AI tools were 19% slower. Even more surprising — they thought they were 24% faster, and still believed afterward they'd been 20% faster.

This seems counterintuitive at first, but it makes sense. For experienced developers who already know their codebase well, writing code by hand is fast. AI tools actually interrupted their workflow — waiting for generation, reviewing output, making adjustments. The overhead added up.

But there's an important caveat: participants were experienced open-source developers. For newcomers or people unfamiliar with the codebase, AI tools genuinely improve efficiency.

The takeaway: vibe coding's productivity gains aren't universal. They depend on who you are and what you're doing.

Security: the biggest concern

Security is the most worrying aspect of vibe coding, and it deserves a deeper look.

Veracode released a report in October 2025 with a sobering conclusion: over the past three years, LLMs had gotten dramatically better at generating functional code, but their ability to generate secure code had barely improved. Larger models weren't better than smaller ones at security. Only OpenAI's reasoning models showed a small improvement, but nothing close to the gains in functionality.

CodeRabbit analyzed 470 open-source GitHub PRs in December 2025 and found that AI co-authored code had 1.7 times more "major" issues than human-written code. This included logic errors, incorrect dependencies, control flow defects (75% more common), and security vulnerabilities (2.74x higher). Formatting errors and naming inconsistencies were also elevated.

What does this mean? AI-generated code looks like it works, but there might be time bombs hiding underneath. Just because it passes your tests doesn't mean it's safe in production. Attackers specifically target this kind of "looks fine on the surface" code.

In December 2025, security researcher Etizaz Mohsin discovered vulnerabilities in the Orchids vibe coding platform. He demonstrated the attack to a BBC News reporter in February 2026. A vibe coding platform's security issues making BBC News tells you how serious this is.

Technical debt: the hidden cost

Beyond security, technical debt is another major concern.

GitClear did a longitudinal analysis of 211 million lines of code changes from 2020 to 2024. They found:

Code refactoring dropped from 25% of changes in 2021 to under 10% by 2024
Code duplication roughly quadrupled
Copy-pasted code exceeded moved code for the first time in two decades
Code churn (code that gets rewritten shortly after merging) nearly doubled

What does this tell us? AI-generated code runs, but it might not be maintainable. The thing you vibe-coded together in a weekend could turn into spaghetti three months later.

Fast Company reported in September 2025 that "the vibe coding hangover is upon us" — senior engineers inheriting AI-generated codebases were hitting "development hell." The code worked, but nobody understood it. Change one thing, break three others.

I hit this myself. When I first built the site, I was rushing and let AI generate a bunch of page components in one go. Two months later, when I wanted to refactor, the coupling between components was a mess — Component A depended on Component B's state, which depended on Component C's function, which was only used once. Took an entire weekend to untangle.

Impact on open source

A January 2026 paper titled "Vibe Coding Kills Open Source" made an interesting argument.

The authors contend that vibe coding lowers the cost of using and building on existing code, but also weakens user engagement with open-source maintainers. When open-source projects can only monetize through direct user interaction, increased vibe coding adoption reduces participation and sharing, ultimately degrading the availability and quality of open-source software.

There's also a more subtle problem: LLMs tend to recommend well-established libraries that appear frequently in their training data. Ask the AI "how do I make HTTP requests," and it'll almost certainly recommend axios or fetch, not some lighter but less-known library. This disrupts the natural selection process for libraries and tooling — newer open-source tools struggle to get discovered.

And AI won't submit useful bug reports or be aware of potential issues. For open-source maintainers, user feedback is crucial for improving projects. Vibe coding cuts off that feedback loop.

I hadn't thought about this angle before. Vibe coding is great for individual developers, but it might be quietly harmful to the open-source ecosystem.

Even Linus Torvalds uses it

A fun footnote: in January 2026, someone discovered that Linus Torvalds (creator of Linux) had used vibe coding in a personal project called AudioNoise. He wrote in the README: "The Python visualizer tool has been basically written by vibe-coding." He used Google Antigravity.

If even Linus is using it, vibe coding is clearly not a toy anymore. Of course, he only used it for a personal hobby project — he'd never do this with the Linux kernel. Which illustrates the point: vibe coding fits specific scenarios, not everything.

My advice: how to use vibe coding properly

After months of tinkering, here's my approach.

Layer your usage

Divide your project into layers with different levels of vibe coding:

UI layer: Go wild. Generate it, use it, tweak as needed
Business logic layer: Let AI draft it, but review core logic carefully
Data layer: Write by hand or review carefully. AI-generated SQL/ORM code must be verified
Security layer: Auth, authorization, encryption — either hand-write or use battle-tested libraries

Use context files

Cursor has .cursorrules, Claude Code has CLAUDE.md. Write these files well — tell the AI your project conventions, tech stack, coding style. The quality of AI-generated code improves dramatically. I spent an hour writing a detailed CLAUDE.md, and afterward Claude Code's output noticeably better matched my style.

Iterate in small steps

One task at a time. Complete it, test it, commit. Then move to the next. Never let the AI modify ten files at once — if something breaks, you won't know which change caused it.

Error messages are the best prompt

Karpathy was right: paste the complete error message and stack trace to the AI. This works way better than describing "something seems wrong here."

Know when to stop

If the AI fails to fix a bug three times in a row, roll back to the last Git commit and do it yourself. Continuing to prompt the AI only makes things worse — it starts guessing, and the guesses get increasingly wild. I once asked the AI to fix a CSS z-index issue. It made six attempts, each introducing new problems, until the entire page layout was wrecked. Rolled back to the initial commit, manually added one line: z-index: 9999. Two minutes.

Human review for critical paths

Database migrations, API authentication, payment integration, permission controls — if these break, it's an incident. No matter how good the AI-generated code looks, these areas need a human pass.

Getting started with vibe coding

If you haven't used these tools before, here's how to begin.

Step 1: Pick a tool

If you want to work in an IDE, go with Cursor. Download it, open your project, hit Cmd+K (or Ctrl+K) to bring up the AI dialog. Start with something simple, like "add comments to this function" or "convert this component to TypeScript."

If you prefer the terminal, install Claude Code: npm install -g @anthropic-ai/claude-code, then run claude in your project directory. Better for people with command-line experience.

If you don't want to install anything, open bolt.new or v0.dev and try it in the browser.

Step 2: Start with simple features

Don't start with "build me a complete e-commerce system." Begin with small tasks:

"Write a date formatting utility function"
"Add pagination to this list component"
"Write unit tests for this API endpoint"

Get familiar with what the AI can and can't do, then gradually increase complexity.

Step 3: Learn to write good prompts

Prompt quality directly determines output quality. Some tips:

Be specific: Don't say "optimize performance." Say "this function is slow with more than 10,000 records, optimize the query using indexes."
Give context: Tell the AI your tech stack, versions, existing code style
Break it down: Split complex features into steps. Test and confirm each step before proceeding
Describe expected behavior: Don't just say "do X" — say "I expect it to behave like Y"

Step 4: Build a review habit

Start reviewing AI code from day one. You don't need to read every line, but at minimum:

Understand the main flow of the code
Check for obvious security issues (hardcoded secrets, SQL injection, etc.)
Confirm error handling is reasonable
Run the tests

Build this habit early. Trying to add it later, when the codebase is large, is too late.

Where this is going

My take: vibe coding won't replace traditional programming, but it will change what "programming" means. In the future, "coding" might be more about "describing" and "reviewing" than "writing." The act of writing code itself becomes less important; understanding requirements, designing architecture, and reviewing quality become more important.

For beginners, vibe coding is a huge opportunity. You don't need three years of programming language study to build a working application. But if you want to become a genuinely good engineer, you still need to understand fundamentals. Otherwise you're just an "AI operator," not an engineer. This isn't fear-mongering — as AI does more, the value of pure "AI operation" gets compressed. What's truly valuable is the ability to judge whether AI did it right, design system architecture, and handle edge cases AI can't.

For experienced developers, vibe coding is a productivity tool, not a replacement. Used well, it multiplies your output. Used poorly, it actually slows you down. The key is finding your own workflow. My suggestion: try it on a small project first, find your rhythm, then gradually apply it to production work.

My current approach: use vibe coding for scaffolding and repetitive work, write critical logic myself. Hand UI over to AI confidently, keep tight control over data and security layers. That balance point is different for everyone — you have to experiment.

Planning to dig deeper into Bolt.new and Lovable next, to see what these "browser-based vibe coding" tools can really do. Will write a detailed comparison when I'm done.

Questions? Drop them in the comments.

References:*