Cómo hacer que Claude responda más rápido

Anthropic ha hecho claude.ai y la app de escritorio de Claude unas 3 veces más rápidas en un sprint de dos semanas. Lo hicieron con un canal de Slack, Claude Tag metido en cada hilo y una regla muy simple: todo lo que se puede medir, Claude lo puede mejorar. Fusionaron más de 3.000 cambios sin un solo incidente de cara al cliente ni un rollback, según cuenta el propio equipo en su post de ingeniería.

Los usuarios llevaban tiempo quejándose de que claude.ai iba lento.

Tenían razón.

Que una empresa de IA use su IA para arreglar su web no sorprende a nadie (faltaría más). Lo que merece la pena copiar es el método: cómo convirtieron el rendimiento, que es un problema difuso y ruidoso, en una colección de números que Claude podía bajar uno a uno sin romper nada. Ese método lo puedes aplicar mañana en tu proyecto, aunque no tengas ni Slack ni un equipo de veinte personas.

En este post vas a encontrar:

• Las cifras reales del sprint, recorrido por recorrido
• Las instrucciones permanentes que le dieron a Claude y cómo escribir las tuyas
• Por qué contar instrucciones de CPU funciona mejor que medir milisegundos
• El bucle de seis pasos que repitieron en más de 150 hilos a la vez, con un diagrama
• Los guardarraíles que evitaron el desastre con 200 cambios al día
• Prompts sencillos en español para montar tu propio bucle con Claude Code o Claude Tag

¿Cuánto más rápido es claude.ai después del sprint? ¶

La respuesta corta: 3,1 veces más rápido de media (media geométrica de 13 mediciones), comparando el 13 de agosto con el 27 de agosto de 2026, en el percentil 75 de usuarios reales.

El equipo eligió cuatro recorridos que suman el 95% de la actividad de los usuarios: abrir la app, empezar una conversación, cargar una conversación existente y enviar un mensaje. Entre web y escritorio, y entre Chat, Claude Code y Cowork, eso dio trece mediciones distintas. Algunas de las más llamativas:

Y aquí va la tabla completa, para quien quiera los trece números:

Anthropic calcula que, sumado, eso ahorra decenas de miles de horas de espera al día a sus usuarios. Tres segundos por carga no parecen gran cosa hasta que los multiplicas por millones de pestañas.

🔑 El dato que más me gusta: doce de los trece objetivos del sprint estaban cumplidos al tercer día. El resto del tiempo lo dedicaron a subir el listón y buscar cosas nuevas que medir.

Claude Tag: Claude trabajando dentro de Slack ¶

Claude Tag es Claude trabajando dentro de tu Slack. Lo mencionas con @Claude en un canal o en un hilo, le encargas una tarea y la ejecuta en ese mismo hilo, en la nube, aunque cierres Slack. Según la documentación oficial de Claude Tag, está en beta pública para los planes Team y Enterprise, y Microsoft Teams está anunciado como “próximamente”.

Durante el sprint, Claude Tag ejecutaba un modelo interno de investigación que Anthropic describe como “más o menos comparable a Opus 5.5”. Si quieres saber qué da de sí ese modelo por su cuenta, tienes el análisis de Claude Opus 5.5 frente a GPT-6 Astra.

¿Por qué Slack y no una terminal? Por tres razones que se ven a lo largo del sprint:

1. Todo pasa a la vista. Cualquier ingeniero puede entrar en un hilo ajeno, corregir el rumbo o celebrar una mejora.
2. Los hilos escalan en horizontal. Abrir un hilo nuevo cuesta una frase. Llegaron a tener más de 150 en paralelo.
3. Las conexiones son del canal. Un admin conecta GitHub, Datadog o lo que haga falta, y cualquiera que pregunte en ese canal tiene el mismo acceso.

La propia guía de buenos hábitos de Claude Tag lo resume con una idea que el equipo de rendimiento aplicó al pie de la letra: “dale a Claude el destino, no la ruta”.

Las instrucciones permanentes del canal ¶

Antes de empezar, crearon un canal y le dejaron a Claude unas instrucciones permanentes (standing instructions). Esta es mi traducción del fragmento que publicaron:

@Claude Tu trabajo es facilitar todo lo relacionado con el rendimiento de la web de claude.ai y de la app de escritorio. Tus responsabilidades incluyen vigilar los despliegues en busca de regresiones de rendimiento, evaluar la precisión y la cobertura de la telemetría existente, mantener paneles de observabilidad bien cuidados, implementar de forma proactiva soluciones para los problemas observados y las mejoras fáciles, proponer proyectos de rendimiento y comunicarte con tus compañeros humanos. […] El objetivo final de este canal es que llegues a ser tan autónomo como sea posible, pero hoy sabemos que eso todavía no es posible.

