Las arquitecturas limpias cobran cada vez más importancia, especialmente en la era de la programación asistida por IA.
En mi experiencia con OpenCode en proyectos reales me ha llevado a una hipótesis empírica: “la arquitectura hexagonal facilita el trabajo de los agentes de IA”. Los agentes trabajan mejor cuando la arquitectura hace explícitos los límites del sistema, y la arquitectura hexagonal consigue precisamente eso.
La razón técnica es clara:
En arquitectura hexagonal, el dominio vive en el centro. Los casos de uso expresan intención de negocio. Los puertos definen contratos. Los adaptadores traducen el mundo exterior: base de datos, APIs, colas, filesystem, frameworks, UI.
Un agente no entra al proyecto con seis meses de contexto acumulado. Entra leyendo archivos, buscando patrones, indexando nombres, interpretando instrucciones y decidiendo dónde tocar código con una ventana de contexto limitada.
Un agente no razona como un arquitecto humano. Construye una representación del proyecto a partir del contexto disponible. Cuanto más consistentes son las responsabilidades, los nombres y las dependencias, menor es la ambigüedad que debe resolver durante el razonamiento.
Cuando el repositorio tiene una estructura predecible, el agente tiene menos que adivinar. Es como tener un índice en un libro por donde comenzar a buscar.
Si le pides una nueva funcionalidad, puede ubicar el caso de uso correcto o crear uno nuevo siguiendo el patrón existente. Si necesita integrar una API externa, puede trabajar en un adaptador. Si debe respetar reglas de negocio, tiene una señal clara de que el dominio no debería depender del framework ni de la base de datos.
Eso cambia el resultado.
En el vibecoding, la IA tiende a resolver el problema inmediato. Te da una solución que funciona “ahora”, pero no necesariamente una solución que encaja con el modelo del sistema. No suele detenerse sola a proponer una arquitectura limpia, separar puertos, proteger el dominio o pensar en mantenibilidad futura.
Si el proyecto ya tiene una arquitectura limpia, la historia cambia.
El agente empieza a reproducir los patrones que encuentra. Implementa siguiendo la forma existente. Propone archivos donde esperas encontrarlos. Encaja mejor las piezas nuevas en el diseño general.
Ahí es donde herramientas como OpenCode se vuelven más interesantes.
No solo por la ejecución de código, sino por el flujo de trabajo: planificar antes de implementar, dividir tareas, usar sub-agentes cuando tiene sentido, revisar impactos y verificar que cada cambio respete el modelo arquitectónico propuesto.
La arquitectura limpia siempre prometió mantenibilidad, testabilidad y separación de responsabilidades. Con agentes de IA aparece otro beneficio: le da al modelo un mapa operativo del proyecto.
La conclusión que sí me parece defendible es esta:
No solo importa el AGENTS.md, las instrucciones del repo o los comandos de test. También importa que el propio código tenga una forma reconocible.
Una arquitectura limpia le dice al agente, sin escribirlo en cada prompt:
- aquí vive el dominio
- aquí están los casos de uso
- aquí están los contratos
- aquí están los adaptadores
- aquí se prueban las reglas
- aquí no deberías meter infraestructura
Ese mapa reduce fricción. Y cuando reduces fricción en cada tarea pequeña, la velocidad acumulada se nota: implementación, debug, integración de nuevas funcionalidades y colaboración entre varios desarrolladores sobre el mismo proyecto.
Los equipos que tengan código predecible, testeable y bien separado van a sacar más provecho de estas herramientas que los equipos que esperen que el agente entienda un monolito accidental lleno de excepciones históricas.
La IA puede acelerar mucho. Pero acelera lo que encuentra.
Si encuentra intención, reproduce intención. Si encuentra caos, escala caos.
Conversación
Comparte una idea, pregunta o mejora sobre esta publicación.