The vibe-coding call usually comes around day ninety
The pattern is consistent enough to be predictable. A founder or marketing lead builds something with an AI tool. It works. It launches. For two months it is the best decision they made all year — fast, cheap, and functional.
Then something breaks that nobody can explain. Or a form starts silently failing. Or a security scanner flags the site. Or the person who built it moves on and nobody else can safely change anything. The project that took a weekend now needs a specialist, and the specialist's first job is working out what is actually in there.
This is worth writing about without contempt, because the tools are genuinely good and the people using them made a reasonable call. The problem is not that AI wrote the code. It is that shipping code was the only step in the process.
What the 2026 vibe-coding data shows
The adoption figures explain the scale. Around 84% of developers now use AI coding assistance, while trust in the accuracy of that output has fallen from 40% to 29% year over year. That gap — near-universal use, declining confidence — is the story in one line.
On security, the measurements are consistent across independent sources:
- Veracode tested more than 100 language models on security-sensitive coding tasks and found 45% of generated samples introduced an OWASP Top 10 vulnerability.
- Escape.tech scanned over 1,400 vibe-coded production applications and found 65% had security issues, with 58% carrying at least one critical vulnerability.
- GitGuardian recorded 28.65 million new hardcoded secrets in public GitHub commits during 2025, up 34% year on year, with AI-assisted commits leaking at roughly 3.2% against a 1.5% baseline.
On debt, Forrester projects that 75% of technology decision-makers will face moderate to severe technical debt by the end of 2026, and organisations report technical debt rising 30–41% after adopting AI coding tools.
That last number is the one people misread. It is not primarily that AI writes worse code than a junior developer. It is that AI-assisted developers commit at three to four times the rate, so whatever your review process was missing before, it now misses three to four times as much.
The specific failures, in the order we find them
Auditing these codebases produces a remarkably repetitive list.
Secrets in the repository
API keys, database URLs, and payment credentials committed directly, usually because the model produced a working example with a placeholder and the placeholder was replaced with the real value in the same file. Often already in public git history, where rotating the key is the only real fix.
Authorisation that only exists in the browser
The admin panel is hidden from the interface if the user is not an admin. The endpoint behind it checks nothing. This is the single most common critical finding, and it is invisible until someone tries the URL directly.
Validation on the client only
Forms validate beautifully in the browser and accept anything sent directly to the server. The generated code did what was asked — it made the form validate — and nobody specified where.
No error handling on the unhappy path
Everything works when the payment succeeds, the upload completes, and the third-party API responds. When it does not, the user sees a blank screen and the business never learns the sale was lost.
Dependencies nobody chose
Packages pulled in to solve one small problem, several of them overlapping, some unmaintained, occasionally one that does not exist upstream at all. Nobody is tracking their vulnerabilities because nobody knows they are there.
Audit before you decide anything
If you own a site like this, the first move is not a rebuild quote. It is finding out what you actually have. A useful audit answers six questions:
- Are there secrets in the repository or its history? Run a secret scanner. If yes, rotate everything found before anything else happens.
- Is every privileged action checked on the server? Test the endpoints directly, not the interface.
- Is user input validated server-side? Particularly anything reaching a database or a file system.
- What happens on failure? Break a third-party call deliberately and watch what the user sees.
- What is in the dependency tree, and is any of it vulnerable or unmaintained?
- Can anyone other than the original author change it safely? If the answer is no, that is a business risk regardless of code quality.
That list takes a competent developer a couple of days on a typical marketing site or small application, and it converts an anxiety into a scoped decision.
Hardening beats rewriting, usually
The instinct after a bad audit is to start over. It is usually the wrong call. In most vibe-coded projects the product logic is sound — the founder knew what the thing should do, and the AI implemented it competently. What is missing is everything around it: tests, validation, error handling, secret management, logging.
Adding that to working code is a hardening project measured in weeks. Rebuilding throws away the one part that was fine.
The genuine exception is the data model. If entities and relationships were modelled wrongly at the start, every feature built on top inherits the mistake, and patching around it compounds forever. That is the one finding that justifies starting again — and it is worth knowing before you have built another six months on it.
Using AI properly, not less
None of this is an argument for writing everything by hand. The productivity gain is real and permanent. What has to be restored is the review layer that got removed alongside it: mandatory human review of generated code, secret scanning in CI so a leak never reaches a commit, dependency scanning, and a test suite that exists before the volume arrives.
The teams in trouble in 2026 are not the ones using AI aggressively. They are the ones who used AI to multiply output by four and left the review process sized for the old volume. That is a process failure with a technical symptom.
This is also, bluntly, where the difference between an AI draft and a production system shows up — the argument we make in AI website builders versus hiring an agency, and why the build-approach decision deserves a real answer up front. If you have inherited something built this way and want to know what you are sitting on, we will audit it and tell you straight.