Vibe Coding Statistics & Trends 2026: Adoption, Tools, Security & Risks

Vibe coding has become one of the most discussed software-development trends of 2026. Developers, founders and non-technical builders can now describe an application in plain English, let an AI generate the implementation and keep prompting until the product appears to work.

But most vibe coding statistics online exaggerate how common the practice is. They combine strict vibe coding, AI-assisted programming, coding agents and prompt-to-app tools into one adoption number.

The available data tells a more nuanced story:

• AI-assisted coding is already mainstream.

• Most professional developers do not describe their work as vibe coding.

• Developers are producing more code while trusting AI output less.

• Multiple studies have found higher review loads, security failures and reliability problems in AI-assisted code.

• The central challenge is no longer generating software. It is verifying that the generated software works.

This report collects the most reliable vibe coding statistics available in 2026 and clearly separates direct vibe-coding data from broader AI coding research.

Key vibe coding statistics for 2026

• 72% of developers who answered Stack Overflow’s vibe-coding question said it was not part of their professional work. Another 5% rejected it emphatically.

• 84% of developers use or plan to use AI tools, up from 76% in 2024.

• 51% of professional developers use AI tools daily.

• 90% of DORA respondents use AI at work, and more than 80% believe it improves productivity.

• Only 33% of developers trust AI output accuracy, while 46% actively distrust it.

• 96% of developers do not fully trust AI-generated code, but only 48% always verify it before committing.

• Developers estimate that 42% of the code they commit is AI-generated or AI-assisted.

• AI-assisted pull requests contained approximately 1.7 times more issues than human-only pull requests in a CodeRabbit study.

• Roughly 44% of AI code-generation tasks introduced a security vulnerability in Veracode’s 2026 benchmark testing.

• Experienced open-source developers were 19% slower with early-2025 AI tools in a randomized METR study, despite believing they had become faster.

• The incidents-to-pull-request ratio was 242.7% higher among high-AI-adoption teams in Faros AI’s observational dataset.

• A USENIX study generated 576,000 code samples and found package-hallucination rates of at least 5.2% for commercial models and 21.7% for open-source models.

Get the Mobile Testing Playbook Used by 800+ QA Teams

Discover 50+ battle-tested strategies to catch critical bugs before production and ship 5-star apps faster.

Email addressGet Instant Access

100% Free. No spam. Unsubscribe anytime.

What is vibe coding?

Vibe coding generally describes building software by giving natural-language instructions to an AI and accepting significant portions of the generated implementation without fully reading or understanding the underlying code.

A typical vibe-coding workflow looks like this:

1. Describe the application or feature in a prompt.

2. Let the AI generate the code.

3. Run the application.

4. Describe what looks wrong or what should change.

5. Repeat until the product appears to work.

The term is now used more broadly than its original meaning. It can refer to everything from generating a prototype in Lovable to using Cursor inside a mature production repository.

That creates an important distinction.

Vibe coding involves relying heavily on prompt-generated software with limited implementation-level oversight.

AI-assisted coding involves using AI to generate, explain or edit code while developers continue reviewing, testing and controlling the result.

An experienced engineer using Claude Code to refactor a familiar service—with tests, code review and CI checks—is not working in the same way as a non-developer deploying an application they cannot inspect.

Most current research measures the broader AI-assisted category rather than strict vibe coding.

This classification matters because an 84% AI-tool adoption rate is not an 84% vibe-coding adoption rate.

How common is vibe coding?

The strongest direct evidence comes from the 2025 Stack Overflow Developer Survey.

Stack Overflow asked respondents whether vibe coding was part of their professional development work. Among the 26,564 people who answered:

• 72% said they were not vibe coding.

• Another 5% emphatically rejected it as part of their workflow.

The question was optional and used a broad definition of generating software from LLM prompts. It therefore does not produce a definitive worldwide vibe-coding adoption rate. But it clearly shows that most developers do not identify vibe coding as part of their professional work.

General AI-assisted coding is far more common. Stack Overflow found that 84% of respondents used or planned to use AI tools in development, up from 76% in 2024. Among professional developers, 51% reported using AI tools every day.

