Durante los últimos meses hemos visto una tendencia cada vez más frecuente en equipos de desarrollo: combinar Spec Driven Development (SDD) con agentes de IA con la expectativa de obtener implementaciones prácticamente automáticas.
La teoría resulta atractiva. Si definimos correctamente los requisitos, los flujos, los contratos y las reglas de negocio, el agente solo debería encargarse de traducir esa especificación a código.
Sobre el papel parece una evolución natural del desarrollo asistido por IA. Sin embargo, cuando se empieza a trabajar con proyectos reales que incluyen frontend, backend, dominio, infraestructura, seguridad e integraciones externas, la experiencia suele ser bastante diferente.
El origen de los fallos arquitectónicos: La fragmentación de la visión global
En el desarrollo de software actual, la integración de agentes automatizados ha evidenciado una vulnerabilidad crítica: la acumulación de decisiones individuales aparentemente correctas puede derivar en una arquitectura inoperante a nivel global.
Los errores estructurales suelen originarse en disonancias entre las capas del sistema:
- Desplazamiento de la lógica de negocio: Cuando la lógica crítica se implementa en el Frontend para ganar velocidad, se genera una inconsistencia estructural. Esto crea una dependencia innecesaria que impide la reutilización de la lógica en otros clientes o procesos de backend.
- Deriva en contratos de API: Modificar la respuesta de un endpoint sin actualizar el contrato original (OpenAPI/Swagger) rompe la comunicación entre servicios. El sistema parece funcional, pero el contrato implícito con los consumidores se ha corrompido.
- Desactualización de modelos de datos: La modificación de esquemas de bases de datos sin la propagación necesaria hacia el resto de las capas genera una arquitectura fragmentada donde cada módulo debe implementar parches para interpretar los datos.
- Validaciones incompletas: La ejecución de validaciones únicamente en la interfaz de usuario deja al sistema expuesto a vulnerabilidades de seguridad y corrupción de datos al ignorar la validación necesaria en la capa de dominio o backend.
- Incompatibilidad de dependencias: La integración de librerías externas sin una evaluación estricta de la infraestructura existente provoca fallos críticos en los entornos de despliegue y pipelines de CI/CD.
Cada uno de estos cambios, visto de manera aislada, responde a una necesidad técnica específica. Sin embargo, el fallo determinante ocurre por la falta de un mecanismo de validación que asegure la coherencia global. La arquitectura no es una suma de componentes independientes; es el conjunto de sus interacciones. Si se omite la validación de estas relaciones, el sistema pierde su integridad.
El problema del Spec Driven Development (SSD): Falsa sensación de seguridad
Una de las primeras conclusiones a las que hemos llegado muchos equipos es que Spec Driven Development (SDD) sigue siendo extremadamente útil. Reduce ambigüedad, mejora la comunicación y facilita la planificación ayudando a alinear expectativas entre negocio y tecnología.
El principal problema aparece cuando asumimos que una especificación bien escrita convierte automáticamente a un agente en un implementador fiable.
En sistemas con múltiples capas, el agente puede generar código que parece coherente de forma local —archivo por archivo, función por función— pero que resulta inconsistente cuando se analiza el sistema completo.
Dónde empiezan los fallos
Durante las diferentes pruebas usando ssd hemos visto las siguientes situaciones pese a tener un sistema de reglas, skills y mcps bien definidos.
• El frontend implementa lógica de negocio que debía residir en el backend.
• Un endpoint devuelve un contrato diferente al especificado.
• Se modifican modelos de datos sin actualizar el resto de capas.
• Se introducen validaciones incompletas que generan problemas de seguridad.
• Se añaden dependencias incompatibles con la infraestructura existente.
Cabe destacar que cada cambio individual puede parecer razonable para que la aplicación funcione. El problema surge cuando nadie valida la coherencia global del sistema y las implicaciones que estas decisiones tomadas por el agente tienen a corto/medio/largo plazo.
Es importante ser justos: muchos de estos errores también los cometen programadores experimentados. La diferencia es que un agente puede generar miles de líneas de código en minutos, propagando una decisión incorrecta por múltiples capas antes de que alguien la revise.
Un desarrollador puede introducir diez errores. Un agente puede introducir cientos en el mismo tiempo si el proceso de validación no existe.
El ejemplo real: un mini Shazam para localizar los nombres de canciones de mi disco duro
Hace poco intenté desarrollar una pequeña aplicación inspirada en Shazam con un objetivo muy concreto: identificar canciones de mi biblioteca musical para localizar rápidamente el vinilo correspondiente y utilizarlo en un próximo set como DJ.
Funcionalmente era un problema sencillo:
• Subir un fragmento de audio.
• Generar una huella acústica.
• Compararla con una biblioteca local.
• Mostrar el título de la canción que localizamos con el sonido que entra por el microfono.
La especificación estaba claramente definida mediante un enfoque Spec Driven Development (SDD). El resultado, sin embargo, fue muy distinto.
Tras varios días de iteraciones y más de 60 dólares consumidos en herramientas y ejecuciones, la aplicación nunca llegó a funcionar correctamente.
En cada iteración aparecía un problema diferente:
• Cambio de librerías de procesamiento de audio.
• Dependencias incompatibles.
• Modificaciones en el formato de las huellas acústicas y algoritmo de procesamiento de hashing.
• Correcciones que generaban nuevos errores.
El problema no era definir qué debía hacer la aplicación. El problema era validar técnicamente cada decisión que el agente tomaba para implementarla. Al no disponer de conocimientos de bajo nivel de cómo trabajar con archivos de sonidos y algoritmos de procesamiento de audio pese a usar Java en la solución con mis conocimientos no era capaz de corregir las decisiones erróneas que aplicaba el agente en cada iteracción.
Cuando el equipo no domina todas las capas del software a construir
Aquí aparece el riesgo más importante a la hora de utilizar agentes de código tanto si usamos Spec Driven Development (SDD) en el flujo como si aplicamos alguna otra manera de documentar lo que tiene que hacer nuestra aplicación
Si quienes desarrollan el proyecto no conocen en profundidad todos los puntos el control efectivo del software pasa al agente (lo que se conoce como Vibecoding):
• El lenguaje de programación y los frameworks utilizado.
• La arquitectura elegida en el backend de la aplicación.
• Toda la infraestructura donde se va a desplegar nuestros aplicativos (contenedores, seguridad, limitaciones empresariales etc.).
• Sistemas externos a los que nos integramos (pasarelas de pago, apis externas a la organización etc.).
Y ese es el momento en el que empiezan a acumularse errores funcionales, de seguridad y de arquitectura que nadie puede detectar delegando en los agentes todas las decisiones y avanzando sin seguridad en cada una de las versiones que se liberan del aplicativo.
Más código no significa más avance
Uno de los efectos más engañosos es la sensación de progreso. La aplicación arranca correctamente y las parte frontal se ve parecido a los diseños que hemos definido pero a la hora de usarla aparecen muchos errores que se han escapado de la validación del agente y humana.
Las personas que llevan a cabo el desarrollo se ven desbordadas por tener que validar tanto código sin tener todos los conocimientos técnicos para validar los posibles errores existentes y el impacto a largo plazo de las decisiones tomadas por los agentes.
Más código no significa necesariamente más software terminado. A veces significa más deuda técnica oculta creciendo a un ritmo insostenible para las personas que lo mantienen
Lo que suele funcionar mejor en la práctica
Después de trabajar con agentes de código durante un tiempo aparece un patrón bastante repetido:
• Spec Driven Development (SDD) para definir requisitos y límites.
• Agentes para acelerar tareas concretas.
• Validaciones automáticas por capas.
• Revisiones de la arquitectura global de la solución.
• Expertos responsables de frontend, backend, seguridad e infraestructura dentro del equipo para no ceder nunca el control completo del proyecto en ningún área tanto técnica como funcional del proyecto.
Los mejores resultados no se obtienen eliminando a los especialistas en la parte técnica (como se viene diciendo ya muchos años), sino utilizando los agentes de IA para aumentar su capacidad de ejecución.
El modelo de Profile: Agentes guiados por expertos/as
Todos los riesgos descritos anteriormente no significan que debamos limitar el uso de agentes de IA, si no que debemos utilizarlos dentro de un modelo de trabajo que mantenga el conocimiento y la responsabilidad técnica en manos del equipo.
En Profile combinamos equipos con un conocimiento profundo de la arquitectura, las tecnologías, el dominio funcional y el contexto específico de cada proyecto con agentes de IA capaces de acelerar distintas fases del desarrollo. Los agentes ayudan a analizar requisitos, generar código, preparar pruebas, documentar decisiones, detectar inconsistencias y automatizar tareas repetitivas, pero no sustituyen el criterio de las personas responsables de la solución.
La diferencia fundamental está en que las decisiones relevantes no se delegan de manera ciega. Cada cambio que pueda afectar a la arquitectura, la seguridad, los contratos entre sistemas, el modelo de datos, la infraestructura o la mantenibilidad a largo plazo puede ser evaluado y validado por profesionales que conocen las implicaciones reales de esa decisión.
De esta forma, la dupla formada por el agente y la persona experta combina dos capacidades complementarias: la velocidad de ejecución de la IA y el conocimiento técnico, funcional y contextual del equipo. El agente permite explorar alternativas, reducir el trabajo manual y producir resultados con mayor rapidez; el profesional aporta el criterio necesario para seleccionar la solución adecuada, corregir desviaciones y garantizar la coherencia global del sistema.
Este enfoque permite desarrollar más rápido sin renunciar a la calidad.
También posibilita:
- Aumentar la cobertura de pruebas.
- Mejorar la documentación.
- Revisar una mayor cantidad de código y detectar antes determinados errores.
Sin embargo, esta aceleración siempre se produce dentro de un marco de supervisión en el que el equipo conserva el control sobre el proyecto y sobre las decisiones que condicionan su evolución.
Por tanto, el objetivo no es entregar más código en menos tiempo, sino entregar software de mayor calidad con más rapidez y seguridad. Los agentes amplían la capacidad de nuestros equipos, pero son los especialistas quienes dirigen su trabajo, validan las decisiones cruciales y aseguran que cada avance local siga siendo compatible con la visión global del proyecto.
Conclusión
La combinación de Spec Driven Development (SDD) y agentes de IA es una herramienta poderosa, pero no es el combo definitivo.
Una especificación perfecta puede describir correctamente el destino. Lo que no garantiza es que el camino que tomen los agentes mantenga la coherencia arquitectónica, la seguridad, los contratos y la mantenibilidad del sistema.
En proyectos reales, especialmente cuando el equipo no domina todas las áreas técnicas implicadas, los agentes pueden convertir un problema inicialmente manejable en una base de código mucho más grande y difícil de controlar.
Por eso la pregunta importante ya no es “¿podemos desarrollar solo con agentes?”. La pregunta correcta es “¿quién mantiene la capacidad técnica de validar lo que los agentes están construyendo?”.
Porque una buena especificación puede describir perfectamente el destino, pero sigue haciendo falta un equipo con criterio técnico para asegurarse de que el camino no termina en una arquitectura inmantenible.
Si quieres seguir al tanto de las novedades de IA y desarrollo de software, ¡síguenos en Redes Sociales y Canal de YouTube!
