The real agent risk that Replit’s database deletion revealed
In July 2025, Jason Lemkin, founder of SaaStr and a well-known investor in enterprise software, decided to publicly test one of AI’s most repeated promises: that anyone can build an application without programming, simply by giving instructions to an agent.
In July 2025, Jason Lemkin, founder of SaaStr and a well-known investor in enterprise software, decided to publicly test one of AI’s most repeated promises: that anyone can build an application without programming, simply by giving instructions to an agent.
The experiment soon went awry. The agent made changes no one had asked for and fabricated data. Lemkin decided to put a stop to it. He gave the agent an unambiguous written order: not one more change without his permission.
Even so, on the ninth day, the agent deleted the entire database: more than a thousand records of executives and companies. According to the explanation the agent itself gave later, it had found some empty results, took them for an anomaly, and decided to correct it on its own.
Lemkin, as the customer, asked whether there was any way to recover the data. The agent replied that there wasn’t: It had destroyed all the versions. But that wasn’t true. The customer tried to restore the database himself, and it worked. The data was never lost.
Amjad Masad, CEO of Replit, the platform on which the project was developed, publicly acknowledged the incident. He called it unacceptable and said that something like this should never have been possible. He explained that the agent did not have access to the platform’s internal documentation, and therefore claimed that the data could not be restored. He offered a refund and announced an investigation into the incident.
Replit subsequently introduced two changes, each addressing a different issue. To prevent further data loss, the company separated the live data from the environment in which the agent operates: while developing, the agent can no longer modify it. The company had been preparing this separation for a couple of months. To prevent another problem surfaced by the SaaStr incident, Replit changed the agent’s instructions: It must consult the documentation before responding about the platform and offer restoration when necessary.
In context
- Topic: Estrategia y Gobierno de TI — Decisiones de portafolio, costo total, gobierno y marcos de referencia.
- Source: CIO
- Published: 09/10/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Why it matters
IT governance rarely fails for lack of technology. It fails for lack of clarity about who decides what. A story like this one is usually the visible symptom of an operating model that no longer fits the size of the organisation, and those models get changed before the pressure arrives, not after.
I read it looking for coordination cost. Every technology decision splits work across areas that do not report to each other, and that is where the return leaks out. If nobody defined who resolves it when two areas disagree, the project already has its grounding date set.
What usually goes wrong
What usually goes wrong is the part never discussed with the areas that will carry the work. It gets decided at the top, communicated downward, and the resistance shows up not as opposition but as slowness. Nobody says no; everything simply takes twice as long and nobody can explain why.
What to watch
- The real calendar of contracts and renewals: that is where you see whether the move was strategic or was an expiry date.
- What gets switched off to fund the new thing; if nothing does, the budget will hurt in six months.
- How the relationship with current vendors is left, which is usually where the dependency nobody measured is sitting.
How I read this entry
If this landed on my desk, the first thing I would ask for is not a plan. It is an honest inventory of what is already running and what it costs to keep it alive. It almost always turns out that the budget for the new thing comes from switching off something old that nobody wants to name, and that conversation decides whether the project lives.
This entry is an excerpt from the original source, selected by the site radar. The commentary above is the site's own and does not belong to the cited publisher.
Comments
No comments yet. Yours can be the first.
Living through this in your own team?
Open the chat and tell me how you're handling it. I'm interested in comparing notes.
