Los skills dejan de ayudar cuando el modelo mejora

SwarmAttacker incluye más de 60 skills expertas escritas a mano, una por clase de vulnerabilidad. Inyección SQL, XSS, SSRF, IDOR y el resto reciben cada una un playbook en texto plano: así funciona esta clase, así la conviertes en un hallazgo real. En tiempo de ejecución inyectamos la skill correspondiente directamente en el worker que persigue esa pista. Es el tipo de cosa que todo el mundo te dice que construyas. El conocimiento experto curado, dice la sabiduría convencional, es la gran ganancia.

Así que lo medimos de la única forma honesta: apagamos todas las skills y volvimos a ejecutar la suite completa de 104 aplicaciones. El resultado fue más interesante que «las skills son buenas».

¿Qué costó realmente apagar todas las skills?

Con todas las skills desactivadas, la tasa de resolución bajó del 94% (98 de 104) al 87% (90 de 104). Ocho benchmarks perdidos. Real, pero no el colapso que cabría esperar al arrancar 60 playbooks expertos.

Y el coste fue en la dirección contraria, con fuerza. El worker sin skills usó menos de la mitad de los tokens: de 2.14M por aplicación a 0.91M. Fue el mayor cambio de coste de cualquier componente que probamos. Toda esa pericia inyectada no era gratis; era lo más caro del prompt, y quitarla hizo al agente drásticamente más ligero.

Durante los primeros 20 minutos, el agente sin skills iba por delante

Aquí está el remate. A los veinte minutos, la configuración sin skills había resuelto más que el sistema completo: 79 frente a 71. Durante todo el primer acto de cada ejecución, las skills eran peso muerto. El worker genérico y ligero era, si acaso, más rápido en la salida. Las skills solo recuperaron la ventaja en la segunda mitad, terminando 90 a 98.

Cuando miramos dónde se perdieron los ocho benchmarks, el patrón era limpio. El descubrimiento sobrevivió bien sin skills. El worker seguía encontrando el punto de inyección, seguía consiguiendo su punto de apoyo. Lo que faltaba era el último paso, específico de cada clase: convertir un punto de apoyo que funciona en la flag real en los objetivos más difíciles y atados a convenciones, donde hay que conocer el único truco exacto que esa clase concreta exige. Las skills son ahora una herramienta para la cola difícil, no un multiplicador de base.

Por qué las skills rinden menos en un modelo más inteligente

Da un paso atrás y tiene sentido. Un modelo base moderno ya conoce lo común. No hace falta explicarle a GPT-5.5 qué es XSS ni cómo funciona una inyección SQL basada en UNION. Ha leído todo internet, incluidos todos los tutoriales, todos los writeups y todos los post-mortem de CTF que habríamos parafraseado en una skill. El andamiaje experto que era un gran impulso en modelos antiguos ha sido absorbido silenciosamente por los pesos.

Aquí no podemos hacer un A/B entre dos generaciones de modelos, así que no vamos a fingir que medimos «las skills ayudaron a GPT-4 en X y a GPT-5.5 en Y». No lo hicimos. Pero la forma del resultado, el modelo base pasando sin ayuda por los casos fáciles y medios, es exactamente lo que esperarías si el modelo ya ha absorbido la mayor parte de lo que las skills solían aportar. En un modelo frontera, las skills solo se ganan su lugar en los márgenes.

El conocimiento experto que habrías escrito a mano en una skill hace dos años ya está en el modelo. En los casos comunes, estás pagando tokens para contarle cosas que ya sabe.

Qué significa esto si estás construyendo

No inviertas meses en una biblioteca gigante de skills o RAG para un modelo frontera. El instinto de cargar por adelantado cada pizca de conocimiento del dominio tenía sentido cuando el modelo base era más débil; hoy sobre todo te compra una factura de tokens mayor y un primer acto más lento. En su lugar:

• Deja que el modelo base se ocupe de los casos comunes. Lo hará, y lo hará más rápido sin tu andamiaje estorbando.
• Mantén las skills ligeras y apuntadas a la cola larga, los casos límite atados a convenciones donde el truco exacto importa y el modelo, de otro modo, se quedaría a un paso.
• Vigila el coste en tokens de tu pericia. El conocimiento inyectado es lo más caro de un prompt. Si no mueve la tasa de resolución, es puro sobrecoste.

Es la misma historia que hemos visto repetirse en otros sitios: el modelo sigue absorbiendo el andamiaje que construimos a su alrededor. Lo vimos también con el prompt engineering, donde las reglas cuidadosas que escribimos resultaron ser cosas que un modelo fuerte ya hace por sí solo. Las skills son la siguiente capa en adelgazar. Construye para los márgenes, no para el centro.