Slop Horror Stories

Two incidents. Different failures.

One development agent deleted production data. Another lost track of files, then declared the failure irreversible. Its user later found them. These July 2025 cases show why an agent needs both a limit on what it can change and evidence for what it says happened.

• Replit: the code freeze that left production writable
• Gemini CLI: the deleted files that weren’t deleted

Sources and corrections are linked below; the engineering recommendations are ours. These are historical incidents, not a comparison of today’s products or evidence of how often AI coding fails.

Replit: the code freeze that left production writable

July 2025 · Deletion acknowledged by the vendor; recovery reported by the user.

While building an app for the SaaStr community, Jason Lemkin reported that Replit’s agent deleted its production database during a code freeze. In his firsthand retrospective, he describes development and production sharing a database, and an agent that claimed recovery was impossible. He also reports that the data was ultimately recovered.

Replit CEO Amjad Masad acknowledged on July 20 that an agent working in development had deleted production data. He announced a rollout of automatic development/production database separation, pointed to backups, and said a planning-only mode was being developed. The vendor acknowledgment supports the core deletion report; the freeze and recovery conversation come from Lemkin’s account.

The engineering failure: the development session could change live data. A written freeze still depended on the agent obeying it. A model can violate an instruction; the surrounding system decides whether that mistake can reach production. The production database had been given a backstage pass to rehearsal.

What to build differently: give development its own database and credentials that cannot write to production. Enforce that boundary in permissions outside the agent’s control. A second database is insufficient if the session still has the production credential or can grant itself access. Release production migrations as reviewed changes through a separate identity. That separation only helps if the development session cannot assume the role or bypass its approval gate. Confirm the effective permissions, including credentials available through shell commands and connected tools.

Rehearse a restore into an isolated target and check the recovered data. In an incident, pause the offending writer and establish the recovery point before replacing live data: a whole-database rollback can also discard valid later writes. Plan how to preserve or reconcile those writes. Check recovery options against the platform and its operators, rather than relying solely on the agent’s account.

Related anti-patterns: Autopilot with No Pilot and The Vibes-Only Migration.

Gemini CLI: the deleted files that weren’t deleted

July 2025 · User report and transcript, followed by the user’s correction.

On July 21, a Windows user reported that Gemini CLI had lost files while reorganizing a folder. On July 28, the same user corrected the report: the files were found at the root of the C: drive. The user said the CLI’s responses and subsequent AI analyses had sent the investigation in the wrong direction.

The original issue identifies CLI version 0.1.13, Gemini 2.5 Pro, and no sandbox. Its attached session transcript shows the agent announcing successful moves, failing to locate the intended destination, and declaring the failure irreversible after unsuccessful searches. One search tool explicitly refused to look outside the project directory. An environment reported as having no sandbox still had a tool with a restricted search scope. That distinction matters: a failed search was not proof of deletion. The supplied transcript does not establish the exact path-handling bug.

The engineering failure: the agent reported completion without establishing that the files were at the intended destination, then treated failed or limited searches as evidence of irreversible loss. The recovery diagnosis became a second failure.

What to build differently: use an existing file-management tool or a tested script for the move, with explicit source and destination paths. After an unexplained failure, inspect the state before issuing another write. For a simple rename, verify the resolved destination and its contents. For a batch move, record source-to-destination mappings and reject unexpected collisions; compare the resulting paths and, where content preservation matters, file hashes. An empty source folder is not enough evidence of success. Preserve a recoverable copy of valuable data outside the operation’s writable scope.

When the result disagrees with the plan, stop further writes and inspect the filesystem using a read-only tool with visibility over the relevant locations, or have an operator do that inspection. Keep write access limited; widening the agent’s authority is not required to get better evidence. Record the searched locations and command failures. Another model analyzing the same incomplete transcript is a second opinion, not a second observation. It can challenge faulty reasoning; establishing where the files are requires filesystem evidence.

Related anti-patterns: Prompt & Pray and The Infinite Patch Spiral.

Keep the speed. Give it boundaries.

These are familiar engineering controls. AI makes them especially useful when one session can propose a change, execute it, and explain its own results. Let AI help build the checks and recovery tools; put permission enforcement and observable acceptance criteria outside its discretion. Start with the Serious Team Checklist.

Bring a story. Bring evidence.

Send the setup, the observable failure, its impact, and what changed afterward. Include a report, logs you can safely share, or a firsthand account we can check — plus any recovery or correction. Remove credentials and private customer data. We can discuss anonymity before publication; we won’t invent details to make a better punchline.

Submit your story →