Vibe coding is building software by describing what you want to an AI model and accepting the generated code with little or no review. The high is speed and access for non-specialists. The low is that unreviewed code can carry flaws, and research suggests users of AI assistants can feel safer than they are.
Where does the term come from?
Wikipedia records that computer scientist Andrej Karpathy coined the term in February 2025, describing coding where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." Collins English Dictionary named it word of the year for 2025. Advocates say it lets amateur programmers produce software without long training. Critics point to lack of accountability, maintainability problems and a higher risk of security vulnerabilities.
What are the highs?
Speed to a first working version is real. A founder can test an idea in an afternoon. A designer can build an internal tool. A senior engineer can skip boilerplate. For throwaway prototypes and personal scripts, the trade is often fine, because the blast radius is small.
What does the research say about the lows?
Two studies are worth knowing, with a caveat: both tested older tools, so treat them as evidence of a pattern, not a score for today's models.
- Pearce and colleagues (published at the IEEE Symposium on Security and Privacy 2022) prompted GitHub Copilot across 89 scenarios tied to high-risk weakness categories from MITRE's Top 25. Across 1,689 generated programs, about 40 percent were vulnerable.
- Perry and colleagues, in a user study with Dan Boneh among the authors, found that participants with access to an AI assistant based on OpenAI's codex-davinci-002 wrote significantly less secure code than those without, and were more likely to believe their code was secure. Participants who trusted the AI less and engaged more with their prompts wrote code with fewer vulnerabilities.
The second finding is the one to remember. The risk is not just a flaw in the output. It is the false confidence that makes people stop checking.
What goes wrong in practice?
Constructed example. A solo founder prompts an assistant for a sign-up page with a database. It works. It also builds a query by joining user input into a string, stores a service key in the front-end bundle, and pulls three packages the founder has never heard of. Nothing looks broken. Each of those issues is ordinary and findable by standard checks. None was looked for.
Common categories to expect: injection and input handling, secrets in code, over-permissive access, missing authentication on new endpoints, and dependencies pulled without a second look.
What guardrails keep the speed?
You do not need to stop vibe coding. You need checks that run whether or not anyone read the code.
- Automated scanning in the editor and the pull request: dependencies, secrets, code patterns.
- Tests the model did not write, at least for security-relevant behavior.
- A rule that anything touching authentication, payments or personal data gets a human reviewer.
- Least privilege for the assistant: scoped tokens, no production credentials, a sandbox.
- Dependency policy, so new packages are checked before they land.
Where Safeguard fits
Safeguard's IDE extensions and pull request gates run dependency and code scanning while you build, reachability analysis narrows the list to what your code can reach, and the MCP Guardrail limits what an AI agent may do through MCP tools. For a quick look, the free in-browser scan at gold.safeguard.sh/scan checks up to 100 dependencies.
How to check or apply this
- Sort projects by stakes: throwaway, internal, customer-facing, regulated. Set review rules per tier.
- Turn on secret scanning and dependency scanning in every repository, including prototypes you might ship.
- Require human review for security-sensitive changes, regardless of who or what wrote them.
- Give AI tools the smallest credentials that work, and keep production out of reach.
- Ask the model to explain trade-offs, then verify the claims yourself.
- Record which parts of a codebase were generated, so reviewers know where to look.
- Re-run scans on a schedule, since new vulnerabilities are disclosed against old code.
Quick check
Is AI-generated code always insecure?
No. The studies found a meaningful share of vulnerable output and increased overconfidence, not universal failure. The point is to verify rather than assume.
Are the studies still current?
They tested Copilot as of 2021 and a 2022-era model. Newer models may behave differently, so run your own checks on your own code.
Sources
- Wikipedia: Vibe coding
- Pearce et al., Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions
- Perry et al., Do Users Write More Insecure Code with AI Assistants?
Last reviewed: 18 October 2026.
