Back in February 2025, Andrej Karpathy coined the term “vibe coding” to describe his weekend coding experiments: tell an AI what you want, hit Accept All on whatever it spits out, and move on without reading the code. Within months, Collins Dictionary’s Word of the Year 2025 was “vibe coding”. But as the term spread its meaning got fuzzy. Now people use it for any AI-assisted coding, which makes it impossible for engineering leaders to have sensible policy conversations.
The question for CTOs isn’t whether AI coding tools are useful. It’s where you draw the line between acceptable experimentation and unacceptable risk. This article defines vibe coding precisely—using the originator’s actual words—then maps the spectrum from vibe coding through augmented coding to AI-assisted engineering. The goal is shared vocabulary so your team can discuss AI coding without talking past each other.
This is the foundational terminology that our comprehensive guide to vibe coding and engineering leadership builds on.
What Is Vibe Coding and Where Did the Term Come From?
Andrej Karpathy—former OpenAI research director and Tesla AI lead—posted on X in February 2025 describing a new coding style he called “vibe coding”. His original definition: “fully giving in to the vibes, embracing exponentials, and forgetting that the code even exists”.
Karpathy’s context was specific: throwaway weekend projects and personal prototypes, not production systems. He described using Cursor Composer with Claude Sonnet, barely reading the diffs, hitting Accept All when things looked roughly right. “I ask for the dumbest things like ‘decrease the padding on the sidebar by half’ because I’m too lazy to find it. I ‘Accept All’ always, I don’t read the diffs anymore”.
When something broke, his approach was straightforward: copy the error message, paste it back to the AI, iterate until it worked. No understanding required. “Sometimes the LLMs can’t fix a bug so I just work around it or ask for random changes until it goes away”.
Karpathy explicitly qualified vibe coding as appropriate for “throwaway weekend projects” and code that’s “not serious” and “no one has to maintain”. Collins English Dictionary named “vibe coding” its Word of the Year for 2025. Merriam-Webster added an entry by March 2025.
The term’s spread from Karpathy’s narrow definition to a broad catch-all for any AI-assisted coding has created confusion in policy discussions. That confusion matters. If all AI-assisted development gets called “vibe coding” you can’t have nuanced conversations about where AI tools help and where they create risk.
How Does Vibe Coding Differ from AI-Assisted Engineering?
AI-assisted engineering is the professional standard. Developers use LLMs to generate code but review, test, and understand all generated code before committing it to production. Simon Willison’s golden rule provides the clearest boundary: “I won’t commit code that I can’t explain exactly what it does”.
Vibe coding explicitly rejects this standard. The developer doesn’t read, understand, or review the generated code. The difference lies in the developer’s relationship to the output, not the tool itself. Same AI, fundamentally different practice.
Willison puts it clearly: “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 confusion arises because both use the same tools—Cursor, Copilot, Claude. The difference is entirely in developer discipline and process.
Willison notes that professional software developers need to create code that demonstrably works and can be understood by other humans. Vibe coding to a production codebase is “clearly risky”.
Lumping vibe coding with responsible AI use creates policy paralysis. You can’t write sensible guidelines when the same term covers both throwaway weekend experiments and production deployments.
What Is Augmented Coding and How Does Kent Beck Define It?
Kent Beck—creator of Test-Driven Development and Extreme Programming—introduced “augmented coding” as a disciplined alternative. It embraces AI assistance while preserving craftsmanship. His core principle: the value system is the same as hand coding—tidy code that works—but the developer doesn’t type much of the code themselves.
Beck’s framework: “In vibe coding you don’t care about the code, just the behaviour of the system. In augmented coding you care about the code, its complexity, the tests, & their coverage”.
Augmented coding integrates AI into established engineering practices rather than abandoning them.
Test-Driven Development (TDD): Write failing tests first, use AI to generate implementations that pass, refactor while keeping tests green.
“Tidy First” principle: Separate structural changes (refactoring) from behavioural changes (features), with small frequent commits.
Code review remains standard: The developer understands and reviews everything the AI generates.
Test coverage requirements: Maintained or increased, not abandoned.
Beck described his practical experience using Augment Remote Agent for complex transliteration tasks in his BPlusTree3 project. He spent about four weeks building a performance-competitive, production-ready B+ Tree library in Rust and Python while travelling and recovering from a concussion.
Augmented coding sits in the middle ground. Not the “YOLO weekend project” of vibe coding, but also not the pre-AI traditional development workflow. Beck positions this as “beyond the vibes”—getting AI’s speed benefits without sacrificing the quality practices that make code maintainable.
How Do Vibe Coding, Augmented Coding, and AI-Assisted Engineering Compare Across Key Dimensions?
The terminology represents a spectrum, not a binary choice. Most teams fall somewhere along it, often in different places for different tasks. Steve Krouse puts it well: “Vibe coding is on a spectrum of how much you understand the code. The more you understand, the less you are vibing”.
Here’s how they compare across five dimensions:
Review Process: Vibe coding has no review (Accept All always). Augmented coding uses peer review with TDD. AI-assisted engineering uses formal review with quality gates.
Understanding Level: Vibe coding means “forget the code exists”. Augmented coding requires partial understanding with strategic focus. AI-assisted engineering requires complete explanation capability.
Appropriate Use Cases: Vibe coding for throwaway projects and prototypes. Augmented coding for team projects with test coverage. AI-assisted engineering for production systems and customer-facing applications.
Testing Requirements: Vibe coding treats tests as optional. Augmented coding requires TDD (tests written first). AI-assisted engineering mandates automated plus manual testing.
Risk Level: Vibe coding carries high risk and is unsuitable for production. Augmented coding has medium risk depending on team discipline. AI-assisted engineering has low risk as professional standard.
Most engineering teams using AI tools are practising somewhere between augmented coding and AI-assisted engineering without having a name for it. The spectrum helps you identify where your team’s actual practice falls versus where it should fall for different project types.
A single team may use different approaches for different contexts. Vibe coding for internal hackathons, augmented coding for team projects, full AI-assisted engineering for production deployments. Having precise terminology enables policy discussions that acknowledge nuance rather than defaulting to blanket approval or prohibition.
When Is Vibe Coding Appropriate? The Optimistic Case
Karpathy himself scoped vibe coding to legitimate use cases you shouldn’t prohibit.
Weekend hackathons and learning projects: Experimentation without production consequences helps developers learn new domains and AI tool capabilities.
Personal productivity tools (“software for one”): Non-programmers and developers building tools only they will use, where maintenance burden falls solely on the creator. Steve Krouse vibe coded apps to calculate weekly growth rates and propose to his fiancée. “I was able to vibe code these apps way faster than I could’ve built them, and it was a blast”.
Rapid prototyping for stakeholder feedback: Getting a visual prototype in front of decision-makers within hours rather than weeks, with no intention of shipping the prototype code.
Throwaway scripts and one-off utilities: Data migration scripts, one-time analysis tools, automation that runs once and is discarded.
Kevin Roose—New York Times journalist, not a professional coder—vibe coded several “software for one” applications successfully. This demonstrates the democratisation argument: non-programmers building functional software that would previously have required hiring a developer.
Simon Willison champions vibe coding for appropriate contexts while maintaining clear boundaries about when to stop: “I really don’t want to discourage people who are new to software from trying out vibe coding. The best way to learn anything is to build a project!” He’s published more than 80 experiments built with vibe coding.
The optimistic case is strongest when the code is personal, temporary, or explicitly disposable—when no one else has to maintain, secure, or depend on it. For a deeper exploration of when and why AI coding tools genuinely help, see the case for AI coding tools.
When Is Vibe Coding Inappropriate? Understanding the Risk Contexts
The risks of vibe coding emerge in specific, identifiable contexts where unreviewed code causes real damage.
Production systems and customer-facing applications: Unreviewed AI-generated code introduces security vulnerabilities, performance issues, and bugs that affect real users. In May 2025, Lovable, a Swedish vibe coding app, had security vulnerabilities in 170 out of 1,645 generated web applications allowing personal information to be accessed by anyone.
Security-critical or compliance-regulated environments: In December 2025, security researcher Etizaz Mohsin discovered a security flaw in the Orchids vibe coding platform. In July 2025, SaaStr founder documented Replit’s AI agent deleting a database despite explicit instructions not to make changes.
Complex codebases with multiple contributors: Vibe-coded additions create maintenance burden for the entire team. Code that the original developer doesn’t understand becomes unmaintainable when they leave or when requirements change.
Systems requiring long-term maintenance: Code you don’t understand today becomes code no one understands tomorrow. “When you vibe code, you are incurring tech debt as fast as the LLM can spit it out”, says Krouse.
The evidence goes beyond anecdotes. CodeRabbit analysis of 470 open-source GitHub pull requests found AI-co-authored code contained approximately 1.7 times more issues compared to human-written code. Security vulnerabilities were 2.74 times higher in AI-generated code. Logic errors were 75% more common. Readability issues spiked more than three times.
GitClear analysis of 211 million lines of code from 2020-2024 found code refactoring dropped from 25% of changed lines in 2021 to under 10% by 2024. Code duplication increased approximately four times in volume. Code churn nearly doubled.
Thoughtworks Technology Radar placed vibe coding on “Hold”—their strongest caution level. “As AI coding assistants gain traction, so does the body of data and research highlighting concerns about complacency with AI-generated code”.
For a comprehensive analysis of the long-term costs of vibe coding and technical debt implications, see our detailed examination of code quality degradation, security vulnerabilities, and why understanding matters for maintainability.
Why Does This Terminology Matter for Engineering Leaders?
Precise terminology isn’t academic pedantry. It’s the foundation for clear policy, productive team discussions, and sound risk management.
Policy foundation: Without shared definitions, “we use AI coding tools” could mean anything from vibe coding prototypes to AI-assisted production engineering. Policy requires precision.
Team communication: When a developer says “I vibe coded this,” does the team know whether that means a throwaway prototype or a production feature? Shared vocabulary eliminates ambiguity.
Risk management: Understanding where on the spectrum your team operates lets you match risk controls to actual practice rather than applying blanket rules.
Addressing anxiety about being cautious: Feeling cautious about unreviewed AI-generated code isn’t being a Luddite—it’s stewardship. Kent Beck uses AI tools daily through augmented coding while maintaining strict quality standards. Leading voices in software engineering share this caution.
Cautious decision-making about AI tools is the same engineering judgement that prevents shipping untested code or skipping security reviews. It’s professionalism, not resistance to innovation.
The goal isn’t to prohibit AI tools but to ensure teams use them at the appropriate point on the spectrum for each context. This vocabulary enables the policy and framework discussions covered in later articles—the AI productivity paradox for the measurement evidence, and senior engineers adapting or resisting for team dynamics challenges.
How to Start Discussing AI Coding Practices With Your Team
Start with shared definitions, not opinions. This article’s terminology gives you a neutral starting point that doesn’t assume any position is right or wrong.
Here’s a framework for productive policy discussions:
Name the spectrum: Introduce the vibe coding / augmented coding / AI-assisted engineering terminology so everyone knows what they’re discussing.
Acknowledge enthusiasm: Developers experimenting with AI tools are showing initiative. The question is how to use AI responsibly.
Distinguish contexts: Help the team identify which projects or tasks warrant which level of rigour. Hackathons and prototypes are different from production deployments.
Set boundaries collaboratively: Teams that co-create their AI usage policies are more likely to follow them than teams given top-down mandates.
Avoid the common trap of framing this as “old school vs new school”. Kent Beck created TDD and embraces AI through augmented coding. Being pro-quality and pro-AI go hand in hand.
This is the beginning of a larger conversation. The framework for responsible AI-assisted development provides the detailed implementation playbook. For navigating team dynamics, see how senior engineers are adapting to AI coding tools. For the strategic framework tying all topics together, see our full strategic analysis of vibe coding and the death of craftsmanship.
FAQ Section
Is vibe coding the same as using GitHub Copilot or ChatGPT for coding?
Not necessarily. Vibe coding is defined by the developer’s behaviour—accepting AI-generated code without reviewing or understanding it. A developer using GitHub Copilot who reads, tests, and understands every suggestion is practising AI-assisted engineering, not vibe coding. The tool doesn’t determine the category—the developer’s level of review and understanding does.
Did Andrej Karpathy invent vibe coding or just name it?
Karpathy coined the specific term “vibe coding” in a February 2025 post on X, describing a practice he’d been experimenting with using Cursor Composer and Claude Sonnet. The underlying behaviour—accepting AI-generated code without close review—existed before the term, but Karpathy’s naming crystallised it into a concept the industry could discuss and debate.
Is augmented coding just a fancy term for using AI tools responsibly?
Augmented coding is Kent Beck’s specific framework that integrates AI code generation with established engineering practices like Test-Driven Development, the Tidy First principle, and mandatory code review. It’s more structured than simply “being careful with AI”—it has concrete methodology including writing tests before AI generates code and separating structural from behavioural changes.
Can I vibe code for personal projects but use AI-assisted engineering at work?
Yes, and this context-switching is exactly what the terminology spectrum is designed to support. Many developers vibe code personal projects and weekend experiments while maintaining strict review and testing standards for professional work. The key is your organisation’s policies clearly distinguish which contexts permit which approach.
Why did Collins Dictionary name “vibe coding” Word of the Year 2025?
Collins selected “vibe coding” because it captured a significant cultural moment: AI tools making software development accessible to non-programmers for the first time at scale. The selection reflected the term’s rapid spread from a single social media post in February 2025 to mainstream usage within months.
What does Thoughtworks mean by putting vibe coding on “Hold”?
Thoughtworks Technology Radar uses “Hold” to indicate practices that organisations should approach with caution. For vibe coding, this means Thoughtworks’ experienced engineering advisors believe it carries material risk for production use cases and recommend organisations proceed carefully, particularly for code that will be maintained, deployed to users, or handles sensitive data.
Is it possible to vibe code safely?
Vibe coding is safer in specific contexts: personal projects, throwaway prototypes, hackathon experiments, and code running in sandboxed environments like Claude Artifacts. The risk increases with the code’s intended lifespan, audience, and access to sensitive data. For disposable code that only you will use, the risks are minimal. For anything else, augmented coding or AI-assisted engineering is more appropriate.
How do I know if my team is vibe coding or doing AI-assisted engineering?
Ask three questions: Does the developer review and understand every line of AI-generated code before committing? Are there tests covering the AI-generated code? Can the developer explain what the code does and why? If the answer to any of these is “no” for production code, the team is closer to vibe coding than AI-assisted engineering on the spectrum.
Does being sceptical of vibe coding make me a Luddite?
No. Kent Beck—who created Test-Driven Development and Extreme Programming—uses AI tools daily through augmented coding while maintaining strict quality standards. Thoughtworks, one of the most respected engineering consultancies, placed vibe coding on “Hold”. Scepticism about unreviewed code is engineering judgement, not resistance to innovation.
What is the difference between vibe coding and no-code or low-code platforms?
No-code and low-code platforms provide constrained visual interfaces with pre-built components and guardrails. Vibe coding uses general-purpose LLMs to generate arbitrary code from natural language prompts with no inherent constraints or guardrails. Vibe coding can produce more flexible and powerful results but also introduces unbounded risk because the generated code has no structural limitations.
Will vibe coding replace traditional software engineering?
No credible source suggests this. Even vibe coding’s strongest proponents, including Karpathy himself, scope it to throwaway and personal projects. Production software engineering requires understanding, testing, security review, and maintainability—practices that vibe coding explicitly skips. AI tools are changing how engineers write code, but the need for engineering discipline remains.
How should I update my team’s coding standards to account for AI tools?
Start by adopting the three-tier terminology (vibe coding, augmented coding, AI-assisted engineering) and mapping which approach is acceptable for each project type. Define clear expectations for code review, testing, and understanding of AI-generated code in production contexts. The framework for responsible AI-assisted development provides a detailed implementation playbook.
