Una encuesta de Sonar de 2026 muestra que el 88 % de los desarrolladores afirma que el código generado por IA está aumentando la deuda técnica, y los defensores del desarrollo basado en especificaciones (spec-driven development) argumentan que un paso de especificación disciplinado puede detener esa deriva.
Por qué es importante este problema
Cuando un humano recibe un ticket vago, hace preguntas para aclarar dudas. Un agente de IA, por el contrario, rellena los huecos con su mejor suposición y entrega un código que parece plausible. La ilusión de corrección es costosa: la misma encuesta de Sonar informa que más de la mitad de los encuestados han visto código que supera las comprobaciones básicas pero oculta defectos sutiles. Esos defectos se acumulan como deuda técnica, obligando a realizar refactorizaciones posteriores, ralentizando la entrega de funcionalidades e inflando los presupuestos de mantenimiento.
Cómo es el desarrollo basado en especificaciones
El desarrollo basado en especificaciones (SDD, por sus siglas en inglés) invierte el orden actual. En lugar de dar instrucciones a un modelo de IA con una breve historia de usuario, el equipo escribe una especificación detallada y ejecutable por agentes que reside en el mismo sistema de control de versiones que el código. La especificación se convierte en la única fuente de verdad: registra la intención, los casos límite, las expectativas de rendimiento y cualquier restricción que el modelo de IA deba respetar.
El proceso no sustituye el trabajo de diseño humano; lo codifica. Al trasladar las decisiones de la memoria de un desarrollador a un documento concreto, tanto los humanos como los futuros agentes de IA pueden rastrear por qué una pieza de código se comporta de cierta manera. Redactar una especificación requiere un esfuerzo inicial, pero depurar la salida ambigua de una IA cuesta mucho más después.
Cambiando el flujo de trabajo
Product backlog – Mantenga los elementos cortos, capturando solo la intención y los criterios de aceptación de alto nivel. Esta lista sigue impulsando la priorización.
Sprint planning – Los equipos discuten el objetivo general y acuerdan un Sprint Goal, pero posponen la implementación detallada hasta que la especificación esté lista.
Durante el sprint – La persona que toma la tarea escribe una especificación precisa y legible por máquinas. La especificación enumera los formatos de entrada, los resultados esperados, el manejo de errores y cualquier requisito no funcional. Dado que la especificación está bajo control de versiones, los revisores pueden comentar, sugerir ediciones y aprobar cambios tal como lo harían con el código.
Definition of Done – Añada “Spec reviewed and approved” al control de calidad. Ningún código se considera completo hasta que la especificación supere los mismos estándares de revisión que la implementación.
Adaptación de Kanban – Inserte dos nuevas columnas: “Spec Drafted” y “Spec Approved”. Los elementos de trabajo ahora fluyen desde backlog → Sprint Goal → Spec Drafted → Spec Approved → In Progress → Done. Este cambio visual hace que el paso de coordinación, anteriormente invisible, sea explícito.
Herramientas que ya imponen especificaciones
Plataformas como GitHub Spec Kit y AWS Kiro han añadido controles que requieren un documento de requisitos antes de que comience cualquier generación de código por IA. No sustituyen al modelo de IA; alinean a los agentes de mentalidad literal con la intención humana. Al convertir la especificación en un requisito previo, estas herramientas automatizan la transición sin romper los pipelines de CI/CD existentes.
Posibles críticas
Los críticos dicen que escribir una especificación añade fricción a una cadencia ágil que ya es rápida. El contraargumento: el tiempo dedicado a redactar una especificación suele ser una fracción del tiempo que se pierde más tarde depurando código producido por IA a partir de un prompt ambiguo.
Otra preocupación es que las especificaciones pueden quedar obsoletas a medida que los requisitos evolucionan. La integración con el control de versiones resuelve esto: cualquier cambio en la especificación crea un nuevo commit, activa una revisión y obliga al equipo a reevaluar el código asociado. En la práctica, tratar las especificaciones como código mantiene la documentación actualizada.
Qué observar a continuación
La adopción aún es incipiente, pero el impulso es visible. A medida que los generadores de código por IA se vuelvan más capaces, la necesidad de una intención precisa y legible por máquinas no hará más que crecer.
En resumen: Convertir prompts vagos en especificaciones concretas y revisadas puede parecer un paso adicional, pero transforma las conjeturas en decisiones responsables.