Podcast - Desarrollo de software con IA: SDD y la gobernanza del conocimiento corporativo.

La generación de código con inteligencia artificial ha dejado de ser una curiosidad para convertirse en una herramienta cotidiana dentro del desarrollo de software.

Hoy es difícil encontrar un equipo técnico que no utilice asistentes como GitHub Copilot, Cursor o modelos conversacionales como Claude para acelerar tareas, resolver dudas o construir fragmentos de código con mayor rapidez.

La promesa inicial se ha cumplido en buena medida: escribir código es hoy más rápido que hace apenas dos años. Sin embargo, cuando el desarrollo sale del terreno individual y entra en el contexto de una gran organización, aparecen límites muy claros.

Porque una cosa es generar código que funciona y otra muy distinta generar código que encaja dentro de una arquitectura empresarial compleja, respeta estándares internos y sigue reglas técnicas que muchas veces no están escritas en un prompt.

Ese es precisamente uno de los grandes debates actuales en torno al llamado vibe coding: la idea de interactuar con la IA de forma casi conversacional, describiendo lo que se necesita y dejando que el modelo complete el resto.

En proyectos pequeños o prototipos rápidos puede resultar extremadamente eficaz, pero en sistemas corporativos con años de evolución, múltiples equipos y dependencias cruzadas, el contexto local ya no basta.

El problema de fondo es que estos asistentes trabajan, en la mayoría de los casos, con una visión parcial del sistema. Ven el archivo abierto, algunas referencias cercanas y las instrucciones inmediatas del desarrollador/a, pero no tienen acceso real a la fotografía completa de la organización: ni conocen las librerías aprobadas, ni distinguen qué patrones arquitectónicos son obligatorios, ni saben qué decisiones previas condicionan una implementación concreta.

Por eso, uno de los riesgos más frecuentes es que la IA produzca código técnicamente correcto, pero incompatible con el ecosistema real de la compañía.

Puede introducir dependencias no autorizadas, repetir soluciones ya resueltas internamente o romper convenciones críticas de diseño. A medida que crece el tamaño del sistema, también crece la entropía del software generado si no existe una guía estructurada.

En ese punto, la conversación deja de ser puramente sobre productividad y pasa a ser una cuestión de gobernanza tecnológica.

Del prompt aislado al conocimiento corporativo estructurado

La respuesta que muchas organizaciones están empezando a explorar consiste en dejar de tratar la IA como un simple asistente conversacional y empezar a integrarla dentro de una arquitectura de conocimiento empresarial.

Aquí es donde aparecen conceptos como RAG, MCP y SDD, tres piezas que juntas cambian completamente el enfoque.

El primero, Retrieval-Augmented Generation o RAG, permite que el modelo no dependa únicamente de su entrenamiento general, sino que consulte conocimiento interno antes de responder. Pero no basta con almacenar código sin más. La diferencia real aparece cuando ese conocimiento se organiza con jerarquía.

No todo el código tiene el mismo valor. Hay documentación, librerías comunes, aplicaciones históricas y, sobre todo, proyectos de referencia que representan cómo debe hacerse realmente una implementación dentro de la organización.

La IA necesita distinguir entre cualquier fragmento heredado y aquello que verdaderamente define el estándar interno.

Ese conocimiento estructurado es lo que permite que una respuesta deje de ser genérica y pase a parecerse al modo real de construir software dentro de una compañía.

MCP: el estándar que conecta la IA con el ecosistema real de desarrollo

La segunda pieza es MCP, un protocolo que está ganando protagonismo porque resuelve uno de los grandes problemas actuales: cómo conectar modelos de IA con herramientas corporativas sin crear integraciones frágiles.

En lugar de enlazar cada modelo con cada sistema interno de forma individual, MCP actúa como una capa estándar de conexión. Eso permite que distintos modelos puedan consultar las mismas fuentes sin depender de integraciones duplicadas.

En la práctica, esto significa que un modelo puede consultar información funcional de Jira, recuperar ejemplos del repositorio interno, acceder a convenciones por lenguaje o framework y mantener sesiones de trabajo consistentes sin que importe demasiado si detrás está Claude, GPT o cualquier otro modelo.

La clave no es solo conectar herramientas, sino desacoplar el conocimiento del modelo concreto que se esté utilizando.

Eso aporta algo especialmente valioso en entornos corporativos: flexibilidad tecnológica sin rehacer toda la arquitectura cada vez que cambia el modelo dominante.

El gran cambio: dejar de pedir código y empezar pidiendo intención