Fíjate en la última frase. Le dicen a dónde van, y también le dicen que todavía no ha llegado.

En Claude Tag, una instrucción permanente se guarda en la memoria del canal y aplica a todos los hilos. Para dejar la tuya basta con pedirlo así:

@Claude recuerda para este canal: respuestas cortas, y enlaza siempre la fuente de cada dato.

Y para comprobar qué se ha quedado grabado:

@Claude ¿qué recuerdas de este canal?

Si no usas Slack, el equivalente en Claude Code es tu CLAUDE.md: el fichero de instrucciones que se carga en cada sesión del proyecto. Una versión mínima para un proyecto propio podría ser esta:

## Rendimiento

- Antes de optimizar nada, escribe o localiza un benchmark que reproduzca el problema.
- Cada PR de rendimiento incluye la cifra de antes y la de después.
- Los tests unitarios van antes que la optimización, nunca después.
- Cualquier cambio visible para el usuario va detrás de un feature flag.

Guía interactiva gratis

Tu CLAUDE.md es el canal de instrucciones de tu proyecto

En el curso gratis hay una parada entera para el fichero de instrucciones (CLAUDE.md, agents.md y /init) y otra para verificar lo que hace el agente. Sales con tu primer proyecto con IA montado paso a paso.

Entra en el curso gratis →

Primero los datos: cómo elegir qué optimizar ¶

Empezaron por los datos, no por las intuiciones. Le pidieron a Claude que analizara el uso real a través del servidor MCP de Datadog y fue Claude quien identificó los cuatro recorridos de mayor impacto.

Luego vino la parte aburrida y decisiva: instrumentar hasta que las trece mediciones fueran comparables. Cada una empezaba con una interacción del usuario, terminaba cuando el resultado estaba pintado en pantalla y separaba el trabajo del cliente del trabajo del servidor.

Con esa base arrancaron con una lista de unos veinte proyectos elegidos a mano. Claude estimó el impacto de cada uno en milisegundos y sumaron esas estimaciones para fijar los objetivos del sprint. Los primeros cambios que aterrizaron:

• Un compositor estático metido en el HTML, para que el usuario pueda escribir mientras React todavía se está inicializando.
• Una caché de código V8 precompilada, para que el proceso principal de la app de escritorio no recompile desde cero en cada arranque.
• El compositor montado entre conversaciones, en vez de destruirlo y crearlo de nuevo.
• Precarga de sesiones al pasar el ratón por encima de ellas en la barra lateral.
• Un 90% menos de re-renderizados en la barra lateral.

Ninguna de esas técnicas es nueva. Lo nuevo es la velocidad a la que llegaron a producción. Y como los objetivos se quedaron cortos enseguida, alguien escribió en el canal algo que me parece la mejor instrucción de todo el sprint:

@Claude hemos financiado casi todos los proyectos de la lista original y más. Vamos a hacer un repaso […] ¿qué no hemos explorado, en qué podemos hacer hill climbing, dónde está la mayor oportunidad ahora? […] estoy abierto a ideas LOCAS

Traducido a tu día a día, un prompt de arranque para tu proyecto podría ser así de sencillo:

Analiza los datos de rendimiento que tienes a mano y dime cuáles son los tres
recorridos de usuario más lentos de la app. Para cada uno, propón dos mejoras
y estima cuántos milisegundos ahorraría cada una.

¿Qué es el hill climbing y por qué necesita benchmarks deterministas? ¶

Hill climbing es optimizar a base de pasos pequeños: cambias algo, mides, y si el número mejora te quedas con el cambio. Subes la colina a tientas, pero siempre hacia arriba. Funciona de maravilla con un agente de IA, con una condición: el número tiene que ser fiable.

Y ahí está el problema del rendimiento web. El tiempo de reloj (wall-clock) es lo que siente el usuario, pero es muy ruidoso. Los milisegundos bailan de una ejecución a otra según la carga de la máquina, así que no sirven como puerta en CI: tendrías tests que fallan un martes sí y otro no.

El equipo quería iterar más rápido que su ritmo de despliegues. Claude podía trabajar durante horas, incluso de noche, y necesitaba validar sus prototipos sin esperar a los datos de producción. Hacía falta medir en el laboratorio.

