Cómo hace code review el equipo de Claude Code y qué copiar

El equipo de Claude Code no ha quitado la revisión de código: ha pasado casi toda la lectura a las máquinas y guarda a las personas para los cambios con riesgo. Según el artículo de Anthropic «How the Claude Code team does code review» en claude.dev, publicado el 15 de octubre de 2026, cada cambio atraviesa siete capas: verificación antes de abrir el pull request, una revisión de Claude en cada PR, una revisión de seguridad que impide fusionar con hallazgos abiertos, CI, aprobación humana según el riesgo (ninguna, una o dos personas), cola de fusión con lanzamiento gradual y reversión rápida. Claude escribe cerca del 90 % del código de Claude Code y, aun así, cada cambio tiene una persona que responde de él.

Casi todo se puede copiar con herramientas públicas, pero no tal cual. Con cualquier plan tienes /code-review en local, y tus reglas de revisión tienen que ir en CLAUDE.md, porque el comando no lee REVIEW.md: una prueba del 23 de octubre de 2026 con Claude Code 2.1.309 lo muestra. Con Team o Enterprise, Code Review revisa cada PR de GitHub y sí lee REVIEW.md, pero nunca aprueba ni bloquea un PR; el bloqueo que usa Anthropic es configuración de sus propios repositorios y tienes que montarlo tú.

Hay tres cambios que no dependen del plan y que puedes hacer hoy: añadir «Testing», «Risk» y «How to revert» a la plantilla de PR, usar CODEOWNERS con protección de ramas para que autenticación, facturación, flujos de CI e instaladores pasen siempre por una persona, y limitar las rondas entre el agente que escribe y el que revisa.

Las siete capas de un cambio en Claude Code y con qué copiarlas

Cada capa atrapa unos errores y deja pasar otros; la idea es que pocos atraviesen las siete y que lo que pase se deshaga en minutos. La revisión ya no es una puerta al final del camino, sino algo continuo, «como un corrector ortográfico mientras escribes»: la mayoría de los cambios ya los ha revisado y corregido Claude al menos una vez antes de que una persona los mire. La tabla resume lo que hace cada capa dentro de Anthropic y el equivalente público que existe a 23 de octubre de 2026.

La capa 1 es la que más pesa. Boris Cherny, creador de Claude Code, calcula que darle a Claude una forma de verificar su trabajo hace que el resultado final sea «dos o tres veces mejor»; es su estimación, no una medición. Antes de abrir un PR, muchos ingenieros del equipo pasan además unas skills internas que buscan errores, simplifican el diff y prueban el comportamiento de extremo a extremo. No están publicadas, pero /code-review y /simplify cubren parte de ese trabajo; para elegir entre ellas tienes Las mejores skills de Claude Code: cuáles usar e instalar primero.

Cuando el revisor automático marca lo mismo una y otra vez, el equipo lo arregla en el origen: en la skill, con una regla de lint o en los archivos de instrucciones. CLAUDE.md describe el proyecto (stack, convenciones, objetivos y lo que no es objetivo) y se carga en cada revisión, así que en un repositorio grande se mantiene corto y apunta a otros documentos; el revisor marca además el código que rompe una convención de CLAUDE.md y los cambios que dejan desfasada una de sus líneas. Cuándo y cómo se carga ese archivo lo explica la Guía de memoria de Claude Code (2026): CLAUDE.md, auto memory y cuándo necesitas un plugin. REVIEW.md lo escriben los responsables de cada parte del código y solo habla de revisión; más abajo hay un ejemplo.

Cero, una o dos aprobaciones: decide el cambio, no el autor

En los repositorios de Claude Code un cambio se fusiona sin aprobación humana, con una persona o con dos, y lo decide lo que toca el cambio, no quién lo escribió. Estos son los tres niveles que publica Anthropic:

Un clasificador lee el cambio y elige el nivel, y un segundo clasificador pregunta si ese cambio concreto necesita otra persona aunque su nivel diga que no. Hay rutas que siempre pasan por una persona: las que los responsables han marcado como sensibles y cualquier archivo de flujo de CI. Los caminos ligeros solo valen para los autores de la lista de confianza del repositorio, que suele ser el equipo que lo mantiene; cualquier otro necesita una segunda persona.

