Checkpoints y rollbacks: volver atrás de forma limpia en vez de seguir remendando

Commits de Git antes de pasos arriesgados y funciones de rebobinado integradas convierten un intento fallido de un agente en un simple «volver atrás», en vez de corregir sin fin.

Dos niveles de checkpoints

En el trabajo con agentes vale la pena tener checkpoints en dos niveles: de forma permanente en Git (un commit antes de un paso arriesgado, que puedes recuperar de forma dirigida en cualquier momento) y localmente en la propia herramienta, como el checkpointing de Claude Code, que guarda automáticamente el estado de los archivos antes de cada prompt.

Cómo funciona el rewind de Claude Code

Antes de cada prompt, Claude Code guarda automáticamente una instantánea (snapshot) del código. Mediante /rewind (o pulsando Escape dos veces con el campo de entrada vacío) abres un menú con opciones de recuperación — desde restablecer por completo código y conversación hasta restablecer solo la conversación manteniendo el código.

Por qué volver atrás es mejor que seguir remendando

Cuando un agente se ha enredado en un enfoque equivocado, «simplemente dejar que siga reparando» suele llevar a parches cada vez más nuevos sobre unos cimientos ya rotos. Un rollback limpio hasta el último estado funcional y un nuevo intento deliberado suele ser más rápido que rescatar paso a paso un estado ya enmarañado.

El límite de los checkpoints

Los checkpoints integrados solo registran cambios que la propia herramienta hizo mediante sus herramientas de archivo — los cambios hechos con comandos de Bash como rm, mv o cp quedan fuera. Los checkpoints complementan a Git, pero no lo sustituyen: los checkpoints son el «deshacer» local, Git es el historial permanente.

EJEMPLO

git add -A && git commit -m "checkpoint: antes de refactorizar auth.py" # después dejar que el agente trabaje libremente # si hace falta: git reset --hard HEAD~1 (volver al checkpoint) # o dentro de la sesión: /rewind → "Restablecer código" para el último prompt

🛠️ EJERCICIO — PRUÉBALO TÚ

Fija de forma deliberada un checkpoint de Git antes de una tarea arriesgada con un agente y prueba tanto /rewind como un rollback de Git.

Haz commit del estado limpio actual de tu proyecto con un mensaje de checkpoint claro.
Deja que un agente haga un cambio más grande y arriesgado (p. ej. una refactorización en varios archivos).
Usa /rewind para restablecer de forma dirigida solo el código, mientras la conversación se mantiene.
Simula un caso peor: además, restablece de prueba con git reset --hard al commit anterior.

✅ AUTOEVALUACIÓN

☐ ¿Pudiste con /rewind restablecer de forma dirigida solo el código, sin perder la conversación?
☐ ¿Qué habrías hecho si el agente hubiera eliminado el archivo en su lugar mediante rm?

QUIZ RÁPIDO

¿Qué NO registra el checkpointing de Claude Code, de modo que para eso sigue siendo necesario Git?