Instalar 40 skills no te hace programador: desarrollo modular con IA desde los fundamentos

Últimamente no hay día en que no aparezca en LinkedIn o en YouTube alguien con el mismo mensaje: «Instala estas 40 skills en tu agente y programa como un senior sin saber programar».

Y uno entiende el atractivo. Pegas un paquete de instrucciones, le dices a la IA «hazme un dashboard bonito» y en dos minutos tienes algo en pantalla. ¿Quién no quiere eso?

El problema aparece una semana después: cuando hay que cambiar algo, cuando el botón no respeta la marca, cuando el agente se inventa una API que no existe o cuando arreglar un bug rompe tres cosas en otro lado.

La idea de que acumular herramientas compensa la falta de fundamentos es justamente al revés. Más instrucciones sobre una base desordenada no ordenan nada: agregan ruido. Vamos a ver por qué pasa esto y cómo se construye software modular con IA sin depender de la magia de turno.

El problema: más skills no significa más inteligencia

Las “skills” (paquetes de instrucciones, reglas y herramientas que se cargan en el asistente) no son malas por sí mismas. El problema es cargarlas todas, todo el tiempo, sin criterio. Eso desencadena tres patologías bien documentadas en los modelos de lenguaje.

1. Prompt bloat: el contexto saturado

Cuando el entorno inyecta muchas skills de forma estática, el modelo recibe al mismo tiempo decenas de esquemas de herramientas, reglas y restricciones que no tienen nada que ver con la tarea que le pediste.

Los análisis sobre degradación del razonamiento recopilados por la comunidad de MLOps muestran caídas medibles en la calidad de la respuesta desde unos 3.000 tokens de instrucciones densas, aunque la ventana de contexto aguante cientos de miles más. Que el modelo pueda leer un millón de tokens (como vimos en el análisis de Gemini 4 Argon) no significa que preste la misma atención a todo.

2. Lost in the Middle: lo del medio se pierde

Los modelos recuerdan mucho mejor lo que está al principio y al final del contexto que lo que queda en la mitad. En un contexto inflado de skills, tus reglas de diseño y tus contratos funcionales suelen quedar justo en esa zona muerta. Resultado: el agente “olvida” instrucciones (lo que se conoce como instruction drift) y falla en los casos límite.

3. Zero-shot: cuando la IA rellena los huecos con promedios

Si le pides algo sin especificación, el modelo tiene que adivinar. Y cuando adivina, se va al centro estadístico de su entrenamiento: paletas pastel, botones con bordes súper redondeados, componentes monolíticos y clases duplicadas. Es la misma lógica que hace que todo el contenido generado por IA suene igual (algo de lo que ya hablamos en ¿El SEO murió con la IA?): sin contexto propio, obtienes el promedio de internet.

La alternativa: que la especificación mande, no el prompt

La respuesta de la ingeniería de software moderna se llama Desarrollo Guiado por Especificaciones (Spec-Driven Development o SDD). La idea es simple: en lugar de que el centro del trabajo sea el chat con la IA, el centro es un documento de especificación que sirve de fuente de verdad tanto para las personas como para los agentes.

La premisa clave es separar el qué del cómo. Tú defines qué debe hacer la funcionalidad, sus reglas y criterios de aceptación; la IA se encarga de la sintaxis, pero no improvisa la lógica de negocio.

En un análisis publicado en el sitio de Martin Fowler se distinguen tres niveles de adopción:

• Spec-first: escribes la especificación antes del código, pero después se queda desactualizada en un cajón.
• Spec-anchored: la especificación vive en el repositorio y evoluciona junto con el código, con pruebas automáticas como puente. Es el punto más sano para la mayoría de equipos.
• Spec-as-source: la especificación es lo único que editas y el código es un subproducto generado. Suena bonito, pero revive los problemas del viejo desarrollo dirigido por modelos (UML): si no hay verificación determinista, la naturaleza probabilística del modelo genera diferencias entre lo que pediste y lo que corre.

Otro detalle importante es diferenciar dos tipos de documentos:

• Memoria permanente (AGENTS.md, CLAUDE.md, constitution.md): convenciones, arquitectura, seguridad y dependencias permitidas. Casi no cambia.
• Especificaciones de cada cambio (spec.md): requisitos, contratos y criterios de aceptación de una funcionalidad puntual. Viven en su rama y se cierran con ella.

