Análisis / Desarrollo y agentes
Spec-driven development: cuándo ayuda a programar con IA
Escribir lo que debe hacer una función puede evitar malentendidos. La cuestión es cuánto detalle necesita la tarea y si mantener esa especificación mejora el resultado tanto como cuesta prepararla.
Qué es el desarrollo guiado por especificaciones
El spec-driven development, o SDD, utiliza una especificación explícita para orientar la implementación y su validación. En un flujo con IA, ese documento ayuda a comunicar el comportamiento esperado al agente y a quienes revisan su trabajo.
Kiro organiza sus specs en requisitos o análisis del error, diseño y tareas. Spec Kit propone un conjunto de herramientas para trabajar desde especificaciones. Son formas de estructurar el proceso; la documentación producida todavía necesita revisión.
Cuándo compensa escribir una especificación
Resulta especialmente útil cuando hay reglas de negocio, varios participantes o decisiones que deben mantenerse durante semanas. Para una corrección pequeña, puede bastar con explicar el error, el comportamiento esperado y lo que debe conservarse.
Una especificación práctica debería permitir responder:
- Qué problema resuelve el cambio y para quién.
- Qué entradas y resultados se esperan.
- Qué límites y permisos se aplican.
- Qué ocurre en los casos de error.
- Cómo se decidirá que el trabajo está terminado.
La longitud no es una medida de calidad. Si dos requisitos se contradicen, añadir más páginas no resuelve la ambigüedad.
Un ejemplo de requisito que se puede comprobar
«Mejorar la búsqueda» deja demasiado abierto. «Permitir buscar productos por referencia exacta y mostrar un estado vacío cuando no haya coincidencias» define una conducta verificable.
Todavía habrá decisiones por aclarar: mayúsculas, espacios, referencias incompletas y permisos de acceso. Resolverlas antes de implementar puede evitar cambios posteriores.
Mantén la especificación junto al código y actualízala cuando cambie el comportamiento aprobado. Un documento obsoleto puede orientar mal tanto a una persona como a un agente.
Qué demuestra la evidencia disponible
Los estudios sobre productividad con IA no deben presentarse automáticamente como pruebas a favor o en contra del SDD. METR explicó en febrero de 2026 que su experimento con desarrolladores afrontaba problemas de selección de tareas y participantes, y que cambiaría el diseño.
Esa cautela importa: una medición en un grupo, unas herramientas y unos repositorios no describe todos los equipos. Tampoco basta con sentir que el proceso es más rápido.
Cómo probarlo en tu equipo
Compara cambios de alcance parecido. Cuenta el tiempo de especificación, implementación, revisión y corrección. Registra defectos, requisitos olvidados y trabajo rehecho.
Define de antemano qué mejora buscas: menos ambigüedad, menos errores o una incorporación más sencilla de otra persona. Si el documento cuesta más de lo que aporta, reduce su detalle.
Para las instrucciones permanentes del repositorio, consulta cómo escribir un AGENTS.md útil. La especificación de una función y las normas generales del proyecto cumplen papeles diferentes.
Para probarlo en un encargo real, cuéntanos qué parte del trabajo se repite y dónde se pierde el tiempo.
Fuentes
Comprobado el 20 de septiembre de 2026