¿Las skills de agentes de IA ayudan más a los modelos débiles? Lo hemos medido

En un artículo anterior hicimos una afirmación y admitimos que no la habíamos comprobado: que nuestras skills de agente de front-end deberían ayudar más a los modelos más débiles y baratos que a uno de vanguardia. La lógica era sólida (el conocimiento que se te entrega vale menos para un modelo que ya lo conoce), pero la lógica no es evidencia. Así que hicimos el experimento. Esto es lo que dicen los números.

El planteamiento

Volvimos a ejecutar las mismas tareas de construcción con dos ejecutores más débiles, Haiku 4.5 y Sonnet 4.6, con las skills y sin ellas, y las evaluamos con los mismos instrumentos que usamos con el modelo de vanguardia (Opus 4.8). El número que importa es la mejora: cuánto mejora la skill el resultado, medida en cada nivel de modelo.

Dos pruebas: las siete skills de conocimiento (evaluadas por corrección objetiva) y la skill de proceso "visual polish" (juzgada a ciegas por calidad).

Resultado 1: cuanto más débil es el modelo, mayor es la mejora

En corrección, el patrón es limpio y monótono:

La skill lleva todos los niveles hasta el 100%, pero cuanto más débil es el modelo, mayor es la brecha que cierra. La mejora se triplica aproximadamente del modelo de vanguardia al más pequeño. Los modelos débiles sin ayuda seguían olvidando precisamente las convenciones que codifican las skills (una estrategia de tamaños coherente, breakpoints que respetan la accesibilidad, el estado de la navegación móvil, señales de rendimiento); la skill las restauraba cada vez. Hipótesis confirmada.

Resultado 2: el buen gusto se transfiere hacia abajo; la verificación no

La skill de calidad fue más interesante. Juzgado a ciegas, el resultado con skill ganó 3 de 4 comparaciones directas en los modelos más débiles (el modelo de vanguardia, ejecutando el bucle completo de renderizado, había ganado sus dos comparaciones). El revisor volvió a señalar las versiones sin ayuda como el resultado genérico de IA por defecto y las versiones con skill como "diseñadas a medida".

"Los diseños ganadores apuestan por paletas seguras y tipografía editorial; los perdedores se apoyan en los valores por defecto genéricos: degradados morado/índigo, texto de titular con degradado, tarjetas centradas uniformes."

Pero la única derrota es el resultado más útil de todo el estudio. El modelo más pequeño, incluso con la skill, perdió una comparación; no por parecer genérico, sino por entregar una llamada a la acción con contraste roto (texto blanco sobre fondo blanco). Ese es exactamente el tipo de defecto de ejecución que el bucle de renderizar y refinar de la skill está diseñado para detectar mirando la página renderizada, y un modelo más débil y sin navegador no podía ejecutar ese bucle de forma fiable.

Así que las dos mitades de la skill se comportan de forma distinta a medida que los modelos se debilitan: el buen gusto entregado (un sistema de diseño validado, barreras contra antipatrones) se transfiere a los niveles inferiores y evita que el resultado parezca genérico. La verificación (renderizar, criticar, corregir) no; necesita a la vez un navegador y suficiente capacidad para juzgar una captura de pantalla.

Lo que cambiamos

Los hallazgos tienen una solución clara: si un modelo débil no puede ejecutar el bucle de mirar y refinar, dale un umbral de verificación que no dependa del juicio del modelo. Así que añadimos a la skill de polish:

• Una puerta de calidad automatizada y sin dependencias: un script que señala los defectos deterministas (falta de estados de foco, ausencia de protección de reduced-motion, falta de etiqueta viewport, contenido oculto hasta que carga el JS, la paleta genérica de IA, sombras planas, fallos de contraste evidentes) y que debe pasar antes de entregar. En las pruebas rechazó correctamente las líneas base genéricas y aprobó la página de referencia.
• Una matriz de escenarios: qué verificación ejecutar para cada combinación de potencia del modelo y disponibilidad de navegador, con la puerta automatizada como la constante que se mantiene en todos los casos.

La puerta es una heurística, no un renderizador; no puede ver el contraste real de los píxeles, así que cuando hay un navegador disponible, la comprobación completa de renderizado sigue ejecutándose. Pero convierte el "creo que está bien" en un resultado comprobado, independientemente de la capacidad del modelo.

Qué significa esto para los equipos

• Las skills de conocimiento son una ganancia mayor en los modelos más baratos: podría decirse que es su mejor caso de uso. Si ejecutas un modelo pequeño o económico en producción, las skills bien construidas son de donde procede buena parte de tu calidad.
• No esperes lo mismo en un modelo de vanguardia: ya conoce las convenciones, así que una skill de corrección apenas lo mueve.
• El buen gusto entregado viaja; la autoverificación no. Un sistema de diseño mejora el resultado de cualquier modelo; el bucle de mirar y corregir necesita capacidad y un navegador.
• Dale a cada nivel una puerta automatizada. Es como evitas que un modelo barato entregue el error que no puede ver por sí mismo.

Cómo aplica esto SplatDev

Construimos sistemas de desarrollo mejorados con IA adaptados al modelo que realmente ejecutas (de vanguardia o económico), con las skills, las barreras y las puertas automatizadas que hacen que el resultado sea fiable en ese nivel. Y lo medimos: dónde están las ganancias, dónde no lo están y qué añadir para cerrar la brecha.

¿Ejecutas un modelo sensible al coste y quieres sacarle más calidad?

Contacta con SplatDev: construye mejor con IA

O escríbenos a [email protected]