La documentación de Claude Code dedica una página a los puntos de control, la función que permite rebobinar lo que ha editado el agente. La parte más útil de esa página no es cómo se usan, sino la sección de limitaciones.
Allí se lee, por ejemplo, que los puntos de control no registran los archivos modificados con comandos de shell, y que no sustituyen al control de versiones. Es una forma honesta de decir algo que vale para cualquier herramienta: rebobinar tiene un perímetro, y lo que el agente hace fuera de ese perímetro no vuelve con un atajo de teclado.
De ahí sale la tesis de esta pieza: antes de ampliar los permisos de un agente de código, decide cómo se deshace cada cosa que podrá hacer. El agente actúa solo donde el cambio es reversible; donde no lo es, decide una persona.
Qué se puede rebobinar hoy
Según su documentación, Claude Code guarda un punto de control antes de cada mensaje que inicia un turno, conserva los 100 más recientes de la sesión y permite volver a cualquiera de ellos con /rewind o pulsando Esc dos veces. Se puede restaurar el código, la conversación o las dos cosas.
El perímetro está escrito en la misma página:
- Comandos de shell. Los archivos borrados, movidos o copiados con
rm,mvocpno se recuperan rebobinando. Solo se registran las ediciones hechas con las herramientas de edición del propio agente. - Subagentes. Por lo general, rebobinar no restaura lo que editan; la documentación pide usar git para revertirlo.
- Cambios externos. Lo que se toca fuera de la sesión, a mano o desde otra sesión, normalmente no se registra.
- Historial. Los puntos de control sirven para recuperar una sesión, no como historia del proyecto: para eso sigue estando git.
Límite Todo esto vive dentro del repositorio. Una base de datos, un servicio en la nube o un mensaje enviado quedan fuera de los puntos de control de Claude Code.
El mapa de la reversibilidad
Antes de dar un permiso nuevo, conviene hacer un mapa sencillo: dónde podrá actuar el agente, si eso se puede deshacer, con qué, y quién decide en cada caso.
| Dónde actúa el agente | ¿Se puede deshacer? | Con qué | Quién decide |
|---|---|---|---|
| Editar archivos con sus herramientas | Sí, dentro de la sesión | Punto de control y git | El agente puede actuar solo |
| Commits en una rama propia | Sí | Revertir el commit o descartar la rama | El agente actúa; integrar lo decide la revisión |
| Archivos tocados con comandos de shell | Solo si estaban en git | git; lo no versionado se pierde | Una persona, antes de comandos que borran |
| Base de datos de desarrollo o pruebas | Si hay una copia que se pueda restaurar | Copia previa o entorno desechable | El agente, solo si la copia existe |
| Datos compartidos o de producción | A menudo no, o no del todo | Copias de seguridad, si existen y se han probado | Una persona |
| Servicios externos: enviar, publicar, cobrar, abrir una incidencia | No | Nada: como mucho, una corrección posterior | Una persona |
La primera fila y el límite de los comandos de shell salen de la documentación de Claude Code; el resto de la tabla y la columna «quién decide» son lectura propia de onext
El agente actúa solo donde el cambio se puede deshacer. Donde no, decide una persona, antes y no después.
La regla no pregunta si el agente es bueno, sino cuánto cuesta equivocarse. Un error que se deshace en un minuto es un coste pequeño, aunque se repita. Un error sin vuelta atrás puede ser caro aunque pase una sola vez. Por eso la línea se traza por la reversibilidad, no por la confianza.
Permisos antes, reversibilidad después
Los permisos responden a qué se le deja hacer al agente; lo explicamos en la seguridad de tu agente está en los permisos, no en el prompt. La reversibilidad responde a qué pasa cuando, con esos permisos, se equivoca. Las dos preguntas se hacen a la vez: un permiso cuyo efecto no se puede deshacer es el que merece una aprobación humana.
Esa aprobación no puede depender de que el modelo lea una instrucción del tipo «ten cuidado con la base de datos». Lo que tiene que cumplirse va en controles que se aplican solos, como contamos en Claude Code para equipos: contexto no es control. Y el mapa hay que revisarlo cada vez que se conecta una herramienta nueva: cada servidor MCP añade acciones fuera del repositorio, y muchas no tienen vuelta atrás, como explicamos en servidores MCP: las integraciones que nadie gobierna.
Revertir también se entrena
DORA, el programa de investigación de Google sobre equipos de software, publicó en septiembre de 2025 un modelo con siete capacidades que amplifican los beneficios de la IA. Una de ellas es un control de versiones sólido: según su análisis, el uso frecuente de las funciones de vuelta atrás (rollback) mejora el rendimiento de los equipos asistidos por IA. Su recomendación es directa: a medida que la IA aumenta la velocidad de los cambios, el control de versiones se convierte en una red de seguridad crítica, y conviene que los equipos dominen las funciones de revertir.
Es decir, poder deshacer no basta: el equipo tiene que saber hacerlo rápido y sin drama. Es una de las piezas de la red que conviene revisar antes de implantar un agente, como contamos en antes del agente, la red.
Cinco decisiones antes de ampliar permisos
- Haz la lista de sitios donde podrá actuar. Repositorio, terminal, bases de datos, nube y cada integración conectada.
- Escribe cómo se deshace cada uno, y pruébalo una vez. Una copia de seguridad que nadie ha restaurado no es todavía una vuelta atrás.
- Saca del alcance del agente lo que no tiene vuelta atrás. O déjalo detrás de la aprobación de una persona.
- Dale una rama propia y entornos desechables. Lo que hace ahí se descarta entero si sale mal.
- Revisa el mapa con cada herramienta nueva. Un servidor o una integración más cambian lo que el agente puede romper.
La rama propia no quita la revisión: lo que el agente quiera llevar a la rama principal sigue pasando por alguien que entienda qué hace el cambio y por qué, como contamos en revisar código generado por IA.
El mercado ya lo vende como servicio
El 5 de octubre de 2026, LTM anunció BlueVerse AgenTraceIQ, una oferta para adoptar agentes de IA de forma segura que permite, según su nota de prensa, la «restauración rápida de sistemas, datos, configuraciones y repositorios tras acciones no deseadas o destructivas». Incluye Rubrik Agent Cloud para Claude Code.
Que exista un producto así dice que el problema es real y que las empresas grandes ya lo tienen encima. Pero buena parte se resuelve con lo que el equipo ya tiene: git, ramas, entornos desechables y copias probadas. Lo que ninguna herramienta resuelve es el correo ya enviado o el dato compartido que no tenía copia. Eso se decide antes, y lo decide una persona.
Dónde encaja onext
En AI-Accelerated Development, una persona decide donde hay riesgo. El primer paso es un diagnóstico gratuito, y si en el diagnóstico no vemos diferencia, no hay Quick-start. Si quieres revisar qué puede tocar hoy el agente de tu equipo y cómo se deshace cada cosa, es una buena conversación para empezar.
Preguntas frecuentes
¿Qué es un punto de control (checkpoint) en Claude Code?
Es una copia del estado de los archivos que Claude Code guarda antes de cada mensaje que inicia un turno. Con /rewind, o pulsando Esc dos veces con la entrada vacía, se puede volver a ese punto. Solo cubre las ediciones hechas con sus herramientas de edición de archivos, y la propia documentación aclara que no sustituye al control de versiones.
¿Los puntos de control deshacen lo que hace el agente con comandos de shell?
No. La documentación de Claude Code lo dice expresamente: no registra los archivos modificados con comandos Bash, como rm, mv o cp. Si esos archivos estaban en git sin cambios pendientes, se pueden recuperar con git; si no estaban versionados, no hay copia de la que tirar.
¿Y lo que cambian los subagentes?
Por lo general, rebobinar no restaura sus ediciones, y la documentación recomienda usar git para revertirlas. La excepción es una skill bifurcada que se ejecuta en primer plano, porque edita durante tu propio turno.
¿Qué acciones de un agente no se pueden deshacer?
Las que salen del repositorio sin una copia previa que se pueda restaurar: borrar datos sin copia de seguridad probada, cambiar la configuración de un servicio compartido, enviar un mensaje, publicar algo o lanzar una operación en un sistema externo. Ahí, como mucho, se corrige después.
¿Significa esto que un agente no debe tener acceso a la terminal?
No necesariamente. Significa que, antes de darle ese acceso, conviene saber qué comandos pueden destruir algo sin vuelta atrás y dejarlos fuera de su alcance o detrás de la aprobación de una persona.
¿Hace falta comprar una herramienta de restauración para usar agentes?
Ya hay servicios que restauran sistemas, datos y repositorios tras acciones destructivas de agentes. Pero buena parte del problema se resuelve con lo que el equipo ya tiene: git, una rama propia para el agente, entornos desechables y copias de seguridad probadas. Lo que no tiene vuelta atrás no lo arregla ninguna herramienta: lo decide una persona antes.
Fuentes
- Anthropic, «Checkpointing», documentación de Claude Code (sin fecha visible; consultada el 14 de octubre de 2026).
- Kevin M. Storer y Derek DeBellis (Google Cloud), «Introducing the DORA AI Capabilities Model: 7 keys to succeeding in AI-assisted software development», 23 de septiembre de 2025.
- LTM, «LTM Launches BlueVerse AgenTraceIQ», Business Wire India en UNI, 5 de octubre de 2026.
- Las citas de fuentes en inglés están traducidas por onext. El mapa de la reversibilidad (salvo lo que se atribuye a la documentación de Claude Code), la regla y las cinco decisiones son lectura propia de onext.
Bernat López es fundador y CEO de onext, boutique de IA. Acompaña a equipos de desarrollo y de producto a trabajar con IA con método —especificación antes de programar, una persona que decide donde hay riesgo y Spec-Driven Development— y aplica a su propia empresa lo que propone: onext funciona con su propio sistema agéntico.
LinkedIn →