The Term That Broke Developer Twitter

In early 2025, Andrej Karpathy — former Director of AI at Tesla, OpenAI co-founder, and one of the most respected figures in machine learning — posted a description of how he'd been building software lately. He called it vibe coding. The idea was deceptively simple: you describe what you want to an AI, it generates the code, you mostly don't read the code, you just run it and iterate. If something breaks, you describe the problem. If it works, you move on. You're not writing software. You're vibing.

The reaction was immediate and polarizing. Some developers celebrated it as the liberation they'd been waiting for. Others treated it as a declaration of professional apocalypse. Breathless tech blogs wrote about how "anyone can code now." Grizzled engineers wrote Twitter threads about why this was reckless and dangerous. Both camps mostly missed the point.

This article is for developers who actually want to understand what vibe coding is, where it genuinely succeeds, where it will get you fired (or worse), and what it means for the craft of software development going forward.

What Karpathy Actually Said

Karpathy's description of vibe coding was precise, even if the term sounded casual. The key elements: you use a capable frontier model (he mentioned Cursor with Claude Sonnet), you engage in a flow state where you're not manually typing code, you accept suggestions wholesale, and crucially — you give up trying to maintain a full mental model of the codebase. When errors appear, you paste them back in. You describe what you see. You let the AI fix it. You forget about the implementation details almost immediately after they work.

He wasn't describing this as a philosophy for all software. He was describing what had become possible for certain types of projects. But the internet latched onto the concept and generalized it immediately, which is where the confusion began.

When Vibe Coding Actually Works

Let's be honest about where vibe coding shines, because it genuinely does in specific contexts.

Prototyping and throwaway scripts. If you need a quick script to rename 500 files, parse a CSV, or stand up a simple Express server to test an API — vibe coding is legitimate and fast. The code doesn't need to be maintained. It needs to work once. The usual professional standards for readability, test coverage, and architectural purity simply don't apply.

Personal projects with low stakes. Building a tool just for yourself? A weekend project that 20 people might use? Vibe coding can get you to a working product in hours instead of days. If something breaks, you fix it with the same process. The feedback loop is tight and the consequences of imperfect code are minimal.

Learning new frameworks and languages. Counterintuitively, vibe coding can accelerate learning. When you ask an AI to build something in a framework you've never used and then actually study what it generated, you compress days of documentation-reading into an hour of reading real working code. The key word is "study" — you still need to read it.

Scaffolding and boilerplate. Setting up auth flows, configuring build tooling, wiring together a standard CRUD API — these are areas where the patterns are well-established and the AI's suggestions are reliably correct. Senior developers who vibe code their scaffolding and then carefully build the novel logic on top are being genuinely efficient, not lazy.

In all these cases, vibe coding is a legitimate productivity multiplier. The issue isn't vibe coding itself. The issue is misapplying it.

When Vibe Coding Will Destroy You

Here's where most of the breathless coverage gets irresponsible. Vibe coding applied to the wrong contexts doesn't just produce bad code — it produces code that looks correct, tests superficially, and then fails in ways that are deeply hard to debug because the developer has no mental model of what the code is actually doing.

Security-sensitive systems. Authentication, authorization, encryption, payment processing, data access controls — these are areas where the devil is entirely in the details. An AI-generated auth middleware might look correct and even pass basic tests while containing a subtle flaw in token validation that creates a privilege escalation vulnerability. The developer who vibe coded it and moved on has no way to audit it because they never built the mental model. Vibe coding security-critical systems is professional negligence.

Production systems at scale. Code that runs at scale has failure modes that only emerge under real load, with real data, at real timing. Race conditions, memory leaks, inefficient database queries that are fine with 100 rows and catastrophic with 10 million — these require a developer who understands the code deeply enough to reason about edge cases. If your entire production codebase is a black box that you've been vibing into existence, you have no tools when it starts failing in production at 3 AM.

Accumulated complexity. Here's the sneaky failure mode that gets sophisticated developers: vibe coding works fine for a while, then compounds. You vibe code feature A. Then you vibe code feature B, which interacts with A. The AI generates code that technically works but makes architectural choices that create friction for feature C. By the time you're vibing your way through features D, E, and F, the codebase has become a maze of inconsistent patterns, duplicated logic, and hidden coupling that the AI itself starts struggling to work with coherently. The debt accumulates invisibly.

Anything you'll need to debug. The most underappreciated cost of vibe coding is the debugging asymmetry. Generating code with AI is fast. Debugging code you don't understand is brutally slow. When something breaks in code you vibe coded three weeks ago, you're not debugging your own logic — you're reverse-engineering a stranger's code that you accepted without reading. Every minute of vibe coding can cost you ten minutes of confused debugging later.

