Los agentes de programación con IA pueden ayudar a los equipos de software a abordar problemas arquitectónicos que van más allá de la simple escritura de código, pero su utilidad depende de la claridad de los objetivos y las restricciones que defina el equipo. El artículo publicado en InfoQ, elaborado por Pierre Pureur, Kurt Bittner y Todd Miller y revisado por Daniel Bryant, advierte que proporcionar al agente únicamente requisitos funcionales no garantiza una arquitectura escalable, segura o fácil de mantener.
El enfoque propuesto se basa en los requisitos de atributos de calidad (Quality Attribute Requirements o QARs), como el rendimiento, la seguridad y la escalabilidad, así como en aclarar las compensaciones que el agente debe tener en cuenta. El artículo también insiste en la necesidad de probar lo que produce el agente mediante métricas claras, en lugar de limitarse a revisar el código o confiar en sus recomendaciones.
1. Documentar los servicios heredados antes de depender de ellos
Una arquitectura moderna puede depender de un servicio heredado que desempeña una función específica, como recuperar datos de pólizas de seguros de un sistema antiguo basado en una base de datos IMS. El problema es que estos servicios pueden carecer de documentación precisa, lo que dificulta comprender los flujos de datos o detectar defectos lógicos y de seguridad que podrían aparecer en fases avanzadas del desarrollo o después del paso a producción.
El agente puede representar el diseño del servicio y documentar los flujos de datos; después, puede examinar el código y proponer correcciones o una refactorización si el servicio resulta difícil de comprender y mantener. Sin embargo, este uso no elimina la necesidad de que un ingeniero decida si el servicio puede conservarse o si sus riesgos exigen sustituirlo.
2. Buscar defectos arquitectónicos
Se puede orientar al agente para que encuentre incumplimientos de los estándares arquitectónicos, prácticas de programación degradadas o partes que necesiten una refactorización. Entre los ejemplos de revisión se incluyen el diseño de las interfaces de programación de aplicaciones, así como interfaces complejas, inseguras o ineficientes, y las infracciones de los límites del diseño guiado por el dominio (DDD).
El artículo señala que el agente probablemente encontrará muchas mejoras, por lo que el equipo debe distinguir entre los problemas importantes y las sugerencias de bajo valor. La calidad de los resultados aumenta cuando los ingenieros definen objetivos medibles, alternativas conocidas y compensaciones claras, en lugar de limitarse a describir las funciones requeridas.
3. Auditar la seguridad con aislamiento del agente
El agente puede utilizarse para representar flujos de datos, identificar archivos de alto riesgo, examinar defectos lógicos complejos y crear pruebas o scripts que simulen intentos de explotación; después, puede proponer parches para los problemas detectados. El artículo presenta una experiencia que incluyó paquetes npm clasificados como riesgo de seguridad: se actualizaron dos paquetes, se sustituyó uno y se conservó otro después de considerar la alerta una falsa alarma.
Sin embargo, este uso requiere restricciones operativas explícitas: limitar el acceso del agente a los archivos autorizados, ocultar las contraseñas de las bases de datos y los secretos, ejecutar las pruebas en una red aislada y exigir una revisión humana antes de integrar cualquier cambio.
4. Crear una base arquitectónica para los prototipos
La velocidad de los agentes permite construir rápidamente un prototipo, pero el resultado puede ser temporal e inadecuado si no se definen objetivos arquitectónicos. El artículo propone preparar aplicaciones estructurales predefinidas que incluyan el estilo de escritura del código, el diseño de la base de datos, las interfaces, las plataformas y los marcos preferidos, además de QARs redactados en formato Markdown.
También se pueden utilizar plantillas de GitHub para estandarizar la estructura inicial de las aplicaciones e incorporar los estándares del equipo desde el principio. Lo mejor es describir el objetivo, las restricciones y la forma de verificar su cumplimiento, en lugar de imponer de antemano al agente una solución detallada.
5. Generar arquitecturas iniciales comprobables
El artículo propone utilizar el agente para crear Minimum Viable Architectures o MVAs, de modo que no se limiten a código que demuestre las funciones, sino que incluyan también las pruebas, los datos de prueba y el entorno de ejecución necesarios para verificar los QARs. El agente puede generar herramientas de prueba y configuraciones de contenedores, pero el equipo debe asegurarse de que las pruebas midan realmente los atributos requeridos.
También se debe evaluar la capacidad de la MVA para admitir escenarios de cambio arquitectónico, porque ampliar una arquitectura generada automáticamente puede resultar costoso si no está diseñada para evolucionar.
¿Qué cambia en la práctica?
El mensaje principal del artículo es que los agentes de programación hacen más rápida la producción de código, pero aumentan la importancia de formular los requisitos, las restricciones y las pruebas. Las habilidades relacionadas con la escritura de código no desaparecen, pero determinar qué debe construirse, qué se considera una calidad aceptable y cómo se medirá se vuelve más delicado. Por ello, el agente debe tratarse como una herramienta bajo supervisión arquitectónica, no como un sustituto del criterio de ingeniería.