Claude se aceleró a sí mismo tres veces en dos semanas: dentro del sprint de Anthropic

En agosto, Anthropic hizo la experiencia central del sitio claude.ai y de la aplicación de escritorio Claude unas tres veces más rápida en un solo impulso de dos semanas. Los usuarios llevaban mucho tiempo quejándose de la lentitud, y el equipo lo reconoció abiertamente antes de ponerse manos a la obra. Según la publicación oficial de ingeniería en claude.dev, se desplegaron más de 3.000 cambios sin ningún incidente visible. Lo que más me sorprendió es que todo el esfuerzo se dirigió desde un único canal de Slack, con un modelo de guardia en cada hilo.

Por dónde empezar

El equipo empezó analizando los datos de uso y se concentró en cuatro recorridos que cubren el 95 por ciento de la actividad: abrir la aplicación, iniciar una conversación, cargar una conversación existente y enviar un mensaje. Repartidos entre web, escritorio y productos, esos recorridos se convirtieron en trece mediciones distintas. En el percentil 75, el tiempo hasta una página escribible tras una carga fresca pasó de 3,1 segundos a 0,55, abrir una nueva sesión de código bajó de 0,8 a 0,3 segundos y cargar una sesión en la nube de 2,6 a 0,73 segundos. En total, el equipo estima en decenas de miles las horas de espera eliminadas cada día.

El sprint arrancó con una veintena de proyectos elegidos a mano, y el modelo había estimado por adelantado su impacto en milisegundos. Al tercer día, doce de trece objetivos ya estaban cumplidos. Para acelerar los arranques, el redactor se integró directamente en el HTML de la página para que el usuario pudiera escribir mientras React aún iniciaba. Se preparó una caché de código V8 precompilada para el proceso principal del escritorio, el redactor quedó montado entre conversaciones, las sesiones sobrevoladas se precargaron y los repintados inútiles de la barra lateral se redujeron un 90 por ciento.

Todo lo medible puede mejorar

La filosofía del sprint cabe en una frase: en cuanto el modelo puede medir algo, puede acelerarlo. Antes, medir era el paso cero: añadir un contador, esperar datos y luego entender el problema. Aquí la medición se convirtió en el primer paso de la escalada, y el trabajo de mayor impacto del equipo pasó a ser encontrar nuevos números que escalar. Un ingeniero llamado Sam propuso contar instrucciones JavaScript en vez del tiempo de reloj, y en once minutos se abrieron cinco frentes de medición. Este relato se detalla en la publicación oficial de claude.dev, lo que muestra que el método es reproducible.

El tiempo de reloj es ruidoso e inservible como cerrojo de integración, así que el equipo construyó una escalera de contadores deterministas : instrucciones vía Valgrind para rutas JavaScript puras, más validaciones React, llamadas V8, recálculos de estilo y mutaciones del DOM para rutas de navegador. Cada nueva medición tenía dos misiones: dar un número que mover en el laboratorio y servir de techo que solo puede bajar. Toda medición incapaz de probar su correlación con el tiempo real se descartaba sin piedad. Según el resumen publicado en iphoneincanada.ca, esta disciplina fue la garantía central de un despliegue tranquilo.

El experimento de validación corrió sobre dos rutas calientes: la rutina que ensambla el árbol de mensajes de una conversación y el analizador de líneas de estado del código. El perfilado mostró que un cuarto de las instrucciones de la primera ruta venía de búsquedas de diccionario que resolvían tres veces el mismo identificador. Una hora después, los contadores habían bajado 48 y 31 por ciento mientras el tiempo real caía 78 y 44 por ciento. Dos nuevos cerrojos aterrizaron en la integración continua, con una tarea diaria que baja cada techo. Como señala el análisis en analyticsindiamag.com, tales cerrojos son la herramienta más práctica contra la erosión de avances.

Ciento cincuenta hilos en paralelo

El sprint pronto se estabilizó en un ciclo: alguien abre un hilo con la grabación de un momento lento, el modelo traza el flujo y construye una medición que lo demuestra, vuelve con unas solicitudes del tamaño del riesgo en cuanto el laboratorio promete, vigila el despliegue y lee los datos de campo, y luego ajusta el cerrojo ante un avance o apaga la bandera e itera ante un fallo. Más de 150 hilos corrían a la vez, y cerca de un tercio de las solicitudes traía telemetría o protecciones extra. En la evaluación publicada en fourweekmba.com, entregar más de 3.000 cambios sin incidentes se presenta como la mejor prueba de esta disciplina.

Mi caso favorito fue la caza del temblor de la barra lateral. Las filas aparecían en momentos distintos tras la carga y la página se veía inestable, sin que ningún monitor existente lo detectara. Un ingeniero llamado Issac sugirió mirar directamente la interfaz de inestabilidad de diseño del navegador, y el modelo produjo un evento de telemetría que ligaba cada salto a una región y fase con nombre. La prueba fallaba 20 de 20 veces en la rama principal y pasaba 20 de 20 con la corrección. Los datos de campo mostraron que el 31 por ciento de las cargas movía algo tras el pintado útil, y los culpables se limpiaron uno por uno.

