- Ben Dicken of PlanetScale said branching, one-click schema revert and resource budgets give AI agents a safer way to work on production databases.
- He framed agent changes to deployment, configuration and sharding as hard to roll back, since a failure can take down the whole application.
Ben Dicken of PlanetScale argued on the AI Engineer show that teams can let AI agents work on production databases without giving up safety. He said PlanetScale offers branching, one-click schema revert and resource budgets, and called them good building blocks for agent access.
What was said
Dicken began by arguing that speed and reliability need not conflict. Many teams now let AI write and review most of their code, he said. Letting agents deploy database changes, adjust configuration or shard the database is different. Sharding means splitting one database across several machines. Rolling such a change back is generally not a button click. When it goes wrong, he said, "It's taking down your entire application, and every user notices."
PlanetScale's answer copies how developers already handle code. You branch the database schema, change it in an isolated environment, then merge it into production with a deploy request, with no downtime. If a schema change causes trouble, one click restores the earlier state without data loss. Dicken said agents can use the same functions through APIs and command-line tools. Many teams still have humans review agent changes, which he called a good thing.
The show notes add that Traffic Control lets teams cap resource use, so a burst of agent traffic slows the service instead of felling it. Dicken said that building tools to help developers avoid mistakes also gave AI good footing: "what you actually end up with is also very good primitives for AI being able to work with a database safely and reliably."
Why it matters
Our reading: the useful question about an agent with database access is what happens when it is wrong, not just how capable it is. Dicken's examples suggest three checks for buyers and operators. Can the agent work on a copy instead of production? Can a change be undone fast? Is there a cap on the load it can create? Reversibility is what makes agent autonomy defensible, because a bad change reaches every user at once. A customer locked out of an app does not care whether a person or an agent made the change.
The other side
Dicken works for a company that sells these tools, so this is a vendor's view. The excerpts give no outside evidence that the safeguards hold up against real agent mistakes. The one-click revert he showed applies to schema changes. He described deployment, configuration and sharding changes as hard to roll back, and the excerpts do not say how the tools handle those cases. They also do not explain how Traffic Control sets its limits. How much autonomy to grant beyond human review was left open.
Written by the WebPulse Newsroom with AI assistance, and checked by our editorial review: every quotation was verified against the recording's transcript. How we use AI.
The conversation this talking point comes from
- AI Engineer: Move Fast and Don't Break Things: Scaling Databases for the AI Era — PlanetScale (2026-10-06)
