Anthropic transfirió la guardia de primera línea de su CI/CD interno a Claude Tag. En el documento publicado el 18 de agosto, las dos cifras más reveladoras son estas: tras abrirse un ticket de incidente, Claude entrega el primer análisis respaldado por evidencia en una mediana de 14 minutos; en los casos favorables, en solo 4 minutos el informe inicial ya señala la causa raíz.
El contexto que motivó esto se explica sin rodeos: el volumen de código entregado por ingeniero cada trimestre se multiplicó por 8 respecto al nivel original. Con la producción disparada, también aumentó el número absoluto de builds fallidos, pruebas inestables y rollbacks de despliegue, y cada diagnóstico suele ocupar más de una hora, a menudo fuera del horario laboral.
Qué llaves tiene Claude en la mano
Que esto funcione depende de la configuración de permisos, no del modelo en sí. A través de conectores MCP, Claude obtiene un conjunto de accesos: Grafana y el almacén de logs para ver métricas y stack traces, Datadog como monitoreo adicional, GitHub para revisar commits, ver cambios y abrir PRs, Kubernetes para dar recomendaciones a nivel de clúster, y PagerDuty junto con varios canales de Slack para recibir alertas y enviar conclusiones. Claude cuenta con su propia cuenta de servicio, cuyas acciones son auditables.
La decisión de si una alerta debe despertar a alguien se escribió directamente como regla en lenguaje natural. El ejemplo que da el artículo: si la tasa de errores supera el 2% durante más de 5 minutos y no coincide con una ventana de lanzamiento conocida, se llama a la guardia. Antes, este tipo de umbrales vivía en archivos de configuración del sistema de monitoreo, y cambiarlos requería pasar por el proceso de release; al escribirlos como reglas que Claude puede leer, el costo de ajuste se redujo a editar una línea de texto. Además de las alertas automáticas, los miembros del equipo y la página interna de incidentes también pueden activarla manualmente.
La fase de triaje corre en paralelo
Cuando llega un incidente, Claude lanza un agente orquestador, que a su vez despacha varios subagentes para investigar en paralelo distintas dependencias: uno revisa logs, otro compara los commits más recientes, otro observa las curvas de métricas. El resultado de este «flujo de trabajo dinámico» es precisamente ese análisis de 14 minutos.
El criterio se apoya en dos tipos de archivos. Uno son los archivos de skill, escritos como manuales de investigación según el tipo de incidente; uno de ellos trata específicamente la ruta de diagnóstico de una clase de bug particularmente terco y tiene 617 líneas. El otro es lessons.md, al que el propio Claude añade contenido tras el cierre de cada incidente, para consultarlo primero la próxima vez que aparezca un patrón similar. Ambos tipos de archivo están en GitHub y pasan por el mismo proceso de revisión que el código.
La etapa de corrección deja espacio para las personas. El resultado más común es un PR, cuyo despliegue se decide tras la revisión de un ingeniero; el despliegue gradual se controla con feature flags; en los casos que involucran al clúster, Claude sugiere vaciar, aislar o escalar recursos, pero la ejecución la decide una persona. Tras el cambio, usa el mismo conjunto de herramientas para volver a verificar la corrección.
A quién le queda el resto del trabajo
Anthropic deja claro que reserva varias cosas para las personas: las mejoras de arquitectura a medio y largo plazo; completar hipótesis junto con Claude en modo compartido, ya que este no siempre acierta a la primera y hace falta la intuición humana para corregir el rumbo; la puerta de revisión de los PR; y el tono de la comunicación, ya que el formato de los informes de estado tuvo que ajustarse varias rondas antes de encajar con el gusto del equipo, una parte que no se logró automatizar.
El traspaso de guardia también se convirtió en un producto. Hay un informe semanal consolidado, resúmenes diarios, y otro agente llamado ci-weather que reúne varios incidentes en un comunicado de estado visible externamente.
Una cuenta fácil de pasar por alto
La cifra de 8 veces, situada entre «por qué se hizo esto» y «cómo quedó tras hacerlo», no significa lo mismo en cada extremo. Primero es el origen de la presión: con un equipo del mismo tamaño, si el volumen de entregas se multiplica por 8, el número de tickets de incidentes no se queda quieto. A la vez, es también la premisa que sostiene este sistema de guardia: si el código todavía se escribiera línea a línea por personas, la forma, la frecuencia y la explicabilidad de los incidentes estarían más cerca de la intuición de los ingenieros, y el beneficio marginal de que la IA haga el triaje no sería tan evidente. Una vez que la IA participa masivamente en escribir código, tiene sentido, dentro de esa misma cadena, dejar que también asuma la primera capa de diagnóstico.
El umbral para implementarlo también queda claro: se necesita el plan Team o Enterprise de Claude, y conectar las herramientas y configurar los permisos toma varias horas al principio. Para la mayoría de los equipos, la dificultad probablemente no esté en la conexión técnica, sino en atreverse a entregar una cuenta de servicio capaz de abrir PR y manejar el clúster.
Fuentes: blog oficial de Anthropic, CocoLoop; las cifras de mediana de 14 minutos en triaje, 4 minutos en la identificación más rápida de la causa raíz, el aumento de 8 veces en el volumen trimestral entregado y las 617 líneas del archivo de skill se verificaron según el comunicado público de la empresa.