Cómo uso vibe coding para Lighthouse 100% en rendimiento, accesibilidad y SEO

Introducción

Quiero explicar cuánto se puede equivocar la gente al usar vibe coding para crear sitios increíblemente hermosos. Todos se enfocan en la belleza aparente, en ese look que impresiona a primera vista, cuando en realidad lo que de verdad importa es qué tan bueno y performante es tu producto junto con esa misma belleza. Belleza sin rendimiento es solo fachada.

En este tutorial, vas a aprender el flujo exacto que uso para lograr 100% en Lighthouse en rendimiento, accesibilidad, SEO y mejores prácticas, usando vibe coding con Cloud Code y DeepSeek. Básicamente, es el proceso que aplico en todos mis proyectos web, y que separa un portafolio real de uno de fachada.

Tiempo estimado de lectura: 9 min

El verdadero portafolio es cuando alguien abre tu sitio, presiona F12 y ejecuta Lighthouse. Eso es lo que importa.

Requisitos previos

Antes de que arranquemos, déjame ser bien directo sobre lo que vas a necesitar para seguir este flujo sin tropezarte. Software primero: el Cloud Code, que es mi harness preferido para vibe coding, y una inyección del DeepSeek V4 Pro, el modelo que cambió el juego después de la actualización del 12 de agosto. También vas a necesitar un browser Chromium con Lighthouse disponible, y si quieres correr las métricas de forma automatizada, el headless browser resuelve.

De conocimiento, lo ideal es que ya tengas algo de familiaridad con vibe coding, aunque sea básica, y nociones de performance web, accesibilidad y SEO. No necesitas ser especialista, pero entender qué significa cada una de esas áreas ayuda muchísimo a la hora de evaluar las sugerencias de la IA.

De entorno, cualquier proyecto web en Node.js o JavaScript sirve, siendo que en realidad lo que importa es que tu stack corra en un browser Chromium, porque es ahí donde Lighthouse corre y reporta todo lo que necesitamos.

Por qué esto importa

El problema de la belleza aparente es que engaña a todos, incluso al dueño del sitio. Subes una landing page con efectos bonitos, animaciones suaves, esa estética impecable, y crees que el trabajo está hecho. Siendo que en realidad lo que sostiene un producto no es lo visual, es lo performático que es, lo accesible que es, lo bien ranqueado que está en SEO y lo mucho que sigue las mejores prácticas de desarrollo. Y Lighthouse reporta exactamente esas cuatro cosas en cualquier browser Chromium, que es básicamente la métrica que separa un sitio de fachada de un sitio de verdad.

Si el desarrollador no hace accesibilidad en su propio sitio, ¿cómo la va a hacer en el del cliente? Si no hace performance en su propio sitio, ¿cómo la va a hacer en el del cliente? Si las mejores prácticas no están en su sitio, ¿cómo van a estar en el del cliente? Yo vengo aplicando este enfoque en todos mis proyectos web, y en proyectos Node.js y JavaScript uso otras herramientas de métrica, pero el foco aquí es lo que Lighthouse puede decirte sobre cualquier página.

Entonces, básicamente, el verdadero portafolio es cuando abres tu sitio, le das F12 y corres Lighthouse. Ese es tu portafolio real, y por eso tiene que ser perfecto.

Configuración

Antes de nada, necesitas configurar el entorno de vibe coding que realmente entrega resultados, y no solo queda en la belleza aparente. Yo uso Cloud Code porque tiene, en mi opinión, el mejor harness para gestionar el flujo de desarrollo con agentes de IA, pero la magia ocurre cuando le inyectas DeepSeek. Te voy a mostrar el archivo de configuración que uso, básicamente un config.json dentro de la carpeta .cloudcode del proyecto.

// .cloudcode/config.json
{
  "provider": {
    "type": "openai",
    "apiKey": "${DEEPSEEK_API_KEY}",
    "baseUrl": "https://api.deepseek.com/v1"
  },
  "model": {
    "name": "deepseek-chat",
    "version": "deepseek-v4-pro",
    "parameters": {
      "temperature": 0.3,
      "maxTokens": 4096
    }
  },
  "harness": {
    "waves": true,
    "subAgents": true,
    "lighthouseIntegration": true
  }
}

Puede que te estés preguntando por qué uso DeepSeek en lugar de otros modelos, y la respuesta es que, después de la actualización del 12 de agosto, DeepSeek V4 Pro alcanzó un nivel de razonamiento equivalente al GLM 5.2, que era el estado del arte para modelos open source, por un precio que, básicamente, ningún competidor puede igualar, siendo que en realidad lo que importa es tener un modelo barato y lo suficientemente inteligente para tomar decisiones de optimización sin romper el presupuesto del proyecto. El harness de Cloud Code gestiona todo el flujo de waves de desarrollo, sub-agents y la integración con Lighthouse, y DeepSeek entra como el motor de razonamiento que va a proponer e iterar los cambios. Es una combinación que, en la práctica, me permite enfocarme en la calidad real mientras la IA se encarga de las experimentaciones aburridas.

