Vibe coding, where you describe what you want and an AI assistant writes the code, is a fair way to get a first version in front of people. The vibe coding security risks show up afterward, once real users and real data are involved. The 2026 research points the same way: the code runs, it is often not safe, and the upkeep lands on whoever owns the code afterward.
This piece pulls together five recent sources and ends with a short list of checks to run before launch. Three of them come from companies that work in this field commercially, so we have stuck to what their reports state and said where they don’t explain their method. The sources don’t argue against using AI. They describe the gap between getting something to work and getting it safe, and the dull work on the far side of that gap.
A working demo hides the vibe coding security risks
Vibe coding runs on a simple feedback loop: does it work? If yes, keep going. That loop says nothing about whether the code is safe.
A July 2026 test of more than 100 AI models ran four rounds of coding tasks. Generated code passed a syntax check close to 100% of the time. It passed the security checks 56% of the time, so nearly 44% of results fail when the model gets no security-specific guidance. Here is how the groups compared:
| Group | Average security pass rate |
|---|---|
| All models | 56% |
| Coding-specialized models | 51% |
| General-purpose models | 52% |
| Reasoning models | 56% |
| Non-reasoning models | 51% |
By language, Python scored highest at 63% and Java lowest at 30%. The best single model on the leaderboard reached 68%.
Two limits matter before you quote any of this. The test used raw models, not agents or a team with tooling and human review, and it used no security prompting. A team that asks for secure code, scans the output and reviews it may do better than 56%, but the test doesn’t show whether it does or by how much.
An independent view comes from a June 2026 academic preprint that surveys the research on secure code generation. Its authors report that models can recognize relevant security principles and still fail to turn them into secure, working code, and that the field “still lacks a systematic understanding of how these techniques improve security.” That is why this article gives no figure for how much any single fix helps.
Scanning code for bugs is a different job from scanning for leaked keys.
Secrets are the quiet leak
A key pasted into a file is the simplest kind of leak, and a 2026 report on secrets sprawl says there are more of them than ever. It counted:
- 28.65 million new hardcoded secrets in public GitHub commits in 2025, a 34% rise and the largest one-year jump it has recorded.
- 1,275,105 leaked secrets for AI services, up 81% year on year.
- Commits made with Claude Code leaking secrets at 3.2%, against 1.5% across all public commits.
That last figure deserves caution. The report doesn’t explain how it identified AI-assisted commits, and it covers one tool. Read it as a hint that fast AI-assisted work may make this mistake easier, not as a measured rate for your project.
The same report has two findings that apply to private projects. Internal repositories are roughly six times more likely than public ones to contain hardcoded secrets, so “it’s private” is not a defense. And credentials confirmed valid in 2022 were still valid when retested in January 2026, with a validity rate above 64%. A key that leaked once and wasn’t rotated can keep working for whoever found it.
Deleting a file doesn’t remove a key from the repository’s history. The question that matters after launch is who keeps this code healthy.
The bill that arrives later
A software-quality benchmark published on 9 June 2026 draws on more than 30,000 systems and over 400 billion lines of code. Its central finding, in the report’s own words: “AI does not fix or break software discipline on its own. It amplifies what is already there.” Where quality is measured and managed, AI speeds delivery. Where it isn’t, it speeds up technical debt, cost and security exposure.
A few numbers from the report put that in context:
- In the report’s testing, AI-generated code had about twice the security risk violations of human-written code.
- AI-generated code was only 1.9% of enterprise production code, so this is an early picture.
- 86% of code in the benchmark falls below its recommended maintainability rating. With AI code at under 2% of the total, that figure mostly describes code people wrote by hand, which is our reading, not the report’s claim.
- A stronger architecture cuts issue-resolution time by 30%.
What follows from that is ours, not the report’s: when code is cheap to produce, there is more of it to understand, test and patch. A vibe-coded app with no owner after launch is a version of this problem a small company can easily meet. If you inherit one, the steps in our handover checklist apply as they are, and signs your architecture is slowing your growth describes what the upkeep cost looks like when it arrives.
What to check before real users arrive
An April 2026 research note from the Cloud Security Alliance gathers other studies on vibe-coding security debt and offers a practical list. We have used its recommendations as the base for this one. Run it before the app holds anyone else’s data. SAST is static analysis of your own code, and SCA checks the packages you depend on:
| Check | What it catches | First step |
|---|---|---|
| Scans in the build | Vulnerable packages, common code flaws | Add SAST and SCA so a failing scan blocks a release |
| Database access rules | Strangers reading other users’ data | Review Supabase or Firebase rules by hand |
| Secret scanning | Keys in the repo or the browser | Scan the code and its history, rotate what you find |
| New dependencies | Packages that don’t exist or aren’t the one you meant | Check each name, its age and its maintainer |
| Human review | Mistakes in login, permissions, payments, personal data | Have someone with security experience read those parts |
| Ownership | Nobody fixing anything after launch | Name who handles patches, keys and incidents |
A caution on this list: it lowers the risk and does not remove it. Those test figures cover raw models with no security prompting, and none of the numbers in this piece measure how much scans, reviews or better prompts improve the result, so we can’t give you a figure. Treat the list as the floor for anything that holds other people’s data, not as a guarantee.
In our view the first five cost little before launch and a lot after a breach. The last one costs nothing, and it is easy to skip.
When AI-built code is a reasonable choice
Our rule of thumb is to ask what happens if the app breaks or leaks. Three questions sort most cases:
- Does it hold other people’s data?
- Does it handle logins or money?
- Will it still be running in a year?
A prototype, a demo or an internal tool that holds nothing sensitive can answer no to all three, and vibe coding is a good fit. Any yes means the app has earned the checks above. If you would like a second pair of eyes before launch, a technical and security audit covers the same ground, and our look at where AI pays off in an existing product covers the product side.
Use AI to get to a first version quickly, then treat that code like any other code nobody has reviewed. Before launch: add scans to the build, lock down database rules, hunt for secrets and rotate whatever you find. Then name an owner for the code. If the app holds other people’s data or money, get an outside review before real users arrive.
Sources
- Veracode: 2026 GenAI Code Security Report press release, 28 July 2026
- Software Improvement Group: State of Software 2026, 9 June 2026
- GitGuardian: The State of Secrets Sprawl 2026
- Patir et al.: SoK: AI Secure Code Generation, arXiv preprint, 23 June 2026
- Cloud Security Alliance: Vibe Coding Security Debt, research note, 6 April 2026
Frequently asked questions
What is vibe coding?
Building software by describing what you want to an AI assistant and accepting the code it writes. It is a quick way to get a first version working. The risks in this article come from what happens when that code reaches real users and real data.
Is AI-generated code less secure than human-written code?
The studies point that way, with limits. A 2026 software-quality benchmark found AI-generated code had about twice the security risk violations of human-written code. A July 2026 test of more than 100 models found they passed security checks 56% of the time without security-specific prompting. Neither says every AI-built app is unsafe. Both say you should not assume it is safe.
Do newer AI models write safer code?
Not by much. The July 2026 test reported the security pass rate as virtually unchanged since last year. Coding-specialized models averaged 51% and general-purpose models 52%. Reasoning models did a little better at 56%, against 51% for non-reasoning models.
Is a private repository a safe place for API keys?
No. A 2026 secrets-sprawl report found that internal repositories are roughly six times more likely than public ones to contain hardcoded secrets, and that credentials confirmed valid in 2022 were still valid when retested in January 2026. Keep keys out of the code, and rotate any key that has ever been committed.
Can I launch a vibe-coded app?
For a prototype, a demo or an internal tool that holds nothing sensitive, usually yes. If the app holds other people's data, handles logins or payments, or will run for more than a few months, run the checks in this article first and decide who owns the code after launch.
What should I check first?
Start with two things: who can read and write your database, and whether any keys are sitting in the code or the browser. An April 2026 research note on vibe-coding security lists database access rules and secret scanning among its first actions for AI-built apps.
