Deshacer lo que hizo un agente: checkpoints, control de versiones y sus límites
Deshacer lo que hizo un agente de IA exige puntos de restauración. Qué se revierte fácil, qué no y cómo diseñar el deshacer para que la persona confíe.
¿Por qué deshacer es parte del diseño?
Un agente que actúa rápido también puede equivocarse rápido. Si la persona no tiene una forma clara de volver atrás, deja de delegarle tareas. Los permisos que definen qué puede tocar el agente, en UX de permisos para agentes, son la otra mitad de esa confianza. El deshacer es lo que hace que la autonomía sea tolerable: se sabe que un error tiene salida.
Hay una diferencia de fondo que conviene tener clara desde el inicio. Revertir un cambio en un archivo es recuperar un estado. Revertir un efecto en el mundo, como un mensaje que ya llegó a un cliente, no es posible. Un diseño honesto no promete deshacer lo que no se puede deshacer.
¿Cómo funcionan los puntos de restauración?
Claude Code, por ejemplo, registra un checkpoint antes de cada mensaje que inicia un turno. Según su documentación, guarda instantáneas de los archivos de los 100 checkpoints más recientes de cada sesión y permite restaurar el código, la conversación, o ambos, desde un menú de rewind. También ofrece resumir la conversación desde un punto, para liberar espacio de contexto.
Esa misma documentación enumera límites que conviene conocer:
- Los cambios hechos por comandos de terminal no se rastrean. Si el agente ejecuta
rm,mvocp, el rewind no puede deshacerlos. Solo se rastrean las ediciones hechas por las herramientas de edición. - Las ediciones de subagentes y de otras sesiones no están garantizadas. No cuentes con el rewind para ellas; ten git como respaldo.
- Los cambios externos no se registran. Lo que la persona cambia a mano, fuera de la sesión, normalmente no entra al checkpoint.
- Los checkpoints no son eternos. Solo se conservan los 100 más recientes de la sesión, y con sesiones antiguas un rewind puede fallar porque los archivos ya no existen.
Lo que se aprende de esta lista es que el deshacer depende de qué herramienta hizo el cambio. Un diseño que lo promete de forma general engaña.
¿Qué papel tiene el control de versiones?
El control de versiones es la red de seguridad más fuerte para cambios de código. Anthropic, al describir cómo un agente trabaja a lo largo de muchas sesiones, recomienda hacer commits descriptivos: permiten volver a un estado funcional y revertir un cambio malo sin depender de la sesión.
Para un diseñador que trabaja con agentes, la lección es práctica: si el producto guarda cambios en un repositorio, cada turno importante debería terminar en un commit con un mensaje que diga qué hizo el agente. Así el deshacer es un git revert, no una adivinanza.
¿Qué se puede deshacer y qué no?
| Tipo de acción | ¿Se puede deshacer? | Cómo |
|---|---|---|
| Edición de archivo por herramienta de edición | Sí | Checkpoint o control de versiones |
| Comando de terminal que modifica archivos | Difícil | Solo con git o copias previas |
| Creación de un registro en tu sistema | Depende | Borrar, si el sistema lo permite |
| Correo, mensaje o notificación enviados | No | Solo se puede compensar con otro mensaje |
| Pago o cargo ejecutado | No | Requiere un proceso de reembolso |
La última columna es la que más se olvida. Para las acciones que no se pueden deshacer, la protección es previa: aprobarlas antes de que ocurran, no revertirlas después. Ese es el terreno de la aprobación de acciones, y de mostrar el efecto antes con la vista previa de cambios.
¿Cómo diseñar el deshacer?
- Muestra qué se va a revertir antes de confirmar. “Restaurar el código a las 14:32” es claro. “Deshacer” a secas no lo es.
- Separa código y conversación. A veces la persona quiere volver al código pero conservar la charla, o al revés. Ofrecer ambas opciones evita perder algo sin querer.
- Marca lo que no se puede revertir. Si una acción tuvo efecto externo, dilo con el mismo peso visual que el botón de deshacer.
- Conserva el registro. Aunque se revierta, debe quedar qué hizo el agente y cuándo. Eso sirve para auditar y para entender el error.
Ejemplo
Ejemplo ilustrativo: un agente refactoriza los estilos de una aplicación y, sin querer, cambia también el archivo de configuración de temas. La persona lo nota después de tres turnos.
El equipo tiene checkpoints por turno y commits al final de cada tarea. La persona abre el menú de restauración, elige el punto antes del refactor y restaura solo el código. El archivo de temas vuelve. Pero el agente también ejecutó un comando de terminal que generó archivos temporales en otra carpeta: el checkpoint no los rastreó, y la persona tuvo que borrarlos con git. El equipo añadió a su guía que los comandos de terminal se revisan al final de cada tarea.
¿Cuándo NO conviene prometer deshacer?
Cuando la acción tiene efecto fuera del sistema, cuando el sistema no registra sus cambios, o cuando la restauración puede pisar trabajo de otras personas. En esos casos el diseño debe dar confianza por otra vía: aprobación previa, borradores sin enviar o una vista previa del efecto.
Errores comunes
- Prometer un “deshacer” general cuando solo cubre archivos editados por una herramienta.
- Mostrar el botón sin decir qué estado va a volver.
- No separar lo revertible de lo externo.
- Depender solo de la sesión y no de un historial de commits.
- Olvidar que los checkpoints son limitados y el rewind puede fallar.