The Skills That Actually Matter Now

Vibe coding changes what skills are valuable, but it doesn't eliminate the need for skill. It shifts the valuable skill set upward in abstraction.

System thinking over syntax. If you can describe the system you want to build — its components, their responsibilities, how they interact, what guarantees they need to maintain — an AI can generate a lot of the implementation. The developer who can think clearly at the system level and express it precisely gets dramatically more leverage from AI tools than the developer who can write clever algorithms but can't articulate architecture.

Critical reading of AI output. The developers who will thrive in a vibe coding world aren't the ones who never read the code. They're the ones who can rapidly evaluate AI-generated code — spot the obvious issues, identify the subtle risks, recognize when the AI took a shortcut that will cost you later. This requires deep programming knowledge, ironically.

Knowing where to vibe and where not to. This is judgment, and it's genuinely hard. You need to accurately assess which parts of your system are high-stakes versus low-stakes, which requirements are well-understood versus novel, which failures would be embarrassing versus catastrophic. Developers who can make this assessment correctly will use vibe coding as a force multiplier. Those who can't will use it as a liability generator.

The Karpathy Insight That Everyone Missed

What most coverage missed about Karpathy's original observation is that he was describing something he could do because of deep expertise, not despite lacking it. He has decades of experience in ML, systems, and software. When he vibes code into existence, his intuitions about what looks right, what to test, and what to be careful about are informing every decision he makes even when he's not reading every line. He's not operating without judgment — he's operating with judgment that's become so internalized he doesn't need to consciously apply it.

A new developer trying to vibe code their way through a complex system doesn't have those internalized heuristics. They won't know what they're not seeing. They'll ship the security vulnerability confidently because it looked fine.

Vibe coding is a power tool. Power tools don't make expertise irrelevant. They make expertise more productive — and make inexperience more dangerous.

The Practical Framework

If you want to actually use vibe coding well, here's the framework that matters:

Define your trust zones. Before a project starts, be explicit about which parts of your system you'll vibe and which you'll write carefully and review in detail. This isn't about being conservative — it's about being intentional. Scaffolding and boilerplate: vibe it. Auth and payments: write it carefully and review everything.

Keep some mental model. Even when you're vibing, maintain a high-level understanding of what the AI is doing. You don't need to understand every line. You need to understand every component and its responsibilities. If you lose even that, you're not vibing — you're drifting, and you'll eventually crash.

Test more, not less. When you're generating code you haven't fully read, tests are your safety net. Write more tests than you think you need. Let the AI generate them too, but review them — a test that always passes because it's testing the wrong thing is worse than no test at all.

Schedule comprehension time. Every week or two, read through the code you've been vibing into existence. Not to rewrite it — just to understand it. Stay connected to your own codebase. The moment it becomes fully opaque to you is the moment you've lost control of the project.

Where This Is Going

Vibe coding is not a fad and it's not the end of programming. It's an inflection point in the relationship between developers and their tools. The tools are getting better fast — frontier models are increasingly capable of generating correct, well-structured code for complex problems. The gap between "describe it" and "ship it" will continue to narrow.

But software development has always been fundamentally about managing complexity, making tradeoffs, and reasoning carefully about systems that fail in unintuitive ways. Those challenges don't disappear when code generation gets easier. They intensify, because the volume of code you can generate outpaces your ability to understand it if you let it.

The developers who will define the next decade aren't the ones who reject vibe coding as irresponsible, and they're not the ones who embrace it uncritically as a replacement for thinking. They're the ones who learn to use it precisely — knowing when to flow and when to scrutinize, when to trust the AI and when to distrust it, when to move fast and when the stakes demand slowness.

Karpathy named something real. The question is whether you use that insight to build better, or to build faster without caring about better. The tools don't decide that. You do.

Key Takeaways

  • Vibe coding — describing intent to AI and accepting code without deep reading — is a legitimate technique for low-stakes, high-iteration contexts like prototyping and personal projects.
  • Applied to security-critical, high-scale, or complex production systems, it creates invisible technical debt and dangerous blind spots.
  • The key skill shift is from writing code to specifying systems, reading AI output critically, and knowing where to trust the AI versus where to scrutinize it.
  • Karpathy's original insight was enabled by deep expertise — the technique is safer in experienced hands and risky in inexperienced ones.
  • The right framework: define your trust zones explicitly, maintain high-level system understanding, test more than usual, and periodically reconnect with your own codebase.