We Scanned 424 AI-Generated Projects. These 10 Mistakes Kept Showing Up

We scanned 424 AI-generated projects built with Lovable, Bolt, v0 and Copilot-assisted repos. 21.6 million lines of code, one deterministic engine, the same 295 rules for every project. The scans produced 346,944 issues. That is one issue every 62 lines.

14% of projects shipped a leaked secret. 87% carry at least one security finding. Of 183 Lovable projects, exactly two are clean on security.

The full dataset is open under CC-BY-4.0, methodology and corrections included: github.com/qualityclouds/stat-e-of-ai-code-2026-. None of these failure classes surprised us. We have catalogued 13 million+ issues across 950+ enterprise platform instances over 9 years, and the AI corpus reproduces the same classes at higher volume and higher speed.

The mistakes cluster into five categories. Here are the ten that appear most in our data, and what each one costs.

Category 1: Security gaps

1. Missing authorisation logic. Security findings appear in 87% of the projects we scanned; only 56 of 424 are clean. The sharpest cut is architectural: 98% of the 206 Supabase-backed projects carry at least one security finding, against 77% of everything else, at 2.4x the security-issue density. The exposure is client-side: service-role keys reachable from the browser, auth logic running on the client, public storage buckets. The missing Row Level Security behind CVE-2025-48757, which hit 170+ Lovable apps, is this mistake at scale.

2. Hardcoded secrets and leaked credentials. 14% of projects in our corpus shipped at least one leaked secret or hardcoded credential. These are public repositories. Anyone with the URL has the key, and an attacker who forges a token never needs to steal a password.

3. Decade-old vulnerabilities, reintroduced. Dynamic values bound to href without URL validation, a HIGH finding, appear in 63% of projects. The vulnerability class is older than most of the frameworks involved. Models trained on public code reproduce public code's mistakes.

Category 2: Supply chain

4. Unpinned and invented dependencies. Wildcard dependency versions, a HIGH security finding, show up in 52% of projects (6,038 findings). Any upstream release, careless or malicious, rides into the next build. Our ruleset catches the pinning problem. The naming problem, assistants inventing plausible package names that attackers then register (the technique now called slopsquatting), needs registry verification on every import an assistant suggests.

Category 3: Correctness

5. Business logic flaws. Negative order quantities. Prices below zero. Discounts that stack forever. In our scans this is where AI-generated code fails hardest, because the model never knew the rule existed. Generic scanners miss these because they aren't syntax errors; they are violations of rules only your business knows.

6. Silent failure. Async operations without error handling appear in 79% of projects. It fires 138,601 times, our single most common HIGH finding. Empty catch blocks that swallow errors appear in 67% of projects, network requests without timeouts in 71%. This code works in the demo and fails without a trace in production. The speed you gained on generation comes back as an invoice on debugging.

Category 4: Maintainability

7. Density that compounds. The corpus averages 16 issues per 1,000 lines. The median Lovable project ships 644 issues, roughly 4.5x the median of any other platform. Nested ternaries appear in 78% of projects, console.log instead of structured logging in 74%. Each finding is small. At 644 per project, they are the maintenance backlog.

8. The supervision effect. Copilot-assisted repos, where a human drove the architecture and reviewed the output, come in at 9.1 issues per 1,000 lines. Fully generated Lovable projects come in at 18.1, double. React + Vite, the default output of most prompt-to-app tools, is the dirtiest stack in the corpus at 80% higher density than the non-web baseline. The more of the codebase the model authors unsupervised, the worse the density gets. That gap is the debt that compounds after the demo.

Category 5: Agent behaviour

9. Acting with excessive permissions. Agents run under developer accounts, and developer accounts can touch production. The Replit incident, where an agent deleted a production database during a code freeze, is the canonical case. After 9 years of watching what changes on governed enterprise platforms, our position is simple: an agent's write access deserves the same scrutiny as a contractor's.

10. Misleading the human who approves. Wiz's GhostApproval research showed major assistants resolving a disguised symlink to a developer's SSH keys while the approval dialog displayed a harmless filename. Review is only a control if the reviewer sees what the agent sees.

What to do on Monday morning

Three of these categories (authorisation, business logic, agent behaviour) sit exactly where traditional static analysis is weakest, which is why so much of this ships despite passing scans.

A practical first step: we published a free, open-source agent skill called production-ready-check. You install it, ask your coding agent "is this production ready?", and it grades your codebase 0 to 100 across Security, Performance, Maintainability, Manageability and Scalability, with a file-level citation for every finding. It runs fully offline, needs no account, and catches most of categories 1, 3 and 4 before a human reviews the pull request.

It's a heuristic estimate, and it says so. For versioned, deterministic rules and an auditable score you can compare across runs and teams, that's what the Production-Ready Score in Quality Clouds Hub does. It runs the same engine and the same 295 rules that produced every number in this post, built on 9 years of governance data from 950+ enterprise platform instances. The Free tier is permanent: portal.qualityclouds.ai.

And if you want to check our numbers, don't take our word for them. The per-repo CSV, the methodology and the corrections log are all in the open dataset.

Frequently Asked Questions