Paso 1: Configurando DeepSeek en Cloud Code

Personalmente me gusta mucho usar Cloud Code, que tiene el mejor harness para este tipo de flujo, pero la magia ocurre cuando inyectas DeepSeek como modelo de razonamiento. Después de las actualizaciones de agosto, sobre todo la del día 12, DeepSeek V4 Pro llegó al mismo nivel de razonamiento que un GLM 5.2, que era nuestro SOTA para modelos open source, a un precio que solo DeepSeek puede poner en el mercado. Eso cambia el juego porque puedes iterar rápido sin miedo a reventar el presupuesto.

La configuración es directa. Defines el modelo en el archivo de configuración de Cloud Code y apuntas al endpoint de DeepSeek:

# Configura DeepSeek V4 Pro como modelo de razonamiento en Cloud Code
cloud-code config set model deepseek-v4-pro
cloud-code config set model.thinking enabled true
cloud-code config set model.endpoint https://api.deepseek.com/v1

Lo que importa aquí es model.thinking enabled true. Eso es lo que activa el modo de razonamiento, que es lo que va a permitir que la IA piense antes de proponer optimización. Sin eso, solo estás usando un autocomplete caro.

Un consejo: antes de pasar al siguiente paso, corre cloud-code config get model y verifica si el modelo activo es DeepSeek V4 Pro. Ya perdí una tarde entera optimizando con el modelo equivocado, pensando que el problema era el código cuando en realidad era la configuración.

Paso 2: Integrando Lighthouse en el flujo

Con DeepSeek corriendo en Cloud Code, el siguiente paso es hacer que Lighthouse sea parte de tu ciclo de desarrollo, y no una auditoría que corres una vez al final, después de que todo ya está hecho. La forma que uso es integrar Lighthouse directamente en el flujo con un browser headless, y la construcción de tu software puede llamar a esa integración en varias etapas que definas, con varios subagentes, y usando waves de desarrollo.

El concepto de waves es básicamente el siguiente: en cada wave, corres una métrica, dejas a la IA libre para proponer experimentos, y al final ella te reporta sus ideas. Corriges lo que no tuvo sentido y vuelves a intentarlo si algún experimento degrada el producto de una manera que no valga la ganancia de rendimiento.

El script de abajo es un ejemplo de cómo ejecutar Lighthouse mediante un browser headless en Node.js. Abre la URL, ejecuta la auditoría y guarda el informe en JSON. Puedes enchufarlo en un cron, en un hook de tu harness de vibe coding, o llamarlo manualmente cuando quieras medir una wave:

// lighthouse-runner.js
import { chromium } from 'playwright';
import lighthouse from 'lighthouse';

const url = process.env.URL || 'http://localhost:3000';

const browser = await chromium.launch({ headless: true });
const { port } = await browser.startServer();

const { lhr } = await lighthouse(url, {
  port,
  output: 'json',
  logLevel: 'info',
  onlyCategories: ['performance', 'accessibility', 'seo', 'best-practices'],
}, {
  extends: 'lighthouse:default',
  settings: {
    formFactor: 'desktop',
    throttling: { rttMs: 40, throughputKbps: 10240, cpuSlowdownMultiplier: 1 },
  },
});

console.log(`Rendimiento: ${lhr.categories.performance.score * 100}`);
console.log(`Accesibilidad: ${lhr.categories.accessibility.score * 100}`);
console.log(`SEO: ${lhr.categories.seo.score * 100}`);

await browser.close();

Lo que esto permite es medición continua sin interrumpir el flujo de vibe coding. En cada wave, tienes un número concreto para decidir si el cambio que la IA propuso vale la pena, en lugar de confiar en suposiciones o en "la belleza aparente" del resultado visual.

Paso 3: Corriendo métricas y experimentos

Con Lighthouse integrado en el flujo, el siguiente paso es dejar que la IA trabaje de verdad. En cada wave, le das libertad para proponer optimizaciones, correr Lighthouse de nuevo y ver qué cambia. La idea es simple: en lugar de que estés tratando de adivinar qué mejora el rendimiento, la IA prueba hipótesis por sí sola y te trae los resultados.

Aquí hay un script que dispara una wave de experimentación. Ejecuta Lighthouse, recoge las métricas, le pide a la IA sugerir una optimización y corre todo de nuevo para comparar:

// scripts/experiment-wave.js
const { runLighthouse } = require('./lighthouse');
const { askAI } = require('./ai');

async function runWave(url, context) {
  const before = await runLighthouse(url);
  console.log('Métricas antes:', before);

  const suggestion = await askAI(`
    Lighthouse reportó: ${JSON.stringify(before)}.
    Propón una optimización e impleméntala.
  `);

  await suggestion.apply();
  const after = await runLighthouse(url);
  console.log('Métricas después:', after);

  return {
    before,
    after,
    suggestion: suggestion.summary(),
  };
}

