Software Agéntico: Cuando la Ingeniería de Software se vuelve Ingeniería del Conocimiento

En un sistema legacy grande, escribir un cambio puede tomar unas horas. Encontrar dónde hacerlo, y comprobar que no rompe nada, puede tomar días o semanas. Esa diferencia explica casi todo lo que el debate sobre agentes de IA suele pasar por alto.

El debate ya tiene texto de referencia: Agentic Software: How AI Agents Are Restructuring the Software Paradigm. Su tesis central es clara. En el software tradicional, la lógica de decisión vive en el código. En el software agéntico, vive en el agente, que genera código cuando lo necesita. El código deja de ser el producto y pasa a ser un efecto secundario.

Hay mucho de cierto en eso. Quien usa asistentes de programación lo nota todos los días: cada vez más valor sale de expresar la intención, de decir qué quieres lograr, y menos de teclear cada línea. El paper también es honesto en un punto que conviene no perder: reconoce que los agentes rinden muy bien en tareas aisladas y todavía batallan con proyectos grandes, mantenimiento a largo plazo y sistemas que no dejan de cambiar.

Donde se pasa de la raya es en el tono. El título y varias conclusiones sugieren algo cercano al fin de la ingeniería de software. Esa promesa ya la hemos oído. Ensamblador a C. C a frameworks. Frameworks a low-code. Low-code a IA generativa. Cada capa de abstracción iba a eliminar a los programadores, y cada vez seguimos necesitando ingenieros. Lo que cambia es el nivel en el que trabajan. El código no desaparece; se hunde una capa más abajo, igual que el ensamblador sigue ahí debajo de todo lo que escribimos en lenguajes de alto nivel.

Hasta aquí, una respuesta razonable y algo cómoda. El problema es que trata a “la industria” como si fuera un solo lugar.

Dos mundos con el mismo nombre

La predicción de que en cinco años se escribirá mucho menos código a mano suena plausible. Pero es plausible sobre todo en proyectos nuevos y en startups. En una empresa grande, con código legacy gigantesco repartido en múltiples plataformas y tecnologías, y poco documentado, todavía hace falta mucho trabajo manual de interpretación y mucho código escrito a mano.

Los agentes brillan cuando el proyecto empieza de cero, la arquitectura es simple o está bien documentada, hay pocas dependencias externas y los requisitos están claros. Ahora pon al lado el paisaje típico de una empresa grande. Millones de líneas de código. .NET, Java, SAP, mainframe, Python y JavaScript conviviendo, no siempre en paz. Reglas de negocio acumuladas durante décadas. Documentación incompleta o desactualizada, que a veces es peor que no tener ninguna. Integraciones con cientos de sistemas. Y, casi siempre, comportamientos que nadie entiende del todo pero de los que depende el negocio.

En ese terreno, el cuello de botella no es escribir. Es entender.

Ingeniería de conocimiento

Cuando el problema principal es saber qué hace realmente un sistema y qué va a pasar si lo tocas, el trabajo se parece menos a programar y más a investigar. Es ingeniería de conocimiento.

Aquí la IA sí ayuda, y bastante. Sirve para explorar código, explicar módulos, generar documentación, crear pruebas y sugerir refactorizaciones. Todo eso reduce el tiempo que un ingeniero pasa perdido en un repositorio ajeno.

Pero hay cosas que todavía no hace bien. No infiere con fiabilidad reglas de negocio implícitas, esas que nunca se escribieron porque “todo el mundo sabía”. No reconstruye decisiones históricas que nadie documentó. No evalúa impactos organizacionales. Y no navega dependencias entre decenas de equipos, donde la pregunta relevante muchas veces no es técnica sino “¿a quién le va a doler esto?”.

Por eso la automatización avanza más rápido en startups y productos nuevos que en organizaciones con décadas de deuda técnica. No es que las empresas grandes sean más lentas para adoptar herramientas. Es que su trabajo más caro nunca fue el que las herramientas aceleran.

Lo que sí cambia

Nada de esto significa que el paper describa una fantasía. La tendencia es real. Es probable que en unos años se escriba mucho menos código manual, incluso en empresas grandes. Lo que el paper confunde es el fin de escribir código a mano con el fin de la ingeniería de software. Son cosas muy distintas.

Lo que queda cuando el código se automatiza es justo lo que siempre fue difícil: arquitectura, diseño de sistemas, seguridad, gobernanza, integración, priorización de producto, liderazgo técnico. Y hay un giro que vale la pena notar. Mientras más autónomos sean los agentes, más importa definir bien los objetivos, las restricciones y las métricas de éxito. Un agente que ejecuta rápido una instrucción mal planteada no ahorra trabajo; lo multiplica.

En un sistema legacy eso pesa todavía más. Un agente puede escribir el cambio en minutos. Lo que nadie puede darle todavía es la lista de comportamientos raros de los que depende el negocio, porque esa lista no existe en ningún archivo. Existe repartida en la cabeza de gente que lleva años ahí, en tickets viejos y en incidentes que alguien recuerda a medias.

El código siempre fue la parte fácil de explicar. Lo difícil era, y sigue siendo, saber qué no se debe tocar.