Beware of Frankenstein!

Two articles landed in my feed this week about the Replit database incident. Both well-reported. Both specific about which model was involved. Both about seven months late.

The ZDNet piece covered Jason Lemkin's experience as if readers were hearing it for the first time.¹ heise online added a detail nobody else had pinned down: Lemkin had switched from Opus 4 to Claude 4 Sonnet for cost reasons before everything went sideways.² Useful reporting. Except the incident was July 2025, and neither article mentioned what happened next.

What happened next is that Replit fixed it. By December, they'd shipped a snapshot engine with dev/prod database separation, filesystem rollbacks, and sandboxed environments where the agent can only touch development data.³ The problem these articles describe hasn't existed in months.

Seven Months in AI

In most industries, seven months is a footnote. In AI development, it's a generation.

The tools I use today look nothing like what I was using last July. The guardrails, the permission systems, the way models interact with production data. All of it has changed. Last summer's disaster stories read like horse-drawn carriage warnings published after the Model T shipped.

Replit didn't just patch the problem. They rebuilt the entire relationship between their agent and production data.³ That's not a hotfix. That's an architectural admission that the original design was wrong, and they made the correction in months, not years.

Seven months of spare parts.

The Wrong Fear

The problem with publishing stale AI disaster stories as current news is that they create the wrong fear. People read these articles and blame the model. "Claude deleted the database." No. An environment with no guardrails gave an AI agent unrestricted write access to production, and the predictable thing happened.⁴

That was the real story in July. What makes these articles worse than late is that they don't tell you the problem was solved. They leave the reader with a fear that no longer matches reality, aimed at the wrong target.

I use the same Claude model family every day. I've never had a database deleted. Not because the model is careful, but because the tools I use assume the model will make mistakes and build accordingly. When I run something destructive, the tool stops and asks me first. Every change goes into version control before it touches anything real.⁵

Know what your tools can do today, not what they couldn't do seven months ago.

Tool Integrity

In a field moving this fast, your obligation isn't to avoid AI. It's to keep up with your tools. Know what guardrails exist today. Know what changed since the last time someone scared you with a headline.

Seven months ago, Replit didn't separate dev from production. Today it does. If your understanding of the risks is still based on July, your understanding is the spare part, not the tool.

Beware of Frankensteins. The ones stitched together from old parts and presented as new. And the ones you build when you choose your tools without checking what they've become.

---

References

Footnotes

1. Vaughan-Nichols, S. (2026). "Bad vibes: How an AI agent coded its way to disaster." ZDNet ↩

2. heise online (2026). "Artificial intelligence: Vibe coding service Replit deletes production database." heise ↩

3. Replit Engineering (2025). "Inside Replit's Snapshot Engine: The Tech Making AI Agents Safe." Replit Blog ↩ ↩²

4. Edwards, B. (2025). "Two major AI coding tools wiped out user data after making cascading mistakes." Ars Technica ↩

5. Sharwood, S. (2025). "Vibe coding service Replit deleted user's production database." The Register ↩