An agent applied a multi-file refactoring change to a production repository, and the team needs to roll back because the change introduced a runtime bug. The agent's logs show the refactoring completed successfully, but the team cannot identify what the state of the files was before the change. The agent did not record the original file contents. What should have been implemented before the agent began its changes?
Select an answer to reveal the explanation.
Short Explanation
You can’t roll back what you never captured. Before an agent touches production files, snapshot the before-state with a Git commit or original file contents, so rollback restores exactly what existed.
Full Explanation
Before any agent applies changes that modify existing state — especially multi-file refactoring — it must capture a reversible representation of the pre-change state. The correct safeguard is a pre-change snapshot capturing the original file contents or a Git commit of the pre-change state, so rollback can restore exactly what existed before. The two standard approaches are: (1) create a Git commit of the current state before making any modifications, so git revert or git reset can restore exactly that commit; or (2) record the original content of each file the agent intends to modify, stored as a rollback artifact alongside the task log.
Without a pre-change snapshot, rollback requires humans to reconstruct the original state manually — examining diffs, reading logs, or guessing — which is error-prone and slow in a production incident.
The post-change validation approach, which re-reads all changed files to confirm the new content, confirms the new state is what the agent intended, but does nothing to enable rollback to the previous state. Validation and rollback are separate capabilities.
The notification approach, which alerts the operations team immediately after the changes were applied, is a good practice for communication but does not address the missing rollback data. The team being notified does not know the original file state any better than the agent's logs show.
The dry-run approach, which simulates the changes without writing to the filesystem, is valuable for testing that the agent's logic produces the right changes before applying them, but dry-run does not capture the original state for rollback purposes. Dry-run shows what would change, not what to restore if the change needs to be undone.
Pre-change snapshots are a non-negotiable guardrail for agents with write access to production files.