La Arquitectura de Software es más importante ahora mismo que nunca.
Es lo que nos asegura que nuestro código pueda escalar.
Un código con una mala base, hace que entregar nuevas funcionalidades sea más complicado. Tanto si programa un humano como si programa un agente.
Y también afecta a la percepción que tenemos de la programación agéntica.
Vamos a poner un ejemplo.
Programación agéntica con una mala arquitectura
Teniendo la estructura del código:
⏺ ecommerce/
├── src/
│ ├── controllers/
│ │ ├── ProductController # 2847 líneas
│ │ ├── CartController # 1923 líneas
│ │ ├── OrderController # 3156 líneas
│ │ ├── UserController # 1542 líneas
│ │ ├── PaymentController # 2234 líneas
│ │ └── ShippingController # 1876 líneas
│ ├── models/
│ │ ├── Product # Solo esquema de BD
│ │ ├── Cart
│ │ ├── Order
│ │ ├── User
│ │ └── Payment
│ ├── routes/
│ │ └── index
│ ├── utils/
│ │ └── helpers # Funciones random
│ └── index
└── Makefile
Al decirle al agente el prompt:
Añade productos sugeridos en el carrito del usuario
Lo más probable es que el cambio que haga sea:
⏺ ecommerce/
├── src/
│ ├── controllers/
│ │ ├── ProductController # 2847 líneas
- │ │ ├── CartController # 1923 líneas
+ │ │ ├── CartController # 2387 líneas (+464)
│ │ ├── OrderController # 3156 líneas
│ │ ├── UserController # 1542 líneas
│ …
└── Makefile
Básicamente lo que hace el agente es respetar la arquitectura que tenemos. En este caso una arquitectura MVC.
Y eso no es malo, depende del contexto puede ser algo bueno:
- Cuando estamos montando una nueva aplicación y queremos explorar.
- Cuando estamos solventando un bug de la manera más rápida.
Pero sí que tiene bastantes desventajas si tenemos una aplicación que requiere de mantenimiento a lo largo del tiempo:
- El agente ha consumido mucho contexto para poder hacer esta tarea ya que va cargando esos mega ficheros.
- Cuantas más funcionalidades vayamos añadiendo, más lento irán los agentes.
- La probabilidad de alucinación se incrementa y, por lo tanto, el riesgo de que no haga lo que esperamos.
Si solo has probado la programación agéntica con este tipo de código, lo más probable es que tu opinión sobre programar con IA sea: "Va bien, pero hay que ir con mucho cuidado y revisar todo lo que hace".
Programación agéntica con una buena arquitectura
Ahora veamos qué pasa con una estructura basada en Arquitectura Hexagonal y DDD:
⏺ ecommerce/
├── src/
│ ├── app/
│ │ └── api/
│ │ ├── cart/
│ │ ├── orders/
│ │ └── products/
│ └── contexts/
│ ├── ecommerce/
│ │ ├── cart/
│ │ │ ├── application/
│ │ │ ├── domain/
│ │ │ └── infrastructure/
│ │ ├── orders/
│ │ └── products/
│ └── backoffice/
│ ├── analytics/
│ └── inventory/
├── tests/
│ ├── app/
│ │ └── api/
│ │ ├── cart/
│ │ ├── orders/
│ │ └── products/
│ └── contexts/
│ ├── ecommerce/
│ │ ├── cart/
│ │ ├── orders/
│ │ └── products/
│ └── backoffice/
│ ├── analytics/
│ └── inventory/
└── Makefile
Al aplicar el mismo prompt, el resultado sería:
⏺ ecommerce/
├── src/
│ ├── app/
│ │ └── api/
│ │ ├── cart/
│ │ ├── orders/
- │ │ └── products/
+ │ │ ├── products/
+ │ │ └── suggested-products/ # +18 líneas
│ └── contexts/
│ ├── ecommerce/
│ │ ├── cart/
│ │ ├── orders/
- │ │ └── products/
+ │ │ ├── products/
+ │ │ └── suggested-products/
+ │ │ ├── application/
+ │ │ │ └── ProductSuggester # +45 líneas
+ │ │ ├── domain/
+ │ │ │ └── SuggestedProduct # +23 líneas
+ │ │ └── infrastructure/ # +38 líneas
│ └── backoffice/
│ ├── analytics/
│ └── inventory/
├── tests/
│ ├── app/
│ │ └── api/
│ │ ├── cart/
│ │ ├── orders/
- │ │ └── products/
+ │ │ ├── products/
+ │ │ └── suggested-products/ # +24 líneas
│ └── contexts/
│ ├── ecommerce/
│ │ ├── cart/
│ │ ├── orders/
- │ │ └── products/
+ │ │ ├── products/
+ │ │ └── suggested-products/ # +52 líneas
│ └── backoffice/
│ ├── analytics/
│ └── inventory/
└── Makefile
Aquí vemos que, al igual que antes, ha respetado la arquitectura existente.
Pero hay una gran diferencia: es muchísimo más probable que el prompt haya funcionado perfectamente a la primera:
- Tiene que tocar más ficheros, pero mucho más pequeños y acotados. Por lo tanto, el agente rinde mejor.
- Al tener ficheros pequeños y bien nombrados, el agente puede navegar mejor el código y encontrar dónde hacer los cambios sin cargar todo en contexto.
- Al tener una separación por módulos con agregados pequeños y atómicos, simplemente ha tenido que crear uno nuevo replicando la estructura existente.
- Al tener una buena base de tests, ha creado tests para el nuevo caso de uso, verificando que funcione correctamente.
- Al tener eventos de dominio, esas sugerencias se pueden calcular asíncronamente sin tener que modificar el código de productos. Todo esto gracias a respetar el principio OCP de SOLID.
Además, seguramente el código creado se parece mucho al que haría cualquier persona del equipo.
Lo que está haciendo la IA es que las buenas prácticas brillen mucho más. Aquí es donde la programación agéntica se luce.
Conclusión
La programación agéntica no viene a sustituir las buenas prácticas, sino a amplificarlas.
Todo lo que afecta a los humanos para escalar y mantener el código, afecta de la misma manera a los agentes IA.
Si tu código ya tiene una buena arquitectura, los agentes te ayudarán a escalarla. Si no la tiene, nunca ha habido un mejor momento para aplicarla.