Vibe coding is not “let the AI write the code and call it a day”. It’s a way of working where you set the goals, the constraints and the feedback; an AI agent builds; you validate and correct. Done well, it speeds up prototypes and real features. Done badly, it leaves you with a pile of technical debt, security holes and code nobody understands.
In this post I’ll walk you through what it actually is, where it came from, what the real data says about its risks, and I’ll leave you a method with guardrails so you can use it seriously: control, testing and security.
What “vibe coding” is and where the term came from
The term was coined by Andrej Karpathy (OpenAI co-founder and former director of AI at Tesla) in February 2025. His original description: “you fully give in to the vibes, embrace exponentials, and forget that the code even exists”. In other words: you describe what you want in plain language, you accept the AI’s output with minimal review, and you focus on iterating toward results instead of on every line of code.
In practice, rather than writing every line yourself, you describe the outcome and let an AI assistant generate most of the work. You act as architect + QA + PM: you set the direction, review, test and iterate.
An important distinction: Simon Willison (creator of Datasette) argues that if you review and fully understand all of the code, that is NOT vibe coding: it’s just using an LLM as a writing assistant. Vibe coding means accepting a certain amount of black box.
Why it is taking off right now
- More mature tooling: Claude Code, Cursor, GitHub Copilot, Replit Agent, Lovable and OpenAI Codex all make for fast prompt → code → preview cycles.
- Delivery pressure: in IT, DevOps and product, speed matters. Vibe coding promises a first working prototype in hours, not days.
- Mainstream adoption: Y Combinator reported that 25% of its Winter 2025 startups had codebases that were 95% AI-generated. Even Linus Torvalds used it for personal projects (January 2026).
- Cultural recognition: Collins English Dictionary named it Word of the Year 2025.
When to use vibe coding (and when not to)
When to use it
- Prototypes and internal MVPs
- Automations, scripts, tooling
- Repetitive UIs (dashboards, CRUD, landing pages)
- Personal projects and learning
When not to (or only with a lot of discipline)
- Critical systems (finance, healthcare, production)
- Security-sensitive work (auth, cryptography, permissions)
- Projects where nobody reviews or tests the result
The real numbers: documented risks
There are studies and hard numbers every IT professional should know about before adopting vibe coding:
Security
- CodeRabbit (2025): code co-written with AI has 2.74x more security vulnerabilities, 1.7x more “major” issues and 75% more misconfigurations than code written without AI.
- Veracode (October 2025): LLMs make code more functional, but they do NOT make it more secure.
- Lovable: out of 1,645 applications vibe-coded on their platform, 170 had live security vulnerabilities.
Productivity (the surprise)
- METR (July 2025): a randomized controlled trial with experienced developers found they were 19% slower with AI tools, even though they themselves estimated they had been 24% faster. Overconfidence is real.
Code quality
- GitClear: refactoring dropped from 25% (2021) to under 10% (2024). Code duplication quadrupled. Code churn nearly doubled.
Real-world incidents
- July 2025: Replit’s AI agent wiped a production database despite explicit instructions not to make any changes.
- February 2026: a BBC reporter was hacked through a security flaw in a vibe-coded app (the Orchids platform).
- September 2025: Fast Company reported on the “vibe coding hangover”: engineers stuck in “development hell” with code they don’t understand.
My method: vibe coding with guardrails
With the risks laid out, here’s a practical method for using vibe coding with discipline. The point isn’t to avoid it, it’s to use your head:
- Define the scope: “this is in / this is out”. Without a clear scope, the AI generates features nobody asked for.
- Define success criteria: concrete examples of the input and the output you expect.
- Iterate in short cycles: 10-20 minutes per cycle, tops. Review, test, iterate.
- Use version control from day one: Git from the very first prompt. Every iteration is a commit.
- Minimum tests: smoke tests at the very least. If the AI generated an API, hit it with curl. If it generated a form, submit it with junk data.
- Security review: secrets, permissions, inputs, dependencies. This part is not optional.
A starter prompt (copy/paste)
Act as a senior engineer.
Goal: [describe the feature in 1-2 lines]
Stack: [Next.js/Node/Python/Bash/etc]
Constraints:
- Do not hardcode secrets; use environment variables
- Validate all inputs
- Handle errors with clear messages
- Include at least one test per critical flow
Deliverables:
1) Code changes
2) List of files created/modified
3) Steps to run it locally
4) Security checklistPost-generation review checklist
- Secrets: no keys, tokens or passwords in the repo. Environment variables, always.
- Inputs: validate and sanitize everything (query params, forms, JSON, headers).
- Errors: clear messages for the user, useful logs for you, and nothing sensitive leaking out.
- Dependencies: pin versions and check for known CVEs.
- Permissions: principle of least privilege. If something doesn’t need root access, don’t give it root access.
- Tests: at least one smoke test per critical flow.
Conclusion
Vibe coding is a powerful tool if you use it with discipline: a speed multiplier, not a replacement for judgment. The data shows the risks are real (more vulnerabilities, more technical debt, and a false sense of productivity) but it also shows that with the right guardrails the payoff is genuine for prototypes, automations and internal tooling.
The winning combination: clear goals + short cycles + tests + a security review. If you aren’t willing to review what the AI generates, it isn’t vibe coding: it’s Russian roulette with your codebase.