Sam, uno de los ingenieros, dio con la primera pista:

¿Qué podemos usar en lugar del tiempo de reloj? ¿Podemos medir el número de instrucciones de JS, por ejemplo?

La respuesta de Claude fue una escalera de métricas deterministas:

• Para rutas calientes de JavaScript puro, número literal de instrucciones de CPU: ejecutar el benchmark bajo Valgrind con node --predictable y comparar con una línea base guardada en el repo. Una ejecución, sin estadística.
• Para rutas de navegador, donde Chromium no permite contar instrucciones: commits de React por interacción, número de llamadas a funciones según la cobertura precisa de V8, número de recálculos de layout y de estilos, y mutaciones del DOM.

Once minutos después había cinco hilos abiertos, uno por cada métrica.

💡 Una métrica determinista es aquella que da el mismo número en cada ejecución con el mismo código. Si cambia, es porque has cambiado algo. Eso la convierte en una puerta de CI que no miente.

¿Contar instrucciones sirve de algo si el usuario siente milisegundos? ¶

Esa era justo la duda del equipo, y no se la tragaron sin pruebas. Le pidieron a Claude que lo demostrara:

@Claude demuestra que hacer hill climbing contra cada una de estas métricas produce mejoras medibles en tiempo de reloj. Quitaremos los benchmarks de cualquier candidata que no lo demuestre

Claude eligió dos rutas calientes: la rutina que monta el árbol de mensajes de una conversación y un escáner de líneas de estado en la salida de Claude Code. Al perfilar la primera con Valgrind encontró que una cuarta parte de sus instrucciones eran búsquedas megamórficas en diccionarios, resolviendo el mismo ID de mensaje tres veces.

Una hora después:

El número de instrucciones bajaba y el tiempo de reloj bajaba todavía más. Correlación demostrada. Las métricas que no pasaban esa prueba, o que eran inestables, se tiraban a la basura. Mejor no tener benchmark que tener a Claude escalando la colina equivocada.

Ratchets en CI: mejoras que no se pueden perder ¶

Un ratchet (trinquete, como el de una llave de carraca) es un umbral que solo puede bajar. En el sprint funcionaba así:

1. Cada benchmark tiene un techo guardado en el repositorio.
2. Cualquier PR que suba el número de instrucciones de esa ruta falla en CI.
3. Un job diario baja el techo cada vez que el número ha mejorado.

El resultado es que una mejora conseguida no se puede perder por accidente. Si alguien mete un cambio que vuelve a resolver el mismo ID tres veces, CI se pone en rojo antes de que llegue a producción.

Montar uno sencillo es cuestión de unas pocas líneas. Este ejemplo es mío, no de Anthropic, pero sigue la misma idea:

// scripts/perf-ratchet.mjs
// Compara el resultado del benchmark con el techo guardado en el repo
import { readFileSync, writeFileSync } from 'node:fs';

const BASELINE_FILE = 'perf/baseline.json';
const baseline = JSON.parse(readFileSync(BASELINE_FILE, 'utf8'));
const current = JSON.parse(readFileSync('perf/current.json', 'utf8'));
const tighten = process.argv.includes('--tighten');

let failed = false;
for (const [name, value] of Object.entries(current)) {
  const ceiling = baseline[name];
  if (ceiling === undefined) continue;

  if (value > ceiling) {
    // Empeora: la PR no pasa
    console.error(`❌ ${name}: ${value} > techo ${ceiling}`);
    failed = true;
  } else if (value < ceiling && tighten) {
    // Mejora: el job diario baja el techo
    baseline[name] = value;
    console.log(`⬇️ ${name}: nuevo techo ${value}`);
  }
}

if (tighten) writeFileSync(BASELINE_FILE, JSON.stringify(baseline, null, 2));
process.exit(failed ? 1 : 0);

En la PR lo ejecutas sin argumentos. En el job nocturno, con --tighten, y haces commit del baseline.json actualizado.

Y el prompt para que Claude te monte el primero:

Crea un benchmark que cuente cuántas veces se re-renderiza el componente Sidebar
al abrir la página. Guarda el número actual como techo y añade un paso de CI
que falle si una PR lo supera.

🔑 La lección central del sprint, en palabras del equipo: con Claude, medir algo lo vuelve abordable. Antes, medir era el paso cero: añadías una métrica, esperabas a que llegaran datos y entonces empezabas a entender el problema. Ahora es el primer peldaño de la subida. En cuanto Claude tiene un número que batir, se pone a optimizar.

