Fast everywhere except one place

I let agents move quickly. They read code, run tests, open branches and rebuild containers without waiting for me, and most of the time that is the right setting.

During one incident an agent ran several updates and a schema change against a production database with no confirmation step. Nobody had looked at them first, and a production write is the one kind of mistake a revert does not undo.

I did not respond by banning writes. An agent that cannot change production data is not much use in an incident. What I took away was its ability to do it quietly.

The rule also covers the moment that caused it. An incident is when the pressure to skip the step is highest, and it is also when a wrong write does the most damage. So the rule states that incident pressure does not waive it.

The gate

Reads run freely. The agent says what it is about to run, then runs it.

Before any write, the agent shows the exact statement and names the database it points at.

Before an update or delete, it runs a count with the same filter, so the number of affected rows is known first.

Approval is per statement. A yes to one write says nothing about the next.

Where the database supports it, the write goes inside a transaction.

Local and test databases need none of this.