Guide

What Is Vibe Coding?

A plain-English 2026 guide to vibe coding: where the term came from, what it actually means now that Karpathy has renamed the professional version 'agentic engineering', the tools people use, and the documented security, maintainability and open-source costs.

September 30, 2026 · The AI Rankings

Quick answer: Vibe coding is building software by describing what you want in natural language and accepting the AI’s code largely without reading it. Andrej Karpathy coined the term in February 2025 — “fully give in to the vibes, embrace exponentials, and forget that the code even exists” — and Collins English Dictionary made it Word of the Year on 6 November 2025 (Wikipedia’s vibe coding entry collects the record). In 2026 it is both an ordinary way to get a working prototype in an afternoon and a documented way to ship insecure software: Veracode’s 2026 GenAI Code Security Report found AI models failed 44% of security-relevant coding tasks, and Georgia Tech’s Vibe Security Radar counted CVEs attributed to AI coding tools rising from six in January 2026 to 35 in March 2026 (Cloud Security Alliance). The most useful thing to know is that Karpathy himself moved on: in February 2026 he proposed “agentic engineering” for the professional version — the same agents, with oversight — and reserved “vibe coding” for throwaway work (The New Stack).

This guide is the explainer, not the shopping list. If you want the ranked tools, see best AI for coding for models, IDEs and agents, and best AI website builders for the prompt-to-app platforms. If you want the one-line definition in context with the rest of the vocabulary, see the AI glossary.

What is vibe coding?

Vibe coding is writing software by telling an AI model what you want in ordinary language, running whatever it produces, describing what is wrong, and repeating — without reading the code closely enough to explain it.

The defining feature is not the AI. It is the absence of review. A developer who prompts a model for every line but reads, tests and understands the result is doing something else; the programmer Simon Willison put the boundary bluntly: “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.”

Karpathy’s original description, posted in February 2025, made the point in the other direction. He described seeing stuff, saying stuff, running stuff and copying-pasting stuff, and added the two lines that became the term’s real definition: “I don’t read the diffs anymore” and “Accept All” as standard practice. He was describing a weekend project, and said so.

That is why the term is contested. It began as a self-aware description of a low-stakes way of working, was adopted by vendors as a description of software development in general, and has since acquired a second meaning that its users did not intend: code nobody on the team can explain. Andrew Ng criticised it in June 2025 for exactly that drift, arguing it misleads people into assuming engineers using AI simply go with the vibes.

The practical definition, in 2026: you are vibe coding when you could not answer the question “what does this function do and why is it safe?” about code you are about to ship.

Where the term came from: a timeline

The word travelled from a single post to a dictionary entry in nine months, which is part of why its meaning is so unstable.

The timeline matters for one reason: almost every confident claim about vibe coding is dated. Karpathy’s 2025 post described weekend projects; his 2026 one describes professional work where the human’s job is oversight. Advice written in between tends to be wrong in both directions.

Vibe coding vs AI-assisted coding vs agentic engineering

These three describe different amounts of human attention, and conflating them is the single biggest source of bad arguments about AI and software.

AI-assisted coding is the mainstream case and barely needs a name. In the Stack Overflow Developer Survey 2025, 84% of more than 49,000 respondents said they were using or planning to use AI tools, which is a statement about assistance, not autonomy.

Vibe coding is the subset where review is skipped deliberately. It is a legitimate technique with a narrow correct use, and it is the only one of the three that is defined by what you do not do.

Agentic engineering is Karpathy’s proposal of 8 February 2026 (The New Stack), a year after he coined vibe coding, and his phrasing is the clearest available description of the practice: “the new default is that you are not writing the code directly 99% of the time. You are orchestrating agents who do and acting as oversight.”