El bucle de trabajo, hilo a hilo ¶

Todo ocurría en el mismo canal de Slack, con varios ingenieros y Claude participando en cada hilo. El sprint se asentó en un bucle de seis pasos:

1. Alguien abre un hilo sobre un tramo lento de un recorrido, a menudo con una captura o una grabación.
2. Claude traza el flujo y encuentra o construye un benchmark que demuestra el problema.
3. Cuando tiene un resultado prometedor en el laboratorio, vuelve con una PR. A menudo varias, con el tamaño pensado para el riesgo y la revisión, y todo lo visible para el usuario detrás de un flag.
4. Tras el despliegue, Claude vigila el deploy y lee los datos de campo.
5. Si el rendimiento mejora, Claude asegura la ganancia bajando el ratchet del benchmark. Si no, apaga el flag y vuelve a iterar.
6. Después busca el siguiente tramo lento en el mismo recorrido.

La persona pone el problema y las aprobaciones. Claude pone todo lo demás, incluida la vigilancia después del despliegue, que es la parte que casi siempre se nos olvida a los humanos.

Un ejemplo real: la barra lateral que daba saltos ¶

Alguien compartió una grabación en la que las filas de la barra lateral aparecían tarde después de cargar la página. Las filas de Chat y las de Cowork se resolvían en momentos distintos y la página se sentía temblorosa.

Ningún monitor lo detectaba. Lo más parecido era el Cumulative Layout Shift (CLS), pero cada salto puntuaba unos 0,008, muy por debajo del umbral de “bueno” de Google, que es 0,1. Según las métricas, todo iba bien.

Issac, otro ingeniero, propuso ir directamente a la Layout Instability API que hay debajo del CLS. A partir de ahí, Claude:

1. Creó un evento de telemetría que asignaba las sources de cada entrada layout-shift a una región con nombre (barra lateral, conversación) y a una fase (antes del primer pintado, después de que la página acepte escritura).
2. Escribió un test de integración que abría la página con la barra lateral llena, retenía sus datos hasta después del primer pintado y fallaba ante cualquier salto en cualquier región con nombre.
3. Usó ese test como benchmark: rojo 20 de 20 veces en main, verde 20 de 20 en la PR.

Cuando el evento llegó a producción, Claude leyó los datos de campo y encontró que el 31% de las cargas de página en web movía algo después de que la página fuera usable, sin que el usuario hubiera tocado nada. Luego fue a por las causas una a una: una cabecera que llegaba tarde, un cursor que se desplazaba en cuanto cargaba el nombre del usuario, una lista que se movía cuando aparecía la barra de scroll. Arregló el primer lote y, cuando desapareció, buscó el siguiente.

Si quieres replicarlo en tu proyecto, el prompt no necesita ser más complicado que esto:

Añade un PerformanceObserver de tipo layout-shift que registre qué elemento
se mueve y si ocurre antes o después del primer pintado. Después escribe un
test de Playwright que falle si la barra lateral se mueve al cargar la página.

🛡️ Si tu herramienta de monitorización dice que todo está en verde pero un vídeo dice lo contrario, cree al vídeo. El CLS agrega; la Layout Instability API te dice quién se ha movido.

De un hilo a 150 en paralelo ¶

Una vez que el bucle funcionaba en un hilo, escalarlo era cuestión de abrir más. Y los hilos no se cerraban al cumplir el encargo: Claude seguía. Un solo hilo podía generar cincuenta, a veces cien PRs de optimización. Con el paso de los días era Claude, y no una persona, quien abría hilos nuevos para perseguir oportunidades que había encontrado por su cuenta en otra investigación o en un job nocturno.

Shelley, una de las ingenieras del canal, lo resumió así: “este modelo es un demonio de los números”.

Cada medición nueva destapaba algo. Una muestra de lo que salió:

• Un censo de hooks de React encontró 6.900 hooks y 900 suscripciones al store en la ruta de escritura del compositor, re-renderizando con cada pulsación de tecla.
• Contando recálculos de estilos apareció un único selector :root:has() que añadía 24 milisegundos a cada cambio del DOM.
• Trazando lo que pasaba después del primer pintado encontró un location.reload() olvidado que provocaba medio millón de recargas ocultas al día, invisibles para todas las métricas de carga.
• Leyendo muestras del profiler en pestañas inactivas descubrió snapshots de caché idénticos que se clonaban en IndexedDB dos veces por minuto, en el hilo principal.

El caso de los guiones largos que congelaban la página ¶

