El desarrollo dirigido por especificaciones es la respuesta más sensata que ha producido la industria a un problema muy concreto: los agentes de IA escriben código excelente, pero adivinan pésimo lo que queríamos. Cuando generar código deja de ser el cuello de botella, se traslada a decidir con precisión qué debe existir, y ahí es donde la mayoría de los equipos todavía improvisa.
Este artículo explica en qué consiste el enfoque, por qué importa ahora y cómo aplicarlo sin convertirlo en una nueva burocracia documental.
Contexto del problema
Durante dos años, la forma dominante de trabajar con IA fue conversacional: se describía una intención en lenguaje natural y se aceptaba el bloque de código que parecía correcto. Ese estilo —bautizado vibe coding— funciona de maravilla en un prototipo y se desmorona en producción.
El motivo es estructural, no una limitación pasajera del modelo. Un prompt es efímero: se escribe, se ejecuta y desaparece. Nadie lo versiona, nadie lo revisa, nadie puede diferenciarlo contra la versión anterior. La intención que originó el código se pierde en el momento en que se cierra la conversación.
El resultado son bases de código que crecen rápido y se degradan igual de rápido: APIs alucinadas, suposiciones contradictorias entre módulos escritos en sesiones distintas y una deriva progresiva entre lo que el sistema hace y lo que alguien pensó que debía hacer. Cuando llega el primer incidente serio, no hay documento contra el cual contrastar el comportamiento observado.
Por qué importa ahora
La conversación cambió cuando los asistentes se convirtieron en agentes. Un copiloto que sugiere una línea es un riesgo acotado; un agente que planifica, escribe, prueba y abre un pull request completo multiplica tanto el alcance como el costo del malentendido.
A mayor autonomía, mayor es el valor de la instrucción precisa. Un agente capaz de generar tres mil líneas sin supervisión necesita saber qué pasa cuando el pago se rechaza a mitad de la transacción, qué campos son obligatorios, qué latencia es aceptable y qué debe registrarse en la bitácora de auditoría. Nada de eso cabe en una frase.
De ahí que la especificación se haya vuelto el artefacto central. No como documento ceremonial de fin de proyecto, sino como archivo vivo dentro del repositorio: legible por humanos y por máquinas, versionado en Git, sujeto a revisión por pares y actualizado antes que el código. Cuando entra un bug o un cambio de requisito, primero se corrige la especificación; después se regenera o ajusta la implementación.
Martin Fowler y su equipo describen tres grados de adopción que ayudan a situarse. En el enfoque spec-first, la especificación dirige la generación inicial pero el código sigue siendo el artefacto que se mantiene. En el spec-anchored, ambos evolucionan en paralelo. En el spec-as-source, la especificación es lo único que se edita y el código es salida generada. La mayoría de los equipos serios opera hoy en el punto intermedio, y hace bien.
El ecosistema acompañó el cambio: GitHub Spec Kit, AWS Kiro, OpenSpec y las herramientas de contexto persistente apuntan en la misma dirección. Cuando todos los proveedores convergen en un patrón, suele responder a una necesidad real y no a una moda.
Cómo aplicar el desarrollo dirigido por especificaciones en empresas y gobierno
Una especificación útil no es un documento de cien páginas. Es un texto corto y quirúrgico que responde cuatro preguntas: qué comportamiento se espera, qué casos límite existen, qué contratos de datos deben respetarse y bajo qué criterios se considera aceptado el trabajo.
La forma más práctica de empezar es escribirla en Markdown y guardarla junto al código, no en una herramienta externa. Así entra en el flujo de revisión que el equipo ya conoce: rama, pull request, comentarios, aprobación. Si la especificación vive en otro sistema, se desincroniza en semanas.
Los criterios de aceptación merecen atención especial, porque son la frontera entre una descripción y una prueba. «El sistema debe ser rápido» no es especificable. «La consulta de expediente responde en menos de 800 ms para el percentil 95 con 10 000 registros» sí lo es, y además se traduce directamente en un test automatizado que el propio agente puede escribir.
En el sector público el encaje es aún más natural. Los pliegos técnicos, los requisitos de accesibilidad y las obligaciones de trazabilidad ya son especificaciones: basta expresarlas en un formato que el equipo y sus agentes puedan consumir. Así la institución obtiene, casi como efecto secundario, la documentación auditable que la normativa le exige.
Riesgos o errores comunes
El primer error es reinventar la cascada. Escribir una especificación exhaustiva antes de tocar una línea de código reproduce exactamente el problema que las metodologías ágiles resolvieron hace veinte años. La especificación debe ser iterativa: se refina con lo aprendido en cada ciclo.
El segundo es la deriva silenciosa. Un equipo escribe buenas especificaciones durante dos meses y luego empieza a parchear el código directamente «solo esta vez». A partir de ahí la especificación miente, y una que miente es peor que no tenerla: genera confianza injustificada.
El tercero es confundir extensión con precisión. Los agentes no rinden mejor con más texto, sino con texto menos ambiguo. Diez líneas sin interpretaciones posibles superan a tres páginas de prosa evocadora.
El cuarto, y el más caro, es delegar la especificación en el propio modelo. Pedirle a la IA que redacte los requisitos que luego implementará elimina el único punto donde el criterio humano era indispensable. La IA ayuda a estructurar y detectar huecos; decidir qué debe hacer el sistema es responsabilidad de la organización.
Recomendaciones prácticas
Empieza por una sola funcionalidad de complejidad media que vayas a construir de todos modos. Escribe su especificación, genera con ella y compara el resultado contra lo que habrías obtenido conversando con el agente. La diferencia suele bastar para convencer al equipo sin necesidad de un mandato.
Trata la especificación como código de producción: vive en el repositorio, se revisa en pull request y su modificación requiere aprobación. Si cambiarla es más fácil que cambiar el código, se degradará.
Convierte cada criterio de aceptación en una prueba automatizada. Es el mecanismo que impide la deriva: mientras esas pruebas pasen, especificación y sistema dicen lo mismo.
Y revisa el perfil del equipo. La habilidad que se vuelve escasa no es teclear rápido, sino formular sin ambigüedad: pensar en casos límite, definir contratos y anticipar fallos. Esa capacidad se entrena, y conviene empezar a entrenarla antes de necesitarla con urgencia.
Conclusión
El desarrollo dirigido por especificaciones no es una metodología nueva ni especialmente sofisticada. Es el reconocimiento de algo que la ingeniería siempre supo y que la abundancia de código barato volvió imposible de ignorar: el problema difícil nunca fue escribir, fue decidir qué escribir.
Los equipos que sacan ventaja real de la IA no son los que generan más líneas, sino los que saben expresar con precisión qué quieren construir. La especificación es donde vive esa precisión.
Preguntas frecuentes
¿En qué se diferencia de la documentación tradicional?
La documentación tradicional describe un sistema que ya existe y se escribe al final. La especificación describe el sistema que debe existir, se escribe antes y es la fuente desde la que se genera y valida la implementación. Una es un retrato; la otra, un plano.
¿Sirve para proyectos pequeños o solo para equipos grandes?
Sirve en ambos, con distinta intensidad. En un proyecto pequeño una especificación de veinte líneas por funcionalidad ya evita la mayor parte de los malentendidos. El beneficio crece con la autonomía que le des al agente, no con el tamaño del equipo.
¿Hace falta una herramienta específica para adoptarlo?
No. Un archivo Markdown versionado en el repositorio cubre el caso esencial. Spec Kit u OpenSpec aportan plantillas y automatización útiles, pero conviene entender el método antes de elegir el instrumento.
Deja una respuesta