You’ve probably heard the term “vibe coding” recently—it’s been everywhere in tech and business media. Collins Dictionary named it Word of the Year for 2025. That’s mainstream fast.
As discussed in our comprehensive guide to understanding vibe coding and the future of software craftsmanship, this practice has sparked fierce debate among engineering leaders. The term was coined by AI researcher Andrej Karpathy in February 2025 to describe developers “fully giving in to the vibes” when using AI to generate code. And the practice has taken off. 41% of global code is now AI-generated, with Java hitting 61%.
At Y Combinator‘s Winter 2025 batch, 25% of startups reported codebases that were 95% AI-generated. This level of adoption in venture-backed startups signals something fundamental is shifting in how software gets built.
So you need to understand what vibe coding actually is, how it differs from responsible AI-assisted development, and when you should be concerned about your team’s practices. This article gives you the framework to assess if your developers are engaging in risky vibe coding or professional AI tool usage—and helps you work out the appropriate use cases for each approach.
What is Vibe Coding?
Vibe coding is when developers describe desired outcomes to large language models in natural language and accept the generated code without manual review or full comprehension. It’s that straightforward.
Andrej Karpathy—former OpenAI co-founder and Tesla AI director—introduced the term in February 2025. His definition was specific: “fully giving in to the vibes, embracing exponentials, and forgetting that the code even exists.” He wasn’t being entirely serious, but the term stuck because it captured something real about how developers were starting to work with tools like Cursor, Bolt, and Replit Agent.
The workflow is simple. You describe your goals in plain English (or whatever language you speak). The AI generates code. You execute it and observe what happens. You provide feedback and refine. You repeat until it works. At no point do you necessarily understand the implementation details or review the code for security, quality, or maintainability.
This is fundamentally different from traditional AI-assisted development. GitHub Copilot suggests code, but developers actively guide and review those suggestions. You’re still writing code—the AI is just helping you write it faster. With vibe coding, the AI is doing the writing and you’re just describing what you want built.
Karpathy built prototypes like MenuGen this way, letting LLMs generate all code whilst he provided goals, examples, and feedback via natural language instructions. As he put it: “It’s not really coding. I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.”
The key characteristic that separates vibe coding from other AI-assisted practices is trust without understanding. You accept the output based on the “vibe” that it works correctly, not because you’ve verified the implementation.
How Did Vibe Coding Become Collins Dictionary’s Word of the Year?
Collins Dictionary named “vibe coding” its Word of the Year for 2025—a remarkable trajectory for a term that didn’t exist 11 months earlier. Alex Beecroft, Managing Director of Collins, said it “perfectly captures how language is evolving alongside technology”.
The BBC and major media outlets covered the announcement. The shortlist included other tech terms like “broligarchy” and “clanker”, but vibe coding won because it described something millions of developers were actually doing.
The recognition validates vibe coding as a genuine phenomenon requiring serious consideration from engineering leadership, not merely a passing trend. When a practice becomes mainstream enough to win Word of the Year, it requires your attention. Your team is either doing it, thinking about it, or will be asked about it soon.
What Tools Enable Vibe Coding?
The vibe coding landscape has three tiers of tools, each targeting different user expertise levels and use cases. Understanding these differences helps you select appropriate platforms for different team needs.
Cursor uses Claude Sonnet and serves professional developers within their IDE. Karpathy mentioned using “Cursor Composer with Sonnet” as his example tool. It integrates into your existing development workflow, so experienced developers can leverage AI generation whilst staying in their familiar environment.
Bolt targets non-technical users for rapid application prototyping. You describe what you want in plain language and it generates a functioning app in minutes. The interface is simple—no coding knowledge required. But here’s the problem: StackOverflow testing revealed that Bolt-generated apps contained serious security vulnerabilities. Completely unencrypted data accessible through basic browser inspection tools. Missing authentication. No unit tests. Functionally it works. Securely it doesn’t.
Replit Agent offers autonomous code modification—it can make changes to your codebase based on natural language instructions. This approach seems promising until you learn that in July 2025, Replit’s AI agent deleted a production database despite explicit instructions not to make any changes. Autonomy without reliability is a problem.
Google Cloud offers a three-tier approach. AI Studio targets beginners with no coding needed and single-prompt app generation. Firebase Studio handles beginner to intermediate users for full-stack generation. Gemini Code Assist integrates into professional IDEs for experienced developers. This tiered strategy acknowledges that different use cases need different levels of control.
GitHub Copilot sits at the conservative end of the spectrum. It’s an AI pair programmer—suggesting code whilst you maintain active control and review. Mario Rodriguez, GitHub’s Chief Product Officer, put it clearly: “Vibe coding unlocks creativity and speed, but it really only delivers production value when paired with rigorous review, security and developer judgement.”
So what should you choose? Rapid prototyping? Maybe Bolt or AI Studio. Production development? Cursor or Copilot with proper review processes. Each tool makes different trade-offs between speed and safety. For a detailed comparison of enabling tools, see our comprehensive tool landscape analysis.
How Widespread is Vibe Coding Today?
The adoption numbers reveal significant shifts. GitHub reports 256 billion lines of AI-generated code across its platform. That’s a lot of AI-written software.
But here’s where it gets interesting for you. As mentioned earlier, at Y Combinator’s Winter 2025 batch, 25% of startups reported codebases that were 95% AI-generated. This wasn’t non-technical founders fumbling with Bolt. Jared Friedman, YC managing partner, was clear: “Every one of these people is highly technical, completely capable of building their own products from scratch. A year ago, they would have built their product from scratch—but now 95% of it is built by an AI.”
Garry Tan, YC CEO, called it “the dominant way to code” and warned: “if you are not doing it, you might just be left behind.” That’s strong language from someone who sees hundreds of startups every year.
Even notable developers are using it pragmatically. Linus Torvalds—the creator of Linux—used Google’s AI tools to vibe code a Python visualiser component for his AudioNoise project in January 2026. He explained in the project README: “the Python visualiser tool has been basically written by vibe-coding.” But note what he chose to vibe code: a small, well-scoped component for a personal project where he understood the requirements and could evaluate the output.
Kevin Roose, a New York Times journalist, experimented with vibe coding in February 2025 to create several small-scale “software for one” applications. Non-technical people are building functional software within hours.
But there’s important context missing from these statistics. They represent code generation volume, not necessarily production-ready quality or percentage of AI code surviving into deployed applications. Diana Hu, YC general partner, noted the requirement for expertise: “You have to have the taste and enough training to know that an LLM is spitting bad stuff or good stuff.”
So yes, vibe coding is widespread. But as research reveals concerning quality patterns, adoption rates alone don’t tell the full story. What matters is whether developers use it responsibly.
How Does Vibe Coding Differ from Traditional Programming?
Traditional programming means you write code line-by-line. You need syntax mastery for your chosen language. You understand every line because you wrote it. When something breaks, you debug by tracing the logic manually. You invest years of training to achieve proficiency.
Vibe coding replaces manual coding with natural language instructions to AI. You describe outcomes, not implementations. Just say “create a user login form” and the AI handles the actual code. You iterate through feedback rather than writing syntax. Non-programmers can build functional applications in hours.
The skill transition is from syntax expert to prompt engineer. Scott H. Young argues that developers now “rely more on abstract concerns about things like architecture, algorithms, user experience and design.” You’re thinking about what to build, not how to implement it.
David Fowler, Microsoft distinguished engineer, described it as “outcome-driven development. In coding, normally it’s all about ‘how.’ Vibe coding is all about ‘what’.”
The learning curves differ dramatically. Traditional programming has a steep initial climb followed by gradual mastery. Vibe coding offers quick starts—non-programmers create functional applications within hours—but hidden complexity emerges when you need to debug AI-generated code you don’t understand.
Here’s the catch: even with AI handling implementation, you still need conceptual knowledge. When Scott Young built a language-learning flashcard app, designing features using linguistic principles like Zipf’s law required deep domain understanding. The AI can write the code, but you still need to know what you’re building and why.
Is AI Replacing Developers or Augmenting Them?
AI’s role depends on your implementation approach. Investing in skilled developers using AI tools produces different outcomes than attempting to replace developers with AI. The distinction comes down to maintaining human oversight, testing, review, and accountability.
Simon Willison coined “vibe engineering” to describe responsible AI-assisted development. Experienced developers leverage LLMs whilst maintaining full understanding and production-quality standards. You review everything. You test everything. You understand everything. This approach, detailed in our guide to augmented coding as the responsible alternative, distinguishes disciplined AI usage from uncritical acceptance.
Willison’s line is clear: “If an LLM wrote every line of your code, but you’ve reviewed, tested, and understood it all, that’s not vibe coding in my book—that’s using an LLM as a typing assistant.” The amount of AI-generated code doesn’t matter. Verification does.
Pure vibe coding—accepting AI output without review—means trusting the AI to make security, quality, and architectural decisions without oversight. That’s risky for anything beyond throwaway prototypes.
The vibe engineering approach requires automated testing to catch regressions, comprehensive documentation, version control, code review, and manual QA. Here’s what matters: AI tools amplify existing expertise. Senior engineers extract maximum value. Developers lacking foundational discipline struggle when AI generates code they can’t properly evaluate.
Guido van Rossum, Python’s creator, put it clearly: “With the help of a coding agent, I feel more productive, but it’s more like having an electric saw instead of a hand saw than like having a robot that can build me a chair or a cabinet.”
The technology rewards skilled developers using AI tools as productivity multipliers. Attempting to replace developers with AI doesn’t work. For deeper exploration of the implications for workforce development, see our analysis of career development strategies in the AI era.
Should Engineering Leaders Be Concerned About Vibe Coding?
You need to distinguish between concerning practices and appropriate usage. Context matters.
Red flags: teams deploying AI-generated code to production without review, developers who can’t explain how their code works, missing test coverage, security vulnerabilities from unexamined output.
Lovable had security vulnerabilities in 170 out of 1,645 generated applications—a 10% failure rate on basic security. That’s not good enough for production.
The concept of a “productivity tax” describes time spent cleaning up almost-correct AI code. StackOverflow uses this term for the hours developers spend fixing code that’s 90% right but 10% broken. Sometimes writing it yourself would have been faster.
Addy Osmani calls this “The 70% Problem”: AI tools accelerate development but struggle with the final 30% of software quality. That last 30% is easily tackled by engineers who understand how the system works. Without that understanding, you’re stuck.
But appropriate use cases exist. Karpathy framed it as “throwaway weekend projects”. Rapid prototyping. Learning in safe environments. Personal applications where stakes are low. These are all fine.
Simon Willison is direct: “Vibe coding your way to a production codebase is risky. Most of the work we do as software engineers involves evolving existing systems, where the quality and understandability of the underlying code is important.”
Your risk mitigation strategy should be straightforward. Establish clear policies distinguishing prototyping from production standards. Require code review for all production-bound AI-generated code. Mandate automated testing and security scanning. Train teams in output evaluation—how do you know if the AI got it right?
Assessment questions for your team: Can developers explain AI-generated code functionality? Is your code review process adapted for AI output? Are security practices adequate for AI-assisted development? Do teams distinguish prototyping from production workflows?
Focus on whether your team reviews, tests, and understands AI-generated code before production deployment. Not whether they use AI tools at all.
What This Means Going Forward
Vibe coding represents a genuine shift in development practices. Collins Dictionary’s Word of the Year recognition reflects cultural significance, not just hype. With 41% of global code now AI-generated and a quarter of Y Combinator’s latest batch running on 95% AI codebases, this requires your attention.
But you need a nuanced response. Pure vibe coding—accepting AI output without review—is appropriate for prototyping and experimentation. It’s risky for production systems serving real users. The distinction matters.
Adopt Simon Willison’s vibe engineering approach: leverage AI tools for productivity whilst maintaining professional standards of review, testing, and understanding. Your developers can use AI to write code faster. But they need to verify everything that ships to production.
Your action steps are straightforward. Assess current team practices—are developers reviewing AI-generated code or shipping it blindly? Establish clear guidelines distinguishing prototyping from production workflows. Invest in training for responsible AI tool usage, including prompt engineering and output evaluation.
AI coding tools will continue evolving. Your challenge is channelling adoption towards augmentation rather than reckless replacement. The technology rewards traditional software engineering excellence. Developers who understand architecture, security, quality, and maintainability will extract more value from AI tools than those who don’t.
Because someone needs to verify that the AI got it right. Professional software engineering expertise becomes more valuable in the AI era, not less.
For a comprehensive overview of all considerations—from security and economics to implementation strategies—see our complete guide to understanding vibe coding and the future of software craftsmanship.