Mi favorito. En un barrido buscando tirones de CPU, Claude vio que resaltar la sintaxis de un bloque de código terminado podía congelar la página durante cerca de un segundo.

El culpable: los guiones largos (—).

Si el markdown de una respuesta contenía cualquier carácter fuera de Latin-1, como un guion largo o unas comillas tipográficas, V8 guardaba la cadena entera en UTF-16. Eso mandaba todas las expresiones regulares del resaltado de sintaxis por su camino lento de dos bytes. La solución fue un cambio de veinte líneas: copiar cada bloque de código a una cadena de un byte antes de resaltarlo.

Nadie habría ido a buscar ahí. Por eso compensa tener a alguien (o algo) que mide sin descanso.

En la segunda semana el equipo casi no podía resumir lo que salía en un parte diario. Los días de más actividad aterrizaron más de 200 cambios. Aproximadamente un tercio de las PRs incluía telemetría o guardarraíles nuevos, y cada instrumento nuevo generaba más hilos con más oportunidades. Hasta otros equipos empezaron a llevar sus cambios al canal para que se los revisaran en clave de rendimiento.

Tu IA puede mentirte

Cómo revisar y verificar lo que programan los agentes de IA

Anthropic no se fió de Claude a ciegas: benchmarks, tests antes de optimizar y revisión en cada PR. En esta masterclass montas ese mismo sistema de verificación con skills, Playwright, casos Gherkin y adversarial review entre modelos.

Entrar a la masterclass →

Métodos en directo + casos Gherkin

Los guardarraíles que evitaron romper producción ¶

Con ese ritmo, la pregunta obvia es cómo no rompieron nada. La respuesta es que los guardarraíles se pusieron antes de empezar, porque casi todo lo que tocaban era ruta caliente: el primer pintado, el compositor, la conversación.

Las reglas del sprint:

• Toda PR pasaba por revisión automática y por al menos una aprobación humana.
• Los tests unitarios iban siempre antes que la optimización. Primero fijas el comportamiento, luego lo aceleras.
• Todo lo que pudiera causar un problema visible iba detrás de un feature flag de vida corta.

Los flags se acumularon, claro. Abrieron un hilo para coordinar despliegues y limpieza, y Claude clasificó cada flag como interruptor de emergencia (kill switch) o despliegue gradual (ramp), retirándolos en cuanto era seguro. En dos semanas crearon casi 200 flags y más de la mitad ya estaban limpios al terminar.

Proteger una mejora frágil: el compositor estático ¶

El compositor estático es frágil por diseño. Al usuario se le enseña casi al instante una copia en HTML de la página y React pinta encima cuando termina de cargar. En throttling de 4G, el compositor pasó de aceptar texto a los 2,93 segundos a hacerlo a los 0,36. Si el render de React se desvía un solo píxel, la magia se rompe. Así que Claude construyó docenas de guardarraíles:

• El HTML estático se genera renderizando el componente de React real en jsdom, y un test garantiza que nunca se desincronicen.
• Una suite de integración compara la página estática con el render de React en catorce tamaños de viewport y exige alineación dentro de 1 px.
• Un test de pulsaciones escribe durante el traspaso y falla si se pierde o se desordena una sola tecla.
• En producción, cada traspaso reporta desplazamientos con precisión de una décima de píxel, y Claude abre un hilo para cualquier evento con movimiento distinto de cero.

Encima de eso, el guardarraíl más viejo del mundo: despliegues incrementales. Primero empleados, luego el 1% de usuarios, luego todos.

Y menos mal. Cuatro horas después de activar el compositor estático para los empleados, Marius compartió una grabación: al abrir claude.ai en una pestaña nueva, el compositor bajaba 15-20 píxeles. Claude lo investigó y encontró que no era código de Anthropic. En navegadores gestionados por una organización, la página de nueva pestaña de Chrome tiene un pie de 56 px. Chrome prerenderizaba claude.ai con carga especulativa mientras el usuario escribía la URL, a la altura de esa pestaña más baja, y lo redimensionaba unos 100 ms después de mostrarlo. Como el compositor está al 18% de la altura, bajaba 0,18 × 56 ≈ 10 px, justo lo que medía el vídeo. Claude fijó el layout durante el redimensionado y añadieron un test que simula el prerender.

⚠️ Los tests en headless no ven la interfaz del navegador. Hay bugs que solo existen con un pie de página de Chrome gestionado por tu empresa. Por eso el despliegue incremental no es opcional.

