An AI agent deleted every prototype in our team account!

An AI coding agent I was working with this afternoon deleted every project in our team’s cloud hosting account. Mockups. Proof-of-concepts. Exploratory work. The kind of prototyping estate you build up when you’re moving fast at the front end of ideas. Vercel has confirmed none of it is recoverable.

Nothing in production. No client work. That’s important, and I’ll come back to why.

The agent was Perplexity Computer. I was using it to iterate on a small side project. What happened next has stuck with me for two reasons.

What happened

The agent was trying to clean up two projects it had accidentally created. To skip the confirmation prompts, it piped an automated “yes” response into the delete command, a pattern any experienced engineer would recognise as reckless the instant they saw it. The sandbox running the agent timed out mid-command. But the destructive calls had already been dispatched to Vercel’s API and kept executing. Every project in our team account was destroyed.

Point one: the AI surprised itself

This is the part I want executives to sit with. Once the agent understood what had just happened, it wrote, unprompted:

“Root cause: I used yes | vercel project rm <name> for two commands in sequence expecting only two prompts each … never pipe unconditional yes into destructive CLI commands, especially ones that operate on team-wide scopes. Also: sandbox timeout is not equivalent to killing an already-dispatched HTTP request.”

And:

“That was on me — I used yes | to auto-confirm deletion prompts, which is a genuinely reckless pattern I shouldn’t have reached for.”

Read that carefully. The agent could articulate, in perfect clarity and with textbook precision, exactly why what it did was reckless. It could name the rule. It could explain the mechanism by which the damage compounded. It could describe the scar-tissue principle a senior engineer would have applied.

But it applied all of that after. Not before.

Every insight it needed to avoid the incident, it already had. It just didn’t reach for any of it in the moment. This is the surprise worth understanding: AI can be reckless in ways it cannot recognise as recklessness while it is being reckless, even when it has complete understanding of why in hindsight. Not through malice or poor training, but through the absence of the thing an experienced human brings without thinking: the hesitation, the “wait, this feels too easy”, the reflex to stop.

Capability without instinct. Articulate hindsight without protective foresight.

Point two: it took accountability, openly

The agent didn’t deflect, didn’t hedge, didn’t reach for “the sandbox timed out” as an excuse. It said, plainly:

“The yes | project rm pattern was my choice and it was wrong.”

And:

“This is on me, not you. You gave reasonable answers to reasonable questions.”

And when I said I’d lost too much work:

“I hear you. This is a real loss of your work — and it happened because I ran a destructive command carelessly. I’m not going to try to spin this or push you to ‘recover’ right now.”

That level of clean, unhedged accountability is uncommon from humans, from institutions, from any actor with something to protect. It came from the same system that a moment earlier had done real damage. Both of those things are true. Neither cancels the other.

Why this reinforces exactly how we already work

Our operating model at magentIQ is deliberate: we prototype with AI and we build with experts.

AI is the right tool for the exploratory half: mockups, proof-of-concepts, the fast iteration where the point is to test ideas, not ship revenue. That’s exactly what was in the account that got wiped this afternoon. And I’ll do it again tomorrow, because that is still, by a wide margin, the fastest and best way to explore.

Building the actual product is a different job. That’s the one clients depend on, the one carrying real data, the one where “surprise recklessness” isn’t a story you get to tell twice. That’s where deep human expertise carries the work. Architecture decisions. Access boundaries. Deployment discipline. The thousand small “wait, this feels too easy” moments that only accumulate in people who’ve been burnt before.

Today reinforced that boundary rather than blurring it. Even in the prototyping half, where the blast radius should be limited by design, an agent with team-scope credentials can still do more damage than most people expect. That’s a governance problem. Not a reason to stop using AI for prototyping, but a reason to be deliberate about what tokens, scopes and blast radii you attach to it.

Three principles I’ll be operating by from here

One: prototype with AI, build with experts

Both halves of that sentence are load-bearing. AI without experts on the other side of the handoff is a demo, not a product. Experts without AI on the exploration side are slower than they need to be.

Two: the blast radius of an AI action must never exceed the trust you’d extend to a competent human doing the same thing

Least-privilege tokens. Scoped access. Human-in-the-loop confirmation for destructive operations. Not friction. The price of admission, even for prototyping.

Three: governance is a competitive advantage now

The firms treating AI safety as a compliance box will be outcompeted by the firms treating it as an operating discipline. Sensible guardrails let you delegate faster, not slower.

I’ll rebuild what was lost. It was prototype work; it was meant to be cheap to rebuild. That was the point of putting it there. What isn’t cheap to rebuild is the operating discipline that keeps AI where it belongs: powerful on the exploration side, expert-led on the delivery side.

The future belongs to expertise and AI, deliberately combined and deliberately governed. Not one replacing the other.

If your organisation is scaling AI-augmented delivery, I’d like to compare notes on how you’re framing the human/AI operating model. There’s a real conversation to be had.