Andrej Karpathy posted the phrase “vibe coding” on X in February 2025. Eighteen months later, the same person calls it passé for professional work. That tells you something about how fast this practice has moved, and how unsettled its place in real engineering still is. This article explains what vibecoding actually means, what tools and habits it involves, where it works, and where it has been quietly causing damage. If you are a founder using AI to build your first product, a senior engineer asked to clean up someone else’s prompts, or a teacher figuring out what to do with students who never learn syntax, you are in the right place.
Quick answer
Vibecoding is a prompt-first, iterate-fast, review-light way of building software with an AI model. You describe the outcome you want, the model writes code, you run it, you paste back errors or new requests, and you keep going until it looks right. The defining trait is not the use of AI. It is the willingness to accept generated code without reading it carefully. That tradeoff is the whole story: speed in exchange for understanding.
Curious what AI could do for your business?
No jargon and no hard sell. Just a friendly look at where AI fits, and where it doesn't.
Where the term came from
Karpathy’s original post described “giving in to the vibes” and accepting code without inspecting every line. He framed it as a relaxed style of working with an LLM, suitable for weekend builds and quick experiments. The phrase stuck because it named something a lot of people were already doing.
A 2026 ICSE grey-literature review by Fawzy, Tahir, and Blincoe gave it an operational definition: producing software primarily by describing goals in natural language and iteratively prompting, while relying on minimal review of the generated code. That last clause is the load-bearing one. Plenty of professionals use AI heavily and still read what it writes. That is not vibecoding in the strict sense. Simon Willison argues this distinction matters, because the risks are very different.
What does vibecoding mean in practice?
Vibecoding means a loop that looks like this:
- Describe what you want in plain language.
- Let the model generate code.
- Run it, or try to.
- Paste back the error message, screenshot, or new ask.
- Iterate until the output passes a sniff test.
The cycle is conversational, exploratory, and forgiving of half-formed intent. As DevOpsTales notes, it works beautifully for prototypes and falls apart when the codebase spans many files and weeks. The reason is simple. The thing being passed between turns is a chat thread, not a specification. Anything outside that thread, your architecture, your data model, your error-handling conventions, has to be re-explained or rediscovered every session.
Educators describe the shift differently. They see less syntax memorisation and more emphasis on design judgment, debugging instincts, and what Pine Crest School calls a new literacy. Both views are right. The same loop is liberating for a beginner and dangerous for a maintainer.
The vibecoding tools and workflow people use
Here is the shape of the tooling stack people gravitate toward:
- Chat-style LLM interfaces where you converse and copy code back to an editor.
- Coding agents that read and edit a repo in place, run commands, and propose diffs.
- Plugin-style workflow systems like the open-source opsx-feature-dev project, which uses a 7-phase workflow with specialised agents (code-explorer, code-architect, code-reviewer) to stop context from rotting between sessions.
- Context-engineering frameworks that store standards, architecture notes, and rules in versioned files so multiple AI tools share the same baseline, an approach Packmind documents for large codebases.
Notice the trend. The more serious the tool, the less it looks like pure vibecoding. The mature stack is trying to compensate for vibecoding’s biggest weakness, which is that the conversation forgets things and the project pays the bill later.
Why it spread so fast
Three forces pushed vibecoding into the mainstream.
First, the barrier to creation collapsed. Non-technical founders, product managers, marketing teams, and students can ship working software without years of training. The Harvard Gazette covered this democratization as one of vibecoding’s defining social effects.
Second, speed. For early-stage exploration, ideation, and concept validation, vibecoding is genuinely faster than the alternatives. RedMonk’s 2025 analysis lays out why: when the goal is to learn, not to ship a hardened system, ceremony is overhead.
Third, it feels good. Progress is visible. Each turn produces a file, a screen, a fix. That emotional reward is part of why the practice is sticky, and it is worth being honest about.
Anthropic’s 2026 randomized controlled trial found that AI assistance can reduce performance on coding-related assessments, with the largest gap appearing in debugging.
Anthropic published that finding in January 2026. It deserves its own pause. Debugging and code reading are the skills that let a human safely supervise generated work. If those skills atrophy, the safety net underneath vibecoding gets thinner over time.
The problems nobody warns you about
This is where the evidence gets uncomfortable.
Cycode’s 2026 security report found that 81% of organizations lack visibility into how AI is actually used across their codebases. Keyhole Software reported that roughly 91.5% of vibe-coded applications contain AI-traceable vulnerabilities, with other security scans surfacing more than 2,000 vulnerabilities and 400+ exposed secrets across a sample of about 5,600 applications. The exact percentages come from industry research rather than peer-reviewed benchmarks, so treat the figure as directional. The direction is bad.
Beyond security, the recurring failure modes are:
- Context rot. Multi-file systems drift because the chat thread forgets architectural decisions made three sessions ago.
- The three-month wall. Augment Code’s case work describes projects that stall after initial momentum, when duplication, churn, and amnesia make further progress too costly.
- Missing traceability. Jama Software’s 2026 audit work found code with no link back to requirements, tests for undocumented features, and explicitly scoped features missing entirely. For anything regulated, that is a compliance failure, not a workflow smell.
- Silent technical debt. Tizbi’s 2026 enterprise guidance recommends audit schedules, refactoring cadences, and debt dashboards specifically for AI-generated code, which is an implicit admission of how fast it accumulates.
What strikes me about this evidence is how predictable the failure pattern is. Vibecoding optimizes for visible progress and hides the invisible cost of lost intent. Anyone who has inherited a codebase someone else wrote knows the feeling. Vibecoding just produces that codebase faster.
Vibecoding vs spec-driven development
The clearest contrast in the 2026 literature is between vibecoding and spec-driven development (SDD). SDD writes the behavior contract first, then generates code against it. Jama Software’s definition places SDD at the feature and system level, distinct from TDD, which operates at the unit level.
| Dimension | Vibecoding | Spec-driven development |
|---|---|---|
| Starting point | A prompt | A specification |
| Optimized for | Speed and exploration | Alignment and maintainability |
| Review style | Light or inconsistent | Structured review gates |
| Best for | Prototypes, demos, throwaway scripts | Production and regulated systems |
| Main risk | Context rot, debt, security gaps | Upfront overhead |
| Human role | Prompting and informal steering | Architect, reviewer, verifier |
| Traceability | Weak | Strong |
The deeper differentiator, well captured in a 2026 LinkedIn analysis by Hari Krishnan, is intent management. Vibecoding tolerates drift to keep velocity. SDD pays an upfront tax to make intent explicit and reviewable.
My read is straightforward. Vibecoding is the right name for a phase, not a destination. Teams can use it to discover what they want to build. They should not stop there if the software is going to matter to anyone.
What comes after vibecoding
By 2026, the language has already shifted. The New Stack reports Karpathy declaring vibecoding passé for professional use and offering “Agentic Engineering” as the more honest description of what good AI-assisted work actually looks like. The developer supervises agents, writes specs, reviews diffs, and runs evaluation loops. The AI does the typing. The human owns the architecture, the quality, and the correctness.
Addy Osmani frames the same shift plainly: AI does implementation, the human owns the rest. MindStudio describes it as the natural replacement once systems have to function across multiple sessions and workflows.
What could a custom AI agent take off your plate?
We build production-grade AI systems that quietly handle the busywork, so your team can focus on the work that actually matters.
This is not a rebrand. It is a workflow change. The hard problem in 2026 is not generating code. It is governing the generation with specs, tests, durable context files, and human review.
How to use vibecoding without getting burned
Treat vibecoding as an ideation mode, not a production strategy. For a throwaway prototype, a personal tool, a demo for a stakeholder, a script you will run twice, go fast and skip the ceremony. For anything that will live past next quarter, do three things. Pull the intent out of the chat thread and into a specification document. Add real review gates before code merges, including static analysis and security scanning of AI-generated sections. Track which parts of the codebase came from prompts, so you know where to look first when something breaks. The teams that get value from AI in 2026 are not the ones avoiding vibecoding. They are the ones who know exactly when to stop.
