Anthropic dice que un sprint de dos semanas en agosto hizo unas tres veces más rápidas las tareas principales en claude.ai y la aplicación de escritorio de Claude. Su artículo de ingeniería, publicado el 23 de septiembre, ofrece una respuesta más útil que la cifra del titular por sí sola: muestra qué acciones se aceleraron, cómo comprobó el equipo sus mediciones y en qué decisiones y lanzamientos los ingenieros siguieron siendo responsables.

El gran cambio

  • Qué cambió: Anthropic informa de esperas más cortas en 13 mediciones de acciones habituales en la web y en el escritorio. La cifra de 3,1 veces es la media geométrica de esas mejoras, medida en el percentil 75 los días 13 y 27 de agosto. Es un resultado de la empresa para una selección de recorridos.
  • Por qué importa: Para quienes usan Claude, que una página nueva esté lista para escribir en 550 milisegundos en vez de 3.085 cambia una parte repetida del uso del producto. Para los equipos de ingeniería, este caso muestra a un asistente de IA trabajando en problemas de rendimiento medidos, mientras las personas eligen las prioridades y aprueban los cambios.
  • Qué observar: Anthropic dice que aún debe mejorar el percentil 95, otros recorridos y las conversaciones muy largas. Esas mediciones mostrarán si las mejoras que comunica se extienden más allá de las acciones seleccionadas y de la comparación de agosto.

Qué ganaron los usuarios

Anthropic identificó cuatro recorridos que, según la empresa, representan el 95 % de la actividad de los usuarios: abrir la aplicación, iniciar una conversación, cargar una conversación y enviar un mensaje. En la web, el escritorio y sus productos, estos se convirtieron en 13 mediciones. Cada una comenzaba con una acción del usuario y terminaba cuando se mostraba el resultado; el trabajo del cliente y del servidor se midió por separado.

En una carga nueva de claude.ai en la web, el tiempo hasta que la página estuvo lista para escribir en el percentil 75 bajó de 3.085 a 550 milisegundos: una aceleración de 5,6 veces. El inicio en frío de la aplicación de escritorio bajó de 6.310 a 3.328 milisegundos, o 1,9 veces. Cargar en el escritorio una sesión en la nube de Claude Cowork bajó de 2.566 a 728 milisegundos, o 3,5 veces. La parte del cliente al enviar un mensaje de chat en la web bajó de 180 a 59 milisegundos, o 3,1 veces. Son acciones y plataformas distintas; la cifra global de 3,1 veces es la media geométrica de las 13 proporciones, no el resultado de una sola tarea.

La comparación utiliza la monitorización de usuarios reales de Anthropic en el percentil 75, los días 13 y 27 de agosto. La publicación no incluye una auditoría independiente, resultados en el percentil 95 para estos recorridos ni una estimación controlada de cuánto contribuyó la ayuda de Claude a las mejoras. Anthropic estima que las acciones más rápidas ahorran a diario decenas de miles de horas de espera de los usuarios, pero no muestra el cálculo de esa estimación.

El ciclo de medición detrás de los cambios

El equipo comenzó con unos 20 proyectos seleccionados por los ingenieros. Anthropic dice que utilizó Claude Tag, un agente beta que ejecuta un modelo interno de investigación aproximadamente comparable a Opus 5.5, para detectar cuellos de botella, crear pruebas de referencia y proponer cambios. Según el equipo, alcanzó 12 de sus 13 objetivos iniciales para el tercer día; luego fijó nuevos objetivos y buscó problemas que sus monitores existentes no detectaban.

Un ejemplo comenzó con una grabación de las filas de la barra lateral que se movían después de cargar una página. La medida existente de cambio acumulativo de diseño no hacía destacar el problema. Un ingeniero propuso usar la API subyacente de inestabilidad del diseño. Claude añadió entonces telemetría para identificar la zona afectada de la página y una prueba de integración que retrasaba los datos de la barra lateral. Anthropic informa de que la prueba falló en las 20 ejecuciones del código original y pasó en las 20 del arreglo propuesto. Tras desplegar la telemetría, la empresa dice que detectó movimientos después de que la página ya se pudiera usar en el 31 % de las cargas web. Es un ejemplo documentado del sprint de Anthropic, no una medición reproducida por BIG CHANGE.

El equipo también utilizó mediciones de laboratorio para acelerar el ciclo entre lanzamientos. En dos rutas de ejecución intensiva de JavaScript, comparó el recuento determinista de instrucciones con el tiempo transcurrido usando las mismas pruebas de referencia. Anthropic informa de que las reducciones del 48 % y el 31 % en el recuento de instrucciones coincidieron con descensos del tiempo de ejecución del 78 % y el 44 %. El equipo convirtió esos recuentos en límites de integración continua y luego redujo los límites a medida que mejoraba el rendimiento. Dice que descartó las pruebas de referencia poco fiables o que no seguían la latencia percibida por los usuarios. La distinción importa: un contador de laboratorio orientó los cambios y las mediciones de usuarios reales comprobaron si el trabajo publicado ayudaba.

Dónde mantuvieron el control las personas

Anthropic describe un canal de Slack con muchos hilos acotados, cada uno centrado en un recorrido o una prueba de referencia. Claude rastreaba un problema, proponía una prueba de referencia y solicitudes de cambio, supervisaba los despliegues y leía datos de campo. Los ingenieros fijaban los objetivos, decidían qué compromisos visibles para los usuarios eran aceptables y aprobaban cada cambio. Cada hilo tenía una persona responsable identificada. Se rechazó una propuesta de 900 líneas porque los ingenieros consideraron que ahorrar dos milisegundos por mensaje no compensaba el coste de mantenimiento.

El proceso de lanzamiento incluía varias comprobaciones. Anthropic dice que cada solicitud de cambio recibió una revisión automatizada y al menos una aprobación humana, y que se ejecutaron pruebas unitarias antes de las optimizaciones. Los cambios visibles para los usuarios se ocultaron tras indicadores de funcionalidad de corta duración. Los cambios de mayor riesgo llegaron primero a los empleados, luego al 1 % de los usuarios y después a todo el mundo. Durante el sprint, el equipo introdujo casi 200 indicadores y afirma que retiró más de la mitad antes de que terminara. Anthropic informa de que integró más de 3.000 cambios sin incidentes visibles para los clientes ni reversiones. Ese resultado corresponde al relato de la empresa sobre este sprint; no demuestra que otro equipo o base de código obtendría lo mismo.

El compositor estático muestra por qué importaban los controles. Anthropic colocó un compositor listo para escribir en el HTML inicial mientras se cargaba React. Para comprobar la transición, sus pruebas compararon las versiones estática y React en 14 tamaños de pantalla, verificaron la alineación con un margen de un píxel y permitieron escribir durante la transición para detectar teclas perdidas o reordenadas. La telemetría de campo midió los movimientos durante el cambio. Más tarde, un empleado detectó un desplazamiento del diseño al abrir una pestaña nueva que esas mediciones no habían detectado; Anthropic lo atribuyó al cambio de tamaño del navegador durante la carga especulativa y añadió una prueba para ese caso.

El informe de Anthropic respalda una conclusión concreta: sus ingenieros usaron Claude para buscar y mejorar cuellos de botella medidos dentro de un proceso de lanzamiento dirigido por personas, y algunos recorridos de usuarios seleccionados eran más rápidos al terminar agosto. Queda por saber cómo funciona el producto en la franja más lenta, cuánto durarán las mejoras y qué parte del resultado atribuiría un observador independiente al agente, frente a la instrumentación, la ingeniería y las decisiones de lanzamiento del equipo.