Vibe coding: what the term really means, and why not in production

Vibe coding is not a design method, nor a synonym for “developing with AI”. It is a specific practice: describing what you want to a model, accepting the code without reading it and judging by the result. Here is the exact definition, the cases where it is useful, the documented risks in production and the method we apply to turn a vibe-coded prototype into a maintainable product.

Vibe coding: the exact definition

Karpathy’s post of 2 February 2025

The term comes from a post published on X on 2 February 2025 by Andrej Karpathy, co-founder of OpenAI and former Director of AI at Tesla. In it he describes a new way of programming, made possible by the assistants of the time (he mentions Cursor Composer with a Sonnet model):

• he describes what he wants, often by voice;
• he accepts all changes without reading the diffs (“Accept All”);
• he pastes error messages back without comment and lets the model fix them;
• the code ends up growing beyond his own understanding;
• this is fine, he says, for throwaway weekend projects.

The most quoted line sums up the spirit: you “forget that the code even exists”.

The deciding criterion: nobody reads the code

Working definition: vibe coding means producing software with an AI by accepting the code without reading it in detail, and judging only by the observed behaviour. The tool (Cursor, Claude Code, Lovable, Replit…) or the person’s profile matter little: what makes it vibe coding is the absence of review.

The developer Simon Willison put it as early as 19 March 2025: vibe coding is building software with an LLM without reviewing the code it writes. His personal rule for code meant to last: never commit anything he would not be able to explain to someone else.

From tweet to dictionary

The Collins dictionary made it its word of the year 2025. A year later, on 4 February 2026, Karpathy returned to the subject; several accounts report that he proposes the expression “agentic engineering” for the professional practice: orchestrating agents that write the code, with real engineering discipline.

What vibe coding is not

Vibe coding or AI-assisted development?

Calling any use of AI in development “vibe coding” is wrong, and this confusion discredits serious practices or legitimises uncontrolled deliveries.

Three common confusions

• “Vibe coding = no-code.” No. No-code hides the code behind a vendor platform. Vibe coding produces real source code, with all its defects passed on to you.
• “Vibe coding = a user-centred or UX design method.” No. The term describes neither a design approach nor an agile method. It describes only the relationship between a human and the generated code: they do not read it.
• “A senior developer who uses AI is vibe coding.” Not if they review, test and understand what they integrate. It is not the tool that decides, it is the level of control.

Where vibe coding is useful (and legitimate)

The good use cases

Vibe coding has real value: it reduces the cost of an experiment to almost nothing. We use it ourselves, within a precise framework.

For a startup, the vibe-coded MVP is a tool for validation, not a foundation. If the hypothesis is validated, the product is built on an architecture designed to last: this is the switch we organise in our startup and MVP support.

The minimum framework for vibe coding without risk

• [ ] Isolated environment (container, sandbox, dedicated cloud account with no access to the information system)
• [ ] No real personal data, no production secret in the project or in the prompts
• [ ] Test keys with a spending cap if a paid API is called
• [ ] End-of-life date written in the README, repository excluded from deployment pipelines
• [ ] Explicit decision at the end: throw it away, or start the method for making it reliable below

Why you don’t vibe-code in production

A prototype is for learning; software in production serves users and engages your responsibility. The risks of vibe coding in production have been measured.

Security: code that works is not code that is safe

Veracode’s 2025 GenAI Code Security Report (30 July 2025) tested more than 100 language models: 45% of the samples failed security tests and introduced OWASP Top 10 vulnerabilities. Cross-site scripting was not prevented in 86% of the relevant cases; Java reaches a 72% failure rate. And newer or larger models produce code that works more often, but is no safer. Without review, these flaws go into production.

Exposed secrets

Assistants readily reproduce hard-coded keys, committed .env files or tokens in front-end code. In an analysis published on 27 March 2025, GitGuardian found that around 6.4% of a sample of 20,000 repositories using Copilot contained at least one secret, against 4.6% for all public repositories. It is a correlation, not proof of causality, but it matches what we see in audits.

Hallucinated dependencies and slopsquatting

Models sometimes invent library names. The study “We Have a Package for You!”, presented at USENIX Security in August 2025, analysed 576,000 Python and JavaScript code samples produced by 16 models: on average, at least 5.2% of the packages suggested by commercial models and 21.7% for open-source models did not exist, amounting to more than 205,000 unique invented names.

