Una de las pruebas más difíciles para una herramienta que escribe código es saber quién revisa lo que escribe. Anthropic ha contado cómo lo resuelve con la suya. En una entrada de ingeniería publicada el 15 de octubre de 2026 por Addy Osmani, Morgan Westlee Lunt y Qing Wang, «How the Claude Code team does code review», la compañía afirma que Claude escribe aproximadamente el 90 % del código de Claude Code, su propio agente de programación.
Es una cifra que la empresa da sobre sí misma y que nadie ha auditado desde fuera. Lo más aprovechable del texto no es el porcentaje, sino lo que hacen para que ese volumen no se convierta en un problema.
De 2.500 a 30.000 cambios al día
Según el mismo artículo, los cambios que entran cada día en el monorepositorio de Anthropic pasaron de unos 2.500 en mayo a más de 30.000 en septiembre. En el caso concreto de Claude Code, entre junio y septiembre los cambios fusionados (merged PRs) se más que duplicaron, y la proporción de ellos que hubo que deshacer (reverts) bajó más de un 40 %.
Con ese ritmo, que cada línea pase por los ojos de una persona deja de ser realista. Anthropic lo plantea al revés: su objetivo declarado es que la mayoría de los PR de los repositorios de Claude Code se fusionen con, como mucho, una persona en el circuito —que puede ser la propia autora—, sin que aumenten los reverts ni los incidentes. Y resume su criterio en una frase: preguntarse si «una persona leyó el código» es un indicador impreciso de lo que importa, que es qué podría salir mal con ese cambio y qué control —automático o humano— es el adecuado para detectarlo.
Siete capas, y no todas son una persona
El artículo describe siete capas apiladas:
- Antes del PR. Claude ejecuta pruebas, compilación y linters, y un segundo agente, con contexto limpio, revisa el diff.
- Revisión automática de cada PR. Un revisor basado en Claude lanza agentes en paralelo y otros verifican cada hallazgo antes de que lo vea alguien.
- Revisión de seguridad que bloquea la fusión hasta resolver lo que encuentre.
- Integración continua obligatoria: lint, tipos, pruebas por plataforma y compilación.
- Aprobación humana según el riesgo.
- Cola de fusión, que repite las comprobaciones contra la rama principal con el cambio ya aplicado.
- Vuelta atrás rápida: banderas de funcionalidad, reverts y paneles de incidentes.
La quinta capa es la que más cambia respecto a lo habitual. Según Anthropic, un clasificador asigna cada cambio a un nivel de riesgo. Los de riesgo bajo (documentación, textos, funciones internas o añadidos tras una bandera) pueden fusionarse sin aprobación humana si pasan los controles automáticos; los medios (cambios corrientes de producto y zonas sensibles como la caché, el actualizador automático o los prompts de sistema) necesitan una persona, y el código de mayor riesgo, dos. Siempre interviene un humano en cualquier archivo de flujos de CI y en lo que los responsables del código hayan marcado como sensible.
Un PR que se revisó más de cincuenta veces en una noche
El texto reconoce un tropiezo. Un PR de la CLI pasó «más de cincuenta rondas de
revisión y arreglos durante la noche» antes de que su autor lo detuviera. Al
analizar con git blame qué seguía señalando el revisor, Anthropic encontró
que cerca del 59 % era código que ya estaba ahí desde la primera pasada: el
sistema estaba desenterrando fallos viejos, no corrigiendo los del cambio.
Anthropic dice que desde entonces limita las rondas y revisa solo lo nuevo en cada pasada. Después de esos ajustes, según sus datos internos, los PR que pasan en una sola ronda subieron del 65 % al 78 %, los que necesitaban cinco o más rondas bajaron del 8,9 % al 1,5 % y la media de revisiones por PR pasó de 2,08 a 1,32. Son cifras de la propia empresa sobre su propio trabajo.
Qué cambia para ti
Si usas Claude Code o cualquier otro asistente de desarrollo o de agentes, el artículo es menos una noticia que una lista de prácticas que puedes copiar sin ser Anthropic. Las que recomienda para antes y durante el PR:
- Mantener un
CLAUDE.mdbreve con las convenciones del proyecto y unREVIEW.mdque diga a los revisores qué importa. - Ejecutar en local
/code-reviewy/security-reviewantes de abrir el PR. - Exigir CI en verde y plantillas de PR estructuradas.
- Poner un tope de rondas (propone tres) y, pasadas las primeras, revisar solo el diff nuevo.
- Definir los niveles de riesgo por las características del cambio, no por quién lo firma, y proteger con reglas de rama las rutas sensibles.
- Usar banderas y despliegues escalonados, y medir las aprobaciones humanas y los incidentes como freno.
El revisor automático no es gratis. Cuando Anthropic lo presentó como producto, el anuncio del 9 de marzo de 2026 daba un coste medio de 15 a 25 dólares por revisión, que crece con el tamaño del PR, y decía que el porcentaje de PR internos con comentarios sustanciales había pasado del 16 % al 54 %. Para un equipo pequeño, la parte barata de la receta son las dos primeras capas y los tests, no el clasificador de riesgo.
Qué seguimos sin saber
El propio texto admite un hueco: todavía no tienen «cortacircuitos» que endurezcan las aprobaciones cuando suban los reverts o los incidentes, y los ingenieros los quieren antes de ampliar las fusiones sin ninguna revisión humana. Tampoco hay forma de comprobar desde fuera el 90 % (la propia entrada lo presenta como algo que Anthropic ya había dicho antes, sin explicar cómo lo mide), ni qué parte de la bajada de reverts se debe al proceso y cuál a que los cambios sean más pequeños o más fáciles. Y es una experiencia de una empresa que fabrica el modelo que escribe y el que revisa: no hemos encontrado ninguna medición independiente de si ocurriría lo mismo en un equipo con código más viejo, menos pruebas o sin revisores dedicados.
La conclusión práctica no es que «ya no hace falta leer código», sino que Anthropic ha decidido dónde sigue leyendo una persona y dónde no, y lo vigila con reverts e incidentes. Esa pregunta —qué control corresponde a qué riesgo— es la que cualquier equipo que delegue en un agente tiene que contestar por escrito.