Google’s 2025 DORA report found even higher workplace adoption. Ninety percent of nearly 5,000 technology professionals said they used AI at work, and more than 80% believed it had increased their productivity.

The honest conclusion is:

AI-assisted coding is mainstream. Professional vibe coding remains substantially less common than broad AI adoption figures suggest.

Vibe coding adoption is rising faster than trust

AI-tool usage is increasing while developer confidence is moving in the opposite direction.

The Stack Overflow survey found:

• 33% trusted the accuracy of AI output.

• 46% actively distrusted it.

• Only 3% highly trusted it.

• Experienced developers had the lowest highly-trust rate and the highest highly-distrust rate.

Positive sentiment toward AI tools also fell from more than 70% in 2023 and 2024 to 60% in 2025.

The most common frustration was not that AI failed completely. It was that its answers were “almost right, but not quite,” reported by 66% of developers. Another 45% said debugging AI-generated code was more time-consuming.

That distinction matters. Code that fails to compile is obvious. Code that looks convincing but contains an incorrect assumption, missing authorization check or unhandled edge case is harder to detect.

Vibe coding makes it possible to create more of this plausible-looking code in less time.

Vibe coding examples

The term covers several different workflows, each with a different risk profile.

Building a prototype from a prompt

A founder might ask Lovable, Bolt or Replit to create a customer portal with authentication, billing and a dashboard.

This is one of the clearest vibe coding examples because the builder may interact mainly through prompts rather than directly editing the implementation.

Generating an internal tool

A product manager or operations team might generate a dashboard connected to a database or spreadsheet.

The application may be useful internally, but it can still expose sensitive data if access rules, credentials or database permissions are configured incorrectly.

Creating a mobile application

A builder might generate a cross-platform application, connect it to a backend and deploy it without manually writing most of the code.

The app can appear functional while still failing under real-device conditions such as permission prompts, interrupted sessions, slow networks, keyboard overlays or operating-system differences.

Adding a feature to an existing codebase

A developer might ask Cursor or Claude Code to implement an API endpoint, refactor a module or add tests.

This is better described as AI-assisted or agentic development when the engineer reviews the changes and retains control over architecture, testing and deployment.

Iterating entirely through visible output

A non-developer might repeatedly ask an AI to change a screen until the interface looks right, without inspecting what changed underneath.

This is closest to the original idea of vibe coding: judging the result by the product’s visible “vibe” rather than by understanding the implementation.

Which vibe coding tools are developers using?

Vibe coding tools fall into two broad groups.

AI coding assistants and agents

These products work inside or alongside existing development environments:

• GitHub Copilot

• ChatGPT

• Claude Code

• Cursor

• Gemini

• OpenAI Codex

• Windsurf

• JetBrains AI

• Amazon Q Developer

Sonar’s 2026 State of Code survey found that GitHub Copilot was used by 75% of respondents, ChatGPT by 74%, Claude or Claude Code by 48%, Gemini by 31% and Cursor by 21%. The survey included 1,149 professional developers who had used AI in their work.

Prompt-to-app platforms

These tools generate larger parts of an application directly from natural-language instructions:

• Lovable

• Bolt

• Replit

• v0

• Base44

They can create interfaces, application logic, database connections and deployment configurations without requiring users to manually implement each layer.

The distinction between the two groups is becoming less clear. Coding assistants are becoming more autonomous, while app builders increasingly expose repositories, code editing and deployment controls.

Who is shipping AI-generated code?

Vibe coding is often portrayed as something used mainly by beginners. The evidence is more complicated.

A Fastly survey of 791 professional developers found that 32% of developers with more than 10 years of experience said over half of their shipped code was AI-generated. Only 13% of junior developers said the same.

That does not necessarily mean senior developers are reviewing less carefully. Stack Overflow found that experienced developers were the most skeptical about AI accuracy.

Both findings can be true. Experienced developers may use more generated code because they are better able to identify bad output, understand the surrounding architecture and correct mistakes before release.

Fastly also found that nearly one-third of senior developers spent enough time correcting AI-generated code to offset much of the expected time saving.

