Hace unos días, buscando más información sobre el estado del arte de la IA generativa, me encontré con un paper que decía que en 2030 el desarrollo de software se vería como una pieza musical donde el desarrollador dirige la orquesta que será un conjunto de IAs que generarán y probarán el software. El desarrollador ya no picará, sino que definirá el tempo, repartirá entradas y marcará los cortes. ¿Te parece seductor? Quizá lo sea, pero esto exige una arquitectura a la altura.
Ese mismo día, en otro paper, aunque ya sabéis mi opinión sobre predecir el futuro, que parece tener los pies más en el suelo. Hablaba de 78 preguntas abiertas en 11 áreas de la ingeniería de software que aún no hemos resuelto. Y esto no es que sea un jarro de agua fría, es simplemente una realidad que algunos llevamos diciendo mucho tiempo. Estas preguntas no dejan de ser un checklist que nos puede ayudar a separar la música de nuestra orquesta del ruido. En el paper nos podemos encontrar temas sobre mantenibilidad del código, trazabilidad de las decisiones, seguridad, deuda técnica, etc.
Mientras tanto, el mercado no para, al revés, acelera. McKinsey repite un dato constantemente. Un dato que es el sueño de muchos CEOs. Aplicar IA generativa en el ciclo de desarrollo puede aumentar la productividad en la ingeniería de software entre un 20% y un 45%. Eficiencias que se traducen en menos tiempo en refactorización, en codificación, en documentación, en análisis… Y más foco en diseño, calidad y producto.
Pero no es oro todo lo que reluce, también nos encontramos con señales de alerta que debemos ser capaces de identificar y corregir antes de que se conviertan en problemas reales. Gartner comenta que más del 40% de los proyectos de IA agéntica serán cancelados antes de 2027, debido a costes descontrolados, un valor de negocio dudoso y riesgos muy mal gestionados. Y repito, no es un problema de modelos, es un problema de arquitectura.
PoCs que nunca pasan a producción, o que se presentan como «productivas», son una aberración. El agent washing que últimamente me lo encuentro mucho, es llamar agente de IA a un wrapper sobre un LLM, son simples chatbots que los presentan como agentes autónomos capaces de hacer cualquier cosa, o mi favorito, son sistemas de agentes que básicamente son un flujo lineal de prompts encadenados, sin ningún mecanismo de coordinación. Si tu empresa es una mid-size sin disciplina en arquitectura, esta predicción te afecta brutalmente.
Mi punto es sencillo, 2030 no es el destino, es una consecuencia. Si hoy tratamos a la IA como un plugin, en 2026 nos habrán desbordado los costes. Pero si la tratamos como parte del sistema, seremos capaces de orquestar valor y no haciendo la enésima demo. ¿Pero qué necesitamos para incorporarla?
Primero, límites claros. ¿Cómo haríamos con cualquier software que consideremos serio? Enfoques como DDD para definir bounded contexts en los que la IA pueda tener autonomía real y donde no tenga sentido que la tenga. Debemos evitar que los agentes crucen dominios, pero esto no es nuevo, es aplicar las mismas reglas que ya veníamos aplicando.
Segundo, modularidad, esta característica de arquitectura es fundamental, debemos diseñar arquitecturas limpias con capacidad de abstracción. Esto sin duda ayudará a reducir el vendor lock-in. Me pide el cuerpo seguir con la metáfora, es decir, la orquesta suena mejor cuando se puede sustituir al solista.
Tercero, por supuesto, la observabilidad desde el minuto uno. Logs estructurados, métricas de coste, latencia, éxitos y fracasos, y trazas donde podamos encontrar peticiones, prompts, contextos, cadenas de pensamiento, tokens, etc. Tener una observabilidad fuerte nos permite reconstruir la toma de decisiones de la IA y mejorar el proceso.
Cuarto, gobierno y seguridad. Policy-as-code para las entradas y salidas, qué datos puede ver cada agente, con qué propósito, revisión de prompting con plantillas versionadas, model drift y, por supuesto, un registro de artefactos donde podamos almacenar modelos y embeddings. Esto va más allá de meter un firewall, es incorporar fitness functions para que detectemos antes que los clientes los problemas de nuestro sistema.
Quinto, FinOps aplicado a la IA. Métricas por dominio, es decir, coste por historia de usuario, coste por transacción, tasa de retrabajo humano, coste por test generado, coste por issue resuelto, etc. Si no somos capaces de medir el valor y el coste juntos, perderemos esa eficiencia del 45% en la factura del mes.
Y sexto, ciclos de calidad y de evaluación continua. Igual que, gracias al CI/CD, salimos del infierno del despliegue manual, son fundamentales ciclos para prompts, datos de contexto, evaluaciones, etc. Hay que incorporar, además, testing, más fitness functions, que nos ayuden a evitar problemas con prompt injections o datos sensibles.
Con todos estos cimientos, el rol de desarrollador debe cambiar, quizá es pronto para saber hacia dónde, pero desde luego, debe adaptarse y encontrar su nuevo camino. Y los proyectos construidos sobre ellos evitarán entrar dentro de ese 40% de cancelaciones que predice Gartner.