Cómo el equipo de Claude Code hace la revisión de código: siete pasos y sin cortacircuitos

El 15 de octubre de 2026, el equipo de Claude Code publicó su propio relato sobre cómo revisa el código, una entrada de ingeniería de catorce minutos firmada por Addy Osmani, Morgan Westlee Lunt y Qing Wang. La frase que explica por qué alguien está buscando esto aparece pronto: Claude escribe alrededor del 90 por ciento del código del propio Claude Code. La entrada no es una defensa de esa cifra, sino una descripción de la maquinaria que tuvo que existir por debajo de ella para que resultara viable, y las partes que merece la pena leer con atención son las que todavía faltan.

La mayoría de los resúmenes se detienen en las dos cifras principales: las pull requests fusionadas en el código base de Claude Code más que se duplicaron entre junio y septiembre de 2026, mientras que la proporción que tuvo que revertirse cayó más del 40 por ciento. Ambas cifras provienen del propio equipo y ambas pueden producirse mediante varias configuraciones distintas, incluida la que la gente supone: que la revisión se eliminó en silencio. La publicación afirma que no fue así. Trasladaron la mayor parte de la lectura a las máquinas, optimizaron para el tiempo y la atención humanos e invirtieron en que los errores se pudieran deshacer de forma rápida y sencilla. Todo lo demás es el detalle de cómo.

¿Por qué la revisión se convirtió en el cuello de botella en primer lugar?

La presión no vino de una decisión de política. Vino del volumen. En el monorepo de Anthropic, según la publicación, los cambios que se integraban por día pasaron de unos 2.500 en mayo a más de 30.000 en septiembre de 2026. Claude Code vive en su propio repositorio, separado de ese monorepo, pero está bajo la misma presión a menor escala.

A ese ritmo, admite la publicación, la revisión manual línea por línea es increíblemente difícil, si no imposible. Nadie allí afirma que sea innecesario que una persona lea cada diff. Lo que afirman es que leer cada diff ya no escala, y que «¿leyó un humano el código?» siempre fue un indicador impreciso de la pregunta que importa: qué podría salir mal con este cambio y qué verificación, automatizada o humana, es la adecuada para detectarlo.

Dicho así, la barrera se mueve. La revisión deja de ser una puerta al final del camino y pasa a ser continua, más parecida a la corrección ortográfica mientras escribes. La mayoría de los cambios ya han sido leídos y corregidos por Claude antes de que los vea una persona.

Para qué optimizaron y qué se considera un fracaso

El objetivo declarado es que la mayoría de las pull requests en los repositorios de Claude Code, que según la publicación son la CLI, las aplicaciones de escritorio y web y las aplicaciones móviles, se integren con como mucho una persona en el circuito, que puede ser el autor, sin que aumenten las reversiones ni los incidentes. La tercera cláusula es lo que lo convierte en un objetivo real y no en un mero ejercicio de reducción de costes.

Miden el tiempo humano en ambos lados del registro: el tiempo que las personas dedican a revisar y el que dedican a corregir lo que rompe el código defectuoso. Reducir el primero no ayuda si el costo reaparece en el segundo, y el equipo lo dice directamente. Así que las métricas registradas son las aprobaciones humanas por pull request, reportadas como mediana y percentil 95, los comentarios humanos y cuánto tiempo espera un pull request a una persona. Las tasas de reversión e incidentes subyacen a todo ello como salvaguarda: si aumentan, no se ahorró tiempo humano, solo se trasladó.

Las métricas de coste de revisión son fáciles de manipular de forma aislada; un revisor que lo aprueba todo produce gráficos de tiempo de aprobación preciosos. La barrera de protección es lo que impide que el gráfico mienta.

Siete pasos, no una sola puerta

El artículo presenta el recorrido de un cambio típico en siete pasos numerados. Cada capa detecta algunos problemas y pasa por alto otros, y las comprobaciones más baratas se ejecutan antes que las más costosas.

• Verificación antes de que exista la solicitud de extracción. Claude ejecuta las pruebas, la compilación y el linter, y un segundo agente revisa el diff en un contexto nuevo. Muchos ingenieros también ejecutan habilidades internas: una busca errores, otra simplifica el diff y otra comprueba el comportamiento de extremo a extremo. Boris Cherny, creador de Claude Code, ha dicho que darle a Claude una forma de verificar su propio trabajo es probablemente lo más importante para obtener buenos resultados, y estima que hace que el resultado final sea dos o tres veces mejor.

• Revisión con IA en cada pull request. Una revisión de Claude lee el diff comparándolo con todo el repositorio y con la intención declarada del pull request. Varios agentes buscan errores en paralelo; después, un grupo separado vota cada hallazgo y solo se publica si suficientes están de acuerdo en que es real. Los hallazgos sobre estilo, diagnósticos o limpieza se descartan. Lo que sobrevive aparece como comentarios en línea etiquetados como Important, Nit o Pre-existing. Cuando se lanzó la vista previa de investigación, la proporción de pull requests internos que recibían comentarios de revisión sustanciales pasó del 16 por ciento al 54 por ciento. Los administradores configuran cada repositorio como Quick, Standard o Deep.

