We know AI builds fast. We also know that things happen inside the AI black box that no one plans or intends. We set out to open the box and look at what AI produced---not in a demo, not in a blog post about how great Cursor is---the real code in real repositories that real teams are shipping.
We examined vibe-coded GitHub repositories identified by a "fingerprint" (projects built primarily with AI coding assistance) across a range of frameworks, languages, and team sizes to find patterns, failure modes, and recurring structural problems we hypothesized were there.
We expected some variation. Different tools, different teams, different codebases. Instead, we got the same handful of patterns, over and over, regardless of any of that.
| Pattern | Prevalence |
|---|---|
| Compiled build artifacts committed to source control | Extremely common |
Untyped or any -typed parameters erasing type safety |
|
| Pervasive | |
| God-object files exceeding 1,500 lines | Common |
| Silent fallback chains masking errors | Pervasive |
| Hardcoded design values instead of token references | Nearly universal |
Security violations (eval , innerHTML , hardcoded secrets) |
|
| Frequent |
None of these are exotic. They're boring, structural, and completely invisible in a demo. The code compiled. The tests passed (when there were tests at all). The linters were clean. And underneath all of that, errors were being swallowed silently, missing data was getting papered over with defaults, and the codebase was quietly rotting from the inside.
That's the part that makes this worth writing about: no one would guess any of this was happening. Nobody wants to look.
Silent failures. This is the most dangerous pattern we found, and also the most common. An AI assistant writes a try/catch
, the catch block logs the error (or doesn't), and execution continues as if nothing happened. The app looks like it's working. The user sees no error. But the data is wrong, an operation got skipped, and the system is now in a state nobody accounted for.
The fix isn't complicated; it's just a habit AI doesn't have by default: every error needs to be visible in three places at once: the console, the UI, and as a thrown exception that actually halts execution. If an error only shows up in a log nobody's watching, it isn't handled; it's hidden.
Phantom correctness. This is the quieter cousin of the above. Code that compiles, passes the linter, and operates on the wrong data or a fabricated value without anyone noticing. Two of the biggest contributors: any
types used to make a type error go away instead of actually resolving it, and hardcoded values standing in for something that should have come from a real data source. Both look completely fine in a diff. Neither one throws an error. They just quietly mean the code isn't doing what it looks like it's doing.
None of this is really an intelligence problem. LLMs are very good at producing code that looks correct. That's what they're optimized to do. The gap is that "looks correct" and "is correct" are different claims, and nothing in the default generation loop checks the second one. An AI assistant will also frequently declare a task done once the obvious, cheaper, high-priority, "big win" issues are resolved, leaving warnings and info-level findings "for later," which in practice means never, because nothing forces a return trip.
Guardrails (rules, skills, etc.) are genuinely useful, and they work; but they all act at one specific moment: when the code is being written. They're authoring-time discipline.
There's a second category of problem that shows up only after the code executes: the happy-path trap in async code (what happens on the second concurrent click, not the first), library lock-in from importing a vendor SDK directly across dozens of files, tests that assert implementation details instead of actual behavior and break on every refactor. None of these show up in the demo. They show up in production, or six months later, when someone who wasn't there when the AI wrote it has to touch the code.
And even with perfect authoring-time discipline, there's a problem no amount of prompt engineering solves: LLMs are probabilistic, so the code they generate will drift from design intent over time regardless;
Clean code that no longer matches the design is still drift. That's a structural problem, not a discipline one, and it's a separate problem from anything a rules file can catch.
We turned these findings into a governance framework: six principles and a set of forbidden/required controls organized by the class of problem they prevent, not by technology. It's built to drop directly into whatever you're already using: a system prompt layer, per-tool rules for Cursor, Copilot, or Claude Code, and a set of on-demand skills for the failure classes that need more than a one-line rule.
It's free — no signup required, just an email so the pdf and zip file land in your inbox. If you're shipping a meaningful amount of AI-generated code, it's worth fifteen minutes to see how many of these patterns are already sitting in your own repo. And how you prevent future drift.
We also have other expansion packs in the pipeline. If we have your contact info, we can send them to you.
If you've run into other failure patterns we didn't cover here, I'd genuinely like to hear about them. Ping me on X or LinkedIn.