Anthropic dice que hizo que la experiencia principal de claude.ai y de la aplicación de escritorio de Claude fuera unas tres veces más rápida en dos semanas. La empresa se centró en cuatro recorridos que, según afirma, representan el 95 % de la actividad: iniciar la aplicación, comenzar una conversación, cargar una conversación existente y enviar un mensaje. En el percentil 75 —el punto en el que tres cuartas partes de las cargas medidas se sitúan en o por debajo de un tiempo determinado—, una página nueva de claude.ai pasó a estar lista para escribir en 0,55 segundos, en lugar de 3,1 segundos. Según se informó, una sesión nueva de Claude Code bajó de 0,8 segundos a 0,3 segundos.
El resultado de escritura en 0,55 segundos del párrafo se ilustra con una carga de página nueva antes y después.
La idea central fue convertir la espera en números que Claude pudiera mejorar. Los ingenieros trabajaron con Claude Tag, el asistente beta de Anthropic para Slack que lee hilos y actúa según instrucciones permanentes, en un único canal. Claude rastreó pasos lentos, creó o encontró pruebas de rendimiento, propuso solicitudes de cambios, supervisó despliegues y revisó datos de uso real. Si un cambio funcionaba, se reducía el límite de la prueba; si no funcionaba, una marca de función podía desactivarlo. El artículo dice que se fusionaron más de 3.000 cambios sin ningún incidente visible para los clientes ni ninguna reversión.
El método también abordó problemas que los paneles habituales pueden pasar por alto. Para la falta de fluidez de la barra lateral, Claude relacionó los cambios de diseño con regiones y fases con nombre, y luego usó una prueba que fallaba cuando los datos retrasados movían la página después de que esta ya era usable. La prueba falló en 20 de 20 ejecuciones en la rama principal y pasó 20 de 20 veces en el cambio propuesto. En otra ruta, los recuentos de instrucciones de Valgrind disminuyeron un 48 % y un 31 %, mientras que el tiempo de pared informado cayó un 78 % y un 44 %. Esos resultados emparejados muestran por qué el equipo quería métricas deterministas, pero también por qué exigía una correlación con la latencia real.
Esto demuestra directamente la prueba de falta de fluidez de la barra lateral descrita en el párrafo, en la que se eliminaron los cambios de diseño tardíos.
La contrapartida es que una optimización agresiva puede recompensar atajos. Anthropic dice que rechazó pruebas inestables, exigió aprobación humana para cada solicitud de cambios, puso las pruebas unitarias antes que las optimizaciones y usó marcas de función de corta duración para los cambios visibles para los usuarios. Aun así, el artículo es un estudio de caso de primera parte: las mediciones, el número de incidentes y el ahorro diario de tiempo estimado proceden del sprint de la propia Anthropic, no de una auditoría independiente. El material suministrado no demuestra cómo se mantuvieron las mejoras más allá de ese período de dos semanas.