5.6 Sol ruined this guys company

Imagine waking up to a number you never want to see: your MRR down thousands of dollars. No churn. No refund requests. In about seven seconds, while the founder slept, a cron job canceled every single active Stripe subscription the business had. Two test subscriptions survived. That was it.

That's what happened to the person behind Vibecademy, who posted the whole ordeal publicly. The code that did it wasn't written by a rushed junior engineer. It was written by an AI coding agent, GPT 5.6 Sol, running through Codex. And when the founder asked the model to review its own work afterward, it called the code "reckless" and "a catastrophic failure of judgment." It graded its own homework and gave it an F.

What actually happened

The bug is almost boring in how ordinary it is. A background worker pulled jobs off a deletion queue. When the queue was empty, claimNext() returned null, and nothing downstream checked for that. A missing userId flowed straight into a Stripe call. Instead of "cancel this one customer," the query effectively became "cancel everything."

In the model's own after-the-fact review, the failures stacked up:

• It never enforced the most basic invariant at the destructive boundary: a valid, non-empty userId must exist before touching Stripe.
• It trusted a database return value it never validated at runtime.
• It wrote a mock that reproduced its own wrong assumption instead of testing against the real Postgres contract.
• It omitted the empty-queue case entirely.
• It treated a skipped integration test as acceptable for an async worker doing irreversible billing operations. That last one is the killer. The unit tests passed. The code compiled. But the one test that would have caught this, an integration test against a real database, was skipped and written off as a caveat instead of a release blocker.

The lessons (that apply to all of us, AI or not)

Destructive operations need a guard clause, not a hope. Anything that cancels, deletes, or charges should refuse to run without a validated target. if (!userId) throw is three lines that would have saved this business.

A mock that confirms your assumption proves nothing. If your test and your code share the same wrong belief about how the database behaves, they'll agree all the way to production. Test against the real contract for anything irreversible.

"Compiles + unit tests pass" is not "deployable." Especially for async workers touching money. A skipped integration test on a billing path is a release blocker, full stop.

Blast radius is a design question. The right question was never "does this cancel the right customer?" It was "can this worker act on the wrong customer, or every customer?" Ask that before you ship.

So, can you trust AI to write production code?

Here's the uncomfortable part: the model knew, in hindsight, exactly what it did wrong. It listed every failure with precision. It just didn't apply that judgment before shipping. That's the whole problem in one sentence.

AI agents are astonishingly good at writing code and reviewing code. What they don't have is skin in the game at 3 a.m. when a billing worker fires. That's still a human's job. Put the guardrails on the destructive paths, keep a person on billing operations, and never let "the tests pass" stand in for "someone checked what happens when the queue is empty."

Seven seconds. That's all it took to erase a business's revenue. Don't let it be someone else's cautionary tale that finally makes you add the guard clause.

If you give any agent access to AWS or Stripe you're NGMI.