Qué cambió en la revisión
El equipo de Claude Code informa de que las pull requests fusionadas al código de Claude Code se más que duplicaron de junio a septiembre, y de que la proporción que hubo que revertir bajó más de un 40 por ciento. ClaudeDevs publicó esas cifras el 16 de octubre de 2026. La comparación de pull requests va de junio a septiembre, y el año de esa ventana no está dicho.
El equipo también informa de que el monorepo de Anthropic pasó de unos 2.500 cambios integrados al día en mayo a más de 30.000 en septiembre de este año. Esos recuentos diarios pertenecen al monorepo. Claude Code vive en su propio repositorio, separado de ese monorepo, y el equipo dice que ese repositorio también recibe mucha presión. El equipo llama a la revisión manual línea por línea extremadamente difícil y, a veces, imposible, cuando los cambios salen a esta velocidad. La revisión sigue teniendo dos trabajos, dice el equipo: atrapar problemas antes de que salgan y construir una comprensión compartida del código. El texto sigue sobre todo lo de atrapar problemas antes de que salgan y vuelve a la comprensión compartida del código cerca del final.
La pregunta que el equipo dice hacerse es qué podría salir mal en un cambio y qué comprobación, automática o humana, debería atraparlo. Antes, la revisión esperaba a que una pull request estuviera abierta. Ahora corre mientras se escribe el cambio, y el equipo dice que la mayoría de los cambios ya han sido revisados y corregidos por Claude al menos una vez antes de que se pida a una persona.
Antes de que exista una pull request, Claude tiene que mostrar la salida de una comprobación que pueda ejecutar, como tests, una build o una captura comparada con el diseño. Después, un subagente con contexto nuevo, una pasada distinta de la sesión que escribió el cambio, revisa el diff. Muchas personas del equipo también ejecutan comprobaciones internas que buscan bugs, simplifican el diff y prueban el comportamiento de punta a punta. Los cambios de UI se comprueban contra las guías de diseño. Boris Cherny, que creó Claude Code, llama a dar a Claude una forma de verificar su trabajo probablemente lo más importante para obtener buenos resultados. Estima que esto hace el resultado final entre dos y tres veces mejor. Describe la verificación como un comando bash, una suite de tests o la app en un navegador o un simulador de teléfono. El artículo presenta ese multiplicador como su estimación.
Cada pull request se revisa entonces contra todo el repositorio y la intención declarada antes de que mire una persona. En una corrección de bug, el revisor busca la causa raíz. En la vista previa de investigación, el equipo dice que la proporción de pull requests internas con comentarios de revisión sustantivos pasó del 16 por ciento al 54 por ciento. Con esa cifra no se da fecha de la vista previa ni tasa de clientes. La mayoría de las pull requests de más de 1.000 líneas reciben hallazgos, y la mayoría de las pequeñas vuelven limpias.
El equipo apila seis capas de comprobaciones, con rollback debajo, y luego describe la detección rápida y el rollback como una séptima etapa.
- Antes de la pull request: mostrar la salida de una comprobación que el agente pueda ejecutar y, después, un subagente de contexto nuevo lee el diff.
- En la pull request: Claude revisa el diff contra el repositorio y la intención declarada.
- Revisión de seguridad: según la regla del equipo, un hallazgo abierto de revisión de bugs o de revisión de seguridad bloquea el merge.
- CI: lint, tipos, tests y una build siguen bloqueando.
- Aprobación humana: el riesgo del cambio fija el nivel. Solo los autores de confianza obtienen los recuentos más ligeros, y todos los demás necesitan una segunda persona.
- Release: una cola de merge, un flag primero para empleados, el canal latest y luego stable.
- Después de salir: los flags se apagan sin un deploy, y la revisión del incidente pregunta qué capa debía haber atrapado el fallo.
Aprobaciones según el riesgo y el producto público
En los repositorios propios de Claude Code en Anthropic, el cambio, no el autor, fija el nivel. Un clasificador lee el cambio y elige bajo, medio o alto. Un segundo clasificador puede exigir a otra persona aunque el nivel no lo haría. Las rutas que los propietarios han listado como sensibles, y cualquier archivo de workflow de CI, siguen necesitando a una persona.
Solo los autores de la lista de confianza del repositorio, en su mayoría el equipo propietario, obtienen la vía más ligera de la tabla. Esa lista es una puerta distinta del nivel. Todos los demás necesitan una segunda persona. La aprobación de un agente nunca cuenta como la de una persona. La revisión automática puede dejar pasar un cambio de bajo riesgo, y no puede ocupar un puesto que pide a un humano. En una pull request escrita por un agente, la persona que dirige al agente cuenta como revisor obligatorio, igual que si hubiera tecleado el cambio. Una aprobación cubre un commit. Un push posterior del agente, o un merge resuelto a mano, necesita aprobación otra vez.
Las personas siguen decidiendo si se construye el cambio, cómo tratar la facturación, el auto-updater y la CI, si el cambio fija un patrón que otros copiarán, si la salida de los tests y los hallazgos bastan, y quién es dueño del resultado. Una persona sigue siendo responsable de cada cambio que sale.
Code Review para Claude Code está disponible de forma general en los planes Team y Enterprise. Los administradores fijan cada repositorio en Quick, Standard o Deep. Son profundidades de lo duro que mira el revisor. Deep es la que explica el equipo: usarla donde un bug que se escapa cuesta más que el tiempo extra de revisión. El comando /code-review ejecuta una versión más ligera en local. El artículo del equipo no indica precio y no dice qué planes pueden ejecutar el comando local.
Varios agentes buscan bugs al mismo tiempo. Un grupo distinto vota después, y un hallazgo se publica solo si bastantes coinciden en que es real. Cuántos deben coincidir no está publicado. En este revisor de pull requests, los hallazgos que solo tratan de estilo, diagnósticos o limpieza se descartan. El equipo dice que hizo una prueba A/B de esos filtros en sus propias pull requests antes de conservarlos. Lo que queda se etiqueta como Important, Nit o Pre-existing. Pre-existing marca un bug que la pull request no introdujo. Cada hallazgo se corrige, o el hilo se cierra con un motivo, que es como se descarta un falso positivo. Un commit posterior que arregla el problema borra el hallazgo por sí solo.
Un hallazgo abierto de revisión de bugs o de revisión de seguridad bloquea el merge según la regla del equipo de Claude Code. El texto señala a quien quiera ese bloqueo la GitHub Action de código abierto de security review y /security-review. Code Review en los planes Team y Enterprise publica hallazgos y deja la aprobación a una persona. No activa el bloqueo de merge del equipo. En los repositorios propios de Anthropic, los propietarios deciden qué cambios de bajo riesgo se fusionan solo con comprobaciones automáticas, y el equipo dice que esa línea sigue moviéndose. Esa elección está aparte de la lista de autores de confianza, que decide quién obtiene la vía más ligera.
Sobre el comando local, el registro de cambios de Claude Code dice que /code-review con medium effort también informa de hallazgos de limpieza y de convenciones de CLAUDE.md en modelos sin ajustes de revisión afinados, incluidos Opus 5.5 y Sonnet 5.5. En el revisor de pull requests, los hallazgos solo de estilo, diagnóstico y limpieza se descartan.
| Riesgo | Ejemplos | Aprobaciones humanas |
|---|---|---|
| Bajo | Documentación, textos, funciones solo internas, cambios aditivos detrás de un flag | Ninguna obligatoria cuando la revisión automática y las comprobaciones de seguridad están en verde |
| Medio | Cambios de producto ordinarios y cambios en zonas sensibles como la caché, el auto-updater o los system prompts | Una persona |
| Alto | El código de mayor riesgo, más un conjunto pequeño de rutas que siempre necesitan a dos personas | Dos personas |
Cómo probar el mismo flujo
Antes de una pull request, el equipo señala a los lectores comprobaciones que el agente puede ejecutar, listadas en un CLAUDE.md breve, más hooks que ejecutan formateadores y linters. También señala /code-review y /security-review en local, o un subagente de contexto nuevo. CLAUDE.md lleva la pila, las convenciones, los objetivos y lo que no es objetivo. Cada revisión lo carga, así que el equipo lo mantiene corto. Un REVIEW.md, escrito por los dueños del código, dice cómo se ve el fallo en esa zona, pone tope a los nits, lista rutas que saltar, pide un archivo y una línea como evidencia, y pide un resumen que empiece con un recuento de lo que queda por corregir. Cuando la misma señal vuelve una y otra vez, el equipo mueve la corrección a una skill, una regla de lint o uno de esos archivos.
En cada pull request, el lint, las comprobaciones de tipos, los tests y una build siguen bloqueando. La plantilla pide Testing, Risk y How to revert. Claude puede redactar esas secciones. La persona que pidió el cambio da el visto bueno. Después de tres rondas, el revisor pide al autor que reconsidere el enfoque. Las pasadas posteriores revisan el diff nuevo. Al autor se le pide corregir una clase de bug, los hallazgos ya publicados no se repiten y los agentes de revisión también corren de noche sobre el código existente. El pie del gráfico del equipo sobre pull requests internas dice que hubo menos rondas de revisión por pull request después de esos cambios de convergencia. El pie no da una cifra.
Para la aprobación, escriba niveles a partir del cambio, reserve las vías más ligeras para autores en los que confía e impida que un bot ocupe un asiento humano obligatorio. Use CODEOWNERS y la protección de ramas para que auth, facturación, CI, flujos de release e instaladores necesiten siempre a una persona. Descarte una aprobación cuando un commit nuevo no pueda avalarse.
Su camino de release usa una cola de merge, que vuelve a ejecutar cada comprobación contra main con el cambio aplicado, de modo que dos pull requests que pasan por separado no pueden combinarse en un main roto. El comportamiento nuevo suele salir primero a los empleados detrás de un flag. Las releases públicas van primero al canal latest, y el canal stable va detrás. Cuánto tiempo stable va por detrás de latest no está publicado. Los flags se apagan sin un deploy. Las pull requests de incidentes pasados, los fix-forward y los reverts los confirman ingenieros que conocen el código, y el revisor se ejecuta a diario contra ese conjunto. No se publica una puntuación de esa ejecución diaria.
Lo que sigue siendo un objetivo
El objetivo es que la mayoría de las pull requests en los repositorios de Claude Code, la CLI, las apps de escritorio y web, y las apps móviles, se fusionen con como mucho una persona, que puede ser el autor, y que los reverts y los incidentes no suban. El artículo enuncia el objetivo. No dice que el objetivo se haya cumplido. La evidencia de junio a septiembre es el volumen y la proporción de reverts.
El tiempo humano se sigue con la mediana y el percentil 95 de aprobaciones por pull request, los comentarios humanos y cuánto espera una pull request a una persona. Las tasas de revert y de incidentes son el guardarraíl: si suben, el equipo dice que el tiempo se movió, no se ahorró. Esas medianas, esos recuentos de comentarios y esos tiempos de espera no están publicados.
La frase de que Claude escribe alrededor del 90 por ciento del código de Claude Code es una que el equipo dice haber dicho antes. Este artículo no incluye un método de recuento para esa proporción.
Los cortacircuitos que apretarían la aprobación cuando se muevan las cifras de reverts o de incidentes no están puestos. Los ingenieros del equipo los quieren antes de que más código pase a merges sin aprobación humana. No se da fecha de salida. Advertir un mal merge sigue dependiendo del autor, de la rotación semanal de guardia y de los paneles de reverts e incidentes. Las revisiones de incidentes preguntan qué capa debía haber atrapado el problema.
Una pull request de la CLI pasó por más de cincuenta rondas de revisión y correcciones durante la noche antes de que su autor la detuviera. El equipo lo cuenta como un caso de un autor agente y un revisor agente que se mantenían ocupados el uno al otro. Una persona puede descartar un nit en segundos. Un agente lo corrige, lo que significa otro commit y otra ronda de revisión. El equipo dice que una comprobación con git blame de lo que el revisor seguía marcando encontró que alrededor del 59 por ciento era código ya presente en la primera pasada, y que el revisor rara vez encontraba bugs nuevos y encontraba unos pocos viejos más en cada ronda. El texto no da un tamaño de muestra para ese 59 por ciento.
El equipo mide ese ruido por lo que las personas hacen con los comentarios. Cada comentario se clasifica por la respuesta en la pull request: corregido, llamado erróneo, llamado intencional o dejado de lado como algo que no importaba. El revisor también se ejecuta sobre pull requests que el equipo sabe que están limpias, y el equipo cuenta con qué frecuencia informa de algo que habría llevado a alguien a hacer un cambio dañino. La prioridad escrita es atrapar bugs reales primero y reducir las rondas de revisión después.
La comprensión compartida no tiene un proceso formal. Quien necesita una parte del código pide a Claude una explicación de esa parte, y algunas personas hacen que Claude construya un artefacto pequeño que la enseñe. El equipo dice que los canales abiertos de Slack muestran el trabajo mientras se construye. En un cambio pequeño o mediano, la persona que lo integra suele corregir un fallo posterior. Las salvaguardas que nombran son diffs pequeños, flags, reverts, release por etapas y un uso interno rápido. Como los agentes abaratan empezar, el artículo dice que un compañero debería cuestionar la dirección pronto en el hilo, y que cerrar la pull request es algo ordinario.
Fuente
También de
Fuentes y criterio editorial
Este artículo se apoya en la publicación de ClaudeDevs del 16 de octubre de 2026 y en el artículo de claude.dev que enlaza, How the Claude Code team does code review, comprobado el mismo día, además de la nota del registro de cambios de Claude Code según la cual /code-review con medium effort también informa de hallazgos de limpieza y de convenciones de CLAUDE.md en modelos sin ajustes de revisión afinados, incluidos Opus 5.5 y Sonnet 5.5. El artículo del equipo no indica precio y no dice qué planes pueden ejecutar el comando local. Los pasos de instalación de security review, la guía de buenas prácticas, el anuncio aparte de Code Review y las entradas posteriores del registro de cambios quedan fuera. El pie del gráfico dice que las rondas internas de revisión bajaron tras los cambios de convergencia y no da una cifra. La evaluación diaria de incidentes se describe sin una puntuación publicada.