Revisión de código con agentes: cómo lo hace Claude Code

La revisión de código con agentes ya no va de leer cada diff

Hay una pregunta que me hacen mucho cuando hablo de desarrollo con agentes: “Vale, pero si el agente escribe el código, ¿quién lo revisa?”. Esta semana el equipo de Claude Code ha publicado cómo hace la revisión de código, y es la respuesta más completa que he leído hasta ahora. Lo firman Addy Osmani, Morgan Westlee Lunt y Qing Wang.

El contexto impresiona. Cuentan que Claude escribe cerca del 90 % del código de Claude Code y que, en el monorepo de Anthropic, los cambios diarios pasaron de unos 2.500 en mayo a más de 30.000 en septiembre. Con ese volumen, revisar línea a línea es imposible.

El resultado que me hizo leerlo dos veces

Entre junio y septiembre, los pull requests fusionados en Claude Code se duplicaron con creces, y la proporción que hubo que revertir bajó más de un 40 %. Más cambios y menos errores a la vez. No quitaron la revisión: movieron casi toda la lectura a las máquinas y guardaron la atención humana para lo que de verdad la necesita.

Capas, no una única puerta

Lo que más me gusta es que no confían en un solo filtro. Cada capa pilla unas cosas y se le escapan otras:

• Verificación antes del PR. Le dan al agente algo que pueda ejecutar (tests, una build, una captura para comparar con el diseño) y le piden que enseñe el resultado en lugar de decir “ya está”.
• Revisión de IA en cada PR. Varios agentes buscan fallos a la vez y otro grupo vota cada hallazgo. Solo se publica si suficientes coinciden en que es real.
• Seguridad que bloquea. No se puede fusionar con hallazgos de seguridad abiertos.
• Aprobación humana según el riesgo. Un cambio en la documentación puede fusionarse sin nadie si el autor está en la lista de confianza del repo; el código más delicado necesita dos personas. Y lo decide el cambio, no quién lo escribe.
• Cola de merge, feature flags y rollback rápido. Porque algo se va a escapar igual, y lo importante es detectarlo y deshacerlo en minutos.

CLAUDE.md y REVIEW.md

Cuando el revisor marca una y otra vez lo mismo, lo arreglan en el origen: en una skill, en una regla de lint o en sus archivos de instrucciones. CLAUDE.md le dice al agente qué es el proyecto y REVIEW.md le dice qué importa en cada parte del código. Esto encaja al cien por cien con cómo trabajamos con Spec-Driven Development: el conocimiento vive en el repo, versionado, y no en la cabeza de alguien.

El bucle infinito entre agentes

Esta parte me pareció muy honesta. Un agente que escribe y otro que revisa pueden tenerse ocupados para siempre: un PR pasó más de cincuenta rondas de revisión y arreglos en una noche hasta que su autor lo paró. Al mirarlo, vieron que cerca del 59 % de lo que el revisor seguía marcando era código que ya estaba ahí desde la primera pasada.

Su solución es sencilla. Tras tres rondas, el revisor pide al autor que dé un paso atrás y replantee el enfoque. Además, después de las primeras pasadas solo se revisa el diff nuevo. Me lo apunto tal cual.

Los incidentes como examen

Otra idea brillante: con los PR que causaron incidentes en el pasado han montado un conjunto de pruebas, y el agente revisor se evalúa contra él cada día. Así saben si un cambio en el revisor lo mejora o lo empeora.

Dónde sigue decidiendo una persona

Lo que queda para las personas es lo que mejor se nos da: decidir si algo merece construirse, el código de alto riesgo, la arquitectura que otros van a copiar, leer las pruebas y responder del resultado. Hay una frase que me encanta: quien le pidió el cambio al agente responde de él como si lo hubiera escrito.

Esto conecta con algo que ya conté al hablar del flujo de Giant Swarm: cuando el código sale barato, el juicio humano se mueve hacia el plan y el riesgo, no hacia cada línea.

Lo que me llevo

Si estás metiendo agentes en tu equipo, no empieces quitando la revisión. Empieza dando al agente formas de verificar su trabajo, escribe tu REVIEW.md, define niveles de riesgo y mide dos cosas: el tiempo humano que gastas y cuántos cambios tienes que revertir. Si lo segundo sube, no has ahorrado nada.

Es justo el tipo de proceso que ayudamos a montar en onext. Y si en tu equipo ya dejáis que los agentes abran PR, me encantará saber qué habéis automatizado y qué sigue necesitando a una persona.