Lighthouse 100/100 con un Agent Loop en Claude Code (Guía Completa)

Hace poco subí un reel donde le pido a Claude Code que deje mi web en 100/100 en Lighthouse y lo hace solo, sin que yo toque una línea de código.

No es magia ni un truco para la foto. Es un agent loop: le das un objetivo con una condición que el agente pueda verificar, y trabaja —audita, arregla, vuelve a medir— hasta cumplirlo.

Lighthouse es el caso perfecto para esto, porque la condición de "terminado" es objetiva: las cuatro categorías en 100. No hay opinión. O está en 100 o no está.

Acá te dejo el flujo completo, paso a paso, con el prompt listo para copiar.

Antes de empezar: instalá y configurá Claude Code

Esta guía asume que ya tenés Claude Code instalado y tu proyecto configurado. Si todavía no, arrancá por acá y volvé:

• Cómo instalar Claude Code en 2026 — instalación en Windows, Mac y Linux desde cero.
• Tutorial Claude Code: Guía Completa Paso a Paso — cómo dejar tu proyecto listo: CLAUDE.md, contexto, y el setup que uso a diario.

Si querés entender qué es un agent loop por dentro (y por qué el harness importa más que el loop), leé Agent Loops y Loop Engineering 2026.

Paso 1 — Elegí el proyecto

Abrí la terminal en la raíz del proyecto que querés optimizar. Tiene que ser un proyecto que puedas correr localmente (un npm run build / npm run start, pnpm dev, lo que uses) y, si tenés, con los tests andando.

Por qué importa: el loop va a levantar tu sitio, correrle Lighthouse y leer el score. Si no puede levantarlo, no puede medir, y sin medir no hay loop.

Paso 2 — Iniciá una sesión nueva

Dentro del proyecto, abrí una sesión limpia de Claude Code:

claude

Sesión nueva, no una que venís arrastrando de otra tarea. El contexto sucio es la causa número uno de loops que se van de las manos: el modelo se llena de cosas viejas, resume mal y empieza a inventar. Empezá fresco.

Paso 3 — Tirá el prompt (el /goal)

Acá está el corazón de todo. En vez de pedirle tarea por tarea, le das un objetivo con una condición verificable con /goal:

/goal Dejá este sitio en 100/100 en Lighthouse en las cuatro categorías
(Performance, Accessibility, Best Practices y SEO) en mobile.
 
Condición de "terminado" (verificable):
- Levantá la build de producción local y corré Lighthouse en modo mobile.
- No pares hasta que las 4 categorías estén en 100.
- Después de cada cambio, volvé a correr Lighthouse y mostrame el score.
 
Reglas:
- No rompas funcionalidad existente. Los tests tienen que seguir pasando.
- Cambios chicos y atómicos: un commit por mejora, con mensaje claro.
- Si un cambio no sube el score, revertilo.
- Al final, dejá un resumen de qué cambiaste y por qué.

Lo pegás, le das Enter, y a partir de ahí trabaja solo.

Qué hace el agente, en orden

1. Audita cómo está tu sitio y tu código hoy — saca el baseline.
2. Define qué tiene que arreglar para llegar a 100.
3. Hace los cambios y los prueba: performance, accesibilidad, SEO y best practices.
4. Levanta el sitio en Chrome, le corre Lighthouse y lee el score.
5. Repite sin parar hasta que las cuatro categorías estén en 100.

Vos no hacés ni un paso. Mirás cómo el score sube vuelta tras vuelta.

Paso 4 — Revisá los cambios

Cuando el loop termina (o cuando lo frenás porque ya llegó), revisás el diff. Esto no es opcional: el agente optimiza para el número, y a veces el número se sube con atajos que no querés.

git diff

Cosas a mirar con ojo:

• ¿Sacó contenido o features para subir el score? Una web vacía rinde 100 fácil. No queremos eso.
• ¿Las imágenes siguen viéndose bien? Comprimir de más es la trampa clásica de performance.
• Accesibilidad real, no hacks: que los aria-label y alt tengan sentido, no relleno.
• Tests en verde: corré tu suite y confirmá que no rompió nada.

Paso 5 — Pusheá el PR

Cuando el diff te cierra, lo subís como PR para tener el registro y, si trabajás con alguien, que quede revisado:

git add -A
git commit -m "perf: Lighthouse 100/100 (performance, a11y, SEO, best practices)"
git push -u origin perf/lighthouse-100

Abrí el PR en GitHub. En la descripción pegá el resumen que dejó el agente: qué cambió y por qué. Tu yo del futuro te lo va a agradecer.

Paso 6 — Verificá con Lighthouse (de nuevo, por las tuyas)

Confiá pero verificá. Corré Lighthouse vos mismo, sin el agente en el medio:

• En Chrome: DevTools → pestaña Lighthouse → Mobile → Analyze. Mirá las cuatro categorías.
• Desde la terminal: npx lighthouse https://tu-sitio.local --view
• Online (cuando esté deployado): PageSpeed Insights te da Lighthouse + datos de campo reales.

Si en local te da 100 en las cuatro, ya está la primera mitad. Falta confirmar que aguanta en producción.

Paso 7 — Una vez en producción: WebPageTest

El 100 en local es lab data: tu máquina, tu red, condiciones de laboratorio. Producción es otra cosa — CDN, latencia real, scripts de terceros, caché. Por eso, una vez que deployaste, lo verificás desde afuera.

Andá a WebPageTest y corré un test contra tu URL de producción:

1. Pegá la URL, elegí una ubicación real cerca de tu audiencia y un dispositivo mobile (un Moto G es un buen "peor caso").
2. Corré el test (idealmente 3 corridas, y mirá la mediana).
3. Mirá el filmstrip y la línea de tiempo: cuándo se ve el contenido, cuándo es interactivo.
4. Chequeá los números que importan: LCP, CLS, TBT/INP.

Cierre: lo que realmente estás aprendiendo acá

Esto no va de Lighthouse. Va de delegar trabajo verificable.

El patrón se repite para todo lo que tenga una condición de "terminado" objetiva: "dejá todos los tests en verde", "migrá esto sin romper nada", "subí la cobertura a 90%". Si podés describir cómo se ve terminado de forma que una máquina lo pueda chequear, podés loopearlo.

Lighthouse es el mejor primer loop porque la verificación es gratis y binaria. Empezá por ahí, mirá cómo el agente trabaja solo, y después llevá el patrón a problemas más grandes.

Mostrá receipts, no opiniones. El score está o no está en 100. El resto es ruido.