So what is vibe coding?
Vibe coding is a software development approach where the developer describes what they want in natural language and an AI tool generates the code. The person operating the AI model does not necessarily write, review, or fully understand every line of code that gets produced. The focus shifts to the outcome while the AI handles the implementation.
The term was coined by Andrej Karpathy, a co-founder of OpenAI and former AI lead at Tesla, in a post on X in February 2025. He described it as a workflow where you "fully give in to the vibes" and forget that the code even exists. Collins Dictionary later named vibe coding its Word of the Year for 2025, which shows how quickly the term escaped its original niche.
"If an LLM wrote every line of your code, but you have reviewed, tested, and understood it all, that is not vibe coding. That is using an LLM as a typing assistant."
Simon Willison, programmerPlenty of developers use AI to help speed up the writing of code, but they still read it carefully, test it, and clean it up. Vibe coding is the looser version where the output moves ahead without that level of scrutiny. That is when it stops being just a workflow choice and starts becoming a serious quality issue.
For the testing side of this conversation, see How AI Is Changing Software Testing, What Is AI Testing?, AI Assurance Pro for Testers, and Will AI Replace Software Testers?. Those pages explain why verification work gets more valuable as AI-generated code spreads.
Vibe coding is everywhere now
By 2026, vibe coding is past the novelty stage. The numbers all point the same way. AI is now responsible for a big share of the code teams actually ship.
The productivity gains are real. Sonar found that 82% of developers say AI helps them code faster and 71% say it helps them work through harder problems. That helps explain why adoption moved this quickly.
The harder question is what happens to all that extra AI generated output once it starts piling up in real codebases.
What happens to quality
More code shipped faster sounds good until you look at what it does to review and testing.
In December 2025, CodeRabbit looked at 470 open-source GitHub pull requests and compared code co-authored by AI against code written by humans. The AI-assisted code had roughly 1.7 times more major issues. That does not prove every AI-heavy workflow is sloppy. It does show why faster output still needs careful review and testing.
On security: A 2025 Veracode GenAI Code Security Report found that approximately 45% of AI-generated code samples fail security tests and contain critical vulnerabilities included in the OWASP Top 10 list.
With vibe coding, code can look finished before anyone has properly tested it. A security flaw, missing permission check, or bad dependency can sit there quietly until the app is live.
More code, but the same number of reviewers
AI does not just produce code with different failure patterns. It also produces a lot more of it, faster than most review and testing setups were built to handle.
The time pressure of reviewing code does not go away just because the code came from an AI assistant. Writing speeds up. Checking often slows down. That is how teams end up with more code in motion and less confidence in what is landing.
Verification is where it gets hard
Developers are moving faster and shipping more, and by their own admission they are not fully confident in what is going out the door.
Sonar's 2026 State of Code survey asked developers directly. The answers were blunt:
- 96% of developers said they do not fully trust that AI-generated code is functionally correct
- Only 48% said they always check AI-assisted code before committing it
- 61% agreed that AI often produces code that looks correct but is not reliable
- 38% said reviewing AI-generated code takes more effort than reviewing code written by a human colleague
These numbers are coming from developers who actively use the tools and like the speed boost. They are not anti-AI holdouts. They are describing what happens next. Code that compiles and looks tidy can still hide edge-case failures, integration problems, or security gaps that only show up later. That is the same basic reason teams keep concluding that software testers are still needed in AI coding workflows.
Developers themselves ranked reviewing and validating AI-generated code as the most important skill for an AI-assisted coding environment.
Sonar: The AI trust gapThe people getting the most out of AI coding tools are also the ones saying verification matters most. That is not a contradiction. It is just what AI-assisted development looks like once the novelty wears off.
After the stats, teams still have to decide what to do next. The best follow-ups are How to Test LLM Applications, What Is Hallucination Testing?, How to Become an AI Tester, and Sonar's AI trust gap writeup, because that is where the quality problem turns into testing work.
What traditional testing was built to do, and why AI breaks it
Most testing methodologies were designed for deterministic systems. You run a test, you get a predictable output, you check whether it matches what you expected. Pass or fail. That model worked for decades.
AI disrupts it in two ways.
First, AI-generated code fails differently than human-written code fails. Logic errors, security gaps, and architectural problems in AI-generated code often do not look like bugs on the surface. The code compiles. It runs. It passes simple checks. The problem shows up later, under specific conditions or real-world load.
Second, when the software being built is itself an AI system, a model, an agent, or an AI feature, the testing problem gets harder. AI outputs are non-deterministic. Ask the same question twice and you get two different answers. Both might be fine. One might not be. A standard test suite cannot tell you. You need someone who understands probabilistic evaluation, bias testing, hallucination risk, and behavioral consistency well enough to build coverage for a system that does not behave the same way twice.
Most QA teams were not originally trained for that. NIST and OWASP both treat this as a trustworthiness problem, not just a tooling problem. Once AI is part of the workflow or part of the product, testing has to widen with it.
Is vibe coding a problem or just a shift?
Mostly, it comes down to what happens after the code gets written.
Vibe coding is not inherently reckless. For prototypes, internal tools, and early-stage exploration, moving fast with AI and iterating on results is a completely reasonable approach. The people building the next generation of products are going to use these tools. That ship has sailed.
The risk pattern is more specific than "AI coding is dangerous." It is what happens when vibe-coded applications move from prototype to production without proper review, and when teams assume that because AI wrote it, it is probably fine. The Sonar data shows that the developers using these tools do not actually believe that. 96% of them said so directly.
So the conversation keeps circling back to verification. Once more AI-written code heads toward production, review and testing become the bottleneck whether a team planned for it or not.
That bottleneck is not only a QA concern. It can become a business risk when leaders, customers, auditors, or insurers ask what evidence exists. The guide on AI insurance risk and AI testers looks at that side of the problem.
What software teams should do with that
None of this is glamorous, but it matters.
Teams adopting AI coding tools need to strengthen their verification work, not cut it. The fact that AI can write code faster is an argument for investing more in testing, not less. More output moving through the pipeline means more places for defects to hide.
Standard code review processes built for human-written code may not catch what AI-generated code tends to produce. The failure modes are different. Hallucinated API calls, security patterns sourced from low-quality training data, business logic the AI guessed at rather than inferred from real requirements. These are things standard review checklists were not built around, because they did not exist before.
And for teams building actual AI features, the testing challenge goes past the code itself. Now you are validating the behavior of a system that does not behave the same way every time. That is a different job from running a regression suite.
Why people start looking for AI testing paths
Once AI-generated code becomes normal, teams start asking who actually knows how to verify it well. That question is bigger than one badge or one course, but it does explain why AI-specific testing paths are getting more attention.
One path people look at is the ASTQB AI Assurance Pro™ designation, which combines foundational testing, AI-specific testing methodology, and generative AI testing. It is not the only path, but it does give people a structured way to show they have gone deeper on this than casual tool use.
Vibe coding is not really a story about typing less. It is a story about what happens when software gets produced faster than it gets challenged.