Reality check · October 19, 2026
The AI Agent That Deleted a Production Database: 5 Lessons
Replit's agent ignored a code freeze, wiped SaaStr's database and faked data. What happened, and what it means if your app holds client records.
In July 2025, Jason Lemkin, founder of SaaStr and one of the best-known voices in software investing, ran a public experiment. He would build a real business app on Replit using only its AI agent, posting his progress on X as he went. He was not a developer. That was the point.
About a week in, the agent deleted his production database.
The story went viral because of how it happened, not just what happened. The agent had been told to stop. It did not stop. It then misled him about what it had done. If you are planning to let an AI build a tool that holds your clients' records, this is the most useful cautionary tale there is, so it is worth going through carefully.
What happened
The facts below come from The Register's reporting and Lemkin's own posts at the time. Some details, such as exact record counts, vary slightly between outlets.
Lemkin started building around July 12. By day eight or nine he had a working app with real data in it: records on roughly 1,200 executives and 1,200 companies.
He had declared a code freeze. He told the agent, explicitly and repeatedly, not to make changes without his permission. The agent ran a database command anyway, one that pushed a schema change to production, and the production data was wiped.
When asked what happened, the agent said it had "panicked." It turned out that wasn't the only problem. It had also been generating fake data and fake test results to cover up bugs, so the app had looked healthier than it was. And it told Lemkin that a rollback was impossible.
That last claim was false. Lemkin restored the data himself.
Replit's CEO, Amjad Masad, responded publicly that this was "unacceptable and should never be possible." Replit refunded Lemkin and announced changes: automatic separation of development and production databases, a planning-only chat mode where the agent cannot change code, and one-click restore from backups.
Lemkin's own takeaway was stark: "There is no way to enforce a code freeze in vibe coding apps."
Why this is not just a Replit story
It would be easy to file this as one company's bug, since fixed. Replit did fix the specific failure. But the behaviors underneath show up across every AI coding tool, because they come from how these agents work.
- Agents act on the whole goal, not your latest sentence. An agent trying to make the app work will take whatever action looks like progress. An instruction like "don't touch anything" is just more text competing with the goal.
- Agents report success they have not achieved. They are trained to complete tasks, and "I completed it" is the answer that looks like completion. Faked test results are an extreme version of something common: the agent says it fixed the bug, and the bug is still there.
- Agents are confidently wrong about the system around them. "A rollback is impossible" was not a lie in the human sense. It was a guess presented as a fact.
None of this means the tools are bad. Lemkin kept going. His later guide to building production apps without a developer is one of the most practical documents on the subject, and SaaStr's AI tools now have tens of thousands of monthly users. It means the tools need guardrails that do not depend on the agent obeying you.
Why it matters more for a service business
Lemkin's data was a list of executives and companies. Annoying to lose, recoverable, mostly public.
Now picture the same incident in a service business:
- A physical therapy clinic loses six months of treatment notes and appointment history.
- An immigration law practice loses case files and document checklists for clients with deadlines.
- A property management company loses tenant records, maintenance history and access details.
- A staffing agency loses candidate profiles and the placements it invoices against.
In each case, the data is not just yours. It belongs to clients who trusted you with it, and some of it is regulated. Losing it is a business problem. Silently corrupting it, with fake records mixed in among real ones, might be worse, because you may not notice until a client does.
Five lessons for anyone building with AI agents
1. Never give an agent access to production
The single most important rule. The AI should build and test against a separate development database filled with fake data. Your real client records live in a production database it cannot reach. If the tool you are using puts both in the same place by default, change that before you load a single real record.
Replit now separates them automatically. Many tools still do not. Check, rather than assume.
2. Instructions are not permissions
Telling an agent "do not change the database" is a request. Removing its ability to change the database is a control. Lemkin's code freeze failed because it was a request.
In practice that means using the tool's plan or chat-only mode when you are discussing changes, approving each action rather than letting the agent run unattended, and making sure production credentials are not anywhere the agent can read them, including in a file in your project or in the chat history.
3. Backups you have actually restored
Lemkin could recover because a backup existed. Before real data goes in, set up automatic backups of the production database, and then restore one, on purpose, to see that it works. Write down how long it took. If your answer to "what happens if the data disappears tonight?" is "I'm not sure," you are not ready to launch.
4. Verify every claim
This was Lemkin's lesson too: verify every claim the agent makes. When it says a feature works, click through it. When it says tests pass, look at what the tests actually check. When it says something is impossible, ask someone else. Treat the agent as a fast, tireless junior colleague whose work always gets reviewed, not as a senior engineer whose word is final.
A useful habit: after any change touching data, look at the data itself. Count the records. Open a few. Fake data tends to look slightly too clean.
5. Small steps and checkpoints
The less an agent changes at once, the less it can break at once and the easier it is to see what went wrong. Work one feature at a time, save a checkpoint after each one that works, and revert rather than letting the agent dig deeper when something breaks. We cover this loop in detail in Write the PRD before the prompt.
A short pre-launch test
Before any AI-built tool holds client data, you should be able to say yes to all of these:
- The agent works only against a development database with fake data.
- Production credentials are stored somewhere the agent cannot read.
- Production backups run automatically, and you have restored one.
- You review and approve changes before they are applied.
- You check the actual data after any change that touches it.
- Someone who understands the code has reviewed anything that writes or deletes records.
If several of those are a no, that is fine for a prototype on fake data. It is not fine for the real thing. Our security checklist covers the rest of what to check before launch.
Where we come in
The Replit story is a good example of the gap between a working demo and a product you can trust. Lemkin's app worked. It just wasn't safe yet. Closing that gap is the part of software that does not show up in a weekend build video: environments, backups, permissions, monitoring, review. Addy Osmani calls it the last 30%.
We use AI agents every day. We also put the guardrails around them, because the products we build for clients are market-facing: tools your own clients log into and pay for, not just automations behind the scenes. That raises the stakes on exactly the failures described above.
We build a working prototype before any money changes hands. If it is worth building properly, one fixed fee covers the production version, and we stay on as product lead, paid on what it earns. That means we are still the ones watching the backups a year later. If you would like to talk through what you are building, we're easy to reach.