Your AI built you a startup. It also built you a time bomb.
· Mick Brzeziński
- AI agents
- vibe coding
- build in public
Your AI built you a startup. It also built you a time bomb.
Nobody tells you about Day 60.
Day 1 is magic. You describe an app to Lovable or Bolt or Replit, and twenty minutes later it’s live — auth, payments, a database, a landing page. Ten years ago that was a seed round and three engineers; now it’s a Tuesday afternoon and a $20 subscription. Believe that part. It’s genuinely new, and most people never ship anything at all.
The 30% nobody mentioned
Google’s Addy Osmani has a name for it — the “70% problem.” AI gets you 70% of the way to a working product fast; “that final 30% becomes an exercise in diminishing returns.” The edge cases, the rate limiting, the retries, the auth that actually holds, the secrets that aren’t sitting in your frontend — that part still needs real engineering. Some tools are honest about where the line falls: v0 generates the screen by design, not the database, the auth, or the backend — so “I built it in a weekend” usually means the interface exists and the actual product doesn’t.
The 30% the AI skips is exactly the 30% that gets you hacked.
It’s not random. Production hardening — input validation, access control, audit logging, PII handling — is invisible in a demo. It doesn’t make the app look more finished, so a model optimising for “looks done” skips it. Your app works the way a stage set works: convincing from the front, hollow behind.
The receipts
- Veracode’s 2025 study tested AI-generated code across 100+ models. 45% of it shipped an OWASP Top 10 vulnerability — 86% failed to defend against cross-site scripting, 88% were open to log injection. And it didn’t improve across model generations. Bigger, newer model — same 45%.
- Security firm Escape.tech scanned 5,600+ live vibe-coded apps and found 2,000+ vulnerabilities, 400+ exposed secrets, and 175 cases leaking PII — medical records, IBANs, phone numbers — sitting on the public internet.
- Lovable shipped apps whose database had no working lock on the door (CVE-2025-48757): anyone who opened browser dev-tools could read users’ names, emails, even API keys. An analysis found 170 apps exposed this way. Lovable’s first “security scanner” checked whether a rule existed — not whether it actually did anything.
- A founder’s Replit AI agent deleted his production database during an explicit code freeze, against written instructions — then reported the data as unrecoverable. (It wasn’t. He restored it by hand.)
- The meter runs while it fails. When the AI writes a bug, you spend more credits prompting it to fix the bug it just wrote — a thread on Vercel’s own forum is titled, word for word, “Credits Gone Fast, Errors Cost More Than Dev Hire,” and after Replit’s Agent 3 launch The Register reported costs jumping several-fold.
And the developers feel it. In Stack Overflow’s 2025 developer survey, 46% now actively distrust the accuracy of AI tools — only about a third trust it, and favourable sentiment slid from 70%+ to 60% in a year. The single biggest frustration, cited by 66%: code that’s “almost right, but not quite.” Almost-right is the most expensive kind of wrong, because it ships.
Why this gets worse before it gets better
Most people read this backwards. The models are getting dramatically more capable — agents now run for hours unsupervised. That’s real. But capability and security are two different curves, and they’re moving in different directions.
The widening gap is invisible in a demo — and obvious to an attacker.
Apiiro’s 2025 analysis (7,000+ developers, 62,000 repos) found AI-assisted code generating 10,000+ new security findings a month by mid-2025 — a 10x jump in six months — with privilege-escalation flaws up 322%. GitClear found code duplication rising and refactoring falling as AI spread: more code generated, less of it cleaned up.
So we’re shipping insecure code faster, with more confidence, because the demo looks more polished. Gartner projects that by 2028, prompt-to-app development will drive a 2,500% increase in software defects.
Osmani has a name for the deeper version of this: comprehension debt — “the growing gap between how much code exists in your system and how much of it any human being genuinely understands.” AI generates code far faster than anyone can read it, so the debt compounds silently — until something breaks and nobody on the team knows why, because nobody wrote it. (It’s the cousin of the velocity debt a Carnegie Mellon study measured: fast in month one, paid back by month three.)
If you built something this way, here’s a 5-minute gut check
In March 2025 a founder posted that his new SaaS was built with Cursor — “zero hand written code.” Two days later: “guys, i’m under attack.” Strangers were calling his API directly to max out the keys on his credit card, walking straight through the paywall, and filling his database with junk. “As you know, I’m not technical,” he wrote. He’d aced the demo and failed every question below.
You don’t need to panic. You need to look. Open your app and ask:
- Where do your API keys live? If any sit in frontend code or a public repo, stop reading and rotate them now — that’s the bill that maxed out his card.
- Can a logged-in user read another user’s data? On Supabase or Firebase, is row-level security actually configured — not just “enabled”? And it isn’t only indie projects: in July 2025 the Tea app left its ID-verification photos in a storage bucket with no authentication in front of it — roughly 13,000 selfies and government IDs ended up on 4chan, and the first class-action suit landed three days later.
- Is your paywall enforced on the server, or just hidden in the UI? If it’s in the UI, it’s not a paywall — it’s a suggestion, and his was gone in 48 hours.
- If your data vanished tonight, could you get it back? A bad migration — or an agent “tidying up” — can wipe a database in seconds. If you’ve never run a restore, you don’t have backups; you have hope.
- Could anyone explain how your auth flow works? If not — that’s comprehension debt, the scariest one: you can’t fix what no one on the team understands.
Aced all five? Genuinely — well done. If even two or three made your stomach drop, that’s not a you-problem; nobody told you these existed. The tool’s job was to get you to launch, and it did.
The fix: put the engineer back
Every failure above is the same gap — no one who actually understands the system is accountable for it. So the fix isn’t a better prompt or a different builder. It’s an engineer who owns the thing end to end: writes the lock on the database, reads the diffs, and leaves you code you can hand to anyone.
So what
Keep using the AI builder. It’s the fastest way ever invented to find out whether an idea is worth building, and a weekend demo that wins the room is worth real money. Just don’t confuse the demo for the product. The scarce skill used to be can you build it at all; now everyone can build the first 70%. The valuable thing is the last 30% that keeps it from leaking, breaking, or getting wiped — before Day 60 finds it for you.
If your prototype is getting traction, here’s the only question that matters: who’s accountable for what it does the first time a real user trusts it with something they can’t afford to lose?