En un artículo complementario mostramos que las skills de agentes de IA pueden hacer que el resultado de front-end sea de forma medible más bello en una prueba a ciegas. Este artículo es la otra mitad de la historia, la que la mayoría de los posts de "la IA mejoró nuestro código" se saltan: dónde las skills no ayudaron, cuánto costaron y cómo sabemos que la diferencia es real. Si estás decidiendo si invertir en skills de agente, las carencias importan tanto como los avances.
Construimos ocho skills y las probamos de dos formas distintas. El resultado más importante es que las ocho skills no son una sola cosa: se dividen con claridad en dos tipos que se comportan de maneras opuestas.
Dos tipos de skills
Resulta tentador tratar las "skills de agente" como una única palanca. No lo son.
Skills de conocimiento (siete de ellas)
Estas codifican qué es un buen front-end: arquitectura CSS, un sistema de diseño, maquetación responsive, HTML semántico y accesibilidad, animación, CSS moderno y compatibilidad de navegadores, y rendimiento. Son material de referencia que el agente carga bajo demanda.
Una skill de proceso
La octava, "Visual Polish", codifica cómo trabaja un diseñador: construir, renderizar en un navegador real, hacer una captura, criticarla frente a una rúbrica, corregir lo más flojo y repetir; además de una biblioteca de recursos de sistema de diseño ya validada y una "definición de terminado" estricta. Cambia el comportamiento del agente, no solo su conocimiento.
Esta distinción resultó explicar todos los resultados que vienen a continuación.
Cómo lo medimos
Dos evaluaciones, cada una comparando la misma tarea construida con skills frente a sin asistencia (sin skills):
- Evaluación de corrección: siete tareas de construcción, calificadas mediante comprobaciones objetivas: ¿usa unidades relativas, HTML semántico, estados de foco accesibles, breakpoints basados en em, carga diferida nativa, etcétera?
- Evaluación de calidad: dos tareas nuevas (una sección de precios y una landing page de finanzas), juzgadas a ciegas: un revisor independiente puntuó únicamente las capturas renderizadas, no sabía cuál era cuál y las etiquetas se aleatorizaron para que no pudiera reconocer patrones.
Las cifras
| Medida | Con skills | Sin asistencia | Veredicto |
|---|---|---|---|
| Tasa de aprobado en corrección | ~90% | ~95% | En la práctica, un empate |
| Calidad a ciegas — Tarea 1 | Ganó (alta confianza) | Perdió | Distintividad 9 frente a 3 |
| Calidad a ciegas — Tarea 2 | Ganó (alta confianza) | Perdió | Distintividad 8 frente a 3 |
| Tiempo por tarea | +~33% | referencia | Las skills cuestan más |
| Tokens por tarea | +~24% | referencia | Las skills cuestan más |
Lee esos dos bloques juntos y aparece la historia completa: en corrección, con skills y sin skills empatan; en oficio, las skills ganan de forma decisiva, pero cuestan más.
Dónde ganan las skills (los avances)
1. Oficio y estética: la victoria decisiva
Con la skill de proceso, el resultado pasó del reconocible "aspecto genérico por defecto de la IA" a algo con dirección de arte genuina, y ganó una comparativa a ciegas en ambas tareas con alta confianza. El revisor, sin idea de cuál diseño era cuál, señaló de forma independiente las delatoras de las versiones sin asistencia: el degradado morado oscuro y el texto de titular con degradado.
"Uno tiene dirección de arte y es claramente un diseño a medida, material de tablero de inspiración. El otro se apoya en las dos delatoras más grandes de IA genérica a la vez. La diferencia es clara, no marginal."
2. Detecta defectos reales
Como la skill de proceso obliga al agente a renderizar y mirar, detectó dos errores de nivel de producción que una revisión de código pasó por alto: contenido que era invisible sin JavaScript y una maquetación que se desbordaba horizontalmente en móvil. Una generación de una sola pasada no detectó ninguno, porque nada la hizo mirar el resultado.
3. Impone tus convenciones, siempre
Las skills inyectan de forma fiable decisiones específicas del proyecto que un modelo no elegiría por defecto: una estrategia de tamaños consistente, media queries basadas en em, CSS moderno condicionado por datos reales de compatibilidad de navegadores, seguridad de reducción de movimiento y sombras en capas (no planas). Esa consistencia a lo largo de cientos de ejecuciones es en sí misma un entregable.
Dónde no lo hacen (las carencias)
La parte honesta. Son reales y merece la pena planificar teniéndolas en cuenta.
Las skills de conocimiento apenas superan a un modelo potente
Un modelo de vanguardia ya conoce las unidades relativas, el HTML semántico y los fundamentos de accesibilidad. Así que en la evaluación de corrección, las siete skills de conocimiento esencialmente empataron con el modelo sin asistencia, y en una tarea el evaluador incluso las puntuó ligeramente por debajo. Su valor es la consistencia y ayudar a modelos más débiles o más baratos, no una mejora bruta en uno de primer nivel.
Cuestan más
Las ejecuciones con skills usaron aproximadamente un 24% más de tokens y un 33% más de tiempo en las tareas de conocimiento; el ciclo completo de renderizar e iterar es aún más pesado (decenas de pasos de construir y comprobar frente a un puñado). Estás comprando calidad con cómputo: merece la pena cuando la calidad importa y es un derroche cuando el trabajo es "código correcto, rápido".
La mejor palanca necesita un navegador
El superpoder de la skill de proceso es renderizar en un navegador real. En un entorno sin uno, degrada a una skill de conocimiento y la mayor ventaja desaparece. Planifica la cadena de herramientas en consecuencia.
La calidad es difícil de medir de forma barata
Nuestras comprobaciones objetivas de corrección eran malas juzgando la calidad: en su mayoría aprobaron ambas versiones y produjeron falsos negativos en la tarea de diseño. Una evaluación de calidad genuina necesitó un juez a ciegas al estilo humano. Y nuestra evaluación de calidad fue pequeña: dos tareas, un revisor. Convincente, pero aún no estadísticamente robusta.
La idea que lo une todo
Una frase lo resume:
"La corrección está resuelta. El oficio no. La brecha entre un front-end competente y uno excepcional no es conocimiento que le falte al modelo: es gusto aplicado a través de la iteración y una negativa a entregar el resultado genérico por defecto."
Por eso añadir más conocimiento apenas movió la aguja, mientras que añadir un proceso (renderizar, criticar, refinar, frente a un gusto ya incorporado) la movió mucho. Una instrucción de texto no puede hacer que una sola pasada quede perfecta al píxel. Una skill que obliga al agente a mirar su propio trabajo y corregirlo sí puede.
Qué significa esto para los equipos
- No esperes una mejora de corrección de un modelo potente. Si tu evaluación solo comprueba la corrección, las skills parecerán inútiles, porque estás midiendo lo que el modelo ya hace.
- Invierte en proceso, no solo en prompts. Los avances duraderos vienen de los bucles de verificación que el agente debe ejecutar, no de archivos de instrucciones más largos.
- Entrega gusto, no principios. Los valores por defecto validados y con criterio superan a los consejos abstractos siempre.
- Mide la calidad como la experimentan los usuarios: renderízala, mírala, compara a ciegas. Las comprobaciones booleanas no pueden ver la belleza.
- Presupuéstalo. El resultado de calidad cuesta más tokens y más tiempo; gástalo donde la calidad sea el objetivo.
Recomendaciones: cerrar las carencias
Los hallazgos apuntan a una lista de tareas concreta, para nuestro propio conjunto de skills y para cualquier equipo que construya uno:
- Escala la evaluación a ciegas. Dos tareas y un revisor demuestran la dirección, no la magnitud. Amplía a diez o más tareas de distintos tipos de página, añade un segundo juez de IA e incluye al menos un revisor humano. Haz seguimiento de la tasa de victorias y la confianza, no de un único veredicto.
- Ajusta la activación, no solo el contenido. Una skill que no se dispara no vale nada, y una que se dispara en la tarea equivocada es peor. Ejecuta una pasada automatizada de optimización de descripciones para que cada skill se active cuando debe y permanezca en silencio cuando no debe.
- Haz que la skill de proceso degrade con elegancia. Cuando no haya navegador disponible, debería detectarlo y recurrir a su conocimiento y su lista de comprobación en lugar de asumir que puede renderizar, para que nunca pierda en silencio su mayor palanca.
- Consolida el conocimiento solapado. Ocho skills arrastran cierta superficie duplicada: CSS moderno, responsividad y rendimiento pisan el mismo terreno. Unos límites más nítidos suponen menos que mantener a medida que la plataforma evoluciona.
- Enruta por intención. Usa el pesado bucle de renderizar e iterar cuando la calidad sea el objetivo; sáltalo para "producir código correcto, rápido". El mayor derroche es pagar cómputo de nivel de oficio por una herramienta interna desechable.
- Vuelve a medir en un modelo más débil. Las skills de conocimiento deberían ayudar más donde el modelo base es menos capaz; confirmarlo cuantifica su valor real para despliegues sensibles al coste.
Cómo aplica esto SplatDev
Este es el trabajo que hacemos para los clientes: no solo apuntar una IA a una base de código, sino diseñar las skills, los mecanismos de protección y los bucles de verificación que hacen que su resultado sea fiablemente excelente, y luego demostrar el resultado con una evaluación honesta en lugar de darlo por hecho. Medimos calidad, no solo velocidad, y te decimos dónde están los avances y dónde no.
¿Quieres una IA que entregue trabajo digno de un portafolio, y una descripción honesta de sus límites?
Contacta con SplatDev — Construye mejor con IA
O escríbenos a [email protected]