¿Qué papel tuvieron los humanos? ¶

El bucle era productivo, pero no era autónomo. Mantenerlo rápido, seguro y en la dirección correcta era trabajo de las personas, y tenía tres partes.

Ambición ¶

Por defecto, Claude es prudente con el alcance: abre tickets en vez de arreglar, duda sobre la viabilidad e hincha sus estimaciones. Como el equipo confiaba en sus guardarraíles, buena parte de su trabajo al principio fue empujar a Claude a ser más valiente.

Un intercambio real. Claude propone subir una PR pequeña “esta semana” y avisa de que el número tardará unos días. Raymond responde:

si la subes ahora mismo, yo la fusiono y la despliego. Tenemos poder para hacer cualquier cosa. Por favor, sé más valiente

Claude: “Hecho, la PR estará en menos de una hora”.

Cuando alcanzaban los objetivos, los hilos se frenaban. Sam iba hilo por hilo con el mismo mensaje: “Sigamos bajándolo, los objetivos no son el punto de parada. ¿Qué es lo siguiente? Sé ambicioso”.

Para tu propio proyecto, algo tan simple como esto cambia el tono de la sesión:

Has cumplido el objetivo. No pares aquí: busca la siguiente mejora más grande
en este mismo recorrido y propón cómo medirla.

Gusto ¶

Cada hilo tenía una persona responsable con nombre. Claude acompañaba cualquier cambio perceptible con capturas o vídeos de antes y después para que esa persona decidiera. ¿Una tabla debe rellenarse celda a celda o esperar a tener la fila entera? ¿El skeleton de carga aparece al instante o solo pasado medio segundo? ¿Merece la pena un fundido palabra a palabra en el texto que llega en streaming si cuesta una quinta parte del presupuesto de cada frame?

Claude buscaba milisegundos. Las personas decidían qué milisegundos merecían la pena.

Dirección ¶

Cada hilo era estrecho a propósito: un benchmark o un recorrido, y Claude solo buscaba mejoras dentro de ese alcance. El equipo lo describe como “ciento cincuenta martillos buscando clavos”. Las decisiones humanas eran de secuencia e impacto: qué superficies priorizar, cómo fusionar hilos que se pisaban y cuándo cerrar uno que ya daba rendimientos decrecientes.

Una PR de 900 líneas recibió una respuesta de una línea: “decido que 2 ms por envío no compensan la complejidad de mantener este plugin de build”. Así también se dirige.

🎯 Si solo te llevas una cosa: el agente pone la tenacidad, tú pones el criterio. Ninguna de las dos cosas sobra.

Streaming a 120 fps con 8 milisegundos por frame ¶

Una de las misiones secundarias del sprint enseña todo el sistema funcionando a la vez. Para demostrar una optimización en una regex del resaltado de sintaxis en vivo, Claude adjuntó una grabación de una respuesta larga llegando en streaming en el laboratorio. En una esquina había añadido un contador de frames por segundo, calculado en la propia página a partir de los timestamps de requestAnimationFrame.

Raymond lo vio y preguntó si estaban limitados a 60 fps, y si Claude podía llevar la fluidez del scroll y del streaming a 120.

Claude confirmó que el banco de pruebas iba a 60 Hz porque Chromium en headless funciona así por defecto. Veinticinco minutos después tenía un rig determinista a 120 Hz usando el control de begin-frame de DevTools: exactamente 240 frames para 240 begin-frames de 8,33 ms. Con eso, “¿este frame cabe en el presupuesto de 120 Hz?” dejaba de ser una lectura ruidosa y pasaba a ser una comprobación exacta.

Con un presupuesto de 8,33 milisegundos por frame, Claude recorrió una respuesta larga frame a frame para encontrar los lentos. Eliminó trabajo O(longitud del mensaje) en cada fragmento memorizando los bloques terminados, movió la tokenización de los bloques de código en crecimiento a un worker y hizo que las tablas aparecieran celda a celda.

En ese único hilo aterrizaron casi sesenta PRs. Las respuestas largas pasaron de bloquear el hilo principal unos 750 ms en total a unos 200 ms, usaban más o menos un tercio de la CPU y mantenían 120 fps de principio a fin en un MacBook de 120 Hz. El propio rig se convirtió en un job nocturno, con Claude vigilando regresiones.

Cuando empezó el sprint nadie había planeado optimizar los milisegundos entre frames durante el streaming. Pero resultó que se podían contar. Y todo lo que se podía contar, Claude lo podía escalar.

