Así revisa código el equipo de Claude Code: siete capas y niveles de riesgo

Claude escribe alrededor del 90% del código de Claude Code. Con ese punto de partida, la pregunta de cómo revisar lo que entra en el repositorio deja de ser teórica, y el equipo de Anthropic que mantiene la herramienta acaba de explicar su respuesta en How the Claude Code team does code review, firmado por Addy Osmani, Morgan Westlee Lunt y Qing Wang y publicado el 15 de octubre.

Simon Willison destacó al día siguiente el párrafo que mejor resume el cambio de enfoque: "¿lo ha leído una persona?" es una aproximación imprecisa a la pregunta que importa, que es qué puede salir mal con este cambio y qué control, automático o humano, es el adecuado para detectarlo.

De puerta final a corrector continuo

El primer efecto de esa reformulación es temporal. Antes, la revisión era un peaje al final del camino: escribir el código, abrir el PR y esperar a un compañero. Ahora funciona, en palabras de los autores, "más como un corrector ortográfico mientras escribes". La mayoría de los cambios ya han pasado al menos una vez por la revisión y las correcciones de Claude antes de que alguien del equipo los mire, de modo que los errores rutinarios se filtran pronto y la atención humana se reserva para preguntas de más nivel.

Las cifras que acompañan el artículo explican por qué necesitaban cambiar. Los PRs fusionados en Claude Code se duplicaron con creces entre junio y septiembre de 2026, mientras la tasa de reverts caía más de un 40%. En el monorepo de Anthropic, los cambios que llegan a diario pasaron de unos 2.500 en mayo a más de 30.000 en septiembre. Con ese volumen, un modelo de revisión basado solo en personas no escala.

Siete capas en lugar de una aprobación

El sistema que describen tiene siete capas:

1. Verificación previa al PR: los agentes ejecutan tests y lint, y un subagente revisa el diff.
2. Revisión de código con IA: Claude analiza el cambio con el contexto de todo el repositorio, y varios agentes verifican cada hallazgo antes de publicarlo.
3. Revisión de seguridad: una pasada automática independiente que bloquea el merge si quedan problemas abiertos.
4. CI automatizada: lint, comprobación de tipos, tests por plataforma y builds.
5. Aprobación humana según riesgo: un clasificador asigna un nivel. Riesgo bajo no requiere aprobaciones, medio requiere una y alto requiere dos.
6. Cola de merge: vuelve a comprobar cada cambio contra la última versión de main.
7. Monitorización tras el merge: feature flags, despliegue gradual, guardias y rollback rápido.

El quinto punto es el más llamativo. Que un cambio clasificado como de bajo riesgo pueda entrar sin aprobación humana rompe una costumbre muy arraigada, y el equipo lo compensa con una norma clara para cambios pequeños y medianos: "si lo fusionas, es tuyo". Además, una aprobación cubre un commit concreto, no el PR en abstracto.

Lo que costó afinar la revisión automática

El artículo no esconde los tropiezos. El porcentaje de PRs que reciben comentarios sustanciales de la revisión automática subió del 16% al 54%, lo que obligó a trabajar la convergencia: hubo un PR que encadenó más de 50 rondas de revisión antes de que lo pararan. Tras los ajustes, los PRs que pasan en un solo ciclo subieron del 65% al 78%, y los que necesitan cinco rondas o más bajaron del 8,9% al 1,5%.

Para orientar al revisor usan dos ficheros: `CLAUDE.md`, con las convenciones del proyecto, y `REVIEW.md`, donde los responsables de cada parte del código indican qué les importa revisar. Los bugs de incidentes pasados se convierten en casos de evaluación diarios. Quien quiera replicar parte del flujo tiene los comandos `/code-review` y `/security-review` en local, y la función Code Review for Claude Code en los planes Team y Enterprise.

Dónde siguen haciendo falta personas

Los autores son explícitos: la dirección estratégica y el alcance, el código de alto riesgo como facturación, actualizadores automáticos o workflows de CI, las decisiones de arquitectura que sientan precedente y la evaluación de la evidencia que aportan tests y revisiones siguen siendo trabajo humano, igual que la responsabilidad sobre lo que se publica.

También cuestionan el argumento de que ir más despacio es más seguro. Lo es, dicen, "pero sobre todo porque haces menos". Para compartir conocimiento proponen pedir a Claude explicaciones del módulo que vas a tocar en lugar de confiar en leer diffs ajenos de forma pasiva.

Para quién es útil

Para equipos que ya trabajan con Claude Code y notan que la cola de PRs se ha convertido en el cuello de botella, el artículo es casi un manual. Para responsables de ingeniería, el valor está en el clasificador por niveles de riesgo y en medir reverts y rondas de revisión, no solo velocidad.

Las cifras vienen de un equipo que construye la propia herramienta, con un monorepo y una cultura muy concretos, y no se trasladan tal cual a un equipo de cinco personas. Lo que sí nos parece portable es la pregunta de partida: qué puede salir mal con este cambio y qué control está mejor situado para detectarlo.