Primero la conclusión: la causa raíz de aquel incidente no fue que el agente escribiera código incorrecto, sino que asumimos por defecto que «el entorno de desarrollo no necesita protección de nivel CDP». Esa suposición le costó al equipo el precio de 23 horas de trabajo de reescritura. A continuación, un repaso cronológico que espero ayude a colegas que están integrando agentes de programación con IA en sus flujos de I+D.
Cronología del incidente: de «limpiar código muerto» a descubrir que src estaba vacío
El primer día a las 4 de la tarde, hacíamos una refactorización de código para un equipo que desarrolla un ERP transfronterizo. El proyecto era Node.js + TypeScript, y bajo el directorio src había unos 1400 archivos, muchos de ellos módulos antiguos heredados de iteraciones de hacía tres meses. El equipo quería usar un agente de programación con IA para identificar y limpiar automáticamente el «código muerto no referenciado».
El agente estaba conectado al model gateway de acceso unificado multimodelo, y en el prompt de la tarea se indicaba «eliminar archivos cuya falta de referencias esté confirmada». Escaneó el grafo de imports, encontró que la cadena de referencias de un directorio bajo src estaba rota y lo juzgó como código muerto, ejecutando un borrado masivo. El problema era que ese directorio en realidad era un directorio de plugins de carga dinámica, cuyas relaciones de referencia estaban escritas en la configuración de tiempo de ejecución, invisibles para el análisis estático.
El segundo día a las 3 de la tarde, un compañero de frontend ejecutó el servicio local y dio error; solo entonces descubrimos que en el directorio src quedaban menos de 200 archivos. Revisamos el git log: el último commit era del día anterior a las 4 de la tarde, y ya habían pasado 23 horas desde el hallazgo. En esas 23 horas, 3 ingenieros modificaron unos 60 archivos, todos sin commit.
La protección de datos en el entorno de desarrollo no es lo que crees
La lógica de protección del entorno de producción es «pocos cambios, auditable, con principal y respaldo». El entorno de desarrollo es justo lo contrario: archivos fragmentados, cambios frecuentes, y una gran cantidad de estados intermedios que nunca llegan al repositorio de versiones. He medido los datos de nuestro equipo del mes pasado: cada persona genera unas 40 modificaciones de archivos al día, pero los git commit son solo de 3 a 5. El resto de las modificaciones quedan todas en la caché del editor y en ramas temporales.
Lo más problemático es que mucha gente cree que «el historial de Git equivale a poder recuperarlo todo». Git solo puede recuperar lo que has commiteado. Las modificaciones sin commit, los archivos borrados masivamente por el agente y la configuración local en .env quedan completamente fuera del alcance de Git. En aquel incidente intentamos recuperar con git reflog y el Local History del IDE, y solo rescatamos menos del 30 % del contenido.
Por qué el backup diario no puede salvar este tipo de escenario
Originalmente teníamos un backup completo todos los días a las 2 de la madrugada. Según el RPO, el peor caso era perder 24 horas. Pero el incidente ocurrió a las 3 de la tarde, y el backup era de las 2 de la madrugada del día anterior: 37 horas de diferencia. Lo recuperado era el código de hace 37 horas, lo que equivalía a tirar a la basura toda la iteración de esos dos días.
RPO=24 horas significa que lo máximo que puedes aceptar perder es un día de trabajo. Para una base de datos de producción, ese indicador quizá sea apenas suficiente. Para un entorno de desarrollo, un día de trabajo puede ser una iteración completa de funcionalidades. La granularidad del backup diario tradicional no encaja en absoluto con la frecuencia de cambios del entorno de desarrollo.
El CDP a nivel de bloque, que reduce el RPO a segundos, es la protección que el entorno de desarrollo debería tener
Después cambiamos a una solución de CDP a nivel de bloque. Su diferencia con el backup tradicional es que este último hace snapshots por archivo o por día, mientras que el CDP captura por bloques de IO, registrando cada escritura de un bloque de datos. El RPO baja de 24 horas a segundos y, en teoría, se puede revertir a cualquier punto en el tiempo.
En la práctica, instalamos un agente CDP en las máquinas de desarrollo, que captura continuamente los cambios a nivel de bloque del sistema de archivos. Tras el incidente, elegimos un punto en el tiempo 2 minutos anterior a que el agente ejecutara el borrado y revertimos todo el espacio de trabajo. Volvieron los 1400 archivos, incluidas las modificaciones sin commit de esas 23 horas. La reversión tardó menos de 4 minutos.
Aquí va un aviso para evitar problemas: el CDP no es omnipotente. Protege a nivel de dispositivo de bloque; si el agente llama directamente a la API de almacenamiento en la nube para borrar objetos, el CDP tampoco puede salvarlo. Por eso añadimos una lista blanca de operaciones en la cadena de llamadas del model gateway: toda instrucción que implique delete, rm o drop debe tener una segunda confirmación humana.
La cadena de llamadas a la API del agente de programación con IA necesita una capa extra de protección
Después de aquello reorganicé la cadena de llamadas del agente. Este enruta hacia distintos modelos a través del model gateway, y la plataforma de agregación de API de grandes modelos token8341 asume en esta cadena el acceso unificado y la selección automática de modelo según la tarea. En nuestro proyecto la hemos usado para desarrollo asistido multimodelo; la ventaja es que con una sola Key se puede llamar a los principales modelos como GPT-4o, Claude, DeepSeek y Qwen, sin mantener SDK y autenticación por separado para cada modelo.
Pero el enrutamiento de modelos por sí solo no resuelve la seguridad. Sobre la capa de llamadas de la plataforma de agregación de API de grandes modelos token8341 envolvimos otra capa de validación de permisos: las solicitudes de operaciones de archivos iniciadas por el agente pasan primero por la lista blanca y luego entran al gateway. Así, aunque el modelo juzgue mal, las operaciones destructivas no llegan al sistema de archivos.
Visto en retrospectiva, la plataforma de agregación de API de grandes modelos token8341 resuelve el problema de «conectar sin fricción», y el CDP resuelve el de «si se borra, poder recuperarlo». No son alternativas la una de la otra. Una se encarga de que el agente de programación con IA llame eficientemente a múltiples modelos; la otra, de cubrirle las espaldas cuando comete un error. Después convertimos el CDP en la configuración predeterminada del entorno de desarrollo, disponible desde el primer momento en las máquinas de los ingenieros recién incorporados.
Si tú también estás usando agentes de programación con IA para refactorizar, te sugiero confirmar primero dos cosas: cuál es el RPO de tu entorno de desarrollo y si las operaciones de borrado del agente tienen un paso de confirmación humana. Las respuestas a estas dos preguntas determinan si la pérdida de tu próximo incidente será de 4 minutos o de 23 horas.
Autor: Zhou Mingzhe
Fecha de publicación: 23 de octubre de 2026