Los hilos se dejaban abiertos en vez de cerrarse, y un solo hilo producía a veces cincuenta o cien solicitudes de optimización. Cada vez más era el propio modelo quien abría hilos nuevos. Shelley, ingeniera del equipo, llamó al modelo demonio de los números. Encontró 6.900 ganchos React y 900 suscripciones que se redibujaban con cada tecla en la ruta de escritura. Mostró un selector raíz que añadía 24 milisegundos a cada cambio del DOM, un comando olvidado que causaba medio millón de recargas ocultas al día y copias de caché duplicadas dos veces por minuto. Según el reporte en ciol.com, estos hallazgos figuran entre los ejemplos más llamativos.

Una de las correcciones más elegantes vino de un guion largo. Resaltar un bloque de código terminado congelaba la página cerca de un segundo, y el culpable era un único carácter no Latin-1 en la respuesta. V8 guarda tales cadenas en UTF-16, lo que pasaba cada regla de resaltado a la vía lenta de dos bytes. La corrección cupo en veinte líneas que copian cada bloque a una cadena de un byte antes de resaltarlo. Como subraya el resumen en lavx.hu, hallazgos pequeños y profundos como este serían imposibles sin medición de laboratorio.

Sin velocidad no hay protecciones

Como casi todas las rutas calientes se tocaban, la seguridad se construyó por adelantado: cada solicitud pasaba revisión automatizada con al menos una aprobación humana, las pruebas precedían a las optimizaciones y todo lo visible viajaba tras una bandera efímera. Se abrieron unas doscientas banderas en dos semanas y más de la mitad se limpió antes del final. El redactor estático era especialmente frágil; el verdadero componente React se renderizaba en un documento virtual y la deriva se probaba en catorce tamaños de pantalla al píxel, mientras una prueba de tecleo no perdonaba ni un carácter.

La caza más divertida empezó con una grabación cuatro horas después del lanzamiento interno. El redactor caía unos 10 píxeles al abrir la página en una pestaña nueva. El modelo halló la causa en el comportamiento de Chrome y no en el código: en navegadores gestionados, la página de pestaña nueva lleva un pie de 56 píxeles, escribir en la barra de direcciones pre-renderiza la página a la altura corta en segundo plano y la página crece unos 100 milisegundos tras el primer pintado. El modelo fijó el diseño y añadió una prueba que imita el pre-renderizado. Este caso se cuenta en la publicación oficial de claude.dev como el mejor ejemplo del puente entre laboratorio y campo.

El trabajo de los humanos: ambición, gusto, rumbo

El ciclo era productivo pero no autónomo, y los humanos tenían tres misiones. La primera era la ambición: el modelo tendía a estrechar el alcance y a inflar estimaciones, así que el equipo lo empujó a más audacia apoyándose en las protecciones. La segunda era el gusto: cada cambio visible llegaba con grabaciones de antes y después, y los humanos decidían opciones como la aparición inmediata o diferida de una pantalla esqueleto. La tercera era el rumbo: cada hilo se mantenía deliberadamente estrecho, y la charla cubría las superficies prioritarias, la fusión de hilos en colisión y el cierre de hilos con rendimiento decreciente. Una solicitud de 900 líneas se rechazó en una frase, demasiado compleja para 2 milisegundos por envío.

Una misión secundaria se hizo legendaria con su regla de 8 milisegundos. Se añadió un indicador de cuadros a una larga respuesta en flujo con meta de 120 Hz: 8,33 milisegundos por cuadro. Gracias al control de cuadros de las herramientas de desarrollo en un navegador sin cabeza, el modelo logró exactamente 240 inicios para 240 cuadros y recorrió la respuesta cuadro por cuadro. El trabajo dependiente de la longitud desapareció vía resultados memoizados , la segmentación de cercas de código migró a un trabajador y las tablas se revelaron celda por celda. Cerca de sesenta solicitudes aterrizaron en un solo hilo, la carga del hilo principal bajó de 750 a 200 milisegundos y un portátil de 120 Hz sostuvo la cadencia plena de principio a fin.

Cuando los proyectos planeados terminaron antes, el equipo pidió explícitamente al modelo ideas descabelladas y la escalada entró en nueva ronda. El autor valida ese llamado con su experiencia: una invitación parecida lo llevó a crear un entorno de ejecución a medida con una ganancia de dos a cuatro veces. Como nota el análisis en fourweekmba.com, esta segunda ola superó ampliamente los objetivos iniciales y trajo el verdadero salto del sprint. La lección es clara: cuando se cumplen las metas, busquen cosas nuevas que medir en vez de detenerse.

A través de la mirada del autor

El creador del vídeo aborda el proceso con cautela, él que lleva años criticando la calidad de ingeniería de Anthropic, y pone el artículo en paralelo con la campaña de rendimiento de su propio producto. El caché local, la barra lateral instantánea y el retardo de su selector de modelo resuenan sin cesar con el texto. Su lección central: enseñen primero al modelo a medir en vez de pedirle que corrija. El segmento patrocinado del medio, que presenta un estándar de inicio de sesión usable por agentes en nombre del usuario, se despacha en una sola frase.

Las réplicas del sprint también subieron corriente arriba, con contribuciones hacia Electron, Chromium y Node. El escritorio y la web son hoy unas tres veces más rápidos que a principios de agosto, con cerrojos que guardan el nivel. Pero el equipo afirma que el trabajo no terminó: el percentil 95, otros recorridos y las conversaciones larguísimas aún tienen margen. Como también nota el reporte en iphoneincanada.ca, los usuarios empiezan a sentir la aceleración a diario. El canal sigue abierto y el equipo planea seguir hilo por hilo.