ES/EN/PT
Reporte de Lighthouse con puntaje perfecto tras un agent loop en Claude Code

Lighthouse 100/100 con un agent loop

Max TecheraSuscribirse

Le pedí a Claude Code que dejara mi web en puntaje perfecto en Lighthouse. Y lo hizo solo, sin que yo tocara 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, porque la condición de "terminado" es objetiva: las cuatro categorías en 100. O está en 100 o no está.

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é:

⚠️ No saltees esto

El loop es tan bueno como el contexto que le des. Un proyecto sin CLAUDE.md ni un comando para correr el sitio hace que el agente adivine, y adivinar quema tokens. Cinco minutos de setup te ahorran la mitad del loop.

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 y, si tenés, con los tests andando. El loop va a levantar tu sitio, correrle Lighthouse y leer el score: si no puede levantarlo, no puede medir.

🎯 Tip

Trabajá siempre en una rama nueva: git checkout -b perf/lighthouse-100. Así todo lo que haga el agente queda aislado y lo revisás de una en el PR.

Paso 2 — Iniciá una sesión nueva

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

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)

En vez de pedirle tarea por tarea, le das un objetivo con una condición verificable con /goal:

claude code
/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.
- Si un cambio no sube el score, revertilo.

⚡ Por qué este prompt funciona

Tiene un objetivo medible (100/100), una verificación que el propio agente puede correr (Lighthouse), y límites que evitan el desastre (no romper tests, cambios atómicos, revertir lo que no suma). Eso es loop engineering: la condición de salida y los límites importan más que el bucle.

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.

Paso 4 — Revisá los cambios

Cuando el loop termina, revisá el diff. No es opcional: el agente optimiza para el número, y a veces el número se sube con atajos que no querés.

claude code
$ git diff
  • ¿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.
  • Accesibilidad real, no hacks: que los aria-label y alt tengan sentido.
  • Tests en verde: corré tu suite y confirmá que no rompió nada.

⚠️ Ojo

Si algo del diff te hace ruido, no lo mergees. Pedile al agente que lo explique o que lo revierta. El 100 no vale si rompe la experiencia real.

Paso 5 — Pusheá el PR

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

claude code
$ 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 y pegá en la descripción el resumen que dejó el agente: qué cambió y por qué.

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

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

  • En Chrome: DevTools → pestaña Lighthouse → Mobile → Analyze.
  • Terminal: npx lighthouse https://tu-sitio.local --view
  • Online: PageSpeed Insights te da Lighthouse + datos de campo reales.

Paso 7 — Una vez en producción: WebPageTest

El 100 en local es lab data: tu máquina, tu red. Producción es otra cosa — CDN, latencia real, terceros, caché. Una vez que deployaste, verificá desde afuera con WebPageTest:

  1. Pegá la URL, elegí una ubicación real cerca de tu audiencia y un dispositivo mobile.
  2. Corré el test (idealmente 3 corridas, 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.

🎯 Tip

WebPageTest te muestra el waterfall de cada request: ahí ves al tercero que te frena (un pixel, un chat, una fuente) que en local ni aparece. Si el score baja en prod, volvés a correr el loop apuntando a la URL de producción.

Cierre: lo que realmente estás aprendiendo

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í, y después llevá el patrón a problemas más grandes. Mostrá receipts, no opiniones.

Preguntas frecuentes

Compartir