The pattern that operationalises this is spec-driven development: you write a specification and a plan first, the agent implements against it, and the spec becomes the artefact under review rather than the prose prompt. GitHub open-sourced a toolkit for it, Spec Kit, in September 2025, and Amazon’s Kiro shipped as a spec-driven agent; both are covered in best AI for coding. For the broader concept of goal-directed AI systems, see what is agentic AI.

What vibe coding actually looks like

Stripped of the argument, the loop is short and the same everywhere.

1. Describe the outcome. “A page where people upload a CSV and see a chart of the second column.” Not a function signature — a result.
2. Accept the output. The tool writes files, installs packages, sets up a database, runs the app.
3. React to what you see. “The chart is too small.” “It breaks on empty rows.” “Add a login.”
4. Repeat until it looks right. Stop when the screen matches your head.

Step four is where the whole argument lives. “Looks right” and “is right” diverge in exactly the places you cannot see: authorisation, input validation, error paths, secrets handling, what happens at a thousand rows instead of ten.

Two honest pictures of who does this and why:

The non-engineer building something that did not exist. A marketer who needs an internal dashboard, a teacher who wants a quiz tool, a founder testing whether anyone wants the product at all. The alternative is not better code — it is no software. For this person vibe coding is a straightforward win, provided the thing never holds anyone else’s data. Linus Torvalds used Google Antigravity in January 2026 to vibe code the Python visualiser for a personal audio-effects project, which is a fair illustration of the category: even people who can write the code sometimes do not want to.

The professional prototyping. An engineer who needs to know whether an approach works before committing a week to it. They vibe code the spike, learn the answer, and throw it away. The failure mode is that the spike ships.

The tools people vibe code with

The tooling has split into four categories that get lumped together and should not be. What separates them is what comes out the other end: a hosted app, a repository, a component, or a change to a codebase you already own.

Prices are headline list prices, change frequently, and credit-based plans can cost far more than the sticker in heavy use. The maintained tables live on best AI website builders for the prompt-to-app platforms and best AI for coding for the models, IDEs and agents; this page does not try to rank them.

The distinction that matters for anyone deciding: the prompt-to-app platforms are vibe coding by design, and the agentic IDEs are only vibe coding if you choose not to read the diff. Cursor and Claude Code will show you every change; whether you look is a decision, not a feature.

One more practical point. The common professional pattern is not to pick one: use a prompt-to-app platform to get to something working, then move the repository into an agentic IDE for the part that needs engineering. That handoff is where the next section starts.

Where vibe coding fails: the 70% problem

The most durable criticism is not that AI code does not work. It is that it works up to a point and then stops, and the point is always the same one.

Addy Osmani named this the 70% problem: AI reliably produces the roughly 70% of a system that “compiles and looks right”, and the remaining 30% is the part that makes software shippable — his list is “error handling, edge cases, performance optimization, security hardening, accessibility, integration testing, deployment concerns”. None of those are visible on the screen when the demo works.

Two consequences follow, and both are uncomfortable in opposite directions.

The first is that the last 30% is where experience earns its keep. Osmani’s conclusion is that “junior developers who only know how to get the 70% are less valuable than senior engineers who can efficiently close the remaining 30%”, because “the hard part of software engineering was never typing the code”. The skill that AI devalues is typing; the skill it makes more valuable is evaluating — which he notes is “a fundamentally different (and arguably harder) skill” than writing.

The second is that the 70% is genuinely worth having. A working prototype in an afternoon is not nothing, and treating it as nothing is the mirror-image error to treating it as a finished product.

Where vibe coding fails: security

This is the part of the picture with the best evidence and the widest gap between perception and measurement.

Nearly half of AI-generated code fails a security test. Veracode’s 2026 GenAI Code Security Report, published on 28 July 2026, found an average security pass rate of 56% on security-relevant coding tasks with no security-specific prompting — meaning models failed 44% of the time, while their code compiled almost 100% of the time. Cross-site scripting was the worst category by a distance: models passed just 15% of the time, failing to secure code against XSS in 85% of attempts (Veracode infographic). The Cloud Security Alliance’s April 2026 note cites Veracode’s 2025 figure of 45%, from the previous edition of the same test.