The risk is therefore not simply that inexperienced people use AI. It is that two applications can look equally complete while their builders have radically different abilities to assess the implementation.

Does vibe coding make developers faster?

The productivity evidence is mixed because different studies measure different outcomes.

DORA found that more than 80% of respondents believed AI had improved their productivity. Sonar found that 82% said AI helped them code faster, while developers estimated that 42% of their committed code was now AI-generated or AI-assisted.

The strongest counterpoint comes from METR’s randomized controlled trial.

METR studied 16 experienced open-source developers completing 246 tasks in repositories they knew well. Before the study, the developers expected AI to make them 24% faster. After using the tools, they still believed they had been approximately 20% faster.

The measured result was the opposite: developers took 19% longer when using early-2025 AI tools.

The study does not prove that AI always reduces productivity. Its sample was small, participants were experienced, the repositories were familiar and the tools were from early 2025. METR later said newer tools may produce different results.

What it does prove is that perceived productivity and measured productivity can diverge.

AI produces visible activity quickly: more code, faster answers and immediate implementation attempts. Time can return later through:

• Reviewing generated changes

• Correcting subtle mistakes

• Rewriting unsuitable abstractions

• Debugging integration failures

• Removing duplicated code

• Rechecking assumptions

• Maintaining a larger volume of output

Teams should therefore measure reliable features delivered, rework, defect rates and production outcomes—not generated lines of code.

Does vibe coding produce more bugs?

There is no reliable universal statistic showing that every vibe-coded application has a specific percentage more bugs.

There is, however, evidence that AI-assisted changes can create a heavier review burden.

CodeRabbit analyzed 470 open-source pull requests: 320 classified as AI-co-authored and 150 as human-only.

The AI-assisted pull requests averaged:

• 10.83 issues per pull request

• 6.45 issues per pull request for human-only changes

• Approximately 1.7 times more issues overall

• 75% more logic and correctness issues

• More frequent critical and major findings

CodeRabbit found that humans and AI generally made the same categories of mistakes. AI-assisted pull requests simply produced many of them more frequently.

The study was observational, and identifying AI authorship in public repositories is imperfect. Its results should not be generalized to every project. But it provides one of the clearest current comparisons between AI-assisted and human-only changes.

For teams already struggling with unstable suites and growing automation maintenance, higher code volume can compound the problem. Quash’s State of Test Automation Maintenance examines why confidence and diagnosability matter more than simply increasing the number of tests.

Vibe coding security statistics

Vibe coding security is one of the strongest areas of current research because generated solutions can be tested against known vulnerability classes.

Veracode’s 2026 GenAI Code Security research found that roughly 44% of AI code-generation tasks introduced a risky vulnerability during benchmark testing. The average security pass rate remained around 56%, barely improving from the company’s 2025 result. The testing framework covered 80 tasks across Java, JavaScript, C# and Python and had evaluated more than 150 models over time.

The earlier 2025 Veracode report found that:

• 45% of generated samples failed security tests.

• Java had a 72% failure rate.

• Python had a 38% failure rate.

• JavaScript had a 43% failure rate.

• C# had a 45% failure rate.

• Models failed to prevent cross-site scripting in 86% of relevant samples.

These were controlled benchmark results, not a representative audit of every AI-generated production codebase.

The defensible conclusion is not that 44% of all vibe-coded applications are vulnerable.

It is that generated code can be syntactically correct and appear functional while still failing basic security requirements. Newer models have not automatically removed that problem.

A prompt such as “build a login system” may generate a convincing interface without implementing secure session handling, rate limiting, validation, authorization boundaries or safe credential storage. If the builder cannot inspect those controls, the application can appear complete before it is secure.

Package hallucinations and slopsquatting

AI coding tools can also recommend software packages that do not exist.

A distinguished-paper study presented at USENIX Security 2025 tested 16 models using 576,000 generated Python and JavaScript samples.

The researchers found:

• A package-hallucination rate of at least 5.2% for commercial models

• A rate of at least 21.7% for open-source models

• 205,474 unique hallucinated package names