Donde realmente cambia el paradigma es en el flujo de trabajo. En el enfoque tradicional de asistentes, el/la desarrollador/a abre el IDE, redacta una instrucción y espera código.

Todo ocurre dentro de una conversación más o menos sofisticada. Pero cuando se trabaja con especificaciones guiadas, el proceso empieza antes del código.

Lo primero no es generar una implementación, sino una propuesta de cambio. A partir de una necesidad funcional o de una historia de usuario, el sistema construye una cadena de artefactos: especificaciones, diseño técnico, escenarios concretos y tareas de implementación. La IA deja de improvisar y empieza a trabajar sobre una intención formalizada.

Esto tiene una consecuencia importante: el contexto deja de depender de una conversación efímera y pasa a convertirse en un activo persistente.

Uno de los grandes límites del llamado context engineering es precisamente su fragilidad. Cada desarrollador/a construye manualmente el contexto que entrega al modelo, decide qué archivos incluir, qué ejemplos mostrar y qué instrucciones reforzar. Ese contexto desaparece cuando termina la sesión y no deja rastro verificable.

Además, cuando el volumen crece demasiado, aparece un fenómeno cada vez más conocido: la saturación de contexto. El modelo empieza a priorizar unas señales sobre otras, atiende menos a ciertas restricciones y pequeños ajustes pueden desalinear requisitos previamente bien resueltos. La IA no se vuelve inconsistente por azar: simplemente compite por atención dentro de una ventana finita.

Por eso el enfoque basado en especificaciones gana fuerza. Porque las specs se convierten en el verdadero contexto: estructurado, persistente, versionado y auditable.

Cuando el código no es la única fuente de verdad

En este modelo, el código ya no es el único artefacto importante. Cada decisión queda acompañada de su intención original, su diseño técnico y su validación funcional. Si algo cambia, no se corrige directamente el código: se actualiza la especificación y la implementación evoluciona desde ahí.

Esto transforma también el proceso de revisión. En un pull request, el revisor ya no ve únicamente líneas nuevas o modificadas. Ve también por qué se hizo ese cambio, qué problema resuelve y qué criterios guiaron la implementación.

El contexto viaja junto al código, y eso mejora radicalmente tanto la calidad del review como el onboarding de nuevos perfiles en el proyecto.

¿Funciona de verdad en sistemas complejos?

La pregunta crítica es si todo esto resiste cuando el entorno deja de ser controlado y aparece la complejidad real: monolitos heredados, migraciones cloud, plataformas híbridas, integraciones con Kubernetes, Terraform o Apache Kafka. Y precisamente ahí es donde más sentido cobra.

En un sistema heredado de cientos de clases, el contexto manual simplemente deja de ser viable. No cabe en la ventana del modelo ni es razonable esperar que un/a desarrollador/a decida manualmente qué partes son relevantes en cada momento.

Una de las aplicaciones más interesantes de este enfoque es la modernización de software legacy. La IA puede analizar módulos antiguos y generar especificaciones formales de comportamiento. No captura todo desde el primer momento, pero sí una parte muy significativa que luego puede refinarse iterativamente.

Esas especificaciones pasan a ser el puente entre el sistema heredado y la nueva arquitectura. Lo importante es que el conocimiento extraído persiste. Un prompt desaparece, una especificación permanece.

El “100% automático” sigue sin ser realista

A pesar del avance, el objetivo NO es que la IA entregue software listo para producción sin intervención humana. Actualmente, incluso en los mejores escenarios, el resultado suele situarse en torno al 80% o 90% del trabajo útil. El resto sigue requiriendo criterio técnico, validación y comprensión profunda del sistema.

Existe además un riesgo menos visible: el knowledge lag. Si todo lo hace la IA y el/la desarrollador/a deja de recorrer mentalmente el código, termina perdiendo conocimiento real sobre el sistema que mantiene.

Ese último tramo que todavía exige intervención humana no es una limitación accidental: es también una garantía de control.

Lo que probablemente veremos en los próximos años

El debate ahora no es si habrá agentes autónomos o no, sino dónde encajan mejor. En tareas repetitivas, scaffolding masivo o migraciones mecánicas, la orquestación pura de agentes tiene mucho sentido.

Pero cuando entra en juego lógica de negocio compleja, auditoría, cumplimiento normativo o arquitectura crítica, el enfoque cambia. Porque en una gran empresa no basta con que el código funcione, también debe poder explicarse, trazarse, revisarse y sostenerse en el tiempo.

Y ahí es donde modelos basados en especificaciones, conocimiento corporativo y control arquitectónico parecen estar marcando ya el camino de 2026.