¿Por qué Spec-Driven Development está fallando y cómo lo reemplaza Intent-Driven Software Development (IDSD)?

El auge de la programación asistida por inteligencia artificial popularizó el Spec-Driven Development (SDD) como respuesta al fracaso del vibe coding (programar por simple intuición o prompts informales). Sin embargo, escribir especificaciones masivas desde cero resulta inviable en la práctica corporativa. Intent-Driven Software Development (IDSD) evoluciona este concept dividiendo la especificación en tres disciplinas claras mediante el framework ICE (Intent, Context, Expectations), obligando al desarrollador a mantener la presencia en el bucle de control en lugar de delegar el criterio de aceptación a la máquina.

Tabla de contenidos

• La ilusión de la especificación completa y el fracaso de SDD
• El Framework ICE: Dividir para Conquistar
• Anatomía de un archivo ICE (Ejemplo Práctico)
• El bucle de ejecución de IDSD
• El peligro de estar "acertadamente equivocado a gran velocidad"
• Para no morir en el intento y consejos que no pediste
• Reflexión Final

El desarrollo de software con inteligencia artificial ha pasado por una rápida transición. Inicialmente, el vibe coding (término acuñado por Andrej Karpathy) dominó la escena: los desarrolladores describían ideas vagas y esperaban código funcional. Al ver que este enfoque producía código inestable y alucinaciones en proyectos reales, la industria buscó refugio Spec-Driven Development (SDD). No obstante, las especificaciones masivas escritas de forma arbitraria abren brechas lógicas que los agentes de IA se ven obligados a adivinar. IDSD surge como la respuesta metodológica que profesionaliza este proceso, definiendo con exactitud qué debe hacer el humano y qué debe ejecutar la máquina.

La ilusión de la especificación completa y el fracaso de SDD

La idea de escribir especificaciones antes de codificar no es nueva; metodologías ágiles de diseño y contratos de software han intentado esto durante décadas. Sin embargo, en la era de la inteligencia artificial, el movimiento de Spec-Driven Development (SDD) ha caído en una trampa metodológica: la ilusión de que podemos (y debemos) redactar especificaciones masivas y ultra-detalladas por adelantado.

Intentar definir de forma manual especificaciones monumentales como los extensos y complejos protocolos de integración que vemos en iniciativas abiertas (por ejemplo, el Model Context Protocol de Anthropic) o specs internas de más de 1,500 lineas resulta inviable en entornos de producción por tres razones fundamentales:

1. El costo cognitivo inicial: Escribir y estructurar una especificación gigante en Markdown antes de generar el código requiere un esfuerzo de diseño mental enorme. Si el desarrollador pasa horas detallando firmas de funciones, tipos y flujos, se pierde la principal ventaja de la IA: la velocidad de desarrollo.
2. La naturaleza estadística de los LLMs: Un modelo de lenguaje no compila una especificación; la interpreta de forma probabilística. Incluso a temperatura 0.0, textos muy extensos o formateados de forma compleja sufren de inconsistencias de interpretación entre modelos (como pasar de Claude 3.5 Sonnet a GPT-4o o Gemini), lo que obliga al desarrollador a ajustar constantemente la redacción de la spec para que la IA "entienda" lo mismo.
3. El mantenimiento y el Specification Drift: Mantener sincronizada una especificación de mil líneas con una base de código real que cambia todos los días es una batalla perdida. Al primer cambio rápido en producción que no se documente en la spec, todo el sistema de generación de código guiada por especificaciones se rompe.

La industria suele mostrar especificaciones impecables de grandes proyectos como si hubieran sido escritas al inicio del desarrollo, cuando en realidad son documentación retrospectiva generada después de que el software ya funcionaba. Escribir ese nivel de detalle de antemano es simplemente incompatible con el desarrollo empresarial moderno.

El Framework ICE: Dividir para Conquistar

Para evitar que los ingenieros redacten especificaciones caóticas llenas de vacíos que los agentes de IA tengan que descifrar, IDSD propone desglosar el problema en tres disciplinas independientes bajo las siglas ICE:

1. Intent (Intención) - El "Qué"

Es el punto de partida y representa el resultado de negocio que el humano desea obtener, sin acoplarlo a una pila tecnológica o servicio específico. Una intención bien estructurada consta de cinco partes indispensables:

• Descripción: Qué es lo que se desea (ej. "el usuario quiere comprar un zapato rojo por menos de 90 dólares").
• Restricciones (Constraints): Límites de negocio (ej. el artículo debe estar en stock y con entrega disponible).
• Escenarios de fallo: Cuándo no se cumple la intención (ej. que retorne un zapato de 140 dólares o uno azul).
• Escenarios de éxito: El camino feliz (ej. añadir al carrito y finalizar la compra del calzado económico).
• Conexiones: Enlaces hacia otras intenciones que se ven afectadas por este cambio (inventario, pasarela de pago).

2. Expectations (Expectativas) - El Límite de Aceptación

Es el conjunto de condiciones bajo las cuales el resultado final se considera terminado (done). Deben estar escritas en términos de comportamiento de usuario o negocio en lugar de lenguaje técnico. Mantener esta disciplina separada evita que la IA autojustifique su código decidiendo de forma autónoma cuándo ha terminado la tarea.

3. Context (Contexto) - El "Cómo"

Representa la arquitectura del sistema actual, el estado del codebase y las limitaciones técnicas. En lugar de incluir todo esto en un solo documento masivo al inicio del prompt, el contexto debe ser suministrado e inyectado de forma progresiva por el arnés de ejecución (harness) a medida que el agente lo necesita.

Vibe Coding vs. SDD vs. IDSD

Anatomía de un archivo ICE (Ejemplo Práctico)

En la práctica, un desarrollador documenta el Intent y las Expectations en un archivo estructurado ligero, dejando que el arnés inyecte el Context de forma dinámica. A continuación se muestra un ejemplo práctico en formato Markdown para la misma feature de Rate Limiter:

# Intent: Proteger los Endpoints de la API

## 1. Descripción
El sistema debe evitar el abuso de peticiones limitando el tráfico por cliente.

## 2. Restricciones (Constraints)
- Usar un algoritmo de Token Bucket.
- Solo se permite Go estándar y la biblioteca go-redis oficial.

## 3. Escenarios de éxito
- Un cliente que realiza peticiones por debajo del límite obtiene una respuesta HTTP 200 y headers de control correctos.

## 4. Escenarios de fallo
- Si un cliente excede el límite asignado (ej. 60 peticiones/min), las peticiones siguientes deben bloquearse inmediatamente retornando HTTP 429.

# Expectations: Criterios de Aceptación

1. El middleware debe interceptar todas las llamadas HTTP antes de llegar a los handlers de negocio.
2. Si el cliente supera el límite, la API debe responder con el status code 429 (Too Many Requests).
3. Todas las respuestas HTTP (tanto de éxito como de error de tasa) deben incluir la cabecera `X-RateLimit-Remaining`.
4. El tiempo de respuesta añadido por la verificación de límite no debe exceder los 2ms en promedio.

Este formato permite que el desarrollador defina la lógica de negocio y las expectativas de validación en minutos, sin tener que detallar la implementación técnica exacta que la IA debe resolver.

El bucle de ejecución de IDSD

En IDSD, el programador nunca abandona el bucle de control, sino que mantiene la propiedad del diseño conceptual.

Figura 1: El flujo de Intent-Driven Software Development con división de responsabilidades.

• El Humano: Define únicamente la intención y las expectativas asociadas a la funcionalidad.
• El Arnés (Harness): Extrae el contexto adecuado del codebase, alimenta al agente de código y valida que los resultados cumplan las expectativas. El arnés (como spec-kit, BMAD u otros) es solo la herramienta mecánica; IDSD es el método estratégico.

El peligro de estar "acertadamente equivocado a gran velocidad"

Cuando los agentes operan sin una intención clara y supervisión constante, surge lo que se conoce como desviación del diseño. A menudo, el desarrollador se aparta del bucle confiando en que el agente resolverá los vacíos de la especificación.

En 2025, un estudio controlado realizado por METR demostró que los desarrolladores experimentados que utilizaban IA para programar eran mediblemente más lentos en la entrega de software correcto, pero terminaban el ejercicio con la firme convicción de haber sido mucho más rápidos. Esto se debe a que la IA facilita generar miles de líneas de código que "parecen correctas" pero que están equivocadas en su lógica fundamental.

Corregir el código generado de forma errónea por un agente puede llegar a ser sumamente costoso. Un desvío de tres días por falta de presencia humana en el bucle puede representar cientos de dólares en costos de tokens y días de refactorización manual para deshacer el trabajo incorrecto.

Para no morir en el intento y consejos que no pediste

Hacer la transición hacia un desarrollo guiado por la intención requiere evitar vicios comunes de la programación tradicional asistida por IA:

1. No dejes que la IA redacte las Expectativas

Es de los errores más comunes: pedirle a la IA "Lee mi intención y escribe los criterios de aceptación por mí". Esto destruye la división de responsabilidades. Si la IA define las reglas con las que será evaluada, ajustará las expectativas para que se adapten a las limitaciones de su propio código autogenerado, permitiendo fallos lógicos graves en producción.

2. Evita la sobrecarga de contexto

No alimentes al agente de IA con todo tu repositorio desde el inicio. El exceso de información incrementa el ruido contextual, degrada la precisión de los modelos de lenguaje y eleva drásticamente el costo de tokens. Deja que tu arnés de desarrollo inyecte únicamente los archivos relevantes del módulo en el que estás trabajando.

3. Mantente en el bucle de control (Human in the Loop)

Tu trabajo en IDSD no es escribir código, es evaluar si el código generado cumple rigurosamente con tus expectativas. No apruebes Pull Requests ni hagas merge de ramas de forma automática solo porque los tests del arnés pasaron. La validación semántica e integradora sigue requiriendo tu criterio técnico.

Reflexión Final

La diferencia entre el éxito y el fracaso al programar con IA no reside en la potencia del modelo de lenguaje o en la herramienta de automatización que descargues. Reside en la disciplina. El desafío no es si tu agente puede generar el código (los agentes actuales son capaces de hacerlo), sino si tienes la disciplina de especificar la intención y las expectativas por ti mismo, y el temple de mantenerte presente en el bucle observando la ejecución en lugar de limitarte a aprobar ciegamente los cambios al final del día.

Puntos clave a recordar:

• ICE divide las responsabilidades: El humano define la intención (Intent) y la meta (Expectations); el software inyecta la realidad del codebase (Context).
• Evita el auto-criterio de la máquina: La IA jamás debe escribir ni redefinir las expectativas bajo las cuales se evaluará su trabajo.
• La velocidad sin dirección es costosa: Generar código erróneo a gran velocidad solo genera deuda técnica que tardarás horas en corregir de forma manual.

Si estás dando tus primeros pasos y quieres entender cómo estructurar especificaciones robustas antes de migrar a la intención pura, te recomendamos leer nuestro artículo previo sobre ¿Cómo transforma Spec-Driven Development la forma en que programamos con IA?.

¿Y tú? ¿Sigues batallando escribiendo especificaciones detalladas para tus asistentes de IA, o estás listo para delegar el código enfocándote únicamente en tu intención?