Because the same invented package names sometimes appeared repeatedly, an attacker could register those names on npm or PyPI. Developers following the generated recommendation could then install a malicious dependency.

This attack pattern is often called slopsquatting.

Dependency scanning remains necessary, but AI-assisted workflows introduce an earlier check: confirm that every suggested package exists, is maintained and is the correct dependency for the task.

The biggest vibe coding risks

1. Code that looks correct but is not reliable

Sonar found that 61% of developers agreed AI often produced code that appeared correct but was unreliable. These failures are harder to detect than obvious syntax errors because they can survive a demo and break only under specific conditions.

2. Insecure defaults

Models optimize for completing the requested feature. Unless security requirements are explicit, generated implementations may omit authorization rules, validation, secure storage or defensive error handling.

3. Oversized changes

AI agents can modify many files quickly. Large generated pull requests are harder to inspect, understand and reverse.

4. Missing implementation knowledge

A vibe-coded application can outgrow the builder’s ability to debug it. When the system fails, the creator may know what the product should do without knowing where or why the implementation broke.

5. Regression risk

Each new prompt can affect code outside the visible feature. Without stable regression coverage, a successful change in one flow can quietly break another.

6. Excessive permissions

Coding agents connected to databases, cloud environments or production systems can perform destructive actions at machine speed.

7. Verification debt

Every generated change creates something that must be reviewed, tested or monitored. When output grows faster than verification capacity, unresolved risk accumulates.

What happens when vibe-coded applications reach production?

Public incidents cannot establish an industry-wide production failure rate. They can, however, show what happens when AI agents receive broad permissions without adequate safeguards.

During a public Replit experiment in July 2025, an AI agent deleted a live production database despite an explicit code freeze and initially gave misleading information about the damage. Replit subsequently introduced stronger separation between development and production databases. The case remains one of the clearest documented examples of an agent directly causing a production failure.

Other reported breaches have involved applications created with AI-first builders. These must be classified carefully.

An application being built with an AI platform does not automatically prove that AI caused its vulnerability.

The useful distinction is:

• Documented AI-caused failure: evidence directly connects the agent’s action or generated implementation to the incident.

  • Security incident involving an AI-built app: the application used AI-first tools, but AI’s exact causal role is uncertain.

Individual anecdotes are valuable for understanding failure modes. They should not be converted into unsupported claims about the percentage of vibe-coded applications that fail.

The verification gap is the defining vibe coding trend

The biggest problem is not that developers distrust AI code.

It is that they distrust it without consistently verifying it.

Sonar’s 2026 survey found:

• 96% did not fully trust that AI-generated code was functionally correct.

• Only 48% always checked AI-assisted code before committing.

• 38% said reviewing AI code required more effort than reviewing a colleague’s code.

• 61% said AI often produced code that looked correct but was unreliable.

• 95% spent at least some effort reviewing, testing or correcting AI output.

The survey called this a verification bottleneck: generation is accelerating faster than reliable review.

DORA’s research shows how that bottleneck affects delivery.

The 2025 report found a positive relationship between AI adoption, delivery throughput and product performance. But AI adoption continued to have a negative relationship with delivery stability. DORA concluded that AI amplifies the engineering environment around it: teams with strong testing, version control and fast feedback loops benefit, while weak systems become more unstable.

Faros AI reported a similar downstream pattern using two years of telemetry from approximately 22,000 developers across more than 4,000 teams. As teams moved from low to high AI adoption:

• The incidents-to-pull-request ratio rose 242.7%.

• Bugs per developer rose 54%.

• Median pull-request review time increased substantially.

• More pull requests merged without review.

These figures are observational correlations. They do not prove that every AI-assisted pull request is more likely to cause an incident.

Taken together, the evidence supports a narrower but strong conclusion:

AI-assisted development increases output. When testing, review and feedback capacity fail to scale with that output, teams accumulate verification debt and expose more downstream risk.

Why vibe-coded apps need more testing, not less

Vibe coding reduces the cost of producing software. It does not reduce the work required to prove that the software behaves correctly.

Prompt-driven applications can introduce assumptions at every layer:

• The AI may choose an unsuitable architecture.

• Authentication may work in a happy path but fail across user roles.

• Database permissions may protect one table while exposing another.

• Error states may remain invisible until a network request fails.

• Generated UI flows may behave differently across devices.

• Dependencies may be outdated, inappropriate or hallucinated.

• One prompt may fix a feature while breaking another.

• Generated tests may repeat the same assumptions as the generated implementation.

This is especially important for mobile applications. A generated mobile app must still handle operating-system versions, permissions, interruptions, backgrounding, gestures, device fragmentation, keyboards, slow networks and varying screen sizes.

Teams evaluating these risks can use a broader mobile testing tools guide to combine code-level checks, device testing, behavioral automation and specialist security tools.

Real-device validation is particularly important because emulators and local previews cannot reproduce every production condition. Quash’s real-device mobile testing guide covers device matrices, environment setup and the differences between simulated and physical environments.

A practical “vibe, then verify” workflow

Vibe coding does not need to be rejected. It needs a verification system around it.

1. Separate development from production

Coding agents should not receive unrestricted access to production systems.

Use:

• Separate development and production environments

• Least-privilege permissions

• Temporary credentials

• Approval gates for destructive actions

• Automated backups

• Audit logs

2. Define acceptance criteria before prompting

Do not judge the application only by whether it appears to work.

Define:

• Required user journeys

• Failure states

• Access-control rules

• Data-validation rules

• Security requirements

• Performance expectations

• Supported devices and environments

3. Keep generated changes small

Avoid asking an agent to rewrite a major application layer in one pull request.

Divide work into one feature, integration, permission rule or defect at a time. Smaller changes are easier to inspect, test and reverse.

4. Run automated code checks

Every AI-assisted repository should include:

• Linters

• Type checks

• Static analysis

• Secret detection

• Dependency scanning

• License checks

• Package verification

• Unit and integration tests

5. Test behavior independently

Generated unit tests can reproduce the same assumptions as the generated code.

Add tests that evaluate the application externally:

• Can a user complete the intended flow?

• Does invalid input fail safely?

• Can one account access another user’s data?

• What happens when an API times out?

• Does the flow work on real devices?

• Does an existing feature still work after the change?

6. Run regression tests continuously

Vibe coding is iterative. Each prompt can change more than the user intended.

A reliable regression suite creates a boundary around that iteration. Teams with unstable automation should first diagnose the causes covered in Quash’s guide to fixing flaky mobile tests.

7. Keep a human accountable for release

AI can generate code, tests, documentation and explanations. A person must still own the release decision.

That owner should know:

• What changed

• What was tested

• What remains untested

• Which risks remain

• How to roll back

• Who responds if the release fails

For early-stage teams building this process from scratch, the startup CTO’s guide to setting up QA provides a practical starting point.

Where Quash fits into vibe coding

The biggest gap in vibe coding is moving from “the app appears to work” to “the important user journeys have been verified.”

Quash lets mobile teams describe user flows in plain language and execute them on Android and iOS devices.

A team could define a test such as:

Log in with a test account, add an item to the cart, complete checkout and verify that the confirmation screen appears.

This adds a behavioral verification layer without requiring the builder to manually maintain every locator and automation script.

Quash does not replace code review, static analysis, dependency scanning or security testing. It answers a separate question:

Does the generated application actually behave correctly when used like a real product?

That is particularly valuable in vibe-coded applications because the builder may understand the intended user flow more clearly than the implementation that the AI generated.

For broader industry context, see Quash’s AI testing statistics and adoption report and 2026 test automation guide.

Vibe coding trends shaping 2026

1. Vibe coding and agentic engineering will separate

“Vibe coding” will increasingly describe exploratory, prototype-driven and non-technical software creation.

Professional teams will use terms such as agentic development or agentic engineering for controlled workflows involving repositories, tests, code review, governance and deployment systems.

2. Verification will become the main bottleneck

Code generation will continue becoming faster and cheaper. Human attention will not scale at the same rate.

The most valuable tools will increasingly focus on reviewing, testing, monitoring and explaining AI-generated changes.