Tres reglas cierran los atajos. La aprobación de un agente nunca cuenta como la de una persona, así que la revisión automática puede despachar un cambio de riesgo bajo pero no ocupar un hueco que pide a un humano. En un PR escrito por un agente, quien dirigió al agente cuenta como uno de los revisores obligatorios, igual que si hubiera tecleado el código. Y una aprobación cubre un commit concreto: si llegan commits que el sistema no puede garantizar, como un push de un agente o una fusión resuelta a mano, hay que aprobar de nuevo.

¿Es sensato fusionar documentación sin que la lea nadie? En el equipo de Claude Code, los buenos REVIEW.md dicen cómo falla cada tipo de código, y para la documentación el fallo es que «miente»: eso es lo que el revisor automático tiene que vigilar. Si en tu equipo la documentación es un contrato con clientes, súbela a riesgo medio; los niveles se escriben a mano y Anthropic recomienda empezar estricto y relajarlos solo con datos.

Qué miden el 90 %, el doble de PR y el −40 % de reversiones

Las cifras de Anthropic son ciertas dentro de su alcance, pero ninguna dice cuántos PR fusiona Anthropic ni cuántos revierte, y dos de ellas se citan a menudo fuera de contexto.

La diferencia entre proporción y recuento importa. Si los PR se multiplican por 2 y la proporción revertida baja un 40 %, el número de reversiones se multiplica por 2 × 0,6 = 1,2: la tasa mejora aunque en total haya más reversiones. Con «más del doble» y «más de un 40 %» sin base no se puede recalcular el dato real.

También conviene saber qué optimiza el equipo, porque la objeción de que perseguir una tasa de reversiones la distorsiona apunta al objetivo equivocado. Lo que se intenta reducir es el tiempo humano por cambio: aprobaciones humanas por PR (mediana y percentil 95), comentarios humanos y tiempo que un PR espera a una persona. Las tasas de reversiones e incidentes son el límite, no la meta: si suben, el tiempo humano no se ha ahorrado, solo se ha movido a arreglar lo que se rompió.

Qué puedes copiar con tu plan: /code-review, ultrareview o Code Review

Con cualquier plan tienes /code-review; con Pro o Max, además ultrareview; y Code Review gestionado solo existe en Team y Enterprise con repositorios de GitHub. Lo que más se confunde entre los tres es qué archivo de reglas lee cada uno y si puede frenar una fusión. Así están a 23 de octubre de 2026, según la comparativa de opciones de revisión en la documentación de Code Review:

Ultrareview no está disponible en Amazon Bedrock, Google Cloud Agent Platform ni Microsoft Foundry, ni en organizaciones con Zero Data Retention o configuración HIPAA; en esos casos /code-review ultra hace una revisión local. Code Review tampoco funciona en organizaciones con Zero Data Retention o HIPAA, y si tus desarrolladores usan Claude Code por Bedrock, Agent Platform o Foundry, necesitas igualmente una organización de Claude en Team o Enterprise para activarlo.

Ninguna de estas herramientas trae el clasificador de riesgo ni la regla de aprobaciones por niveles: eso es configuración de GitHub que escribes tú, como se ve en los pasos de más abajo. Si tu código está en GitLab, Code Review no te sirve; /code-review --comment y Claude en GitLab CI/CD sí.

¿/code-review en local lee REVIEW.md? La prueba del 23 de octubre de 2026

No: /code-review sigue las reglas de CLAUDE.md e ignora REVIEW.md, y una prueba con un repositorio de demostración lo confirma. La documentación de Claude Code sobre /code-review en local lo dice de forma explícita: la revisión local «sigue tu CLAUDE.md, también en una ejecución no interactiva con -p», y REVIEW.md solo configura el servicio gestionado en los PR de GitHub. Si una regla tiene que aplicarse en los dos sitios, va en CLAUDE.md.

La prueba se hizo el 23 de octubre de 2026 en macOS con Claude Code 2.1.309, ejecutando claude -p "/code-review low" --output-format json en un repositorio de demostración. La rama add-discount añadía una función discountedTotal() con cuatro problemas puestos a propósito: un bucle con i <= limit que descuenta un artículo de más y lanza un TypeError cuando limit llega al número de artículos; un segundo bucle que empieza en limit y cuenta dos veces ese artículo; un cálculo de dinero en coma flotante (line * (1 - percent / 100)) que incumple la regla de CLAUDE.md «Money is always stored and computed as integer cents»; y un comentario // TODO, que REVIEW.md declaraba hallazgo Important. Estos eran los dos archivos de reglas:

# CLAUDE.md
# Project rules
- Money is always stored and computed as integer cents. Never use floating-point numbers for prices or totals.
- Run `node test.js` to verify changes.

# REVIEW.md
# Review instructions
## Always check
- Any comment containing "TODO" in a changed line is an Important finding: we do not merge TODOs.
## Cap the nits
Report at most one Nit per review.

En la primera ejecución, con la regla del TODO solo en REVIEW.md, la revisión tardó 17,2 s, encontró los dos errores de bucle y el dinero en coma flotante, citando la regla de CLAUDE.md, y no dijo nada del TODO. En la segunda, con esa misma regla copiada a CLAUDE.md y nada más cambiado, tardó 8,7 s, encontró los mismos tres problemas y además marcó el TODO: según las reglas del proyecto, un cambio con TODO no se puede fusionar y es Important. El CLI estimó un coste de 0,19 $ y 0,09 $; es su cálculo a precio de API, no una factura. La salida llegó en chino solo porque esa instalación de Claude Code tiene configurado ese idioma de respuesta; aquí se resume en español.

Los límites de la prueba son claros: una ejecución por condición, esfuerzo low (que solo informa de los hallazgos más seguros), una sola máquina y un modelo cuya salida varía de una ejecución a otra. No se ejecutaron Code Review gestionado, ultrareview ni /security-review: lo que se describe de esas tres herramientas sale de la documentación de Claude Code.

¿Code Review frena un PR malo? Solo si lo configuras tú

Por defecto, no: Code Review publica hallazgos, pero nunca aprueba ni bloquea un pull request, y la decisión de fusionar queda en tu equipo. Cada revisión deja comentarios en línea marcados como 🔴 Important (un error que conviene arreglar antes de fusionar), 🟡 Nit (menor, no bloquea) o 🟣 Pre-existing (un error que ya estaba y que este PR no introdujo), un resumen y un check llamado «Claude Code Review» que termina en neutral, nunca en fallo. Según la documentación de GitHub sobre ramas protegidas, un check obligatorio se da por bueno si termina en éxito, omitido o neutral, así que marcar este como obligatorio no frena nada.

El bloqueo que describe Anthropic, en el que un PR no entra mientras quede abierto un hallazgo, es configuración de los repositorios de Anthropic. Para tener algo parecido hay dos caminos. El sencillo es activar en la protección de ramas de GitHub la opción «Require conversation resolution before merging», que exige resolver todos los comentarios del PR antes de fusionar; la documentación de Code Review indica que, con ella activa, hay que resolver el hilo de cada hallazgo: cada hallazgo se cierra arreglándolo o resolviendo el hilo con una razón, que es como el equipo de Claude Code descarta los falsos positivos. El más estricto lo propone la página de Code Review sobre leer revisiones en un pull request y queda fuera de la prueba anterior: un job de tu CI lee con gh y jq la última línea del detalle del check, un comentario HTML como <!-- bughunter-severity: {"nit":1,"normal":2,"pre_existing":0} -->, y falla si normal (el número de hallazgos Important) es mayor que cero; ese job, y no el check de Code Review, es el que marcas como obligatorio. Si esa línea falta, no significa cero hallazgos sino que no hay veredicto, y el job debe tratarlo así.

Cómo montar este proceso de code review en tu equipo

El orden importa: primero lo que no cuesta nada y funciona con cualquier plan, después el revisor automático en un solo repositorio, y al final los niveles de aprobación. Son los pasos que Anthropic propone al final de su artículo, ordenados para que cada uno se apoye en el anterior.

1. Escribe un CLAUDE.md corto con los comandos que el agente puede ejecutar para verificar su trabajo (tests, build, linter) y las reglas que deben cumplirse en cualquier revisión. Añade hooks para formateadores y linters; cómo hacerlo está en Claude Code: hooks, comandos de barra y skills, ¿cuál usar?.
2. Pasa /code-review y /security-review en local antes de abrir cada PR. Cuando veas el mismo comentario de revisión dos veces, conviértelo en una línea de CLAUDE.md o en una regla de lint.
3. Añade a la plantilla de PR (.github/pull_request_template.md) los tres campos que usa el equipo de Claude Code. Claude puede rellenarlos, pero los firma quien pidió el cambio:

## Testing
<!-- Qué ejecutaste y qué salió: comando y resultado, captura o salida de los tests -->

## Risk
<!-- Bajo, medio o alto, y por qué: qué rutas toca -->

## How to revert
<!-- Cómo se deshace: revertir el commit, apagar un flag, volver a una versión -->

4. Pon CODEOWNERS y protección de ramas para que las rutas sensibles siempre pidan una persona. En la regla de la rama principal activa «Require review from Code Owners», «Dismiss stale pull request approvals when new commits are pushed» y «Require conversation resolution before merging»; qué hace cada opción lo explica la documentación de GitHub sobre ramas protegidas. Las rutas son las que cita Anthropic (autenticación, facturación, flujos de CI y de publicación, instaladores); cambia los nombres de equipo por los tuyos:

# .github/CODEOWNERS
/src/auth/          @tu-org/seguridad
/src/billing/       @tu-org/pagos
/.github/workflows/ @tu-org/plataforma
/scripts/release/   @tu-org/plataforma
/installer/         @tu-org/plataforma

5. Si tienes Team o Enterprise, activa Code Review en un solo repositorio, con las revisiones en «Once after PR creation» o en manual, y crea un REVIEW.md en la raíz. Fusiónalo antes de esperar efectos, porque, según la guía para personalizar Code Review, lo lee de la rama base o de la rama por defecto y nunca de los cambios del propio PR; las órdenes de bajar la severidad, excluir rutas o limitar los Nit solo se respetan si la rama por defecto está protegida. Ajústalo unas semanas y después amplía a más repositorios. Un punto de partida con los consejos de Anthropic:

# Review instructions

## What Important means here
Important = breaks behavior, leaks data or blocks a rollback.
In docs/, a finding is Important only if the docs say something the code does not do.

## Cap the nits
Report at most three Nits per review.

## Do not report
- Anything CI already enforces: lint, formatting, type errors
- Generated files under src/gen/ and any *.lock file

## Evidence
Every behavior claim needs a file:line citation, not a guess from a name.

## Summary
Start the summary with the number of findings. If there is nothing to fix, say so plainly.

6. Escribe tus niveles de riesgo según lo que toca el cambio y no según quién lo escribe, deja los caminos ligeros solo para autores de confianza y no permitas que la aprobación de un bot sustituya a la de una persona obligatoria. Empieza estricto y relaja un nivel solo cuando tus datos de reversiones e incidentes lo respalden.

Lo que viene después de la fusión (cola de fusión, flags, uso interno primero, lanzamientos escalonados y reversión en un paso) depende más de tu infraestructura que de Claude Code, pero es lo que permite aflojar el paso 6 sin miedo. Anthropic añade un último hábito: convertir incidentes y reversiones en un conjunto de pruebas para el revisor y volver a medirlo cada vez que cambien sus prompts, herramientas o modelo.

Cuánto cuesta: Code Review no tiene precio fijo

Code Review no tiene precio por revisión: se cobra por tokens en créditos de uso, a la organización y aparte del uso incluido en el plan, no al desarrollador que abrió el PR. El coste sube con el nivel de revisión (Quick, Standard o Deep), el tamaño del cambio, la complejidad del código que lo rodea y el número de posibles errores que hay que verificar. El modo «After every push», que es el que arranca por defecto al añadir un repositorio desde la página de administración, multiplica el coste por el número de pushes. La cifra de 15–25 $ por revisión que circula viene de la época del research preview, según publicaciones de terceros, y no es el precio actual. Según el anuncio de disponibilidad general de Code Review, la mayoría de las revisiones terminan ahora en 6–10 minutos, frente a unos 20 durante el preview.