Al final de cada wave, la IA te relata sus ideas, con el antes y el después. Puedes corregir esas ideas o descartarlas si la ganancia no compensa. Lo que acelera la búsqueda del 100% es justamente esa autonomía: la IA prueba cosas que quizás ni pensarías, y tú solo validas lo que tiene sentido. Esto convierte el proceso de optimización en algo continuo, no en un esfuerzo manual que haces una vez y olvidas.

Así fue como llegué al resultado del video de abajo, con Lighthouse al 100% en todo. Cada wave fue una pequeña victoria, y al final aparecieron los fuegos artificiales.

Ahora, si una wave degrada el producto de una manera que no compensa, ahí entra el siguiente paso: corregir e iterar hasta mantener la calidad.

Paso 4: Corrigiendo degradaciones e iterando

En realidad, el punto que más separa a quien usa vibe coding para un portafolio de fachada es este: saber qué hacer cuando la experimentación degrada el producto. Pasa todo el tiempo, la IA propone una optimización que parece obvia, pero en la práctica rompe la jerarquía visual de la página, o el rendimiento ganado no compensa lo que se pierde en accesibilidad. Siendo que la gracia del ciclo está justo ahí, en la corrección.

Estructuré esto con una función de rollback que corre al final de cada wave, comparando el resultado de Lighthouse en la rama principal con la rama de experimentación:

// rollback.js
const categories = ['performance', 'accessibility', 'seo', 'bestPractices'];
const tolerance = 2.5;

function decideToKeep(before, after) {
  const degraded = categories.filter((cat) => after[cat] < before[cat] - tolerance);

  if (degraded.length > 0) {
    console.warn('Revertiendo wave, pérdida en:', degraded.join(', '));
    rollback();
    return false;
  }

  acceptWave();
  return true;
}

La lógica es directa: una tolerancia de 2,5 puntos por categoría, si algún valor cae más allá de eso, la experimentación se descarta y el baseline vuelve. Claro que 2 puntos de pérdida en accesibilidad para ganar 5 de rendimiento puede ser un trade-off interesante, pero eso lo puedo ajustar en la tolerancia en cada ronda, o rechazar la wave de todas formas. La decisión final es mía, no es el script el que manda.

Es este ciclo repetido el que mantiene la calidad: la IA genera, yo paso Lighthouse de nuevo, cuando empeora lo deshago, cuando mejora lo incorporo y tomo otra. Uso este espectro en todos mis proyectos web, desde pruebas personales hasta sitios de clientes, y es básicamente lo que me dejó tranquilo con la respuesta en todo el asunto. Cuando alguien abre el portafolio y corre el F12, el 100% en todo no es fórmula mágica, es el resultado de haber corrido tras las correcciones hasta que solo quede lo que funciona.

Problemas Comunes

Mira, todo el flujo funciona lindo en teoría, pero en la práctica siempre hay algunas aristas. El problema más común que veo es que Lighthouse simplemente no corre en headless. Disparas el comando, y nada. La mayoría de las veces es porque faltan las flags de Chromium, sin la flag --headless=new o el --no-sandbox en entornos restringidos, el headless simplemente no arranca. Entonces, verifica las flags antes de ponerte a depurar el código de la IA.

Otro problema recurrente es que DeepSeek no responde como esperas. Ahí revisas la inyección en Cloud Code y descubres que la versión del modelo está equivocada. Después de la actualización del 12 de agosto, el DeepSeek V4 Pro es el que realmente tiene razonamiento decente. Si estás usando una versión antigua, la IA va a sugerir tonterías. Corre deepseek --version en la terminal solo para asegurarte.

Y están las experimentaciones que empeoran el rendimiento, la IA propone una optimización, la aplicas, y Lighthouse cae de 98 a 70. Eso pasa cuando toca cosas que no debería, como fuentes cargadas de forma síncrona o imágenes sin lazy loading. El secreto es correr Lighthouse manualmente después de cada wave, antes de aceptar la sugerencia. Parece obvio, pero uno siempre quiere confiar ciegamente en la IA. Básicamente, necesitas validar con tus propios ojos, la máquina no siente el contexto de tu proyecto.

Conclusión

El flujo ya está en tus manos. Toma cualquier proyecto web que ya tengas, corre el Lighthouse en él y mira cuál es tu puntaje actual. Después aplica ese mismo ciclo de waves con la IA proponiendo experimentación y midiendo el resultado en cada iteración, y básicamente vas a ver el número subir sin tener que memorizar el manual de documentación de accesibilidad. Siendo que en realidad es esto lo que separa a quien solo apila frameworks de quien entrega un producto de verdad.

Ese es tu verdadero portafolio. No es la landing bonita con animación de scroll, es lo que el browser reporta cuando alguien da F12 y corre la auditoría. Por eso tu portafolio tiene que ser perfecto, porque es la única métrica que el cliente y el reclutador pueden ver sin pedirte explicación.

Si llegas al 100, cuéntame. Manda el print al Slack del equipo o al WhatsApp, porque cuando ves los fuegos artificiales del Lighthouse por primera vez, es difícil no querer compartirlo. Y si llegas a 90 y te quedas atascado, vuelve al paso 4 y deja que la IA experimente una wave más. El flujo aguanta.