¿Qué es el desarrollo basado en especificaciones?
El desarrollo basado en especificaciones (SDD) es una metodología de software en la que se redacta y se acuerda una especificación detallada de los pormenores de la implementación antes de que comience el desarrollo. En otras palabras, sirve como única fuente fiable sobre qué hay que crear y cómo hacerlo.
Con la disponibilidad de herramientas de IA y asistentes de codificación, como GitHub Copilot de Microsoft, Claude Code de Anthropic o Bob de IBM, se ha reducido la barrera de entrada a la generación de código. Un agente de IA basado en LLM que utiliza sofisticados modelos de IA puede ejecutar una serie de tareas iterativas en tiempo real en cualquier momento, todo ello con una única instrucción en lenguaje natural por parte del usuario.
Para el desarrollo de software, esto significa que podemos optimizar y automatizar el flujo de trabajo de desarrollo para crear prototipos, nuevas características, pruebas unitarias y otros elementos. Nunca ha sido tan fácil generar código. Sin embargo, existe un terreno resbaladizo del que los programadores de vibe coding deben ser conscientes: la IA solo es tan buena como las instrucciones que recibe.
Es probable que haya visto la deuda técnica en el mundo real, tal vez sin siquiera darse cuenta. La deuda técnica es anterior al vibe coding y lleva décadas formando parte del desarrollo de software, acumulándose cuando se toman atajos en aras de la rapidez. Sin embargo, el vibe coding acelera la deuda técnica al facilitar la generación de grandes cantidades de código sin comprenderlo ni validarlo plenamente. Quizá exista la presión de lanzar el producto rápidamente, o tal vez el programador de vibe coding simplemente no cuente con los conocimientos técnicos necesarios para frenar la deuda técnica antes de que se genere.
La deuda técnica en el desarrollo asistido por IA puede adoptar varias formas:
- La deriva contextual se produce cuando la corrección de un error en un área afecta de forma involuntaria al funcionamiento de otra, un síntoma de que el código se generó sin una comprensión completa del sistema en su conjunto.
- La fragmentación es otra manifestación habitual, en la que las nuevas características generadas no se ajustan a las convenciones de arquitectura existentes, lo que erosiona gradualmente la coherencia y la facilidad de mantenimiento del código base.
- También hay que tener en cuenta el coste operativo. Sin una especificación clara que sirva de base para el proceso de generación, los desarrolladores pueden verse atrapados en largos ciclos de instrucciones. Este enfoque puede consumir miles de tokens para resolver errores que una especificación bien definida habría evitado por completo.
Imagine una situación que muchos desarrolladores del sector conocen bien. Lleva varios días o semanas trabajando en una nueva característica, que está casi lista para su lanzamiento. Entonces, bajo la presión de una fecha límite que se acerca, se apresura a realizar los ajustes finales mediante una serie de cambios generados por IA.
Las funciones del código generado, ya sea escrito en Python u otro lenguaje, pueden parecer correctas desde la perspectiva del usuario. Sin embargo, en el proceso se han expuesto varias vulnerabilidades, se han introducido conflictos de dependencias y se ha olvidado por completo el tratamiento y las pruebas de casos límite.
Una especificación formal establecida desde el principio proporciona al equipo una fuente fiable común para gobernar cada fase del ciclo de vida del desarrollo de software (SDLC), independientemente de quién haya escrito el código.
Existen varios enfoques y plantillas para el desarrollo basado en especificaciones, con distintos niveles de mantenimiento de las mismas y diferentes compensaciones. Más que una progresión estricta hacia lo “mejor”, la elección adecuada depende de su código base, su equipo y el ámbito del problema. Tenga en cuenta las necesidades y limitaciones de su equipo antes de seleccionar uno.
Desarrollo centrado en las especificaciones
En el desarrollo centrado en las especificaciones, la especificación se redacta antes de generar ningún código, en forma de historia de usuario, criterios de aceptación o un documento formal de requisitos. Una vez que se ha proporcionado la claridad inicial y se ha generado el código, la especificación no se mantiene necesariamente.La especificación podría quedar obsoleta a medida que el software evoluciona. Su objetivo principal era proporcionar claridad inicial sin necesidad de un mantenimiento continuo de la especificación. Este aspecto se considera el “punto de entrada al SDD”1.
Desarrollo anclado en especificaciones
En el desarrollo anclado en especificaciones, la especificación evoluciona junto con el software. A medida que cambian los requisitos y se añaden características, la especificación se actualiza para reflejar el estado actual del sistema. Esto resulta especialmente útil para proyectos que forman parte de iniciativas de mayor envergadura.
Las pruebas automatizadas sirven de puente entre la documentación y la implementación, y a menudo se integran en una canalización de CI/CD para garantizar que ambas permanezcan sincronizadas y sean ejecutables a lo largo de todo el ciclo de vida del desarrollo. Este equilibrio entre estructura y flexibilidad convierte al desarrollo anclado en especificaciones en un enfoque práctico y escalable para la mayoría de los equipos de ingeniería1.
Desarrollo de especificaciones como fuente
En el extremo opuesto del espectro se encuentra el desarrollo de especificaciones como fuente, la forma más centrada en la IA. En el desarrollo de especificaciones como fuente, los cambios en las especificaciones desencadenan automáticamente cambios en el código. Ningún ser humano refactoriza nunca directamente el código.
Este nivel de autoridad de las especificaciones exige un alto grado de confianza en la calidad y la coherencia de la canalización de código mediante IA, que a día de hoy sigue siendo intrínsecamente no determinista. En la práctica, esto significa que puede resultar menos riguroso sin una estricta supervisión humana. Antes de adoptar este enfoque, los equipos deben evaluar cuidadosamente la madurez de su pila tecnológica y su kit de especificaciones, la criticidad de los sistemas implicados y su capacidad para validar los resultados generados por la IA1.
Enfoques híbridos
En la práctica, muchos equipos adoptan enfoques híbridos:
- Tratar las especificaciones como artefactos versionados y apilables, como los registros de decisiones de arquitectura (ADR), en lugar de mantenerlas siempre totalmente actualizadas.
- Utilizar sistemas externos (por ejemplo, gestores de incidencias) como fuente fiable para introducir una separación intencionada.
- Evitar una automatización excesiva en proyectos de alta complejidad o impulsados por la comunidad, en los que un control estricto de los cambios es crítico.
Cada enfoque tiene sus puntos fuertes y sus limitaciones; el contexto es más importante que la adhesión estricta a un modelo concreto.
Según el nivel de autoridad en materia de especificaciones que prefiera, una especificación eficaz puede presentar un aspecto diferente. Sin embargo, suponiendo que se sitúe en algún punto intermedio del espectro y opte por un desarrollo anclado en especificaciones, estas deben describir qué debe hacer el sistema en términos claros y comprobables. Esta especificación evita que se vea limitado prematuramente a cómo se implementará.
La especificación debe ser lo suficientemente detallada como para incluir definiciones de entrada y salida, el esquema de datos, los casos límite y los criterios de éxito. No obstante, debe ser lo suficientemente ágil como para evolucionar a medida que se comprenda mejor el problema. Por encima de todo, una buena especificación debe acelerar el desarrollo: si no le ayuda a escribir mejor código con mayor rapidez ni a reducir los malentendidos, probablemente sea más detallada de lo necesario.
Para ilustrar cómo es una especificación eficaz en la práctica, observe este ejemplo relativo a una característica de autenticación de usuarios:
Usted está implementando una característica de inicio de sesión de usuario para una aplicación web. Utilice la siguiente especificación como su única fuente fiable. No haga suposiciones sobre ningún requisito que no figure aquí. CARACTERÍSTICA: inicio de sesión de usuario RESUMEN: Permitir a los usuarios registrados autenticarse de forma segura utilizando su dirección de correo electrónico y contraseña. CRITERIOS DE ACEPTACIÓN: 1. El formulario de inicio de sesión debe aceptar una dirección de correo electrónico y una contraseña 2. Si las credenciales son válidas, redirigir al usuario al panel de control 3. Si las credenciales no son válidas, mostrar un mensaje de error genérico sin especificar qué campo es incorrecto 4. Bloquear la cuenta durante 15 minutos tras 5 intentos fallidos consecutivos de inicio de sesión 5. Transmitir las contraseñas solo a través de HTTPS; nunca las almacene en texto sin formato FUERA DEL ÁMBITO: - Inicio de sesión a través de redes sociales (OAuth) - Autenticación de dos factores - Flujo de restablecimiento de contraseña CASOS LÍMITE: - Detectar los campos vacíos en el lado del cliente antes de enviar el formulario - Redirigir las sesiones caducadas a la página de inicio de sesión con un mensaje informativo - El formulario debe seguir funcionando si JavaScript está desactivado No comenzar la implementación hasta haber confirmado que se comprenden los criterios de aceptación.
Estas especificaciones son similares a las especificaciones funcionales que redactan los directores de producto, pero se centran estrictamente en lo que debe incluir la implementación (o sus criterios de aceptación) y en cómo gestionar los casos límite de forma adecuada.
Lo más habitual es que esta especificación se aloje en el repositorio del proyecto (“repo”) en GitHub como un archivo Markdown como
En canalizaciones más automatizadas, el archivo de especificaciones se transmite como parte de la instrucción del sistema o de la ventana de contexto al inicio de la tarea, proporcionando al agente sus instrucciones antes de que comience.
Por mucho tiempo y deuda técnica que le pueda ahorrar el desarrollo basado en especificaciones, también es importante recordar que es posible dedicar demasiado tiempo a la “sobreingeniería”. Si dedica tres semanas a debatir el nombre de una sola clave JSON o de endpoints específicos de la API para una característica que podría eliminarse en un mes, esto frustra el propósito del desarrollo basado en especificaciones.
No se centre en exceso en modelar todos los futuros posibles. Es preferible optar por especificaciones ligeras y evolutivas en lugar de otras exhaustivas y “definitivas”. Escriba lo que necesite para avanzar, valídelo rápidamente en el código e itere a medida que cambie la realidad. Un principio general es que el coste de perfeccionar la especificación siempre debe ser inferior al coste de corregir malentendidos en la implementación. Cuando ese equilibrio se invierte, es una señal para dejar de pulir y empezar a crear.
Con la aparición de la asistencia a la codificación basada en IA, el desarrollo basado en pruebas (TDD) y el desarrollo basado en el comportamiento (BDD) inspiraron una nueva corriente: el desarrollo basado en especificaciones. Mientras que el TDD requiere que los desarrolladores definan los resultados esperados a través de pruebas, y el BDD que definan el comportamiento mediante la colaboración, el desarrollo basado en especificaciones plantea primero una pregunta más fundamental: ¿hemos definido claramente qué estamos creando y para quién?2,3
A medida que los agentes de IA asumen una mayor parte del trabajo de implementación, la calidad de dicho trabajo se vuelve directamente proporcional a la calidad de las instrucciones que reciben. Una especificación bien redactada no limita el proceso de desarrollo, sino que lo acelera en el marco de los sistemas de software modernos.
Recursos
Acelere la entrega de software con Bob, su socio de IA para un desarrollo seguro y consciente de la intención.
Optimice los esfuerzos de desarrollo de software con herramientas impulsadas por IA de confianza que minimizan el tiempo dedicado a escribir código, depurar, refactorizar código o completar código, y consiga más espacio para la innovación.
Reinvente las operaciones y flujos de trabajo críticos añadiendo IA para maximizar las experiencias, la toma de decisiones en tiempo real y el valor empresarial.
Notas a pie de página
1 Piskala, D. B. (2026). Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants. arXiv preprint arXiv:2602.00180.
2 Beck, K. (2003). Test-driven development: by example. Addison-Wesley Professional.
3 Farooq, M. S., Omer, U., Ramzan, A., Rasheed, M. A. y Atal, Z. (2023). Behavior driven development: A systematic literature review. IEEE Access. 11. 88008-88024.