Bigger and newer models have not fixed it. Across the models Veracode has tracked, large models scored 53%, medium 51% and small 51% — no meaningful advantage to scale — and models built for coding were no safer than general-purpose ones. Reasoning models did somewhat better, at 56% against 51%, and the strongest single result was GPT-5.5 at 68%. Veracode describes the pass rate as virtually unchanged since its 2025 report: models have become far better at producing code that works while the security of that code has stood still.

The vulnerabilities are now showing up in the CVE record. Georgia Tech’s Vibe Security Radar project, announced on 13 April 2026, scanned more than 43,000 security advisories and used code history and metadata signatures to attribute vulnerabilities to the tool that introduced them. Graduate research assistant Hanqing Zhao’s team confirmed 74 cases, of which 14 were critical and 25 high risk, including command injection, authentication bypass and server-side request forgery. The trend is the striking part: 18 cases across the last seven months of 2025, then 56 in the first three months of 2026 — six in January, 15 in February and 35 in March alone, per the Cloud Security Alliance’s breakdown. Georgia Tech says Claude and GitHub Copilot account for most of the cases detected, partly because they leave clearer signatures in the code they generate, so the split is partly a measure of what is detectable rather than of which tool is worse.

That confirmed count is a floor, not a ceiling. The researchers estimate the true number is five to ten times higher — 400 to 700 cases — according to the Cloud Security Alliance’s synthesis.

Deployed vibe-coded apps leak. Security firm Escape.tech scanned about 1,400 vibe-coded applications and found 2,038 highly critical vulnerabilities, more than 400 leaked secrets, and 175 separate instances of exposed personally identifiable information including bank account data (Escape.tech). The platform-level precedent is older and clearer — in May 2025, 170 of 1,645 web applications built on Lovable were found to allow unauthorised access to personal information.

Two mechanisms are specific to AI-generated code, rather than being ordinary bugs arriving faster:

• Slopsquatting. Around 20% of AI-generated code references packages that do not exist (Cloud Security Alliance). An attacker who registers a commonly hallucinated package name gets their code installed by anyone who runs the install command without checking.
• Confident volume. Apiiro’s analysis of Fortune 50 repositories, as reported by the Cloud Security Alliance, found AI-assisted developers committing at three to four times the rate, while monthly security findings rose roughly tenfold, from about 1,000 to more than 10,000.

If you take one operational thing from this section: a vibe-coded app that holds other people’s data needs a security review before it is public, and the tools for that are listed on best AI code review tools.

Where vibe coding fails: maintainability

Security is the acute problem. Maintainability is the chronic one, and it shows up in the shape of codebases rather than in incidents.

GitClear’s longitudinal study of 211 million changed lines of code from 2020 to 2024 found four trends moving together: refactoring fell from 25% of changes in 2021 to under 10% in 2024, code duplication rose roughly fourfold, copy-pasted code exceeded moved code for the first time in two decades, and code churn nearly doubled. Copying instead of refactoring is precisely what a model does when it cannot see, or is not asked to consider, the rest of the system.

A CodeRabbit analysis of 470 open-source GitHub pull requests in December 2025 put numbers on the review burden: AI co-authored code contained roughly 1.7 times more “major” issues than human-written code, with security vulnerabilities appearing 2.74 times more often and misconfigurations 75% more often. (Both the GitClear and CodeRabbit figures above are as collected in Wikipedia’s vibe coding entry rather than read from the original reports.)

Two effects worth naming:

• The speed is partly borrowed. The much-cited METR randomised controlled trial of July 2025 had 16 experienced open-source developers complete 246 tasks, and found that allowing early-2025 AI tools increased completion time by 19% — while the participants predicted a 24% reduction. The perception of speed and the measurement of it pointed in opposite directions. This is a 2025 result on 2025 tools and should not be generalised to 2026 agents, but it is the strongest evidence that self-reported productivity is unreliable.
• Debugging moves, it does not disappear. In the Stack Overflow Developer Survey 2025, the top frustration with AI tools, cited by 66% of developers, was AI solutions that are “almost right, but not quite”, and 45% said debugging AI-generated code is more time-consuming. Only 29% said they trust AI, down 11 points from 2024 (Stack Overflow), and only 3% highly trust its output.

In May 2026 two engineers behind the OpenClaw project’s Pi coding harness, Mario Zechner and Armin Ronacher, warned publicly of a coming “vibe slop” problem: companies trading near-term output for buggy software, outages and security debt. The warning is notable mainly for its source — the people building the agents, describing the failure mode of using them without review.

The incidents worth knowing about

Three cases get cited constantly and are worth stating accurately, because each is usually told with more certainty than the record supports.

Replit’s agent deleted a production database (July 2025). During a user’s vibe-coding session, Replit’s AI agent deleted a production database despite explicit instructions not to make changes. The lesson is about blast radius, not intelligence: an agent with write access to production can do what write access to production allows.

rsync’s incremental backups broke (May 2026). Users of rsync 3.4.3, released 20 May 2026, reported being unable to perform incremental file backups. Commits attributed to “tridge and claude” had begun appearing at version 3.4.1, and a GitHub issue objecting to AI assistance in the project went viral; maintainer Andrew Tridgell responded in a post titled “rsync and outrage”, explaining that he had used AI for test suites and hardening work. The accounts we found do not attribute the regression to the AI-assisted commits. The case is on this list because it became the public argument about AI in critical infrastructure, not because the cause is established.

An AI-built app invented its own reviews (February 2025). In Kevin Roose’s New York Times account of building “software for one”, one of his vibe-coded apps fabricated fake reviews for an e-commerce site. Nobody asked it to. It is the cleanest small illustration of what “looks right” means: the page rendered, the content was fiction.

The open-source problem

The least-discussed cost of vibe coding is not in anyone’s codebase. It falls on the maintainers of the open-source packages that vibe-coded apps are assembled from.

The argument was formalised in “Vibe Coding Kills Open Source”, a January 2026 working paper by Miklós Koren, Gábor Békés, Julian Hinz and Aaron Lohmann (arXiv 2601.15494, also published as CEPR discussion paper DP21145). Their model is economic rather than empirical, and the mechanism is straightforward: when an agent selects and assembles open-source packages on a user’s behalf, the user never reads the documentation, never files a bug, and never becomes a contributor. Productivity rises because the cost of using open source falls — but the engagement through which maintainers earn their returns, in reputation, contributions and hiring, falls with it. Their conclusion is that under widespread vibe coding, “sustaining OSS at its current scale… requires major changes in how maintainers are paid”. Because the paper is a theoretical model, it produces no headline percentage, and anyone quoting one is over-reading it.

The empirical side of the same problem has already arrived as a workload. On 26 January 2026, cURL’s Daniel Stenberg announced the end of the project’s bug bounty, which stopped on 31 January. Over its life the programme had paid out more than $100,000 for 87 confirmed vulnerabilities; the decisive number is the confirmation rate, which ran “north of 15%” historically and “plummeted to below 5%” from 2025 onward, swamped by AI-generated submissions. His stated reason was not cost but attrition: the “never-ending slop submissions take a serious mental toll to manage”.

GitHub acknowledged the pattern in February 2026, describing an “Eternal September for open source” and shipping maintainer controls including the ability to restrict pull requests to collaborators. Whatever one thinks of the economics, the tooling response has begun.

How to vibe code without creating a problem

Vibe coding is a technique with a correct scope. These are the rules that keep it inside it.

Decide up front whether the thing will ever hold someone else’s data. This single question sorts almost every project. A personal tool, a prototype, a demo, an internal dashboard behind a real login — vibe code freely. Anything that will accept a stranger’s email address, file or payment is not a vibe-coding project any more, whatever it started as.

Never give an agent write access to production. The Replit case is the entire argument. Agents work against a branch, a staging database and a test environment; a human promotes.

Read the diff at exactly one point: before it ships. You do not need to review every intermediate step — that is what the agents are for. You need to review what is about to be deployed. Karpathy’s own distinction between vibe coding and agentic engineering is this review step and nothing else.

Check the dependencies the model added. Around a fifth of AI-generated package references do not exist, and a hallucinated name that does resolve is a supply-chain attack. Confirm that each new package is real, maintained and the one you meant.

Scan before you deploy. A secrets scan and a dependency audit catch a large share of what the research above describes, and both can run in CI. The tools are on best AI code review tools.

Write the spec, then let the agent work. Spec-driven development exists because a written specification gives you something to review that is shorter than the code and more precise than a prompt. It is the cheapest available upgrade from vibe coding to agentic engineering.

Treat the prototype as disposable. The most expensive mistake in this whole field is shipping the spike. If the prototype proved the idea, that was its job; budget for the rewrite rather than discovering you needed one.

Is vibe coding worth it? Segmented verdicts

Best for non-technical people building something that would not otherwise exist: yes, clearly. A working internal tool or personal app beats a spreadsheet and a wish, and the prompt-to-app platforms on best AI website builders get you there without code.

Best for prototypes and validation: yes, and this is the use Karpathy originally described. Build it, learn the answer, delete it.

Best for learning to program: partly. It shows you what is possible and nothing about why code is structured the way it is. Pair it with reading the output and asking the model to explain each part, which turns vibe coding into tutoring.

Best for internal tools behind a real login: yes, with a dependency check and a secrets scan before anyone else uses it.

Best for anything holding customer data or taking payments: no, not on its own. The security research is consistent and the failure mode is invisible until it is public. Use agents, review the diff, scan the result — that is agentic engineering, and it is a different discipline.

Best for large existing codebases: no. This is the agentic-IDE case, where the value is in the agent reading a codebase you own and you reading its changes. See best AI for coding.

Related reading

For the ranked tools, see best AI for coding and best AI website builders. For reviewing what an agent produces, best AI code review tools. For the concept underneath the 2026 version of all this, what is agentic AI, plus best AI agents and, for developers building their own, best AI agent frameworks. Definitions of every term used here are in the AI glossary.

Frequently asked questions

What is vibe coding in simple terms?

Vibe coding is making software by describing what you want in plain language and letting an AI write it, without reading the code it produces. You say what you want, run what comes back, describe what is wrong, and repeat until it looks right. The thing that makes it “vibe” coding rather than ordinary AI-assisted programming is that nobody reviews the code — if you read, test and understand what the model wrote, you are using AI as a fast typist instead.

Who invented the term vibe coding?

Andrej Karpathy, a co-founder of OpenAI and former head of AI at Tesla, coined it in a post on X in February 2025, describing a way of working where you “fully give in to the vibes, embrace exponentials, and forget that the code even exists” and where “Accept All” replaces reading the diffs. Merriam-Webster listed it as slang and trending in March 2025, and Collins English Dictionary named it Word of the Year on 6 November 2025. In February 2026 Karpathy proposed “agentic engineering” for the professional version of AI-assisted development, reserving “vibe coding” for throwaway projects.

Is vibe coding real programming?

It is a real way to produce working software and not a real substitute for software engineering. The distinction is the last 30% — error handling, edge cases, security hardening, integration testing and deployment — which AI produces unreliably and which determines whether software survives contact with users. A vibe-coded prototype is genuine output; a vibe-coded production system is an unreviewed one. Engineering is the reviewing, not the typing.

Is vibe coding safe?

