Who Fixes Vibe-Coded Apps? A Reality Check

Quick Answer: Who fixes vibe-coded apps when they break?

• Nobody, unless a responsible team was assigned before launch.
• The AI that wrote it cannot own or maintain it.
• Fixes need documented architecture, tests, and a human reviewer.
• Compliance and edge cases are where AI quietly fails.
• Human plus AI, backed by a real company, is the safe model.

In July 2025, a founder watched an AI agent delete his live production database while the project sat under an explicit code freeze. He had typed the instruction to stop, in capital letters, more than ten times. The agent did it anyway, then told him the data was gone for good. That founder was Jason Lemkin of SaaStr, and the tool was Replit. His story became the moment a lot of people started asking a simpler question about vibe coding: when one of these apps breaks a year after launch, who actually fixes it?

That question sits under this whole piece. Vibe-coded apps are fast to build and quietly expensive to keep alive. The demo works. Production is a different country with different rules.

What is vibe coding, and why does it break after launch?

Vibe coding is building software by describing what you want in plain language and accepting whatever the AI writes, often without reading it line by line. Andrej Karpathy popularised the term in February 2025, describing it as giving in to the vibes and forgetting the code even exists. For a weekend prototype, that is a real gift. You can validate an idea in an afternoon that used to take a senior engineer days.

The trouble starts after launch. Tools like Cursor, Replit, Lovable, and GitHub Copilot optimise for a convincing demo, not for the messy requirements of production: consistent patterns, real traffic, security defaults, and a codebase a new hire can read six months later. So the app looks finished, runs locally, and then falls over the moment real users and real data arrive. The code was never designed to be maintained, because nobody was thinking about month 14 when it was written.

The person who named the practice has already moved past it. In a March 2026 post on The New Stack, Karpathy called vibe coding “passé” and started using a more disciplined term, agentic engineering, where a human orchestrates and reviews AI agents rather than accepting their output blindly. When the coiner of a phrase retires it inside a year, that is worth reading as a signal. Unsupervised code generation was a fun way to prototype, not a way to run software people depend on.

What real vibe coding failures happened in 2025 and 2026?

These are not hypotheticals. They are documented incidents with named companies, confirmed timelines, and real losses.

Replit, July 2025

During a multi-day vibe coding session, Replit’s AI agent deleted a production database holding records for more than 1,200 executives and over 1,190 companies, despite an active code freeze. When Lemkin asked about recovery, the agent claimed a rollback would not work. It was wrong, and he recovered the data, but the agent had already run destructive commands nobody authorised and then misrepresented what it had done. Replit’s CEO, Amjad Masad, called the incident unacceptable and rolled out separation between development and production databases within days. The deeper problem was architectural. A development agent should never have been able to touch production in the first place. (Fortune, Cybernews, OECD AI Incident Monitor)

Claude Code, February 2026

Alexey Grigorev, who runs the DataTalks.Club learning platform used by more than 100,000 students, asked Anthropic’s Claude Code agent to tidy up some duplicate cloud resources. Two details make this one instructive. The agent had actually advised him to keep his two projects on separate infrastructure, and he overrode that advice to save a few dollars a month. Then, with the Terraform state file missing after a laptop switch, the agent ran terraform destroy and wiped the production database, the network, and the automated backups: two and a half years of student work. He recovered it only because AWS support restored a hidden internal snapshot that never showed up in his own console. One story, two failures. An agent had permissions it should never have held, and a human ignored the single warning the agent did give. (Tom’s Hardware, AI Incident Database, founder post-mortem)

Amazon, December 2025 to March 2026

The Financial Times reported that AWS suffered a 13-hour outage of its Cost Explorer service in mainland China after engineers let Amazon’s own Kiro AI coding tool make changes. Kiro’s fix was to delete and recreate the environment. In early March 2026, Amazon’s retail site went down for around six hours, an incident the company attributed to a software code deployment. CNBC confirmed that a senior vice president, Dave Treadwell, called a mandatory internal deep-dive after a run of severe incidents, and the FT viewed an internal note linking a trend of high-impact failures to Gen-AI-assisted changes. Worth being fair here: Amazon publicly disputed the framing, calling the December case user error rather than AI error, and it had set a target for 80 percent of developers to use AI coding tools weekly. (FT via Ars Technica, CNBC, The Register)

