Arquitectura como feedback para programar con IA

Uno de los principios más útiles cuando programas con agentes de IA es este: darles formas de verificar su trabajo.

Esa verificación puede ser muy directa: correr tests, abrir el navegador, hacer clic en la UI, comprobar que la funcionalidad realmente funciona para usuarios.

Pero hay otro tipo de verificación que también importa: feedback sobre si el cambio respeta las reglas internas de la base de código.

¿Este código nuevo respeta la arquitectura buscada? ¿Cruzó un límite que no debía cruzar? ¿Importó desde una capa que no debería conocer?

Ese es el ángulo que me interesa aquí.

Esta idea de arquitectura ya la conocemos

La idea de arquitectura en sí no es nueva.

La hemos tenido durante mucho tiempo con distintos nombres: layered architecture, Clean Architecture, Onion Architecture, Hexagonal Architecture. Distintos nombres, distintos énfasis, la misma intuición general: darle forma al sistema, limitar qué puede conocer cada parte, y evitar que las dependencias se propaguen arbitrariamente.

Así que no, no estoy proponiendo un patrón nuevo. Si acaso, estoy proponiendo volver a traer uno viejo al frente.

En frontend esto puede verse como rutas que dependen de features, features que dependen de estado y UI compartida, y código compartido que no depende de features de producto. En backend puede verse como API e infraestructura en los bordes, con la lógica de aplicación y dominio protegida de acoplamientos arbitrarios.

Puedes llegar a esto desde arquitectura en capas, desde arquitectura hexagonal o incluso desde Feature-Sliced Design en frontend. La etiqueta exacta importa menos que el principio.

El principio es simple: las dependencias deben tener dirección.

Arquitectura como feedback para agentes

Tradicionalmente, los equipos han intentado proteger la arquitectura con documentación, code review y buenas intenciones.

Eso ayuda, pero no alcanza. Las buenas intenciones, como siempre, no compilan.

La documentación explica reglas, pero no rompe el build. El code review detecta algunas violaciones, pero no todas. Y cuando la IA escribe más código, pequeñas violaciones pueden aparecer más rápido simplemente porque se está produciendo más código. ¿Has visto qué tan seguido estas herramientas alucinan?

El enforcement programático no es nuevo. Estas técnicas y herramientas existían antes del coding con IA. Mi punto es que merecen más atención ahora que los agentes escriben más código, más rápido.

Herramientas como eslint-plugin-boundaries, dependency-cruiser o reglas puntuales de no-restricted-imports permiten que el código valide automáticamente esas restricciones. Puedes pensar en eso como funciones de fitness arquitectónico. En vez de depender solo de documentación y memoria, la base de código puede verificar sus propias reglas estructurales.

Eso cambia el rol de estos checks en una base asistida por IA. Sin enforcement, la arquitectura es más una petición: "Por favor no importes desde ahí." Con enforcement, se convierte en feedback: "Ese import no está permitido. Inténtalo de nuevo." Esto importa mucho cuando quien hace el trabajo es un agente. Los agentes responden muy bien a loops de feedback. Si el linter o CI le dice al agente que cruzó una frontera prohibida, muchas veces puede corregirse solo y probar un diseño mejor.

Verificar en dos direcciones

Cuando hablamos de verificar código generado por IA, muchas veces pensamos en verificación hacia el usuario:

• ¿pasa la suite de tests?
• ¿funciona el flujo en el navegador?
• ¿la UX se siente correcta?

Eso es necesario, pero es solo la mitad de la historia.

También existe la verificación estructural:

• ¿el código nuevo se mantuvo en la capa permitida?
• ¿una feature se metió en internals de otra?
• ¿algo "shared" empezó a depender silenciosamente del código de producto?

Estas violaciones son fáciles de perder en una PR porque cada una, aislada, parece razonable. Un import de una línea no se ve dramático. Tampoco el siguiente. Pero después de suficientes atajos, la base de código pierde su forma.

Por eso me gusta la idea de una arquitectura que se defiende sola. La base debería ayudar a preservar su estructura con checks que disparen temprano y automáticamente.

Supongamos que un agente implementa una feature y alcanza un módulo cruzando un límite no permitido. Falla la regla. Ese fallo es información útil. Y el agente puede arreglarlo y refactorizar sin que tengas que intervenir.

Ese es el punto que quiero destacar. Verificar código con IA no es solo comprobar si la funcionalidad le sirve al usuario. También es validar si el cambio respeta la forma de la base de código. Tests, automatización de navegador y checks de arquitectura sirven al mismo objetivo: darle feedback al agente en tiempo real.