Para estimar tu gasto, la página de costes de Code Review propone un piloto: fija un límite mensual de gasto para Code Review, activa unos pocos repositorios en «Once after PR creation» o manual, mira el coste medio por revisión en Admin settings > Claude Code y multiplícalo por los PR que abre cada repositorio al mes (y por los pushes por PR si usas «After every push»). Si se agota el límite de Code Review, el de la organización o el saldo de créditos, las revisiones se saltan y el PR muestra un aviso. Las organizaciones Enterprise que cumplan los requisitos pueden reclamar al menos 10.000 $ en créditos de Code Review hasta el 15 de enero de 2027, y caducan 30 días después de reclamarlos.

Ultrareview se cobra aparte, según su documentación de precios y ejecuciones gratuitas: en Pro y Max hay 3 ejecuciones gratis, una sola vez por cuenta, y después cuesta normalmente 5–25 $ por revisión en créditos de uso, según el tamaño del cambio, una cifra que el diálogo de lanzamiento estima antes de cada ejecución; cada revisión tarda unos 15–25 minutos. /code-review en local cuenta como el resto de tu sesión. Cómo funcionan esos créditos lo explica Coste del uso adicional de Claude: créditos, Max y Claude Code.

Cuando el agente autor y el agente revisor no terminan nunca

Un agente que escribe y otro que revisa pueden tenerse ocupados sin fin: un PR del CLI pasó por más de cincuenta rondas de revisión y corrección en una noche hasta que su autor lo paró. El ruido cuesta más cuando el autor es un agente, porque una persona descarta un Nit en segundos y un agente lo arregla, lo que supone otro commit y otra ronda. Al pasar git blame por lo que el revisor seguía marcando, cerca del 59 % era código que ya estaba ahí desde la primera revisión: no encontraba errores nuevos, sino unos pocos antiguos más en cada vuelta. El equipo cambió la re-revisión con cuatro reglas:

• Tras tres rondas, el revisor pide al autor que se pare y reconsidere el enfoque.
• Después de las primeras pasadas, solo se revisa el diff nuevo.
• Se señala la clase de error, para que el autor corrija todos los casos y no una sola línea.
• No se repiten hallazgos ya publicados.

Su prioridad, por escrito, es primero atrapar errores reales y después reducir rondas, y hoy miden las rondas hasta aprobar junto con la tasa de detección. Si tu revisor es un agente propio o un bucle en tu CI, escribe estas cuatro reglas en sus instrucciones. Con Code Review, poner las revisiones en «Once after PR creation» o en manual evita además una ronda nueva por cada push.

Qué siguen decidiendo las personas en el equipo de Claude Code

Sí se sigue leyendo código, pero solo donde una persona aporta algo que los checks no aportan. Sacar a un ingeniero sénior de un trabajo profundo para cazar un error rutinario cuesta mucho más que una revisión automática, así que las personas del equipo responden de cinco cosas: decidir si algo se construye (dirección, criterio y alcance), revisar el código de riesgo como facturación, el actualizador automático y los flujos de CI, revisar la arquitectura que otros van a copiar, leer las pruebas de cada cambio y responder del resultado, lo escribiera quien lo escribiera. Leer las pruebas significa mirar la salida de los tests, el comando y lo que devolvió, la captura y los hallazgos del revisor; Anthropic lo resume así: si no puedes decir qué se le escaparía a los checks, pide una revisión de verdad en vez de una aprobación rápida.

La otra función de la revisión, repartir el conocimiento del código, ya no depende de leer diffs ajenos. Nadie en el equipo tiene en la cabeza un modelo completo de Claude Code; quien necesita entender una parte le pide a Claude una explicación de ese trozo, a veces con un pequeño artefacto visual, y el trabajo en canales de Slack abiertos deja ver lo que construyen los demás mientras lo construyen. La norma es «si lo fusionas, es tuyo»: quien fusiona un cambio pequeño o mediano que falla suele arreglarlo, y funciona porque los cambios son pequeños, todo se puede revertir y los incidentes se revisan como fallo del sistema, no como culpa. Cuando alguien ve que un cambio va en la dirección equivocada, lo dice pronto en el hilo y no como comentario bloqueante sobre un PR terminado. Lo que el equipo reconoce que le falta son disyuntores que endurezcan las aprobaciones cuando suben las reversiones o los incidentes; los quieren antes de llevar más código a fusiones sin ninguna persona.