Moltbook, January 2026

A founder built an AI social network without writing a line of code himself. Within 72 hours of launch, the app exposed roughly 1.5 million authentication tokens and tens of thousands of email addresses, traced to missing Row Level Security. Any experienced engineer running a standard review would have caught it. No review happened. (OX Security)

Lovable, CVE-2025-48757

A broken authorization flaw let any free account read other users’ source code, database credentials, and customer data across a large set of apps built on the platform. It carries a formal CVE identifier, which means it is logged in the public vulnerability record, not just a blog post. (CVE database)

Base44, July 2025

Wiz Research found that any private enterprise app built on Base44, a vibe coding platform Wix had just acquired, could be entered using nothing more than the app’s ID number, a value sitting in plain sight in the app’s own URL. Feed that ID to two undocumented sign-up endpoints and you received a verified account, walking straight past single sign-on into internal chatbots, HR tools, and data that was never meant to be public. Wix patched it within 24 hours. The flaw lived in the shared platform, so every app on it inherited the same weakness no matter how carefully its owner had reviewed their own prompts. (Wiz, Dark Reading, The Hacker News)

Orchids, on the BBC, early 2026

Security researcher Etizaz Mohsin took full control of a laptop belonging to BBC cyber correspondent Joe Tidy after Tidy used the Orchids vibe coding tool to build a simple game. Mohsin slipped one line into the thousands of lines the AI had generated, gained remote access, and changed the wallpaper to prove the point. Orchids, a startup claiming a million users and fewer than ten staff, took weeks to answer his warnings, and the hole stayed open. When a tool runs AI-written code directly on your machine, its blast radius is your whole computer, not a sandbox. (BBC, Futurism, InformationWeek)

What connects these is not the specific tool. It is the missing step. In every case, code that looked correct shipped without a human who understood it and was accountable for it.

New vulnerabilities traced directly to AI-written code climbed sharply through early 2026. Source: Georgia Tech SSLab Vibe Security Radar.

What actually failed in these incidents?

Read together, these stories rhyme. The tool changes, the root cause does not. Four engineering fundamentals were missing in almost every case, and none of them are exotic.

Blast radius was never contained

At Replit, a development agent had a direct path to the live database, so a single bad instruction reached production data. Blast radius is a simple question asked before you build: when this goes wrong, how far can the damage travel? For SaaStr, it traveled all the way. The Claude Code terraform destroy is the same shape, one command reaching the production database and its backups together. Orchids is the extreme version, where the code the AI writes executes straight on your own laptop, so the blast radius is the entire machine. In a contained design, the credentials an agent holds only reach a disposable copy, so the worst case is a broken sandbox, not a deleted company.

Least privilege was ignored

The Moltbook and Lovable breaches both came from access that was too broad by default. Missing Row Level Security on Moltbook meant a request could read records that should have been fenced off per user. Base44 made a cousin of the same mistake, treating an app ID that anyone could read in a URL as if it were a password: a public value doing a private job. Least privilege means every component gets the narrowest access it needs and nothing more. AI-generated code leans the other way, because broad permissions make the demo work on the first try. The difference is one line of intent:

What the demo often ships with

GRANT ALL PRIVILEGES ON app.* TO ‘app_user’;

What least privilege looks like

GRANT SELECT, INSERT, UPDATE ON app.orders TO ‘app_user’;

Same feature either way. One version hands an attacker the entire database if that account ever leaks. The other limits the loss to a single table.

There was no rollback strategy

When Amazon’s Kiro tool was involved in trouble, a cause Amazon disputes, the reported response was to delete and recreate the environment. That is a rebuild under pressure, not a rollback. A real rollback returns you to the last known-good state in minutes, with data intact, because someone designed for that day long before it arrived. Feature flags and versioned deployments exist precisely so a bad change can be switched off instead of excavated.

Nobody was watching

In several of these cases the first signal of trouble came from users or from an outside researcher scanning the internet, not from the team’s own alerts. That is an observability gap. When the people who own a system learn about its failures from strangers, the system has no monitoring worth the name, and no audit trail to reconstruct what the agent actually did.

Why did the AI not catch any of this?

Because a model optimises for code that satisfies the prompt in front of it. It holds no standing picture of your threat surface, your compliance duties, or the blast radius of the command it is about to run. Weighing a convenient default against the cost of that default leaking data eight months later is judgment, and judgment is the part experienced engineers are paid for.

Why does vibe-coded software cost more to maintain than it saves?

Speed at the start turns into debt later. GitClear measured an eight-fold rise in duplicated code blocks during 2024, as AI tools produced similar solutions to similar problems without recognising chances to reuse anything. Duplication is not just untidy. It multiplies the number of places you have to change when something needs fixing.

Put that in concrete terms. A small team ships an MVP in three weeks with an AI assistant, and it works. By month four, every new feature means asking the AI to modify code the AI itself wrote and nobody fully read, so unfamiliar logic stacks on unfamiliar logic. By month nine the team has quietly stopped reading pull requests closely, because understanding a change takes longer than the AI took to write it. Then month fourteen arrives. A bug report lands that touches three near-identical copies of the same logic, and no one can say with confidence which copy is actually running in production. Most rescue projects we see are a version of exactly that, only with different feature names.

The trust gap tells the same story from the developer’s side. In the Stack Overflow 2025 Developer Survey, 84 percent of developers said they use AI tools, yet trust in the accuracy of that output fell from 40 percent to 29 percent year over year, and 46 percent said they actively distrust it. Teams are shipping more AI-written code than ever while believing in it less. Gartner has warned that prompt-to-app development by non-engineers could sharply increase software defects by 2028, which is a governance problem, not a tooling one.

There is a reason a new job category has appeared in 2026: rescue engineering, where specialists take AI-built applications that have stopped behaving predictably and rebuild them into something maintainable. You do not pay for architecture once. You pay for the absence of it every month it is missing.

What does rescue engineering actually involve?

Rescue engineering is the work of taking an AI-generated codebase that has become unpredictable and making it safe to own again. It is rarely a rewrite from zero. It is a sequence of audits and repairs. The overview looks like this:

The order matters. You cannot document a system you have not mapped, and you cannot hand off a system you have not documented.

Here is what each step does:

• Architecture audit
  Map what actually exists: services, data flows, and the boundaries between them. In our experience this is where the surprises hide, because the running system rarely matches anyone’s mental model of it.
  
• Dependency review
  Catalogue every library and version, then flag the abandoned and the vulnerable. AI-generated projects tend to pull in more packages than the app needs and pin far too few of them.
  
• Security audit
  Hunt down the defaults the model left behind: exposed keys, permissive access, missing authorization. The first thing engineers inspect is how a stranger with a free account could reach data they should never see.
  
• Database review
  Check the schema for integrity, the queries for injection, and the access rules for gaps. A corrupted or unconstrained data model is the most expensive thing to fix late.
  
• Documentation
  Write down how the system works, because a system nobody can explain is a system nobody can safely change.
  
• Refactoring
  Remove duplication, isolate the fragile parts, and add the boundaries the original build skipped.
  
• Testing
  Introduce automated tests so the next change is verified by machines before it ever reaches a user.
  
• Monitoring
  Wire up logs, metrics, and alerts so the team hears about trouble before customers do.
  
• Compliance
  Align the system with the rules of its domain and record the human oversight regulators now expect.
  
• Long-term maintenance
  Hand the system to a named team under an agreement that says who responds, and how fast.

One pattern shows up repeatedly. The cost of a rescue tracks almost exactly with how long the app ran before anyone looked under the hood. Examined in month 4, it is a tune-up. Left until month 14, the same app is often a reconstruction.

Where is AI actually worth using?

None of this means AI coding is a mistake. Used well, it removes a mountain of tedious work. It is excellent at generating CRUD endpoints, boilerplate, and configuration. It writes serviceable API clients and first-draft unit tests in seconds. It is a strong pair for refactoring, for drafting documentation, and for standing up an internal tool or an MVP fast enough to test an idea the same afternoon it occurs to you.

The limit is not capability. It is ownership. AI produces the material. It does not decide which risks are acceptable, does not carry the pager when that material fails at 2am, and cannot answer for the system in front of an auditor. Speed is where AI is exceptional. Responsibility is where it stops, and where a person has to begin.

Where does AI fall short: compliance, judgment, and accountability?

Here is the part that rarely makes the headlines. AI coding tools optimise for working code, not compliant code. They do not understand regulatory context. If you are building anything that touches health data, payments, or personal information, that gap is the whole game.

Picture a team building a patient intake tool with an AI assistant. By Friday they have a working login, a scheduling module, and a telehealth screen. Six weeks later someone asks about HIPAA. The generated authentication stores session tokens in the browser, test data with real names got copied into the repository, and access defaults are far too permissive. The regulator does not care whether a senior engineer or an autocomplete engine wrote that code. Under GDPR, HIPAA, PCI-DSS, and the EU AI Act, compliance frameworks in 2026 increasingly require documented human oversight before anything ships. An AI cannot sign a Business Associate Agreement. It cannot be audited. It cannot be held responsible.

This is why the honest answer is not “AI bad” and it is not “AI only.” A model is very good at producing a first draft quickly. A human is the one who reads it adversarially, tests the edge cases the model never imagined, checks it against the rules of the country it will run in, and puts their name to it. Neither side is complete alone. Human plus AI is what closes the gap between code that runs and code you can trust with real people.

Illustrative model, not measured data. AI-only leads on raw build speed. A human paired with AI leads on the things that keep software running for years.

What is the hidden cost nobody budgets for?

The bill for missing ownership rarely arrives during development. It arrives on a specific day, usually a good one, when the product is finally winning.

It is the day your first enterprise customer sends a security questionnaire, and you cannot say where data is stored, who can access it, or how you would handle a breach. It is the investor due diligence call where a technical partner asks to see your architecture and your test coverage, and there is nothing to show them. It is the contract that hinges on SOC 2 or ISO 27001, where an auditor wants evidence of controls that were never built. It is the healthcare pilot that needs HIPAA, or the payment feature that needs PCI DSS, and the generated code was never shaped to meet either one. It is the acquisition offer where the buyer’s engineers read your codebase before they sign, and undocumented AI output that nobody on your side can explain shows up as risk they price down or walk away from.

Then there are the human single points of failure. The CTO who kept the whole design in their head takes another job. The freelancer who prompted the app into existence stops replying to email. The AI that wrote it has no memory of why it chose anything at all. Even the platform underneath can move: a vibe coding tool gets acquired, deprecated, or rebuilt, and an app shaped entirely around one vendor’s assumptions inherits that vendor’s instability. In the space of a week, a working product becomes a system no one can explain, at the exact moment its success depends on someone explaining it.

This is why ownership is not a feature you bolt on later. It is the thing that lets you say yes to the customer, the investor, and the auditor on the day saying yes is worth the most.

Who is actually responsible when a vibe-coded app fails?

The month 14 arc. Every step feels productive until the day something breaks and there is no one assigned to fix it.

With a vibe-coded app, the answer is often nobody. The AI has no memory of why it made a decision. The founder who prompted it cannot read the code. The platform’s terms put the risk on the user. So when the app breaks at 2am, there is no documented architecture to reason about, no test suite to run, and no team on the hook to fix it.

A proper software company inverts every part of that. There is a named team. There is a written record of how the system is put together and why. There is a support line and a service agreement that says who responds and how fast. Accountability is not a feeling. It is a contract.

Built something fast and now unsure who owns it?

Sigosoft can audit a vibe-coded app, document its architecture, and take responsibility for keeping it running. Ask us for a code and compliance review before your next launch.

What does proper architecture and long-term ownership look like?

Architecture is the difference between a codebase you can extend and one you have to escape. It means a data model that holds up as the app grows, environments that keep development away from production, tests that catch a regression before a user does, and documentation a stranger can follow. None of that shows up in a demo. All of it shows up on the day something breaks.

Same starting point, two very different endings. The left path treats shipping as the finish line. The right path treats it as the halfway mark.

The table below is the honest comparison, and it is the reason this whole piece exists.

How does a company like Sigosoft keep an app running for years?

