Code is written in plain words now. You describe the task, the model hands back a finished app, it launches, and everything seems to work. But "works" and "safe" are two different words, and the distance between them is measured in other people's money and leaked data. By recent counts, nearly half of AI-generated code contains vulnerabilities, and one in three such projects ships with a hole open to anyone who simply follows the link.
The reason is simple. When a model writes code, it produces the most probable next chunk, not the most correct one. And it cannot see its own mistakes — because it looks at the code with the same eyes that wrote it. Catching those mistakes takes an outside view. Better yet, several views, each with its own blind spots.
So I built exactly that: a pipeline where the code passes through four different models in sequence, each from scratch, each with its own job. The first builds a plan and catches the crude stuff. The second, the mean one, digs deep — what breaks, where the side effects are, which edge cases. The third picks up what the first two walked past, and looks at boundaries and safety. The fourth pulls it together and rules: clean, or back for rework. The methodology is published in the open, with a DOI — not a trick, an engineering process.
To show how it works, I grabbed a live open-source project off GitHub — a task-management app in Python and Flask, about 2,700 lines, with registration, login, roles, email, and Telegram notifications. Exactly the kind of product people ship over a couple of evenings now. I'm deliberately not naming the author: the point isn't to shame a person, it's to show the typical traps almost everyone falls into. Here's what the pipeline found in an hour.
The app has a secret key used to sign every user's entry pass. In the code it reads: take the key from the environment, and if it isn't there — fall back to super-secret-key
.
Sounds harmless. In practice it means this: if the owner forgot to set their own key at launch — and they almost always forget, because "it works anyway" — the app silently uses that fallback. It's identical for everyone who downloaded this code, and it sits in plain sight in a public repository. Knowing it, an outsider can issue themselves an admin pass and walk in as the owner. There's a lock on the door, but the spare key hangs on a nail right next to it, and the nail is visible from the street.
The same trouble next door: the codes for admin and manager roles are also hardcoded with fallbacks right in the source — admin*123*
and manage*159*
. Whoever read the code knows the admin password.
The app hands a logged-in user a digital pass (a JWT) and later recognizes them by it. The signature check itself is done carefully — no complaints there. But there's a subtlety one model almost always misses and the mean second one catches.
When verifying the pass, the code trusts what the pass itself says about how it was signed. It's like a guard who verifies the seal on a pass using the method printed on that same pass. And if a forger writes "no need to check the seal" there — the guard dutifully doesn't check. This is a classic, long-known hole in homemade pass checks, and the check here is exactly that: hand-written, not taken from a proven library.
In the same spot where the pass is decoded, there's an arithmetic error in the padding calculation — the kind you don't see until you hit it. Most of the time it passes, but on certain data lengths the math gives a wrong result and decoding breaks out of nowhere. The user doesn't see a clear error, just "login doesn't work" for no reason. Bugs like this get hunted for days later, because they don't reproduce every time.
None of these three findings shows up on a normal run. The app starts fine, registers, lets you in — "works." The holes sit exactly where a single model doesn't look, because it wrote the code itself and trusts it. The second, third, and fourth view — that's what pulls them out.
And this isn't a vague "feels weak to me." Every finding comes with an exact place in the code, an explanation of what it risks, and a way to fix it. The report is built so you can hand it back to the same AI with "fix this" — and get the fix.
For an honest number: I ran the same pipeline earlier on my own request-routing library — 1,211 lines, 124 passing tests, strict typing. Code I considered finished. The four voices found 8 defects in an hour. So an outside view isn't only for someone else's vibe-code — it's for any code, including mine. Built a product in Cursor, Lovable, Bolt, Replit, or straight in a chat with an AI, and you're about to ship it to real users? Before you do, let the code go through a review like this. I do it as a service: you send a repo link or an archive — within a day you get a scope estimate, a timeline, and a price. Report in 48 hours for small projects. And a rule I hold on every tier: if the review finds not a single significant issue, you don't pay.
Service page with pricing and details — quantareon.com/audit.html
Reach me directly — Telegram @quantareon
The first impulse is noise. The second is signal.