• Revisión de seguridad. Una pasada automatizada independiente. Una solicitud de extracción no se puede fusionar mientras haya un hallazgo abierto de cualquiera de las dos revisiones; lo corriges o cierras el hilo con una razón breve. La misma comprobación es pública como la GitHub Action de revisión de seguridad de código abierto o el comando /security-review.

• Comprobaciones automatizadas que bloquean. Lint, comprobación de tipos, pruebas en todas las plataformas y una compilación.

• Aprobación humana, escalada según el riesgo. Un clasificador lee el cambio y establece el nivel en lugar de que lo establezca el autor. Este paso tiene su propia sección a continuación, porque es donde reside la mayor parte del diseño interesante.

• Cola de fusión, flags y despliegue gradual. La cola vuelve a ejecutar todas las comprobaciones contra main con el cambio aplicado, de modo que dos pull requests que pasan por separado no pueden combinarse y romper main. El nuevo comportamiento se lanza detrás de un flag primero a los empleados de Anthropic y después al canal más reciente, con stable a la zaga.

• Detección y reversión rápidas. Los flags se desactivan sin necesidad de un despliegue, hay una rotación semanal de guardia y las revisiones de incidentes preguntan qué capa debería haber detectado el problema. Algunos errores seguirán pasando, así que la última capa consiste en detectarlos rápidamente en lugar de prevenirlos.

El cambio establece el nivel, no el autor

Una corrección de documentación y un cambio en el actualizador automático no conllevan el mismo riesgo, por lo que no reciben la misma revisión. La tabla del artículo tiene tres niveles y cada uno responde a una sola pregunta: cuántas personas, si las hay, tienen que aprobar esto antes de que se fusione.

Bajo abarca la documentación, los textos, las funciones exclusivamente internas y los cambios aditivos detrás de un flag; una vez que la revisión automatizada y la seguridad estén en verde, no se requiere ninguna persona. Medio abarca los cambios habituales de producto, además de áreas sensibles como el almacenamiento en caché, el actualizador automático y los prompts del sistema, y requiere una persona. Alto abarca el código de mayor riesgo y un pequeño conjunto de rutas que siempre requieren dos personas.

El clasificador es solo la mitad del diseño. Un segundo clasificador pregunta si este cambio en particular necesita a otra persona, incluso cuando su nivel indica que no. Algunas rutas siempre necesitan a una persona, independientemente del nivel: cualquier cosa que los propietarios hayan marcado como sensible y cualquier archivo de flujo de trabajo de CI. Solo los autores de la lista de confianza del repositorio, principalmente el equipo propietario, obtienen las rutas más ligeras; todos los demás necesitan a una segunda persona. La aprobación de un agente nunca cuenta como la de una persona, así que la revisión automatizada puede aprobar un cambio de bajo riesgo, pero no puede ocupar una plaza que exige a un humano. Quien haya solicitado el cambio es responsable de él. Y una aprobación cubre un commit específico, por lo que un nuevo commit, incluido el push de un agente o un merge resuelto a mano, necesita la aprobación de nuevo.

Dos detalles vale la pena tomar prestados incluso si nunca construyes un clasificador. El nivel proviene del cambio, no del autor, y la confianza es una compuerta separada y más estrecha que se superpone a él. Y una aprobación está vinculada a un commit en lugar de a una pull request, lo que cierra el agujero más común de los sistemas de revisión: una marca verde obtenida al principio de una rama que se aplica a código que nadie ha revisado.

El revisor se entrena con sus propios incidentes

Esta es la parte que la mayoría de los textos omiten, y explica por qué el arreglo sigue funcionando en lugar de desviarse.

El equipo recopiló pull requests pasados que causaron incidentes, junto con sus correcciones hacia adelante y reversiones, e hizo que ingenieros que conocen ese código confirmaran cada error y dónde estaba. Esa colección ahora es una evaluación. El revisor se ejecuta contra ella a diario. Cuando cambian sus prompts, herramientas o modelo, el cambio tiene que sobrevivir al conjunto completo: consérvalo si la puntuación sube, descártalo si no. Sus fallos se convirtieron en la suite de pruebas de aquello que se supone que debe detectar sus fallos.

Esa es una postura distinta a la de ajustar un linter, que se evalúa con respecto a un conjunto fijo de reglas. A este revisor se le evalúa en función de las formas específicas en que este código base ya ha fallado, así que la evaluación crece cada vez que algo sale mal. No aparece ninguna puntuación suya en nada de lo que hayamos leído que Anthropic haya publicado, y la publicación no afirma que el revisor esté terminado.

La capa que aún no está construida

Aquí está el reconocimiento que hace creíble la publicación. Todo lo anterior describe un sistema que detecta y revierte errores, no uno que se dé cuenta de que su propia tasa de error está cambiando. El equipo aún no dispone de circuit breakers que endurezcan automáticamente la aprobación cuando cambian las cifras de reversiones o incidentes, y los ingenieros de allí los quieren antes de que más código pase a fusiones sin intervención humana.

