Anthropic ha contado con detalle cómo revisa el equipo de Claude Code el código de su propio producto, que según la empresa escribe Claude en un 90%. El artículo de ingeniería, firmado por Addy Osmani, Morgan Westlee Lunt y Qing Wang, arranca con el dato que lo explica todo: en el monorepo de Anthropic, los cambios que entran cada día pasaron de unos 2.500 en mayo a más de 30.000 en septiembre.
Con ese volumen, leer cada línea a mano es imposible. La respuesta del equipo ha sido pasar casi toda la lectura a máquinas y medir cuánto tiempo humano consume cada cambio, con las reversiones y los incidentes como límite que no se puede cruzar.
Puntos clave
- Entre junio y septiembre, los pull requests (PR, las propuestas de cambio) fusionados en Claude Code se multiplicaron por más de dos, y el porcentaje que hubo que revertir cayó más de un 40%.
- El objetivo es que la mayoría de PR entren con como mucho una persona en el circuito, que puede ser el propio autor, sin que suban las reversiones ni los incidentes.
- Con el revisor automático, los PR internos que reciben comentarios de fondo pasaron del 16% al 54%.
- La aprobación humana va por riesgo: ninguna para documentación o cambios detrás de un interruptor, una persona para cambios normales y dos para el código más delicado.
Siete capas antes de llegar al usuario
El cambio pasa por varias capas, y cada una caza cosas que la anterior deja pasar.
1. Verificación antes del PR. Se le da a Claude algo que pueda ejecutar (tests, una compilación, una captura para comparar con el diseño) y se le pide que enseñe la salida en vez de decir que ha terminado. Luego un subagente con contexto limpio revisa el diff. Boris Cherny, creador de Claude Code, calcula que darle a Claude una forma de comprobar su trabajo hace el resultado entre dos y tres veces mejor.
2. Revisión de IA en cada PR. Varios agentes buscan bugs a la vez y otro grupo vota cada hallazgo. Solo se publica si suficientes agentes coinciden en que es real, y los de puro estilo se descartan. Cada comentario sale etiquetado como Important, Nit o Pre-existing, para que un fallo heredado no parezca culpa del autor. Todos hay que contestarlos: o se arregla o se cierra con un motivo.
3. Seguridad que bloquea. Un PR no se puede fusionar mientras quede abierto un hallazgo de la revisión de bugs o de la de seguridad.
4. Comprobaciones automáticas. Lint, tipos, tests en todas las plataformas y compilación. La plantilla del PR pregunta cómo se probó el cambio y cómo se deshace.
5. Aprobación humana según el riesgo. Un clasificador lee el cambio y decide su nivel. Lo decide el cambio y no quién lo firma. La aprobación de un agente nunca cuenta como la de una persona, y quien dio la orden al agente cuenta como uno de los revisores, igual que si hubiera tecleado el código.
6. Cola de fusión y despliegue gradual. Lo nuevo sale detrás de un interruptor, primero para los empleados de Anthropic, luego en el canal latest y después en stable.
7. Detección y marcha atrás rápidas. Los interruptores se apagan sin desplegar y hay una guardia semanal.
El propio equipo admite un hueco: todavía no tienen mecanismos que endurezcan las aprobaciones de forma automática cuando suben las reversiones, y los ingenieros los quieren antes de dejar que más código entre sin ninguna persona.
Cuando dos agentes se revisan entre sí
La parte más útil del artículo es la de los fallos. Un agente que escribe y otro que revisa se pueden tener ocupados el uno al otro sin fin. Un PR del CLI pasó por más de 50 rondas de revisión y arreglo durante una noche hasta que su autor lo paró.
Al hacer git blame sobre lo que el revisor seguía marcando, vieron que un 59% era código que ya estaba ahí desde la primera pasada. El revisor apenas encontraba fallos nuevos: sacaba unos pocos viejos más en cada ronda. Y el ruido cuesta más cuando el autor es un agente, porque una persona ignora una nimiedad en segundos y un agente la arregla, con su commit y su nueva ronda.
Los cambios que hicieron:
- Tope de tres rondas. A partir de ahí, el revisor pide al autor que replantee el enfoque.
- Tras las primeras pasadas, se revisa solo el diff nuevo.
- Se marca la clase de fallo, para que el autor arregle todas las apariciones y no una línea.
- Nada de repetir hallazgos ya publicados.
Además, cada incidente pasado se ha convertido en un caso de prueba. El equipo reunió los PR que causaron problemas, con sus reversiones, y el revisor se mide contra ese conjunto cada día.
Qué siguen haciendo las personas
Decidir si algo merece construirse, revisar el código arriesgado (facturación, el actualizador automático, los flujos de integración continua), revisar la arquitectura que otros van a copiar y leer las pruebas que aporta cada cambio. Y responder del resultado: cada cambio que sale tiene una persona detrás, lo haya escrito quien lo haya escrito.
Para entender el código sin leer cada diff, el equipo le pide a Claude una explicación de la parte concreta que va a tocar. Tarda minutos y refleja el código de hoy.
Cómo aplicarlo en tu equipo
El artículo cierra con una lista que se puede copiar casi entera:
1. Dale al agente comprobaciones que pueda ejecutar, apuntadas en un CLAUDE.md corto. 2. Pasa /code-review y /security-review en local antes de abrir el PR. 3. Crea un REVIEW.md con lo que importa en cada parte del código y mete ahí los comentarios que se repiten. 4. Añade a la plantilla del PR tres apartados: pruebas, riesgo y cómo deshacerlo. 5. Activa un revisor de IA en un solo repositorio, afina unas semanas y luego amplía. 6. Escribe los niveles de riesgo y empieza estricto. Afloja solo con datos. 7. Convierte incidentes y reversiones en un conjunto de pruebas para el revisor.
El revisor que usa Anthropic por dentro es el mismo Code Review que salió de pruebas hace diez días para los planes Team y Enterprise.
Por qué importa
Cualquier empresa que ya tenga agentes escribiendo código se va a encontrar el mismo atasco que Anthropic: más cambios de los que su equipo puede leer. Lo valioso aquí es la métrica. Anthropic dejó de preguntarse si alguien había leído el código y empezó a medir minutos humanos por cambio, con las reversiones como alarma.
Y deja una lección para equipos pequeños: la red de seguridad que permite ir rápido está en poder deshacer en minutos (interruptores, despliegue por fases, cambios pequeños) mucho más que en revisar más despacio.
Fuente original: claude.dev
Relacionado