Cómo aplicar este método en tu proyecto con Claude Code ¶

No necesitas Claude Tag para copiar la idea. Necesitas un número fiable, un bucle y guardarraíles. Estas son las piezas oficiales de Claude Code que encajan con cada parte del método:

Iterar con /loop ¶

Según la documentación de tareas programadas, /loop ejecuta un prompt de forma repetida mientras la sesión sigue abierta. Admite un intervalo fijo (s, m, h, d) o, si lo omites, deja que Claude elija la espera entre uno y sesenta minutos en función de lo que ha visto:

/loop 30m ejecuta el benchmark de la barra lateral y, si el número ha subido, dime qué commit lo causó

/loop revisa si el CI de mi PR ha pasado y atiende los comentarios de revisión

Dos detalles que conviene saber. Las tareas recurrentes caducan a los siete días, para que un bucle olvidado no se quede funcionando para siempre. Y si ejecutas /loop sin prompt, usa un prompt de mantenimiento que puedes sustituir con un fichero .claude/loop.md en tu proyecto. Si necesitas que el bucle sobreviva a tu portátil apagado, lo que buscas son las Claude Code Routines, que se ejecutan en la nube.

Anthropic lo resume en su guía sobre bucles con una frase que encaja con todo este post: cuanto más cuantitativas sean las comprobaciones, más fácil es que Claude se verifique a sí mismo. Si quieres profundizar en cómo diseñar esa verificación, en Web Reactiva tenemos una guía sobre loop engineering.

Trabajar hacia un objetivo con /goal ¶

Si en vez de un intervalo quieres una condición de parada, /goal hace que Claude siga trabajando turno tras turno hasta que se cumpla:

/goal el benchmark de render del compositor baja de 40 commits de React por pulsación y todos los tests pasan

Aquí vale lo mismo que en el sprint: la condición tiene que ser algo que Claude pueda comprobar por sí mismo. En este post sobre el comando /goal tienes cómo escribir buenas condiciones y cómo evitar que el agente se declare vencedor antes de tiempo.

Revisar con /code-review ¶

El sprint pasaba cada PR por revisión automática. En local, /code-review revisa tu diff en un subagente en segundo plano y te devuelve los fallos de corrección que encuentra. Acepta un nivel de esfuerzo y flags:

/code-review high --fix

En GitHub, el servicio gestionado de Code Review (en research preview para Team y Enterprise) etiqueta cada hallazgo por gravedad: 🔴 importante, 🟡 detalle menor y 🟣 preexistente. Según el anuncio de Anthropic, en PRs de más de 1.000 líneas el 84% recibe hallazgos, con una media de 7,5 problemas, y menos del 1% de los hallazgos los marcan los ingenieros como incorrectos. Cada revisión cuesta de media entre 15 y 25 dólares, según la documentación oficial.

Escribir tareas que terminan ¶

La guía de buenos hábitos de Claude Tag tiene tres consejos que sirven igual en la terminal:

1. Nombra el resultado, no la actividad. “Mira esto” produce un informe abierto. “Deja el benchmark por debajo de X y abre una PR en borrador” tiene un final comprobable.
2. Dale a cada tarea una definición de terminado. “Terminado cuando CI esté en verde” lo puede cerrar Claude solo. “Redacta y déjalo aquí para que lo apruebe” lo cierras tú con un clic.
3. Di qué decisiones vuelven a ti. Si no lo dices, Claude decide caso a caso, y puede hacer un cambio que querías ver antes o parar a preguntar cada dos minutos.

Un prompt que junta las tres cosas:

Reduce el tiempo de carga de la página de ajustes. Terminado cuando el benchmark
baje un 30% y pasen todos los tests. Arregla tú los fallos de lint y de tests.
Pregúntame antes de tocar cualquier API pública.

⚠️ La documentación oficial es clara en esto: las restricciones que escribes en el prompt orientan a Claude, pero no le impiden actuar. Si hay algo que no debe hacer nunca, impónlo fuera de la conversación con permisos del repositorio, protección de ramas o checks obligatorios.

Lo que viene después ¶

claude.ai y la app de escritorio son hoy unas 3 veces más rápidas que a principios de agosto, y los ratchets deberían mantenerlas así. El equipo reconoce que queda trabajo: el percentil 95, otros recorridos y las conversaciones muy largas. También han anunciado un segundo post sobre las contribuciones que hicieron aguas arriba durante el sprint, en Electron, Chromium y Node.js.

