Agentes de IA para auditar arquitecturas: lo que se puede delegar y lo que no
Documentar servicios heredados, detectar interfaces mal diseñadas o violaciones de límites entre dominios: los agentes de código ya asumen ese trabajo, pero solo con objetivos medibles.
Los agentes de código han dejado de ser solo un acelerador para escribir funcionalidad nueva. En equipos con arquitecturas grandes se están usando para dos tareas poco vistosas: documentar servicios heredados que nadie entiende y localizar fallos de diseño antes de que lleguen a producción. Con una condición que se repite en todos los casos: si al agente solo se le dan requisitos funcionales, la arquitectura que salga no cumplirá los atributos de calidad.
Documentar lo que ya nadie recuerda
Es habitual que una arquitectura moderna dependa de un servicio heredado para una tarea concreta, como consultar el histórico de pólizas de un sistema de seguros escrito décadas atrás. Muchas veces ese servicio carece de documentación fiable y su lógica se desconoce, así que usarlo es arriesgado. Un agente puede reconstruir su diseño, trazar los flujos de datos, escanear el código y señalar problemas, incluidas fallas de seguridad. Si el veredicto es que el servicio está demasiado deteriorado, el mismo agente puede refactorizarlo. El riesgo que se evita es concreto: los fallos de un servicio así aparecen tarde, en pruebas de sistema o de aceptación, o directamente en producción.
Fallos de diseño, con el encargo bien acotado
El segundo uso es más ambicioso: pedirle al agente que busque problemas de arquitectura. Interfaces de API difíciles de usar, inseguras o ineficientes, código que se salta los estándares del equipo, violaciones de los límites entre dominios en un diseño guiado por dominio. Cuanto más específico el encargo, mejor: en lugar de "revisa la arquitectura", conviene pedirle que evalúe la capa de servicios y localice componentes que accedan al estado interno de otro dominio o reutilicen su código. Aquí hay que saber cuándo parar, porque el agente casi siempre encontrará algo mejorable y decidir qué hallazgos importan es tarea del equipo. Para que el resultado no sea ruido hace falta alguien con experiencia que sepa formular el encargo, además de objetivos medibles —requisitos de atributos de calidad, con sus compromisos y alternativas— en lugar de una lista de funciones.
La velocidad es la otra cara de la moneda. La generación automática de código no es nueva, pero un agente escribe mucho más rápido que cualquier herramienta anterior, y a ese ritmo es fácil perder el control de la calidad, sobre todo en la arquitectura. La recomendación que se repite es medir: someter el código generado a pruebas que evalúen el cumplimiento de los atributos de calidad, y partir de arquitecturas mínimas viables y aplicaciones esqueleto preconfiguradas para los prototipos. La práctica está en pañales y nadie tiene el manual, así que cada equipo aprende a golpe de prueba y error.