Lo que existe en su lugar es la observación humana. Los flags se desactivan sin necesidad de un despliegue, la rotación semanal de guardia vigila y las revisiones de incidentes preguntan qué capa debería haber detectado el problema. La frase de un colega es la oración más útil para cualquiera que planifique un despliegue similar: bajar el ritmo reduce tu tasa de errores, pero sobre todo porque estás haciendo menos de todo. El equipo prefiere volverse más rápido para detectar y solucionar problemas que más lento para producirlos.

Vuelve a leer los siete pasos con eso en mente. Seis deciden si un cambio sigue adelante. El séptimo es un conjunto de hábitos para fijarse después. No hay ningún bucle de retroalimentación que conecte el resultado con la puerta de decisión, y quienes construyeron el sistema lo dicen.

El segundo trabajo de Review, que la publicación deja en gran medida de lado.

La publicación deja claro que la revisión de código cumple dos funciones: encontrar y corregir problemas antes de que se lancen, y construir contexto compartido en todo el equipo. Se centra en la primera y luego vuelve a la segunda con una respuesta inusualmente honesta: no hay un proceso formal para ello, nadie mantiene un modelo mental completo de Claude Code en su cabeza, y no creen que nadie lo necesite. ¿Quieres entender una parte de la base de código? Pídele a Claude una explicación de exactamente esa parte.

Dos archivos de instrucciones concentran el contexto que antes residía en la cabeza de los revisores. CLAUDE.md le dice a Claude qué es el proyecto, el stack, las convenciones, los objetivos y los no objetivos, y se mantiene breve a propósito. REVIEW.md lo escriben los propietarios del código y describe cómo se manifiesta un fallo en su parte del código, qué rutas omitir, y pide un archivo y una línea en lugar de una suposición.

La responsabilidad tiene una línea propia: si lo integras, es tuyo. Si fusionas un cambio pequeño o mediano y algo sale mal, la norma es que lo arregles. Eso funciona porque los cambios son pequeños, porque los flags y las reversiones deshacen la mayoría de los errores en minutos, y porque el radio de impacto determina cuántas comprobaciones recibe un cambio. Es una norma que se superpone a la regla de aprobación, no un sustituto de ella.

Dónde encaja un router y dónde no

El pipeline anterior es un pipeline de llamadas a modelos: un agente de revisión que lee un diff contra un repositorio completo, varios agentes cazadores de bugs en paralelo, un grupo que vota sobre cada hallazgo, una pasada de seguridad y el revisor ejecutado de nuevo a diario contra una evaluación en crecimiento. Eso es un problema de enrutamiento antes que un problema de revisión, porque que un proveedor tenga una mala tarde no debería detener una cola de merge.

OrcaRouter es un único endpoint compatible con OpenAI para más de 200 modelos con una sola clave, con conmutación por error automática entre proveedores y sin margen, es decir, el precio de lista del proveedor se pasa tal cual. Los equipos que ejecutan su propia versión de este pipeline obtienen una única relación de facturación y un único lugar donde cambiar un modelo cuando cambia la calidad de un revisor, que es exactamente lo que la evaluación diaria está diseñada para detectar.

La frontera importa. Nosotros alojamos modelos. No alojamos Claude Code, no ejecutamos Code Review for Claude Code y no tenemos acceso al pipeline del que trata este artículo. Code Review for Claude Code es un producto de Anthropic, disponible de forma general en los planes Team y Enterprise, con una versión más ligera disponible localmente como /code-review. Si lo que quieres es ese pipeline, ahí es donde está; en la versión de tu propio equipo, un router es una decisión de infraestructura más que una decisión de revisión.

Lo que un equipo más pequeño puede copiar realmente

Escribe las reglas de revisión donde quien revisa pueda leerlas: un CLAUDE.md breve para el proyecto y un REVIEW.md por área que nombre cómo se ve un fallo y exija un archivo y una línea en lugar de una suposición. Pon los niveles de riesgo por escrito, haz que sean una propiedad del cambio y no de la persona autora, empieza con rigor y relaja solo con evidencia. Limita lo que la revisión automatizada puede aprobar y nunca dejes que la aprobación de un agente cuente como la de una persona. Vincula las aprobaciones a los commits. Ejecuta la cola de fusiones. Convierte los incidentes y las reversiones en casos de prueba y vuelve a puntuar al revisor siempre que lo cambies, porque un revisor sin medir es un linter con mejor marketing.

Entonces fíjate en la salvaguarda, no en el tiempo de aprobación. El propio planteamiento del equipo te da la prueba para cualquier cambio en la revisión que estés considerando: ¿se mantuvieron las tasas de reversión e incidentes, o el tiempo simplemente pasó del revisor a la persona que limpia después? Esa pregunta se puede responder con datos que la mayoría de los equipos ya tienen, y separa un proceso que se volvió más rápido de uno que solo parece más rápido durante un trimestre.