Contratos tipados: reduce el espacio donde la IA puede equivocarse

Aquí está, para mí, el truco más subestimado de todos. Cuando le das al asistente una interfaz estricta (en TypeScript, un esquema OpenAPI o un modelo de Pydantic), el modelo ya no tiene que adivinar qué entra ni qué sale. Toda su capacidad se concentra en resolver la lógica interna.

// Contrato de dominio para el cálculo del checkout
export interface CartItem {
  readonly sku: string;
  readonly quantity: number;
  readonly unitPriceInCents: number;
}

export interface CheckoutResult {
  readonly subtotalInCents: number;
  readonly discountAppliedInCents: number;
  readonly totalInCents: number;
  readonly currency: "EUR" | "USD";
}

export interface CheckoutCalculator {
  calculateTotal(
    items: ReadonlyArray<CartItem>,
    policy?: DiscountPolicy,
  ): Either<ValidationError, CheckoutResult>;
}

Un problema abierto («hazme el checkout») se convierte en uno acotado («implementa esta firma»). Es la misma filosofía que defendimos con JEV y los modelos System One: cuanto más estructurada la salida esperada, menos espacio para el desastre.

Esto se complementa con la divulgación progresiva (Progressive Disclosure): el agente solo recibe el contexto indispensable para el bloque de trabajo actual, no todo el repositorio ni el catálogo completo de herramientas. Contexto limpio = menos Lost in the Middle.

TDD en bucle cerrado: que las pruebas no las escriba el acusado

Hay una trampa muy común cuando le pides a la IA el código y las pruebas al mismo tiempo: la inversión de pruebas (test inversion). El modelo escribe una implementación con errores y luego escribe pruebas que validan exactamente esos errores. Todo sale en verde y tú tienes una falsa sensación de seguridad.

La solución es la disciplina clásica de TDD (Rojo, Verde, Refactor):

1. Rojo: la especificación se traduce primero en pruebas que fallan porque todavía no hay implementación. Tú confirmas que fallan.
2. Verde: la IA escribe el código mínimo para que pasen. Si algo falla, la salida de la consola se le devuelve al modelo para que se corrija (bucle cerrado).
3. Refactor: se limpia y modulariza, con la condición de que toda la suite siga en verde.

Cualquier intento de inventar dependencias o saltarse un caso límite se estrella contra una prueba que falla. Eso es determinismo, no fe.

Tu propio sistema de diseño: para que la IA no te entregue la misma app pastel de siempre

Si delegas la interfaz a una skill genérica, el modelo no tiene restricciones sobre proporciones, espacios ni contraste. La solución es darle un sistema de diseño que pueda leer y respetar.

Design tokens en capas (estándar DTCG)

Los tokens son las decisiones visuales convertidas en datos. El estándar del Design Tokens Community Group (DTCG) propone JSON con propiedades tipadas ($value, $type) organizado en tres capas:

• Primitivos: valores puros (colores, escala de espaciado en múltiplos de 4 u 8 px, tipografías).
• Semánticos: el propósito de cada valor (surface.canvas, action.primary), apuntando a un primitivo.
• De componente: propiedades exclusivas de un elemento, como la altura del botón principal.

{
  "color": {
    "primitive": {
      "neutral-100": { "$value": "#f1f5f9", "$type": "color" },
      "brand-500": { "$value": "#3b82f6", "$type": "color" }
    },
    "semantic": {
      "surface": {
        "canvas": {
          "$value": "{color.primitive.neutral-100}",
          "$type": "color"
        }
      },
      "action": {
        "primary": { "$value": "{color.primitive.brand-500}", "$type": "color" }
      }
    }
  }
}

Con herramientas como Style Dictionary, esos JSON se compilan automáticamente a variables CSS, tipos de TypeScript o configuración de Tailwind. Así la IA trabaja con valores cerrados y queda prohibido meter un hexadecimal “a ojo”.

La pila de documentos que el agente sí lee

Los tokens dicen qué valores existen, pero no cuándo usarlos. Para eso, los repositorios modernos usan una pila de cuatro capas:

• AGENTS.md / CLAUDE.md: corto y al grano. Reglas globales, comandos y una orden clara: antes de tocar código visual, lee la documentación de diseño.
• PRODUCT.md: identidad, propuesta de valor y, muy importante, qué estilos están prohibidos.
• DESIGN.md: el contrato de la interfaz: escala tipográfica, retícula, estados interactivos (reposo, hover, foco, presionado, deshabilitado), reducción de movimiento y la regla de reutilizar componentes antes de crear nuevos.
• examples/: componentes aprobados, con un README.md que dice quién los aprobó, cuándo y para qué sirven, para que un prototipo viejo no se vuelva regla por accidente.

Y para cerrar el círculo, linters que validan que los tokens no apunten a referencias rotas y que los contrastes cumplan WCAG.

El paso a paso: construir una app modular con IA en 5 fases

1. Constitución del sistema. Antes de una sola línea de código, escribe el AGENTS.md o CLAUDE.md: versiones exactas, comandos de build y pruebas, tecnologías vetadas, patrones obligatorios (por ejemplo, arquitectura hexagonal) y convenciones de nombres.
2. Sistema de diseño. Define tus tokens en DTCG, compílalos con Style Dictionary y redacta tu DESIGN.md con las reglas de accesibilidad.
3. Especificación y contratos. Para cada funcionalidad, escribe un spec.md con propósito, flujos de usuario y criterios de aceptación. Pídele a la IA que actúe de auditor socrático: que te encuentre casos de error, límites de escala y dependencias que no viste. Luego escribe tú los contratos de tipos.
4. Implementación con TDD. Pruebas en rojo, código mínimo en verde, refactor sin romper nada. Los errores de consola vuelven al modelo hasta que todo pase.
5. Validación y consolidación. Corre la suite completa de regresión, revisa que no haya estilos “quemados” fuera de los tokens, audita accesibilidad (ARIA, foco de teclado) y haz commit del código junto con su especificación.

Fíjate que en ninguna fase la IA decide sola. Es el mismo principio que aplicamos al clasificar texto con JEV y modelos Flash: lo determinista se resuelve con código y reglas; el modelo entra donde de verdad aporta.

En resumen: menos coleccionista, más arquitecto

La fiebre de instalar skills como si fueran stickers privilegia la velocidad del primer demo sobre la salud del software. Inundar el contexto con herramientas ajenas solo aumenta la probabilidad de olvidos, deriva de instrucciones e interfaces que se ven iguales a las de todo el mundo.

La aceleración real con IA viene de aplicar con más rigor los fundamentos de siempre: especificaciones vivas, contratos tipados, tokens de diseño y pruebas primero. (Y si quieres el argumento de fondo de por qué el criterio vale más que nunca, lo desarrollo en La IA abarató el conocimiento, no el criterio.)

Tu trabajo deja de ser escribir prompts y pasa a ser diseñar el contexto y los contratos. Y cuando haces eso bien, la IA deja de ser un oráculo que a veces alucina y se convierte en lo que debería ser: un compilador semántico muy rápido, trabajando bajo tus reglas.

Fuentes y lecturas recomendadas

• Martin Fowler: Understanding Spec-Driven Development: Kiro, spec-kit, and Tessl.
• GitHub Blog: Spec-driven development with AI: Get started with a new open source toolkit.
• IBM: What is Spec-Driven Development?.
• MLOps Community: The Impact of Prompt Bloat on LLM Output Quality.
• Augment Code: Spec + TDD: The Combination That Actually Produces Shippable AI Code.
• Design Tokens Community Group: Design Tokens Format Module.
• Developers Digest: DESIGN.md: The Contract That Keeps AI Agents On Brand.
• Artículos relacionados en este blog:
  • JEV y el Paradigma System One
  • Clasificar Texto Sucio a Gran Escala con JEV y Modelos Flash
  • JEV vs. Laya: Comparativa Real en Inferencia System One
  • Gemini 4 Argon: el salto al millón de tokens de salida
  • ¿El SEO murió con la IA?
  • La IA abarató el conocimiento, no el criterio
  • Attention Is All You Need: el paper Transformer explicado
  • Vibe coding sin Git es manejar sin frenos: qué es un control de versiones