Not by default. Veracode’s 2026 GenAI Code Security Report found that AI models failed 44% of security-relevant coding tasks, with an 85% failure rate on cross-site scripting specifically, and Georgia Tech’s Vibe Security Radar counted CVEs attributed to AI coding tools rising from six in January 2026 to 35 in March 2026 (Cloud Security Alliance). Security firm Escape.tech found more than 400 leaked secrets and 175 instances of exposed personal data, including bank account details, across about 1,400 deployed vibe-coded apps. It is safe for things that hold no one else’s data, and it needs a security review and a dependency check before anything public.

What is the best tool for vibe coding?

It depends on what you want out the other end. For a complete web app with logins and payments, Lovable is the usual starting point for non-technical builders; for internal business tools, Base44; for an app plus hosting and a database in one place, Replit; for individual UI components, v0. If the code already exists and you want an agent working inside it, that is an agentic IDE rather than a vibe-coding platform — see best AI for coding for the ranked comparison and best AI website builders for the prompt-to-app platforms with current pricing.

Can you vibe code an app without knowing how to code?

Yes, and that is the main reason the category exists. Platforms such as Lovable, Base44, Replit and Bolt.new will produce a deployed, working application from a description, managing the database, authentication and hosting for you. The honest limits are that you will not be able to fix it when it breaks in a way the model cannot fix, you will not know whether it is secure, and complex business logic tends to stall around the point where the app looks finished. Keep the first thing you build private, or internal, until someone who reads code has looked at it.

What is the difference between vibe coding and agentic engineering?

The difference is oversight, and it is the reason Karpathy proposed the second term in February 2026. In vibe coding you accept the output without reading it; in agentic engineering you delegate the writing to agents and keep the judgement, reviewing the diff and the tests before anything ships. His description is that “you are not writing the code directly 99% of the time, you are orchestrating agents who do and acting as oversight”. The tools are largely the same; the practice is not.

Is vibe coding dead in 2026?

No, but the word has narrowed. The practice — building from prompts without reading the code — is more common than ever among non-developers and for prototypes, while professional teams have moved to reviewed, spec-driven agent workflows and generally call that something else. What has died is the 2025 claim that vibe coding is how serious software gets written, a claim the person who coined the term retired himself in February 2026.

Why are some developers hostile to vibe coding?

Because they are the ones who inherit it. The maintainability research shows code duplication roughly quadrupling and refactoring falling below 10% of changes over 2020 to 2024 (GitClear), AI co-authored pull requests carrying about 1.7 times more major issues (CodeRabbit), and 45% of developers in the Stack Overflow Developer Survey 2025 saying that debugging AI-generated code is more time-consuming. Open-source maintainers have a sharper version of the complaint: cURL ended its bug bounty in January 2026 after the rate of confirmed vulnerabilities in submissions fell from above 15% to below 5%, swamped by AI-generated reports.

Does vibe coding hurt open source?

There is an argument that it does, and it is economic rather than technical. The January 2026 working paper “Vibe Coding Kills Open Source” models what happens when agents assemble open-source packages on a user’s behalf: productivity rises, but the users never read documentation, file bugs or become contributors, so the engagement maintainers depend on falls away. The paper is a theoretical model and reports no measured effect size. The observable evidence so far is on the maintainer-burden side — cURL’s bug bounty closure and GitHub’s introduction of maintainer controls in February 2026 in response to what it called an “Eternal September for open source”.

How much of the code at big tech companies is AI-generated?

Figures in the 30% to 75% range have been attributed to executives at large technology companies, but they are self-reported, inconsistently defined and rarely accompanied by a methodology, so we do not treat any specific number as verified. The one solidly sourced adoption figure is from the Stack Overflow Developer Survey 2025, where 84% of more than 49,000 developers said they were using or planning to use AI tools — a statement about tool use, not about the share of lines written. The earliest concrete vibe-coding-specific number remains Y Combinator’s March 2025 report that 25% of its Winter 2025 batch had codebases roughly 95% AI-generated.

← All guides