Lo más aprovechable del nuevo artículo de ingeniería de Anthropic no es que claude.ai se haya vuelto unas tres veces más rápido en quince días. Es el dispositivo que el equipo dejó instalado: una barrera en la integración continua basada en el recuento de instrucciones de CPU, un número que solo puede bajar y que convierte cada futura solicitud de incorporación de cambios en una prueba de rendimiento.
Claves del sprint
- En el percentil 75, una carga nueva de claude.ai llegó a una página en la que ya se podía escribir en 0,55 segundos, frente a los 3,1 anteriores; una sesión nueva de Claude Code pasó de 0,8 a 0,3 segundos.
- Se fusionaron más de tres mil cambios en dos semanas sin un solo incidente visible para los clientes ni una reversión.
- En dos rutas críticas el recuento de instrucciones cayó un 48% y un 31%, lo que se tradujo en reducciones de tiempo real del 78% y el 44%: la prueba que permitió al equipo condicionar la CI a los recuentos en lugar de a las mediciones de tiempo.
Por qué recuentos de instrucciones y no cronómetros
Lo que el usuario siente es la latencia, pero una lectura en milisegundos es demasiado ruidosa para tumbar una compilación. La salida de Anthropic fue buscar números deterministas en vez de representativos y demostrar, antes de fiarse de cada uno, que seguía de cerca la latencia real.
La demostración se hizo sobre la rutina que arma el árbol de mensajes de una conversación. El perfilado con Valgrind mostró que una cuarta parte de sus instrucciones eran búsquedas megamórficas en diccionarios que resolvían tres veces el mismo identificador de mensaje. Corregir eso, junto con un escáner de la línea de estado en la salida de Claude Code, redujo las instrucciones un 48% y un 31%. El tiempo real en esas mismas rutas bajó un 78% y un 44%. Solo entonces los recuentos se convirtieron en techos permanentes dentro de la CI, con una tarea nocturna que baja cada techo cada vez que una compilación queda por debajo.
La disciplina alrededor de ese mecanismo pesó tanto como el mecanismo mismo. Toda prueba comparativa que resultaba inestable, o que se movía sin mover la latencia del usuario, se eliminaba en lugar de tolerarse: de lo contrario el modelo escala una colina que nadie quería escalar. Los recuentos de confirmaciones de React, las llamadas de cobertura de V8, los recálculos de estilos y las mutaciones del DOM pasaron por la misma audición.
Contra qué se mide ese triple
El alcance quedó fijado antes de publicar nada. Claude leyó la telemetría de uso a través de un servidor MCP de Datadog y escogió cuatro recorridos que concentraban el 95% de la actividad: abrir la aplicación, iniciar una conversación, abrir una antigua y enviar un mensaje. De ahí salieron trece mediciones instrumentadas entre web y escritorio, cada una delimitada por una interacción del usuario al principio y un renderizado al final.
Doce de los trece objetivos estaban cumplidos al tercer día. Las victorias fueron poco vistosas: un cuadro de redacción estático incrustado en el HTML para poder escribir mientras React se inicializa, una caché de código V8 precompilada para que el contenedor de escritorio se ahorre una recompilación, un cuadro de redacción que permanece montado entre conversaciones, precarga de sesiones al pasar el ratón y un recorte del 90% en los repintados de la barra lateral. Anthropic cifra el ahorro conjunto en decenas de miles de horas de espera de usuario al día.
Los fallos que solo se veían contando
Lo que vino después se parece menos a una lista de tareas de rendimiento que a una auditoría de cosas que ningún panel estaba vigilando. Un censo de hooks encontró 6.900 que repintaban el cuadro de redacción con cada pulsación de tecla. Un único selector :root:has() cobraba 24 milisegundos a cada cambio del DOM. Un location.reload() olvidado se disparaba medio millón de veces al día sin aparecer en ninguna métrica de carga. Instantáneas idénticas de caché se clonaban en IndexedDB dos veces por minuto en el hilo principal.
El caso más extraño fue un bloqueo de un segundo en los bloques de código ya terminados, cuyo rastro llevaba a las rayas largas. Un solo carácter fuera de Latin-1 obliga a V8 a mantener toda la cadena como UTF-16, lo que arroja cada expresión regular del resaltado de sintaxis a una ruta más lenta de dos bytes. Veinte líneas que primero copian el bloque a una cadena de un byte hicieron desaparecer el problema.
El desplazamiento de diseño lo ilustra de forma más directa. Cada salto de la barra lateral puntuaba unos 0,008 en Cumulative Layout Shift, muy por debajo del umbral de 0,1 que marca una página como buena: la métrica estándar decía que no pasaba nada. Leer en crudo la Layout Instability API y etiquetar los desplazamientos por zona de la página reveló que en el 31% de las cargas web algo se movía cuando la página ya era usable.
Cero reversiones es la cifra más difícil
Tres mil fusiones en dos semanas es una afirmación sobre capacidad de producción. Ningún incidente y ninguna reversión, en rutas tan expuestas como el primer pintado y el cuadro de redacción, es una afirmación sobre el proceso, y es la que conviene copiar.
El montaje era convencional pieza a pieza: revisión automatizada más al menos una aprobación humana en cada solicitud de cambios, pruebas unitarias escritas antes que la optimización que protegen, todo lo visible para el usuario detrás de una bandera de vida corta y despliegue por etapas desde los empleados al 1% de los usuarios y de ahí a todos. Lo poco convencional fue el volumen: cerca de doscientas banderas abiertas y más de la mitad retiradas dentro de esas dos semanas, con aproximadamente un tercio de todas las solicitudes de cambios llevando telemetría o salvaguardas nuevas en lugar de correcciones. La instrumentación se trató como parte del cambio, no como un ticket posterior.
Por qué importa
Medir solía ser el paso cero: publicar una métrica, esperar datos y solo entonces empezar a entender el problema. Con un agente capaz de optimizar contra cualquier número que se le entregue, medir pasa a ser el primer paso del ascenso, y el recurso escaso se desplaza a decidir qué merece un número. Es la misma inversión que se ve en otros trabajos de ingeniería con fuerte presencia de agentes, desde una reescritura en Rust de 832.000 líneas hasta Perplexity, que dejó los permisos de despliegue en manos humanas mientras los agentes escribían el código.
Anthropic evita vender la idea de más. Su propio texto señala que el ciclo fue productivo pero no autónomo: los objetivos, las concesiones y las aprobaciones siguieron siendo humanos, y una tarea permanente consistió en empujar al modelo a ser menos conservador con el alcance de lo que es por defecto. La implicación incómoda para quien lea esto como plantilla es que el cuello de botella se traslada a la capacidad de revisión y al criterio sobre qué merece medirse, y ninguna de las dos cosas crece con más agentes.
FAQ — Preguntas frecuentes
¿Qué modelo ejecutó el sprint?
Anthropic afirma que usó Claude Tag en fase beta, con un modelo interno de investigación que describe como aproximadamente comparable a Opus 5.5. Todo el trabajo se coordinó dentro de un único canal compartido de Slack y no con una herramienta dedicada.
¿Revisaron los cambios personas?
Sí. Cada solicitud de incorporación de cambios pasó por una revisión automatizada y exigió al menos una aprobación humana, y lo visible para el usuario salió detrás de banderas de funcionalidad con despliegues incrementales a empleados, luego al 1% de los usuarios y después a todos.
¿Puede un equipo copiar esto sin un modelo interno?
El mecanismo no depende del modelo: basta con demostrar que una métrica determinista se correlaciona con la latencia y después apretarla en la CI. Lo que no se copia es el volumen: tres mil fusiones en dos semanas dan por supuestas una capacidad de revisión y una instrumentación que la mayoría de los equipos tendría que construir antes.
