Never run an AI-written UPDATE or DELETE unreviewed

The fastest way to lose data with AI is to paste a generated UPDATE or DELETE straight into a production console and press enter. The model does not know which rows exist, and a missing or wrong WHERE clause turns a targeted fix into a table-wide overwrite.

Make destructive statements safe with a fixed routine:

1. Read the whole statement out loud. Confirm the WHERE clause names exactly the rows you intend, and that it is present at all.
2. Preview first. Run the same filter as a SELECT and check the row count before you run the UPDATE or DELETE. If the SELECT returns far more rows than expected, stop.
3. Wrap it in a transaction. Begin a transaction, run the statement, inspect the affected count, and commit only when it matches. Roll back otherwise.
4. Back up before anything irreversible. A recent, tested backup is what turns a mistake into an inconvenience.
5. Run it yourself. A person who understands the blast radius executes the statement. Never let an unattended agent both write and run a destructive change.

A prompt that helps: ask the model to write the change as a preview first, then the write itself.

Write a SELECT that shows exactly the rows this change will affect, then the UPDATE itself. State how many rows you expect to match and the assumption behind that number.

The point is not to distrust every query. It is to make sure the human between the model and the data is awake at the moment that matters.