Cómo el equipo de Claude Code hace la revisión de código: capas automáticas, riesgo y rollback rápido

El artículo, publicado en el blog de claude.dev el 15 de octubre de 2026 y firmado por Addy Osmani, Morgan Westlee Lunt y Qing Wang, describe cómo revisa código el equipo de Claude Code cuando, según dicen, Claude escribe alrededor del 90 % del código del propio producto. La pregunta de partida es qué significa revisar a ese volumen y quién detecta los fallos. Nota: el texto descargado se corta de forma abrupta en la sección final sobre propiedad y cultura de equipo. Este resumen cubre solo lo que aparece en el contenido recibido.

El dato central que ofrecen es que, de junio a septiembre, los pull requests fusionados en el código de Claude Code más que se duplicaron, mientras que la proporción que hubo que revertir cayó más de un 40 %. No eliminaron la revisión. Trasladaron la mayor parte de la lectura a máquinas, optimizaron el tiempo y la atención humanos, e invirtieron mucho en que deshacer errores sea rápido y fácil. Como contexto de escala, dicen que en el monorepo de Anthropic los cambios que aterrizan al día pasaron de unos 2.500 en mayo a más de 30.000 en septiembre. Claude Code vive en un repositorio aparte, pero también sufre esa presión.

El planteamiento conceptual es que la revisión de código cumple dos funciones: encontrar y corregir problemas antes de que lleguen a producción, y construir contexto compartido y comprensión del código en el equipo. Los autores proponen sustituir la pregunta «¿lo leyó una persona?» por otra más precisa: qué podría salir mal con este cambio y qué comprobación, automática o humana, es la adecuada para detectarlo. Eso también cambia el momento de la revisión. Ya no es una puerta al final del camino (escribir, abrir PR, esperar a un colega), sino algo continuo, parecido a un corrector ortográfico mientras se escribe. La mayoría de los cambios los ha revisado y corregido Claude al menos una vez antes de que un humano los mire.

El recurso escaso es el tiempo y la atención humanos, que incluyen tanto el tiempo de revisar como el de arreglar lo que rompe el mal código. El objetivo es que la mayoría de los PR de los repositorios de Claude Code (CLI, apps de escritorio, web y móvil) se fusionen con como mucho una persona en el circuito, que puede ser el propio autor, sin aumentar reverts ni incidentes. Para medirlo siguen las aprobaciones humanas por PR (mediana y percentil 95), los comentarios humanos y cuánto espera un PR a una persona. Las tasas de reverts e incidentes son la salvaguarda: si suben, no se ha ahorrado tiempo, solo se ha movido.

El recorrido de un cambio tiene varias capas. La primera ocurre antes del PR: se le da a Claude algo que pueda ejecutar (tests, build, una captura para comparar con el diseño) y se le pide que muestre la salida en lugar de decir que ha terminado. Después, un subagente revisa el diff con contexto limpio. Muchos miembros del equipo ejecutan además habilidades internas que buscan bugs, simplifican el diff y verifican el comportamiento de extremo a extremo, y los cambios de interfaz se comprueban contra las guías de diseño. El artículo cita a Boris Cherny, creador de Claude Code, quien considera que darle a Claude una forma de verificar su trabajo es probablemente lo más importante para obtener buenos resultados, y estima que mejora el resultado final entre dos y tres veces.

Cuando el revisor automático marca repetidamente lo mismo, lo arreglan en origen: en la habilidad, con una regla de lint o actualizando archivos de instrucciones. CLAUDE.md describe el proyecto (stack, convenciones, objetivos y no objetivos) y se carga en cada revisión, por lo que lo mantienen corto y enlazan a otros documentos. REVIEW.md lo escriben los responsables de cada parte del código y dice al revisor qué importa allí. Los buenos son breves: definen cómo es el fallo en ese repositorio (en documentación, «miente»; en configuración, «enruta mal»), limitan los nits, listan rutas a ignorar, piden archivo y línea como evidencia y piden un resumen que empiece con un recuento y diga claramente cuándo no hay nada que arreglar.

