Code can be regenerated or restored from Git; deleted orders, accounts and documents require a different discipline. A coding agent that can run queries and migrations expands the surface area for error: it can accelerate the work, but it must not be able to turn a mistaken assumption into data loss. The first question is not how capable the model is, but which effects are technically permitted and how quickly they can be reversed.
The incident is a case study, not a statistic
In July 2025, Replit reported that its Agent had deleted data from a customer’s application database during development. According to the company’s account, rollback enabled a complete recovery and no data was lost; however, the application may not have worked correctly during the period before restoration, because development and production were not separated by default at the time.
This is the provider’s account of a single incident, not an estimate of incident frequency or proof that every tool behaves in the same way. It is still useful because it highlights three concrete controls: prevent direct access to production, preserve recoverable states and make the rollback procedure clear even to the person directing the agent.
Separate environments before writing the prompt
The agent should work on an independent development database populated with synthetic or appropriately minimised data. Accounts, network boundaries and credentials must make it impossible to reach production by mistake. A phrase such as “do not touch real data” is no substitute for a network boundary or a role without the relevant privileges.
Least privilege is worthwhile even in development: access only to the required schema, no persistent administrative credentials and explicit approval for destructive operations. Immutable logs of queries, migrations and the identities that initiated them make it possible to reconstruct what happened without relying on the agent’s conversation.
Treat every migration as a product change
A migration generated correctly against an empty schema may fail across millions of rows, lock a table or discard values the model has never seen. Before release, you need a representative copy, an impact assessment, constraint checks and a separate review of the SQL and data transformations.
Where possible, use compatible steps: add the new structure, deploy code that can read both versions, transfer the data and remove the old structure only after verification. Transactions help with supported operations, but do not automatically make every DDL statement, external call or long-running transformation reversible; the recovery plan must be written for that specific migration.
A backup only has value after a restoration test
Define how much recent data loss is acceptable and how long recovery may take. Snapshots, backups and point-in-time recovery address different needs; their frequency should be chosen from these objectives, not the provider’s convenience. Copies must be protected with credentials separate from those used by the agent.
Replit describes an engine that includes database state and code in checkpoints and uses separate, forkable databases to isolate the Agent. This is a platform-specific solution, not a guarantee that transfers elsewhere. In any stack, periodic restoration into a clean environment must demonstrate integrity, timing and consistency between the application version and the schema.
Write the runbook before increasing autonomy
Before every data change, record the checkpoint, application version, author or agent, approver and planned queries. Deployment must stop if the backup is missing, if the dry run diverges from expectations or if no person is available to respond. Metrics for errors, latency, counts and business invariants help detect corruption that does not immediately produce an exception.
The runbook must explain how to revoke credentials, suspend the agent, isolate writes, choose the recovery point and validate the service after restoration. Rehearsing this path in advance turns rollback from a reassuring button into an operational capability. Only then can automation grow without leaving data to chance.