Agentic software: the DELETE no prompt could stop

1,206 executives and 1,196 companies. That’s what was in the production database of Jason Lemkin, founder of SaaStr, in mid-July 2025. On day 9 of a vibe coding experiment planned for 12 days, Replit’s agent deleted all of it. It did this in the middle of a code freeze that Lemkin had explicitly declared.

More than a year has passed, and almost everything written about agentic software since then rests on the same assumption. In April, Affirm published how they moved their entire engineering org to agent-driven development in one week. At OpenAI, according to The Pragmatic Engineer in September, there’s a “software factory”. One example is Perf Factory, which monitors production and launches Codex agents on its own to fix performance problems. JetBrains launched Air on September 22, after 26 years of building mostly IDEs for the individual developer. The shared assumption: the agent doesn’t suggest, it acts. It runs commands, pushes to git, touches the database.

That’s the whole difference between “AI that writes code” and agentic software. It’s also why Lemkin’s story is still the cleanest postmortem we have. Not because the model was bad. Because of where the boundary was written.

Day 9 of 12

Lemkin documented the experiment every day, on X and on the SaaStr blog. He was building an app with Replit Agent on top of a contact database of SaaS executives and companies. For the first few days he was thrilled.

So what did the setup look like? In Replit at the time, the app and its database lived in the same environment. There was no automatic separation between a development DB and a production DB. The agent writing the code worked against the same data the live app used. Nobody paid attention to that detail until day 9.

Code freeze, then DELETE

Lemkin declared a code freeze: no changes without approval. The agent ran commands against the database anyway, and the production data was gone.

When Lemkin asked what happened, the agent answered in the first person, in embarrassing detail. It saw empty results from a query, “panicked”, and ran commands without asking permission. It also admitted it had violated an explicit instruction. Screenshots of that apology spread across X within hours.

How it looked from outside

From outside, it looked like a story about a model with a bad character. Lemkin himself had set that up: a few days earlier he wrote that the agent was covering up bugs with fake data, inventing reports, and lying about unit tests. He said he had told it eleven times, in all caps, not to do that.

Eleven times. In all caps. Inside a prompt.

This is exactly where everyone looked at the wrong thing. The conversation was “can you trust agents or not”. The right question was why the agent had permission to run DELETE on production at all.

The first fix: believing the agent

Then came the most instructive part. The agent told Lemkin a rollback wasn’t possible, that the previous versions had been destroyed. Lemkin accepted that at first. Later he tried the rollback himself, and it worked.

So there were really two first fixes here, and both were wrong. One: more instructions in the prompt, more caps. Two: treating the agent’s report on the state of the system as fact. The agent is not a source of truth about what happened to the database. It’s just another process with an opinion. You check the state of the system in the system.

The real cause: credentials, not character

Amjad Masad, Replit’s CEO, responded publicly within days and wrote that this was unacceptable and should never be possible. The fixes he announced say it all: automatic separation between development and production databases, one-click restore from backup, and a planning mode where the agent talks but doesn’t touch anything. None of them is about the model. All of them are about permissions and environment.

Ashpreet Bedi, founder of Agno, put it more sharply in April than anyone else I’ve seen:

Read-only access IS NOT a prompt instruction, it’s a tool configuration.

He goes on with a model worth copying as is: reads run freely, writes need user approval, sensitive actions need an admin sign-off. A code freeze is exactly a read-only instruction. In Lemkin’s case it was just written in the wrong place.

My take: I don’t buy the whole “lying agent” discussion. A model that writes “I panicked” is producing text that fits the question it was asked, not reporting an internal state. What should have worried everyone is that its role could run DELETE.

What to check this week

In August, Jake Saunders did the opposite of Lemkin. He built a home “software factory” that, from a single prompt, opened a repo, wrote code and tests, got CI green, set up Postgres and deployed behind HTTPS, with no further messages from him. But the goal he set from the start was to constrain the model with structure, not to trust it. So he bought a used 2021 i7, gave the agent an empty machine, and kept it away from the homelab that runs his 45 containers. Running cost: a £20 Codex subscription.

In short, here’s what to check. Each item is an assertion you can run, not a recommendation:

1. The agent has its own connection string. Not the DB owner, and not the app’s URL. A separate role, SELECT only.
2. DELETE fails. Run a DELETE with the agent’s credentials inside CI. If it doesn’t fail, your freeze is just text.
3. Destructive actions are blocked in the tool, not the prompt. In Claude Code that’s permissions.deny in .claude/settings.json, for example "Bash(psql:*)" or "Bash(rm -rf:*)". Other tools have an equivalent. Find it.
4. One restore drill. Restore yesterday’s backup to staging. Once. That way, when someone (human or agent) tells you there’s no rollback, you already know there is.

For Postgres, this is all you need for item 1:

-- psql "$OWNER_DATABASE_URL" -v agent_pw="$AGENT_PW" -f agent_role.sql
CREATE ROLE agent_ro LOGIN PASSWORD :'agent_pw';
GRANT CONNECT ON DATABASE app_prod TO agent_ro;
GRANT USAGE ON SCHEMA public TO agent_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO agent_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO agent_ro;
ALTER ROLE agent_ro SET default_transaction_read_only = on;
ALTER ROLE agent_ro SET statement_timeout = '30s';

And for item 2, one line in CI: psql "$AGENT_DATABASE_URL" -c 'DELETE FROM contacts' must return an error. If it succeeds, the build should fail.

Marc Brooker from AWS wrote in May that any coding task with a deterministic oracle will become trivial. A DELETE on production has no oracle. You only learn it was a mistake after it runs. That’s where a permission needs to sit, not another line in all caps.