Vibe Coding Liability: Who Pays When AI-Built Apps Fail?

The bill is coming due for prompt-built software

Vibe coding—describing an app in plain language and letting an AI write it—was sold as a way to open software development to everyone. That part worked. What hasn't caught up is accountability. A growing body of security research shows these apps are shipping with serious flaws, and legal commentators warn that existing doctrine struggles to say who answers when they cause harm.

The pieces fit together uncomfortably. More inexperienced builders are writing more code that fewer people actually read. When something breaks, the trail of responsibility runs cold.

The security numbers

The empirical picture is consistent across several independent efforts. Red Access scanned more than 380,000 web assets on platforms including Lovable, Replit and Base44 and found 5,000 apps built for corporate use. Some 2,000 of those held sensitive data with no authentication, no access controls and no audit trail, all reachable from an ordinary browser 3. The exposed material included financial records, patient conversations, strategic documents, credentials and API keys. In what the researchers called a meaningful number of cases, any visitor received administrative access by default 3. Examples cited include a live financial dashboard at a major Latin American bank and documents from a $200 billion company, reached through a vendor's tool 3.

Other data points in the same direction. Escape.tech found that 65% of more than 1,400 vibe-coded apps it scanned had security issues, and 58% carried at least one critical flaw 4. Georgia Tech's Vibe Security Radar recorded CVEs tied to such code rising from 6 in January 2026 to 35 in March 4. Teams adopting these tools also reportedly see technical debt climb 30–41% 4.

The common thread is who is doing the building. An estimated 84% of AI coding tool adoption now includes people with no engineering background 4. Wiz chief technologist Ami Luttwak argues that non-developers are even more likely to make mistakes than professionals, and that security teams may not be able to catch every error across a much larger volume of source code 1. TechTarget frames this as a new kind of shadow IT, with business units shipping tools that never pass through formal review 3.

Where the law runs out

The sources split on how serious the legal gap is. Bloomberg Law treats it as a compliance problem. After a breach, plaintiffs will likely press companies that put AI in their development pipelines. Those firms will need records showing how they used vibe coding, so they can argue they met a reasonable standard of security 1. Under this view, existing negligence frameworks still apply. Companies simply need the paperwork and human oversight to defend themselves.

The Oxford Political Review takes a bleaker view. It describes a "responsibility vacuum" that opens when code is generated by AI, accepted by people and deployed without meaningful review 2. Its example is a hypothetical autonomous vehicle whose braking logic no human ever read. In that case, the engineers didn't write the code, the AI vendor calls its product a mere tool, and the deploying company can't explain what the software does 2. In that scenario, the article argues, a court looking for a responsible party finds only silence 2.

Reading the gap

The more practical account and the more theoretical one are less opposed than they look. Bloomberg's prescription of documented human review is essentially a way to keep Oxford's vacuum from forming. Liability attaches more easily when someone can show they examined the code and accepted it knowingly. It fails when nobody looked.

That suggests where things are heading. Courts are unlikely to accept "the AI wrote it" as a defense. A deploying organization that ships unreviewed code probably remains the most plausible defendant, whether or not it understands the software. If that holds, the real risk falls on companies whose employees quietly build data-handling apps outside IT's view. The Red Access findings suggest many already do 3.

No settled playbook exists yet. But the direction is visible. Prompt-driven development will need human checkpoints, audit trails and security review built into the workflow, not added later. The promise of letting anyone build software still stands. The data so far shows it will not stay frictionless for long.