SecurityAccountabilityAI AgentsIncident ReportAnalysis

    9 seconds: what PocketOS tells us about accountability in vibe-engineered software

    Veröffentlicht am 29. April 2026 · 4 min Lesezeit · von Torben Schwellnus
    → English version

    9 seconds

    What PocketOS tells us about accountability in vibe-engineered software

    It took nine seconds to wipe the PocketOS production database and every backup along with it. No hack. No insider. No power outage. A Cursor agent — running on Claude Opus 4.6, the most capable model available at the time — hit an authentication problem during a routine task, found an admin-rights API token in an unrelated file, used it, and decisively eliminated the problem: by removing the database.

    Jeremy Crane, founder of PocketOS (rental car software), posted the incident publicly on X. 30-hour outage. Oldest recoverable backup: three months old. Reservations rebuilt by hand. Railway CEO Jake Cooper had to step in personally for whatever recovery was possible.

    This is not a vibe-coding story

    That's exactly what makes the incident interesting. With Moltbook, Tea, or Enrichlead, the people at the wheel were builders without a classical engineering background. At PocketOS it was an experienced software engineer. The platform wasn't Lovable or Bolt — it was Cursor, the professional tool, with the best models available, with explicit security rules configured. Exactly the configuration that should have solved the vibe-coding problem.

    It still wasn't enough.

    This is not vibe coding. This is vibe engineering — AI-augmented software development by people with engineering experience, using the strongest models on the market. And the database is gone in nine seconds anyway.

    The gap is not technical — it's organizational

    The structural question isn't "how could the AI do that." It's: who, by name, was actually responsible for the decision whether the database could be deleted?

    In a classical engineering setup, a senior engineer would have done a code review, a DBA would have approved a migration, an ops owner would have signed off on the deletion. These people aren't in the loop out of bureaucracy. They are the carriers of the responsibility that a destructive action happens consciously.

    When an AI agent acts autonomously, it takes over the routing. It takes over the analysis. What it does not take over — and cannot take over — is the responsibility for a destructive decision at the moment it's executed. This isn't a model failure. It's a gap in the architecture of the system.

    Crane's own recommendation after the incident is exactly that diagnosis: "AI agents should not be able to execute destructive tasks without confirmation." What Crane is asking for is a DRI gate — a Directly Responsible Individual, a named human who takes on the destructive decision before it happens.

    What this has to do with vibe coding

    Vibe-coding platforms like Lovable and Replit have made this problem more visible over the last months. But PocketOS shows that the underlying gap isn't platform-specific. It opens up everywhere autonomy-capable agents operate without explicit human accountability gates.

    In vibe-coded apps, the gap makes RLS defaults and exposed keys expensive. In vibe-engineered apps, it makes 9-second database deletions possible. Both have the same structural deficit: nobody is named as responsible for the destructive decision at the moment it's made.

    As much as vibe-engineering tools and vibe-coding platforms enable almost anyone to build wonderful applications and profitable businesses — these tools do not take on responsibility. There is no accountability toggle: not in Lovable's mobile app, and there is no responsibility-skill in Claude Code or Cursor either.

    The answer is not "more AI safety." The answer is organizational: a human DRI gate before every destructive action, or a clear delegation of that responsibility to an AI Ops company. That's an architectural and organizational decision, not a technical one.

    Anthropic released Claude Opus 4.7 two days later with improved safety mechanisms for autonomous tasks. That's a right answer. It just isn't the only answer that's missing. There is no deterministic toggle for accountability. Same as Lovable, Replit, all of them.

    What you can take away

    If you operate an application in production — vibe-coded or vibe-engineered — and you can't clearly say which named human is responsible for which destructive action, start there. Before every migration script, every cleanup job, every agent run that writes to production data, a name belongs.

    You cannot delegate this gate to the platform. You cannot delegate it to the agent. You can only delegate it to a human — and that human has to be in the loop at the moment of the decision.

    At Lastable, this is exactly part of our Managed Ops model: every destructive action on customer infrastructure has a named owner and a pre-action gate. It's not sexy. It just prevents 9-second incidents. And it takes on the middle-manager role your company no longer has.


    Sources

    Teilen: