El código se duplica y las reversiones bajan: cómo Anthropic dejó de leerlo todo

El 15 de octubre de 2026, el equipo que desarrolla Claude Code, el asistente de programación de Anthropic, publicó cómo revisa su propio código. El punto de partida es inusual: Claude escribe alrededor del 90% del código de Claude Code. Entre junio y septiembre, el número de cambios integrados en el software se duplicó con creces, y la proporción que tuvo que deshacerse cayó más de un 40%. La producción aumentó mientras la tasa de error bajaba, porque el equipo dejó de preguntar «¿una persona lo ha leído todo?» y se preguntó qué control, automático o humano, debía detectar cada error.

El doble de cambios, una proporción revertida un 40% menor

Un equipo de software no modifica directamente su producto. Cada cambio pasa por una pull request, una propuesta de modificación que espera a ser revisada y luego integrada en el código principal. Cuando un cambio integrado rompe algo y se retira, se llama revert, o reversión. Esos son los dos contadores de Anthropic.

La caída se aplica a la proporción de cambios revertidos, no a su número. Tomando los umbrales anunciados tal cual, volumen por dos y proporción por 0.6, el número de reversiones habría crecido alrededor de un 20% con un volumen duplicado. Ese cálculo es nuestro; Anthropic no publica la cifra. El resultado es este: el volumen se duplicó sin que las reversiones siguieran el mismo ritmo.

Ya nadie puede leerlo todo: 30’000 cambios al día

Anthropic conserva la mayor parte de su código en un único repositorio grande. En mayo se integraban en él unos 2’500 cambios al día. En septiembre, más de 30’000.

A ese ritmo, ninguna persona lee cada línea. El equipo extrajo la consecuencia: «¿una persona ha leído el código?» es, a su juicio, un indicador indirecto impreciso. La pregunta correcta es qué puede salir mal y qué control debería detectarlo. El recurso escaso ya no es el código, sino la atención humana. El objetivo pasa a ser que la mayoría de los cambios se integren con como máximo una persona en el proceso, que puede ser su autora.

La salvaguarda cabe en una frase: si aumentan las reversiones o los incidentes, no se ha ahorrado tiempo humano; solo se ha desplazado de la revisión a la reparación. Por tanto, la eficiencia se mide al final del proceso. El equipo sigue las aprobaciones humanas por cambio, el tiempo de espera de una persona y, como freno, las reversiones y los incidentes.

Siete capas de control, cada una detecta lo que dejan pasar las demás

1. Trabajo verificado antes de proponerlo. A Claude se le da una forma de ejecutar lo que escribe, pruebas, compilación, una captura de pantalla para compararla con el diseño, y debe mostrar el resultado en vez de anunciar que ha terminado. Boris Cherny, creador de Claude Code, estima que esto mejora el resultado final entre dos y tres veces. Un segundo agente, que parte de cero, revisa el cambio.
2. Una revisión por agentes en cada cambio. Varios agentes buscan errores en paralelo, otro grupo vota sobre cada hallazgo y solo se publican los que alcanzan consenso. Cada uno debe corregirse o cerrarse con una justificación.
3. Una revisión de seguridad que bloquea. Mientras un hallazgo siga abierto, el cambio no se integra.
4. Comprobaciones automáticas obligatorias. Estilo del código, tipos, pruebas entre plataformas y compilación. El formulario de cada cambio pregunta cómo se ha probado y cómo deshacerlo.
5. Aprobación humana proporcional al riesgo, detallada más abajo.
6. Una cola de integración y después un despliegue gradual. La cola vuelve a ejecutar todas las comprobaciones sobre el código más reciente. La nueva función llega primero a los empleados de Anthropic, detrás de un interruptor que la activa o desactiva.
7. Detección y reversión rápidas. El interruptor desactiva una función sin publicar una versión nueva. Cada semana, el equipo de guardia pregunta qué capa debería haber detectado cada incidente.

Riesgo	Ejemplos	Aprobaciones humanas
Bajo	Documentación, textos, funciones internas, incorporaciones detrás de un interruptor	Ninguna, una vez superadas las comprobaciones automáticas y de seguridad
Medio	Cambios habituales del producto, áreas sensibles (caché, actualizador automático, instrucciones del modelo)	Una persona
Alto	El código de mayor riesgo	Dos personas

Un clasificador asigna el nivel según el propio cambio, no según su autor. Algunos archivos, como los que gobiernan las comprobaciones automáticas, siempre requieren a una persona.

Dos reglas que conviene copiar primero

La primera: la aprobación de un agente nunca cuenta como la de una persona. Una revisión automática puede autorizar un cambio de bajo riesgo; no cubre un puesto que requiere a un ser humano. La segunda: quien solicitó el cambio responde por él, como si hubiera escrito el código personalmente. En un cambio escrito por un agente, la persona que lo dirige cuenta como uno de los revisores requeridos. Además, una aprobación cubre una versión concreta: una incorporación que no haya visto necesita una nueva aprobación.

También se revisa al revisor

El revisor automático mejora mediante un ciclo continuo. Cada incidente pasado se convierte en un caso de prueba, confirmado por un experto, y se evalúa al revisor frente a todos ellos cada día. Surgió un nuevo problema: un agente que escribe y otro que revisa pueden mantenerse ocupados indefinidamente. El revisor señala un error, el agente lo corrige y el revisor encuentra otro. Un cambio pasó por más de 50 rondas durante la noche antes de que una persona lo detuviera manualmente. Ahora, después de tres rondas, el revisor pide al autor que tome distancia y replantee el enfoque.

Medida (Anthropic)	Antes	Después
Cambios que reciben comentarios sustanciales	16%	54%
Cambios aprobados en una sola ronda de revisión	65%	78%
Cambios que requieren cinco rondas o más	8.9%	1.5%
Número medio de revisiones antes de la aprobación	2.08	1.32

Las personas no han desaparecido. Deciden si conviene construir una función, revisan el código arriesgado, facturación, actualizador automático y archivos de control, valoran las decisiones de arquitectura que otros copiarán, leen las pruebas, resultados de los tests, capturas y hallazgos de los revisores, y responden por los resultados.

No es una idea nueva: las máquinas llevan mucho tiempo comprobando máquinas

Nadie comprueba a mano cada paquete que cruza Internet. El protocolo TCP adjunta una suma de comprobación a cada paquete y vuelve a pedir el que llega dañado o no llega. La memoria de un servidor corrige por sí misma un bit alterado mediante códigos de corrección de errores. Una base de datos escribe cada cambio en un registro que reproduce un servidor de reserva, mientras otros procesos lo vigilan. La contabilidad por partida doble, con más de cinco siglos de historia, registra cada transacción dos veces, en el debe y en el haber, de modo que las cuentas deben cuadrar. En 1948, Claude Shannon demostró que un mensaje puede enviarse de forma fiable por un canal con ruido si se añade la redundancia adecuada.

Estos sistemas nunca se hicieron fiables porque una persona inspeccionara cada paso. Se hicieron fiables haciendo que unas máquinas comprobasen a otras, con controles diseñados por personas. El código escrito por agentes se incorpora a esa tradición.

El cuello de botella se ha desplazado

Escribir más rápido desplaza el cuello de botella a la lectura. En 2025, Faros AI analizó datos de más de 10’000 desarrolladores de 1’255 equipos. Los que usaban intensamente la IA integraban un 98% más de pull requests, pero el tiempo de revisión subía un 91%, los errores por desarrollador un 9% y el tamaño medio de los cambios un 154%. El estudio no encuentra una mejora significativa a escala de empresa, ni en el ritmo de entrega ni en la calidad. Faros vende herramientas de medición y mide actividad, no valor entregado: son correlaciones. Aun así, describen el muro con el que chocan los equipos cuando aceleran sin replantear la revisión.

El método de Anthropic presupone una base. El equipo puede aligerar la revisión humana porque allí casi todo es reversible: pruebas que puede ejecutar un agente, interruptores, despliegue gradual y reversión en minutos. Sin eso, revisar menos no es una opción. También reconoce una carencia: aún no tiene un mecanismo que endurezca la aprobación cuando suben las reversiones o los incidentes, y sus ingenieros quieren disponer de uno antes de que más código se integre sin un revisor humano.

Qué extraemos de ello para una organización

• Medir la espera, no las líneas. El volumen de código producido no dice nada sobre la eficiencia. Sí lo dicen el tiempo que un cambio espera a una persona, las aprobaciones por cambio y la tasa de reversión.
• Construir la base antes de abrir el grifo. Pruebas que pueda ejecutar un agente, interruptores, despliegue gradual y reversión rápida. Empezar con rigor y flexibilizar cuando las pruebas lo permitan.
• Convertir cada revisión repetida en una regla, una prueba o una herramienta. Y evaluar al revisor automático cada día frente al peor incidente que haya sufrido la organización: nadie más posee ese caso de prueba.
• Mantener a una persona responsable. En una institución regulada, la pregunta útil es quién aprueba cada cambio y quién responde por él. Es el principio de los cuatro ojos, aplicado a un revisor que nunca duerme.

Todos pueden comprar acceso a los mismos modelos. Lo que distingue a las organizaciones es reconstruir el proceso alrededor de ellos y mantener a las personas donde el criterio, la confianza y la responsabilidad no pueden delegarse.