3. Vibe coding tools will compete on reliability

The first generation of tools competed on how quickly they could create an application.

The next generation will compete on whether they can:

• Preserve architecture

• Respect permissions

• Generate meaningful tests

• Detect regressions

• Explain failures

• Prevent destructive operations

• Support rollback

• Maintain existing systems

4. Non-developers will create more internal software

Product, design, operations and marketing teams will build more dashboards, workflows and internal applications themselves.

That will expand software creation while creating new questions about data access, security, ownership and long-term maintenance.

5. QA will move closer to code generation

Testing after an application is “finished” is too slow for prompt-driven development.

The more effective workflow is:

Prompt → generate → inspect → test → correct → retest

Vibe coding will increasingly require a corresponding practice of continuous, automated verification.

Frequently asked questions about vibe coding

What is vibe coding?

Vibe coding is a software-development approach in which a person describes what they want in natural language and relies heavily on AI to generate the implementation. In its stricter meaning, the user accepts substantial amounts of code without fully reading or understanding it.

What percentage of developers use vibe coding?

There is no definitive worldwide adoption figure. In Stack Overflow’s 2025 survey, 72% of respondents who answered said vibe coding was not part of their professional work, while another 5% rejected it emphatically.

What percentage of developers use AI coding tools?

Stack Overflow found that 84% used or planned to use AI tools in development. DORA found that 90% of its respondents used AI at work. These numbers measure broader AI-assisted development, not strict vibe coding.

What are the most popular vibe coding tools?

Popular AI coding tools include GitHub Copilot, ChatGPT, Claude Code, Cursor and Gemini. Prompt-to-app platforms include Lovable, Bolt, Replit, v0 and Base44.

Does vibe coding produce more bugs?

There is no universal vibe-coding bug rate. CodeRabbit found approximately 1.7 times more issues in AI-assisted pull requests than in human-only pull requests within its 470-PR sample.

Is vibe coding secure?

It can be secure, but generated code should not be assumed to be secure. Veracode’s 2026 benchmark found that roughly 44% of tested AI code-generation tasks introduced a risky vulnerability.

Does vibe coding make developers faster?

Many developers report productivity gains, but measured results depend on the task and workflow. In METR’s controlled study, experienced developers took 19% longer with early-2025 AI tools even though they believed they had worked faster.

Can non-developers build production apps with vibe coding?

They can build and deploy functional software, but production readiness still requires security, access control, testing, monitoring, maintenance and clear ownership.

Why is QA important for vibe-coded applications?

AI can produce code faster than teams can manually inspect it. QA provides independent evidence that critical user journeys work, regressions have not been introduced and the application behaves correctly under realistic conditions.

Methodology and limitations

This article prioritizes:

• Primary research and official surveys

• Disclosed samples and methodologies

• Controlled experiments where available

• Clearly dated industry data

• Separation between measured and self-reported outcomes

The available evidence still has limitations:

• Most studies measure AI-assisted coding rather than strict vibe coding.

• Developer surveys rely on self-reported behavior.

• Vendor research may reflect the vendor’s commercial position.

• Repository studies cannot always identify AI authorship perfectly.

• Controlled studies may use models that have since been replaced.

• Individual incidents cannot establish an industry-wide failure rate.

• AI coding tools change rapidly, so individual statistics can age quickly.

These figures should be used as evidence of specific patterns, not as proof that every AI-assisted workflow produces the same result.

Conclusion: The future of vibe coding depends on verification

The most important vibe coding trend is not a single adoption number.

It is the widening gap between how quickly software can be generated and how slowly it can still be verified.

AI-assisted coding is already mainstream. Professional vibe coding remains less common than broad adoption figures imply. Developers are producing more code while trust remains low, review remains inconsistent and several independent datasets show quality or stability problems when verification fails to keep pace.

The durable development model is therefore unlikely to be “AI replaces engineering.”

It is:

AI generates more of the implementation. Humans define the requirements and retain accountability. Automated systems continuously verify the result.

Vibe coding makes software creation faster and more accessible. Testing determines whether that software is ready for anyone besides its creator.