Issac lo resumió al compartir los resultados con el resto de la empresa: “Hace seis meses no me habrías convencido de que esto era posible”. El canal sigue abierto.

¿Y tú? ¿Qué número de tu proyecto podrías empezar a contar esta semana?

TL;DR ¶

• 🚀 Anthropic hizo claude.ai y su app de escritorio 3,1x más rápidas (p75) en dos semanas, con más de 3.000 cambios y cero incidentes.
• 🧵 Trabajaron desde un canal de Slack con Claude Tag, con más de 150 hilos en paralelo y un humano responsable en cada uno.
• 📏 La clave fue medir: benchmarks deterministas (instrucciones de CPU, commits de React, recálculos de estilo) validados contra el tiempo real.
• 🔒 Cada mejora se protegía con un ratchet en CI que solo baja, tests antes de optimizar, feature flags y despliegue gradual.
• 🎯 Puedes replicarlo con Claude Code: CLAUDE.md, un benchmark, /loop o /goal, y /code-review antes de fusionar.

Preguntas frecuentes ¶

¿Cuánto más rápido es claude.ai después del sprint de Anthropic?

Unas 3 veces más rápido de media: 3,1x como media geométrica de trece mediciones en el percentil 75. La carga fresca de claude.ai en web pasó de 3,1 a 0,55 segundos y cargar una sesión cloud de Cowork pasó de 2,6 a 0,73 segundos.

¿Qué es Claude Tag?

Es Claude integrado en Slack. Lo mencionas con @Claude en un canal o hilo, le encargas una tarea y la ejecuta en ese hilo desde la nube, con las conexiones que un admin haya configurado para el canal. Está en beta pública para los planes Team y Enterprise.

¿Qué modelo usó Anthropic para optimizar claude.ai?

Un modelo interno de investigación que Anthropic describe como más o menos comparable a Claude Opus 5.5, ejecutándose dentro de Claude Tag.

¿Qué es el hill climbing aplicado a la IA?

Es optimizar con pasos pequeños: el agente cambia algo, mide y conserva el cambio solo si el número mejora. Funciona bien con agentes de IA siempre que la métrica sea fiable y esté demostrado que se corresponde con lo que siente el usuario.

¿Por qué contar instrucciones de CPU en vez de medir milisegundos?

Porque el tiempo de reloj es ruidoso y no sirve como puerta de CI, mientras que el número de instrucciones es determinista. Anthropic comprobó que bajar las instrucciones un 48% en una ruta caliente bajaba el tiempo real un 78%, así que la métrica era válida.

¿Qué es un ratchet de rendimiento?

Es un umbral guardado en el repositorio que solo puede bajar. Si una PR empeora el benchmark, CI falla; si el número mejora, un job programado baja el umbral. Así una mejora conseguida no se pierde por accidente.

¿Qué tiene que ver un guion largo con el rendimiento de una web?

En V8, si una cadena contiene algún carácter fuera de Latin-1, como un guion largo o unas comillas tipográficas, se guarda entera en UTF-16. Las expresiones regulares van entonces por un camino más lento, y en claude.ai eso llegaba a congelar la página cerca de un segundo al resaltar código.

¿Por qué el CLS no detectaba los saltos de la barra lateral?

Porque cada salto puntuaba unos 0,008, muy por debajo del umbral de 0,1 que Google considera bueno. Anthropic usó directamente la Layout Instability API para saber qué región se movía y en qué fase de la carga, y descubrió que el 31% de las cargas en web movía algo después de ser usable.

¿Puedo hacer lo mismo sin Slack ni Claude Tag?

Sí. Con Claude Code puedes usar CLAUDE.md como instrucciones permanentes, /loop para iterar con un intervalo, /goal para trabajar hasta cumplir una condición y /code-review para revisar el diff. Lo imprescindible es tener un benchmark fiable y guardarraíles en CI.

¿Cómo evitó Anthropic romper producción con 200 cambios al día?

Con revisión automática más al menos una aprobación humana en cada PR, tests unitarios antes de cualquier optimización, feature flags de vida corta y despliegues graduales: primero empleados, luego el 1% de usuarios y después todos.

Fuentes ¶

• How we made claude.ai 3x faster in two weeks, blog de ingeniería de Anthropic
• Claude Tag: primeros pasos y buenos hábitos
• Getting started with loops, blog de Claude
• Run prompts on a schedule (/loop), documentación de Claude Code
• Code Review, documentación de Claude Code
• Cumulative Layout Shift, web.dev
• Layout Instability API, WICG

🧨 Última oportunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter