Desarrollo basado en especificaciones para agentes de IA
El desarrollo basado en especificaciones (SDD) es una práctica en la que una especificación escrita y testeable — requisitos y criterios de aceptación — es la fuente de verdad contra la que se construye y se verifica el código. En lugar de ir directamente de un prompt o un ticket al código, primero acuerdas qué debe hacer el software y luego construyes según esa especificación. Ahora que los agentes de IA escriben gran parte del código, la especificación es lo que los mantiene construyendo lo correcto.
- La especificación es la fuente de verdad; el código se deriva de ella y se contrasta con ella.
- Los requisitos van acompañados de criterios de aceptación explícitos, así "terminado" es testeable, no subjetivo.
- Los agentes de IA consultan la especificación para conocer la intención en vez de adivinarla a partir del código — menos construcciones erróneas.
- Es complementario al desarrollo basado en tests, no un sustituto de él.
Última actualización: mayo de 2026
¿Qué es el desarrollo basado en especificaciones?
El desarrollo basado en especificaciones invierte el orden habitual del trabajo. En lugar de tratar la especificación como documentación escrita a posteriori — o de saltársela por completo — el SDD convierte la especificación en el artefacto principal. El código, los tests y la revisión remiten todos a ella.
Una especificación en este sentido no es un muro de prosa. Es estructurada: un conjunto derequisitos, cada uno con criterios de aceptaciónexplícitos que indican, en términos testeables, qué debe ser cierto para que el requisito se considere satisfecho. Esa estructura es lo que permite que un revisor, una suite de tests y un agente de IA interpreten todos el mismo documento de la misma manera.
La especificación es además un artefacto vivo. Cuando los requisitos cambian, la especificación cambia primero y el código la sigue — de modo que la especificación nunca deriva hacia la ficción.
Por qué importa ahora: la IA subió lo que está en juego
Los agentes de IA de programación generan código mucho más rápido de lo que una persona puede leerlo. Eso desplaza el cuello de botella. La parte difícil ya no es escribir la implementación — esespecificar la intención con suficiente claridad como para que el código generado sea el código que querías. A un agente al que se le da un prompt vago producirá con seguridad algo plausible y equivocado, y a velocidad de máquina.
La especificación es la baranda de seguridad. Cuando el comportamiento previsto y los criterios de aceptación están escritos, el agente tiene un objetivo inequívoco hacia el que construir y una lista de comprobación contra la que verificar — y un revisor humano tiene algo fijo que aprobar antes de que exista ningún código. El SDD es la forma en que los equipos evitan que la velocidad de la IA se convierta en retrabajo de la IA.
Cómo funciona el desarrollo basado en especificaciones
El workflow es un bucle, no un documento puntual:
- Captura la intención. Registra la dirección a medio formar — el problema, el objetivo, las preguntas abiertas — antes de comprometerte con una solución.
- Especifica el comportamiento. Convierte la dirección acordada en requisitos, cada uno con criterios de aceptación explícitos y testeables.
- Descompón en un plan. Divide la especificación en tareas ordenadas, cada una citando los criterios de aceptación que satisface.
- Implementa. Construye tarea a tarea — una persona o un agente de IA — según la especificación.
- Verifica contra los criterios. Comprueba el resultado contra los criterios de aceptación, no contra una intuición.
- Mantén la especificación viva. Cuando los requisitos cambien, actualiza la especificación primero; el código la sigue.
Beneficios del desarrollo basado en especificaciones
- Los desacuerdos afloran durante la revisión de la especificación — barato — en lugar de después de la implementación — caro.
- "Terminado" es objetivo, porque los criterios de aceptación son testeables.
- La especificación es contexto compartido para todos: producto, ingeniería y agentes de IA.
- Los cambios son trazables — cada tarea remite a los criterios que satisface.
Por qué ayuda específicamente a los agentes de IA
- Intención legible por máquina: el agente lee los requisitos directamente en lugar de inferirlos del código.
- Menos contexto que cargar: el agente consulta la porción relevante de la especificación en vez de todo el repositorio.
- Salida verificable: los criterios de aceptación dan al agente un objetivo concreto de aprobado/fallido.
- Trazabilidad: el código generado puede vincularse de vuelta al requisito que lo motivó.
Desarrollo basado en especificaciones frente a prácticas relacionadas
| Práctica | Fuente de verdad | Relación con el SDD |
|---|---|---|
| Desarrollo basado en tests | Tests que fallan a nivel de código | Complementario — los criterios de aceptación se convierten en los tests. |
| PRD tradicional | Prosa escrita para personas | Menos estructurado; no es directamente testeable ni legible por máquina. |
| Solo prompts ("vibe coding") | El prompt y la conjetura del modelo | Sin un objetivo duradero y revisable — lo que el SDD existe para arreglar. |
Para una comparación detallada de SpecScore frente a otras herramientas de especificaciones, consultalas páginas de comparación.
Compromisos y cuándo no usarlo
El desarrollo basado en especificaciones no es gratis. Adelanta el esfuerzo hacia pensar y escribir antes de que se ejecute código alguno, lo cual es el trato equivocado para un script puntual o un experimento desechable. Y una especificación solo ayuda si se mantiene al día — una especificación abandonada se vuelve engañosa, peor que ninguna. El SDD compensa cuando el trabajo es lo bastante grande como para planificarse, va a mantenerse, o se va a entregar a un agente de IA para construirlo a gran escala.
Hacer desarrollo basado en especificaciones con agentes de IA en la práctica
Para hacer SDD con agentes de IA necesitas dos cosas: un formato de especificación legible por máquina que tanto tu equipo como tus agentes entiendan, y una forma de que los agentes lean, escriban y validen esas especificaciones.
SpecScore es una implementación de exactamente eso. Es un formato abierto de Markdown + YAML para features, requisitos y criterios de aceptación — archivos planos en tu repositorio — emparejado con una CLI que tus agentes invocan para consultarlos, editarlos y hacerles lint. Como la estructura es legible por máquina, un agente puede preguntar "¿qué debería construir a continuación?" y recibir los requisitos abiertos y sus criterios de aceptación, y luego contrastar su trabajo con ellos. Es agnóstico de herramientas y open source.
Empieza con los Skills de IA para tu agente de programación oinstala la CLI.
Preguntas frecuentes
¿Es el desarrollo basado en especificaciones lo mismo que el desarrollo basado en tests?
No. El TDD guía la implementación a partir de tests que fallan, a nivel de código. El desarrollo basado en especificaciones trabaja un nivel por encima: primero fija el comportamiento previsto y los criterios de aceptación en una especificación escrita. Son complementarios — los criterios de aceptación de una especificación a menudo se convierten en los tests que luego guían el TDD.
¿El desarrollo basado en especificaciones te ralentiza?
Añade tiempo antes de escribir código y elimina el tiempo dedicado a reconstruir lo que no era. Para scripts desechables el coste no compensa. Para cualquier cosa que un agente de IA genere a gran escala, o que un equipo deba mantener, escribir la especificación primero suele ser más rápido de principio a fin.
¿Cuál es la diferencia entre una especificación y un PRD?
Un PRD suele ser prosa dirigida a personas. Una especificación en el desarrollo basado en especificaciones es estructurada y testeable — requisitos discretos con criterios de aceptación explícitos — de modo que tanto los revisores como los agentes de IA puedan actuar sobre ella con precisión.
¿Cómo usan una especificación los agentes de IA de programación?
Cuando la especificación es legible por máquina, el agente la consulta para obtener los requisitos y criterios de aceptación relevantes para su tarea actual en lugar de cargar todo el codebase, y luego compara su resultado con esos criterios — una salvaguarda frente al código plausible pero incorrecto.