La inteligencia artificial está cambiando la forma en que construimos software. Hoy es posible generar controladores, servicios, repositorios, pruebas unitarias e incluso propuestas completas de arquitectura en cuestión de segundos. Sin embargo, esta velocidad también introduce un nuevo riesgo: producir grandes cantidades de código incorrecto a una velocidad sin precedentes.
Muchos desarrolladores están descubriendo que la calidad del software generado por IA depende menos del modelo utilizado y más de la arquitectura sobre la cual se construye el sistema. Cuando la arquitectura es clara, las herramientas de IA tienden a producir resultados consistentes. Cuando la arquitectura es difusa o inexistente, la IA suele amplificar los problemas existentes.
Por esta razón, antes de hablar de prompts, agentes o generación de código, es necesario hablar de arquitectura. En un entorno donde una parte importante del código puede ser producida automáticamente, la arquitectura deja de ser un detalle técnico y se convierte en el principal mecanismo de control.
El problema de dejar que un agente programe sin reglas claras
Imaginemos que le pedimos a una IA que implemente una nueva funcionalidad en una aplicación ASP.NET Core:
Implementa el caso de uso para registrar un cliente.
La solicitud parece razonable, pero deja demasiadas decisiones abiertas. El agente deberá decidir dónde colocar la lógica, cómo validar los datos, cómo acceder a la base de datos y cómo manejar errores. En ausencia de restricciones explícitas, tomará decisiones basadas en los patrones más frecuentes encontrados durante su entrenamiento.
El resultado suele funcionar desde una perspectiva técnica. El código compila, las pruebas básicas pasan y la funcionalidad parece correcta. Sin embargo, es común encontrar lógica de negocio dentro de controladores, dependencias directas hacia Entity Framework, validaciones dispersas y un fuerte acoplamiento entre capas.
El problema no es que la IA haya cometido un error. El problema es que nunca recibió reglas claras sobre cómo debía construir la solución.
Cuando un desarrollador senior incorpora a un nuevo miembro al equipo, normalmente le explica la arquitectura, los patrones utilizados y las convenciones del proyecto. Con los agentes ocurre exactamente lo mismo. La diferencia es que la IA ejecutará las instrucciones con una velocidad mucho mayor, tanto para bien como para mal.
La IA genera código acoplado por defecto
Existe una característica importante que muchos equipos descubren después de utilizar IA durante varios meses: los modelos tienden a generar soluciones fuertemente acopladas cuando no reciben restricciones arquitectónicas.
Esto ocurre porque las implementaciones más comunes encontradas en internet suelen priorizar la rapidez sobre la separación de responsabilidades. Como consecuencia, es frecuente obtener ejemplos donde la lógica de negocio depende directamente de frameworks, bibliotecas externas o detalles de infraestructura.
Por ejemplo, una implementación típica podría verse así:
public async Task<IActionResult> Create(CreateOrderRequest request)
{
var order = new Order();
if(request.Items.Count == 0)
return BadRequest();
_dbContext.Orders.Add(order);
await _dbContext.SaveChangesAsync();
return Ok();
}
A primera vista no parece haber ningún problema. Sin embargo, la lógica de negocio, las validaciones, el acceso a datos y la capa web están mezclados dentro de la misma operación.
Cuando este patrón se replica cientos o miles de veces dentro de una aplicación, aparecen dificultades para realizar pruebas, evolucionar el dominio o reemplazar tecnologías específicas.
La IA no está intentando sabotear la arquitectura. Simplemente está optimizando para producir una solución funcional utilizando los patrones más frecuentes disponibles.
El verdadero riesgo no es el código incorrecto
Cuando se habla de IA en desarrollo de software, muchas conversaciones se enfocan en errores sintácticos o defectos funcionales. Sin embargo, esos problemas suelen ser relativamente fáciles de detectar mediante pruebas automatizadas y revisiones de código.
El riesgo más importante es otro: la erosión gradual de la arquitectura.
Cada vez que una nueva funcionalidad introduce dependencias innecesarias, mezcla responsabilidades o viola límites entre capas, la complejidad del sistema aumenta ligeramente. Individualmente, estos cambios parecen insignificantes. Acumulados durante meses o años, terminan convirtiéndose en una deuda técnica difícil de revertir.
La IA puede acelerar enormemente este proceso porque produce cambios con una velocidad mucho mayor que un desarrollador trabajando manualmente.
Por eso, el principal desafío no consiste en evitar que la IA genere código. Consiste en asegurarse de que el código generado respete las reglas arquitectónicas del sistema.
La arquitectura se convierte en un conjunto de guardarraíles
Una forma útil de entender la relación entre arquitectura e IA es pensar en la arquitectura como un sistema de guardarraíles.
Los guardarraíles no indican exactamente qué camino seguir. Su función es impedir que salgamos de la carretera.
Cuando una arquitectura está bien definida, limita las decisiones que pueden tomar tanto los desarrolladores como los agentes. Esto reduce la variabilidad de las implementaciones y aumenta la consistencia del sistema.
Por ejemplo, si la arquitectura establece que:
- La lógica de negocio vive en el dominio.
- El dominio no depende de frameworks.
- La persistencia se accede mediante interfaces.
- La infraestructura implementa contratos definidos por el dominio.
Entonces cualquier implementación generada por IA debe respetar esas reglas. El espacio de posibles soluciones se reduce y los resultados se vuelven mucho más predecibles.
Por qué la Arquitectura Hexagonal funciona especialmente bien con IA
Existen muchas arquitecturas válidas dentro del ecosistema .NET. Sin embargo, la Arquitectura Hexagonal presenta una característica especialmente interesante para los equipos que utilizan IA generativa: define fronteras extremadamente claras.
En una arquitectura hexagonal, el dominio ocupa el centro del sistema. Todo lo demás —bases de datos, APIs, colas de mensajes, frameworks y bibliotecas externas— se considera un detalle de infraestructura.
Esta separación proporciona instrucciones muy concretas para los agentes:
- La lógica de negocio pertenece al dominio.
- La infraestructura no define reglas de negocio.
- Las dependencias apuntan hacia el interior.
- Las integraciones externas se realizan mediante puertos y adaptadores.
Estas restricciones facilitan enormemente la generación de código consistente. En lugar de improvisar dónde colocar cada responsabilidad, el agente dispone de un conjunto claro de límites arquitectónicos.
Un ejemplo práctico en .NET
Supongamos que necesitamos agregar soporte para un nuevo proveedor de pagos en una aplicación de comercio electrónico.
En una arquitectura fuertemente acoplada, la lógica de integración suele terminar dispersa entre servicios, controladores y repositorios. Cada cambio implica modificar múltiples componentes.
En una arquitectura hexagonal, el dominio define un contrato:
public interface IPaymentGateway
{
Task ProcessPaymentAsync(Payment payment);
}
La implementación concreta se ubica en infraestructura:
public class StripePaymentGateway : IPaymentGateway
{
// Implementación específica
}
Cuando la IA recibe este contexto, entiende inmediatamente dónde debe colocar cada pieza. El dominio permanece estable y la infraestructura puede evolucionar sin afectar las reglas de negocio.
La arquitectura proporciona las restricciones necesarias para que la generación automática siga siendo sostenible a largo plazo.
La arquitectura es más importante que nunca
Durante años, muchos equipos consideraron la arquitectura como una preocupación secundaria frente a la implementación. En la era de la IA ocurre exactamente lo contrario.
La capacidad de producir código se está volviendo cada vez más barata. Lo que sigue siendo costoso es mantener sistemas comprensibles, evolutivos y alineados con las necesidades del negocio.
La arquitectura es el mecanismo que permite preservar esas propiedades cuando la velocidad de desarrollo aumenta drásticamente.
Cuanto más código pueda generar un agente, más importante será contar con límites claros que definan dónde debe vivir cada responsabilidad.
Conclusión
La inteligencia artificial no elimina la necesidad de una buena arquitectura. En realidad, la vuelve aún más importante.
Los agentes son extremadamente eficaces generando soluciones dentro de un marco de trabajo bien definido. Sin embargo, cuando las reglas son ambiguas o inexistentes, tienden a producir sistemas cada vez más acoplados y difíciles de mantener.
Por esta razón, la arquitectura debe considerarse el primer paso antes de generar una sola línea de código. Una buena arquitectura no limita el potencial de la IA; lo amplifica. Proporciona los guardarraíles necesarios para que la velocidad de ejecución no termine convirtiéndose en deuda técnica.
Y entre las distintas alternativas disponibles, la Arquitectura Hexagonal destaca porque ofrece precisamente lo que los agentes necesitan para trabajar de forma predecible: límites claros, responsabilidades bien definidas y una separación rigurosa entre el dominio y la infraestructura.