The danger has a name, slopsquatting, a term attributed to Seth Larson (Python Software Foundation) in April 2025: an attacker publishes a malicious package on npm or PyPI under a regularly hallucinated name. In vibe coding, nobody checks the npm install. The supply chain also features in the OWASP Top 10 for LLM applications 2026 (LLM04, “Supply Chain”).

Missing tests and “functional but wrong” code

A vibe-coded prototype generally has no tests, or tests generated by the same model, which validate what the code does rather than what it should do. Our iones lab EXP-06 report illustrates this: of 138 fixes generated by agents on real tickets, 34% were accepted unchanged and 22% after rework. And 18 fixes were “technically working but wrong”: they passed the existing tests while being wrong. No test could catch them: you need a reviewer who knows the requirement.

Technical debt and maintainability

Vibe coding accumulates debt at high speed: duplication, inconsistent conventions, dead code. The day the product has to evolve, nobody knows its structure.

According to our iones lab EXP-01 report, with supervised agents (shared skills catalogue, systematic review), we measured −32% time on standard tasks (CRUD, tests, migrations, across 140 tickets), but no gain in understanding the requirement, architecture or edge cases, and +9% time on complex tasks at the start. AI speeds up what is already framed; without a framework or review, it mostly speeds up debt.

Accountability: who answers for code nobody has read?

In July 2025, the founder of SaaStr described how Replit’s agent, used in vibe coding mode, deleted his production database during an explicitly requested code freeze, then wrongly claimed that restoration was impossible.

Faced with a client, a user or an authority, “the AI wrote it” is not an answer. The GDPR requires security appropriate to the data processed; for manufacturers of products with digital elements, the reporting obligations of the Cyber Resilience Act have applied since 11 September 2026. You need a human able to explain, fix and take responsibility for every line in production.

From vibe-coded prototype to product: the 5-step method

Step 1: decide (discard, take over or rewrite)

Step 2: audit

A code audit before any go-live covers at least:

• Dependencies: real existence, creation date, maintenance, licence, vulnerabilities.
• Secrets in the code and the Git history, then rotation of whatever leaked.
• Static analysis (SAST) and manual review of sensitive areas: authentication, authorisations, payment, database queries.
• Personal data: which, where, on what legal basis.
• Architecture: separate environments, logging, backups.

# Secrets dans tout l'historique Git (TruffleHog v3)
trufflehog git file://. --only-verified

# Vulnérabilités connues des dépendances
npm audit --omit=dev          # Node.js
composer audit                # PHP
pip-audit                     # Python

# Slopsquatting : vérifier que chaque paquet existe et n'est pas apparu hier
for pkg in $(jq -r '.dependencies | keys[]' package.json); do
  echo "$pkg : $(npm view "$pkg" time.created 2>/dev/null || echo 'INTROUVABLE')"
done

A package that cannot be found, or was created very recently, calls for manual checking.

Step 3: put a safety net of tests in place

First freeze the current behaviour with characterisation tests on the critical journeys, then write tests from the requirement (business rules, edge cases, expected errors), not from the code. End-to-end tests (Playwright, for example) on the journeys that generate revenue protect what follows. This is the core of our quality assurance and testing offer.

Step 4: introduce human review

No more code, generated or not, goes in without a pull request reviewed by another developer, with a named owner per module (CODEOWNERS file). Acceptance criterion: Willison’s rule. If the reviewer cannot explain the code, it does not pass, especially when it “makes the tests pass”.

Step 5: refactor under CI control

Refactoring is done in small steps, each protected by a CI that blocks the merge if a check fails: installation from the lockfile (npm ci), lint, tests, npm audit --audit-level=high, secrets scan, SonarQube quality gate and branch protection requiring an approved review. Nothing stops you from continuing to use assistants: within this framework, it is no longer vibe coding, it is AI-assisted development.

Frequently asked questions

Vibe coding: a prototyping tool, never a delivery mode

Vibe coding has a precise definition: describe, accept without reading, judge by the result. For exploring an idea, it is remarkably effective. In production, it passes measured risks on to your users: flaws, exposed secrets, booby-trapped dependencies, code that is wrong but “green”, and technical debt.

Does your vibe-coded prototype have to become a product? We can audit it, put the safety net of tests in place and take over development with a senior team, directly or on a white-label basis. Start with a code audit or contact us: reply within 48 to 72 hours, no-commitment discussion, under NDA.