La segunda capa es la revisión por IA en cada pull request. Claude lee el diff contra todo el repositorio y la intención declarada del PR, y se pregunta si el cambio resuelve su problema, encaja en el sistema o rompe otra cosa; en una corrección de bug busca la causa raíz. La versión pública, Code Review para Claude Code, está disponible de forma general en planes Team y Enterprise, y /code-review ejecuta una versión más ligera en local. Cuando lanzaron la vista previa de investigación, la proporción de PR internos con comentarios de revisión sustanciales pasó del 16 % al 54 %. La mayoría de PR de más de 1.000 líneas reciben hallazgos y la mayoría de los pequeños salen limpios. Los administradores configuran cada repositorio en Quick, Standard o Deep, y este último compensa donde un bug perdido cuesta más que el tiempo extra de revisión.

Los hallazgos se verifican antes de llegar a las personas. Varios agentes buscan bugs en paralelo y luego otro grupo vota cada hallazgo, que solo se publica si suficientes votantes coinciden en que es real. Los que tratan solo de estilo, diagnósticos o limpieza se descartan, y esos filtros se probaron con A/B en PR propios. Lo que queda aparece como comentarios en línea ordenados por severidad y etiquetados como Important, Nit o Pre-existing, para que un bug que el PR no introdujo no parezca culpa del autor. Todo hallazgo debe responderse: se arregla o se cierra el hilo con una razón. A menudo un agente aplica la corrección durante la noche.

La tercera capa es una revisión de seguridad separada que puede bloquear. Un PR no se fusiona mientras haya algún hallazgo abierto de la revisión de bugs o de seguridad. Los falsos positivos se cierran con una razón breve, y si un commit posterior corrige el problema, el hallazgo se limpia solo. Mencionan que se puede replicar con la GitHub Action de revisión de seguridad de código abierto o con el comando /security-review. La cuarta capa son los controles automáticos habituales: lint, tipos, tests en todas las plataformas y build. Un PR típico del CLI puede pasar decenas de comprobaciones. La plantilla de PR pregunta cómo se probó el cambio y cómo deshacerlo; Claude puede rellenarla, pero la persona que pidió el cambio lo firma.

La quinta capa es la aprobación humana escalada por riesgo. Riesgo bajo (documentación, textos, funciones solo internas, cambios aditivos tras un flag): ninguna aprobación humana una vez que la revisión automática y la de seguridad están en verde. Riesgo medio (cambios de producto normales y áreas sensibles como caché, auto-actualizador o prompts de sistema): una persona. Riesgo alto (el código más crítico y un pequeño conjunto de rutas que siempre exigen dos personas): dos personas. Quien fija el nivel es el cambio, no el autor: un clasificador lee el cambio y elige el nivel, y un segundo clasificador valora si este cambio concreto necesita otra persona aunque su nivel diga que no. Algunas rutas siempre requieren a una persona, como lo que los responsables marcan como sensible y cualquier archivo de flujo de CI. Solo los autores de la lista de confiables, sobre todo el equipo propietario del repositorio, acceden a las vías más ligeras; el resto necesita una segunda persona.

Hay reglas adicionales. La aprobación de un agente nunca cuenta como la de una persona: la revisión automática puede dar por bueno un cambio de bajo riesgo, pero no ocupar un puesto que exige un humano. Quien pidió el cambio responde por él, y en un PR escrito por un agente la persona que lo dirige cuenta como uno de los revisores requeridos. Cada aprobación cubre un commit concreto, y si llegan commits que el sistema no puede avalar, como el push de un agente o un merge resuelto a mano, hay que aprobar de nuevo.

La sexta capa es la cola de fusión, los flags y la liberación gradual. La cola de fusión vuelve a ejecutar todas las comprobaciones contra main con el cambio aplicado, de modo que dos PR que pasan por separado no puedan combinarse en un main roto. El comportamiento nuevo suele salir primero tras un flag para empleados de Anthropic, cuyo uso intensivo a menudo destapa regresiones antes que los usuarios. Las versiones públicas van primero al canal latest y el canal stable lo sigue con retraso.

La séptima capa es la detección y el rollback rápidos. Los flags se apagan sin despliegue, hay una rotación semanal de guardia y las revisiones de incidentes preguntan qué capa debería haber detectado el problema. Los autores admiten que aún no tienen interruptores automáticos que endurezcan la aprobación cuando se mueven las métricas de reverts e incidentes, y que los ingenieros los quieren antes de mover más código a fusiones sin humanos. Citan a un colega según el cual frenar reduce la tasa de errores, pero sobre todo porque haces menos de todo; prefieren mejorar la rapidez para detectar y corregir.

El artículo explica también cómo mejoran al revisor. Los incidentes se convierten en evaluación: recopilaron PR pasados que causaron incidentes, con sus correcciones hacia delante y reverts, y los ingenieros que conocen ese código confirmaron cada bug y dónde estaba. El revisor se ejecuta a diario contra ese conjunto, y cada cambio de prompts, herramientas o modelo se puntúa contra todos los casos: si la puntuación sube se mantiene, y si no, se descarta. El ruido se mide observando qué hacen las personas con los comentarios (lo arreglaron, dijeron que era erróneo, que el comportamiento era intencionado o que no importaba) y ejecutando el revisor sobre PR que se sabe limpios para contar cuántas veces propone algo que llevaría a un cambio dañino. Su prioridad escrita es detectar bugs reales primero y reducir rondas de revisión después.

Un punto clave es la convergencia. El ruido cuesta más cuando el autor es un agente, porque arregla el nit, lo que supone otro commit y otra ronda. Un agente autor y un agente revisor pueden mantenerse ocupados indefinidamente: un PR del CLI pasó más de cincuenta rondas de revisión y corrección durante la noche hasta que su autor lo detuvo. Al analizar con git blame lo que el revisor seguía marcando, alrededor del 59 % era código presente desde la primera pasada, es decir, rara vez encontraba bugs nuevos y descubría unos pocos viejos más en cada ronda. Los propios autores lo agravaron al acostumbrarse a ejecutar varias rondas por defecto. Ahora siguen las rondas hasta aprobar junto con el recall, y cambiaron la re-revisión: tope de rondas (tras tres, el revisor pide al autor que replantee el enfoque), re-revisión solo del diff tras las primeras pasadas, señalar la clase de bug para que el autor corrija todas las instancias, y no repetir hallazgos ya publicados. Además, agentes de revisión recorren cada noche el código existente para cazar bugs antiguos.

Según la figura que acompaña al texto, tras estos cambios en PR internos el porcentaje que pasa tras una ronda de revisión y corrección subió del 65 % al 78 %, los que necesitan cinco o más rondas bajaron del 8,9 % al 1,5 %, y la media de revisiones hasta aprobar pasó de 2,08 a 1,32.

Sobre el papel que conservan los humanos, el artículo señala que sacar a un ingeniero sénior de su trabajo profundo para atrapar un error rutinario cuesta mucho más que una revisión automática. Las personas siguen decidiendo si algo debe construirse (dirección, criterio y alcance; un equipo que dio por resuelto su cuello de botella mantuvo revisión humana para cambios de fuera del equipo), revisando código arriesgado como facturación, auto-actualizador y flujos de CI, revisando arquitectura que sienta patrones que otros copiarán, leyendo la evidencia (salida de tests, el comando ejecutado, capturas, hallazgos del revisor) y asumiendo la responsabilidad del resultado. Si no se puede decir qué dejarían pasar las comprobaciones, se debe pedir una revisión real en vez de una aprobación rápida.

La segunda función de la revisión, repartir comprensión del código, no tiene un proceso formal. Nadie mantiene un modelo mental completo de Claude Code ni creen que haga falta. Quien quiere entender una parte pide a Claude un explicador de ese fragmento concreto, que tarda minutos y refleja el código actual; algunos piden además un artefacto visual adaptado a su forma de aprender. Defienden que esto gasta mejor la atención que leer diffs triviales, y que la costumbre de trabajar en canales abiertos de Slack ayuda a ver lo que construyen otros.

El texto recibido termina con la sección «You land it, you own it»: quien fusiona un cambio pequeño o mediano y algo falla normalmente lo arregla. Lo sostienen cambios pequeños fáciles de revisar y revertir, reversibilidad mediante flags, reverts y lanzamientos escalonados, un listón que depende del radio de impacto, regresiones que afloran rápido por telemetría y uso interno, y la ausencia de culpa (las revisiones de incidentes examinan el sistema). La propiedad es también compartida, con canales abiertos donde cualquiera puede ver, retomar o señalar huecos. El contenido se interrumpe a mitad de frase, así que no se conoce el cierre ni las secciones sobre cómo adoptar el proceso y hacia dónde va, que figuran en el índice.