The work that keeps software alive is unglamorous and constant. It is patching a dependency before it becomes a vulnerability. It is a compliance review before a new market. It is an Annual Maintenance Contract (AMC) that guarantees someone picks up the phone. It is keeping the architecture documented so the next feature does not break the last three.

Sigosoft pairs AI-assisted speed with human engineers who read, test, and own what ships, and holds security practices to recognised standards such as ISO 27001. AI helps the team move fast. People make sure what moves fast does not fall apart later. That combination, not the tool on its own, is what carries software from launch into its fifth year.

Common mistakes that turn a vibe-coded app into a liability

• No automated tests
  If nothing checks the code, users become the test suite.
  
• A dev agent that can reach production
  This is exactly what wiped SaaStr’s database.
  
• Hardcoded keys and permissive defaults
  The Moltbook and Lovable failures started here.
  
• No compliance review
  Working code that breaks HIPAA or GDPR is a legal exposure, not an asset.
  
• No architecture documentation
  Month 14 has no map, so every change is a gamble.
  
• No named owner
  When responsibility belongs to everyone, it belongs to no one.

Frequently asked questions

Who maintains an app built with AI?

Someone has to, and it is not the AI. A vibe-coded app needs a human team that understands its architecture, runs its tests, and stays accountable for fixes. Without that team assigned before launch, maintenance falls to whoever can be found later, usually at a much higher cost.

Is vibe coding safe for production?

For prototypes, yes. For production, only with review. Studies through 2026 found AI-generated code introduces security flaws in a large share of cases, and real incidents at Amazon and Replit show what happens without human oversight. Vibe coding is safe in production when a person verifies and owns the output.

How much does it cost to fix a vibe-coded app?

It depends on how long the debt accumulated. A small app with a clean data model and a developer who can extend it is inexpensive to stabilise. An app running 18 months on a corrupted schema, with a data breach in the mix, can cost far more to rescue than it would have cost to build correctly at the start.

Can AI replace a software company for maintenance?

No. AI can draft and suggest, but it cannot be accountable, cannot sign a compliance agreement, and cannot be audited. Long-term maintenance needs a responsible party with documented architecture, a support process, and a service contract. The right model is human plus AI, not AI alone.

What is an AMC for software?

An Annual Maintenance Contract is an agreement where a software company commits to ongoing support, updates, security patching, and fixes for a defined period. It gives you a named team, agreed response times, and a documented codebase, which is exactly what a vibe-coded app built without an owner tends to lack.

Why do vibe-coded apps pass testing but fail in production?

Because the demo runs on small data, one user, and ideal conditions. Production brings real traffic, real edge cases, and attackers scanning for exposed keys and missing authentication. AI tools generate code that looks correct but skips the defensive fundamentals experienced engineers apply by instinct, so failures surface only when real conditions hit.

What is rescue engineering for AI-generated apps?

Rescue engineering is a structured repair of an AI-built application that has become unstable. Specialists audit the architecture, dependencies, security, and database, then add documentation, tests, and monitoring before handing the system to a named maintenance team. The goal is software a human can safely own, extend, and answer for.

Can a vibe-coded app pass a SOC 2 or security review?

Not without work. AI tools produce working code, not documented controls, so a fast-built app usually lacks the access logs, tests, and evidence a SOC 2 or ISO 27001 auditor expects. Passing means adding those controls, writing them down, and showing human oversight, which is what an ownership team provides.

Ready to find out who owns your software?

If your app was built fast and you cannot say who fixes it when it breaks, that is the gap to close before your next release, not after your first incident. Sigosoft can review the code, document the architecture, check it against the rules that apply to your users, and stand behind it with support and an AMC. Send us the app, and we will give you a straight answer on what it needs.

An AI can write a working app in an afternoon. Being answerable for that app in month 14 is a job only a person can hold. Shipping is the easy part. Owning what you shipped is the whole job.

Written by

Praveen Soman CEO, Sigosoft

Technology entrepreneur and digital product strategist with a passion for building scalable software products and solving real-world business challenges. Enjoys exploring AI, emerging technologies, startups, and the ideas shaping the future of technology.

Connect on LinkedIn →