AI Can Build Your App — It Can Also Leak It

There's a story every founder tells themselves in 2026: "I'll describe what I want, the AI builds it, and I ship." For a landing page or a to-do list, that story mostly holds. For anything that touches a user's data, a payment, or a login, it quietly falls apart — and the bill arrives later, as a breach.

We build software for a living, and we use AI every single day. So this isn't an "AI is bad" post. It's the opposite: AI is the best leverage a developer has ever had. But leverage cuts both ways. Hand the same tool to someone who can't read what it produces, and you don't get a developer — you get a very fast way to ship vulnerabilities you can't see.

Here's what the research actually says.

AI writes insecure code at a stubbornly high rate

Veracode's 2025 GenAI Code Security Report tested over 100 models across 80 coding tasks. The headline: 45% of AI-generated code contained a known security flaw. (Veracode)

The detail that should worry you more: it isn't improving. "Newer and larger models don't generate significantly more secure code than their predecessors." Models got dramatically better at writing code that runs — and barely moved on writing code that's safe. On Cross-Site Scripting, the models failed 86% of the time; on log injection, 88%.

This matches the foundational Stanford study by Perry, Boneh et al., which found that developers with an AI assistant wrote significantly less secure code — and, worse, were more confident it was secure. That's the trap in one sentence: the tool that makes you faster also makes you feel safer while you're not.

"It runs" and "it's safe" are different claims

When AI generates code and it works, you get a powerful, false signal: the feature works, so the job is done. But "works" only tests the happy path — the user doing what you expected. Security is about the unhappy path: the user doing what you didn't.

An AI will happily write you a login form that authenticates real users perfectly and lets an attacker log in as anyone via SQL injection. Both behaviors live in the same fifty lines. One you'll see in five seconds. The other you'll see when it's on the news.

This is already happening — at scale

This isn't theoretical. The "vibe coding" wave produced a matching wave of breaches:

• Lovable, a major AI app builder, had projects exposing source code and database credentials for 48 days after a bug report was closed. (The Next Web)
• Researchers scanned thousands of publicly deployed vibe-coded apps and found over 2,000 high-impact vulnerabilities — including hundreds of exposed secrets and leaked personal data, medical records, and bank account numbers. (TechTarget)
• GitGuardian found repositories with Copilot enabled leak secrets at a 40% higher rate (6.4% vs 4.6%) than the general population — and researchers extracted thousands of hard-coded credentials from Copilot, some of them real, working keys. (GitGuardian)
• A critical GitHub Copilot Chat flaw (CamoLeak, CVE-2025-59145, CVSS 9.6) let attackers silently exfiltrate source code and secrets from private repos. (Legit Security)

A common thread runs through all of these: a misconfigured database with no access rules, a secret hard-coded into the frontend, an API with no authorization check. None of these are exotic. They're the things an experienced developer checks by reflex — and exactly the things an AI won't add unless you already know to ask.

"But it's just a small project"

The most dangerous sentence in software. Small projects leak data just as effectively as big ones — they simply have fewer people watching. A Supabase database with row-level security left off doesn't care that your app has 50 users; it exposes all 50 of their emails, passwords, and uploads to anyone who opens the network tab.

And small projects rarely stay small in scope even when they stay small in users. The moment you add a login, accept a file upload, store an address, or take a payment, you inherit an entire category of problems — authentication, access control, secret management, input validation, rate limiting — that never appear in the prompt and won't appear in the output unless someone makes them.

Where AI actually shines (and where it doesn't)

To be clear about the line we're drawing:

AI is genuinely excellent at scaffolding, boilerplate, one-off scripts, UI components, explaining unfamiliar code, writing tests, and accelerating a developer who already knows what "correct" looks like.

AI is genuinely dangerous at anything where the cost of a subtle mistake is a breach and you can't evaluate the output: auth flows, database access rules, payment handling, anything storing personal data. The whole point of expertise here is knowing what the AI silently left out — and you cannot review for a risk you don't know exists.

The difference between a developer using AI and a non-developer using AI isn't typing speed. It's that one of them can read the answer.

What to do instead

You don't have to choose between "move fast with AI" and "be secure." You just have to keep a reviewer in the loop who can tell the difference.

• Use AI to build — then have someone who knows security read it before it touches real data.
• Never ship a database, auth system, or payment flow you can't personally audit.
• Treat "it works in the demo" as the start of testing, not the end.
• If it's already live, get a security review before you find out the hard way.

That's literally what we do: we build with AI at full speed and bring the developer experience that knows where it cuts corners — so you get the velocity without the breach.

FAQ

Can AI build my whole app without a developer?

For a static site or a simple prototype, often yes. For anything with logins, payments, file uploads, or stored personal data — no, not safely. Studies consistently find around 45% of AI-generated code contains a security flaw, and those flaws cluster exactly in the parts that handle sensitive data.

Isn't this only a problem for big, complex apps?

No. Small apps leak data just as easily — a single misconfigured database or one hard-coded key exposes every user you have. The size of the app doesn't change the size of the breach.

Does using a newer, smarter AI model fix the security problem?

Not meaningfully. Veracode found that newer and larger models write more correct code but not more secure code — the security-flaw rate has stayed roughly flat even as models improved.

So should I stop using AI to code?

No — we use it every day. The point is that AI should accelerate a developer, not replace one. Used by someone who can review the output, it's the best tool in the industry. Used blind, it's a fast way to ship vulnerabilities.