Bucles Agénticos Autónomos ArquitectónicosBucles Agénticos Autónomos Arquitectónicos

Mi trabajo como arquitecto de software está evolucionando hacia diseñar sistemas que puedan validarse a sí mismos.

Esto, a su vez, permite usar bucles agénticos autónomos que no comprometen la calidad del código.

En este número quiero compartir contigo mis aprendizajes al diseñar bucles agénticos autónomos arquitectónicos.

#Los prerrequisitos

Dejar que los agentes programen de forma autónoma en un proyecto sin un harness es una auténtica temeridad.

No solo vas a perder la intención sobre cómo debería ser el código: vas a acabar con el aspecto del sistema promedio, que, para mí, no refleja buenas prácticas.

“

Los agentes no tienen gusto.

”

Así que una suite de tests sólida, con tests unitarios, de integración y e2e, es absolutamente esencial. El testing de mutación y el basado en propiedades también son enfoques interesantes para reducir el número de bugs.

Los tests de arquitectura son algo que también estoy explorando.

El linting con Biome u Oxlint puede cazar un montón de inconsistencias, mientras que compilar con TypeScript es obligatorio en proyectos escalables, incluso con IA.

Como ves, todo aquello que pueda validar el proyecto a través de código.

Y aun así, nada de esto importa si no eres capaz de capturar la intención de los cambios.

#La intención

Antes de la IA, definir la intención de una nueva funcionalidad era parte del proceso.

Primero describíamos el problema a resolver mediante una User Story, siguiendo las metodologías ágiles. Al desarrollar funcionalidades con IA es tremendamente fácil caer en la trampa de dejar que los agentes descubran por sí solos todos los caminos y soluciones a un problema dado. A veces resolverán el problema en cuestión y a veces resolverán algo que no tocaba. O lo resolverán de una forma que no es correcta arquitectónicamente.

Es más, descubrir qué hay que resolver y por qué es lo que crea intención.

¿No sientes que en los sistemas diseñados completamente por agentes el conocimiento sobre qué hacen las cosas o por qué se comportan como se comportan está... diluido?

Y con razón: se nota que no hay intención detrás de los prompts que se envían a la IA. Estos prompts tienen esta pinta:

• Implementa todas las issues
• Refactoriza la app con buenas prácticas
• Arregla producción

Estos prompts plantean demasiadas preguntas. ¿Cómo deberían implementarse las issues? ¿Qué son buenas prácticas? ¿Qué está roto y por qué?

Así que necesitamos puntos de contacto donde plasmar una intención verbalizada y bien pensada sobre la tarea en cuestión. El qué y el porqué.

Ahora mismo estoy en el proceso de descubrir esos puntos de contacto. Los ADRs (Architectural Decision Records), las User Stories, las issues, las specs o las notas de cambios son todos candidatos a ser esos puntos de contacto para un Human in the Loop (HITL). Los puntos de contacto deberían diseñarse para que hagan aflorar la intención.

Una vez tenemos la intención, podemos pasar a la ejecución.

#Objetivos para bucles con planificación

Cuando abordo una tarea grande, pero bien definida, y una vez tengo un harness en el que puedo confiar, empiezo con el modo /plan.

Le doy toda la información y el contexto necesarios. Soy cuidadoso con cuánto contexto le paso: solo el imprescindible. Demasiado contexto también es un problema.

Con el contexto listo, le pido a la IA que me entreviste para recabar más contexto sobre la tarea en cuestión.

/plan Quiero migrar [módulo] de [estado actual] a [estado objetivo].

Contexto:
- Issue: [enlace]
- Código relacionado: [rutas]
- Del equipo: [mensajes, restricciones]

Antes de planificar nada, explora el código y después entrevístame para recabar más contexto:
el flujo actual, los casos límite, qué queda fuera de alcance y qué significa terminado.
Sigue haciendo rondas de preguntas hasta que no te queden preguntas relevantes. Solo
entonces escribe el plan.

Esta es una de las técnicas más útiles que he encontrado. A veces no sabes qué preguntas hay que responder. Pues deja que la IA lo descubra mientras tú sigues dando las respuestas correctas.

Una vez ha detallado el plan, lo repaso y hago ajustes si es necesario.

Y después, dependiendo de si es un plan abierto donde quiero que el agente tenga más libertad, o un plan cerrado donde quiero que el agente tenga menos libertad, elijo entre /goal o /loop.

/goal El plan de [plan.md] está completamente implementado: cada paso marcado, los tests
pasando, lint y typecheck limpios, sin commits pendientes y el cambio verificado
manualmente en [entorno].

/loop Trabaja la siguiente fase sin marcar de [plan.md] hasta dejarla en verde: tests,
  lint y typecheck pasando. Haz commit, marca sus casillas y continúa hasta completar
  todas las fases.

Pueden parecer similares, pero saber cuándo usar cada uno es importante.

Para migraciones me ha resultado útil pedirle a la IA que genere un skill donde documente sus aprendizajes. Cuando la migración termina, ese skill se borra.

Después, cuando ha generado el código, ha hecho los commits y ha actualizado la pull request, reviso el código. Como tengo el harness y un plan bien definido, el resultado es el que esperaba: código de alta calidad, guiado por la intención. Justo como a mí me gusta.

#Conclusión

Saber de buenas prácticas, arquitectura y patrones de diseño, y tener una mente orientada a resolver problemas, se traduce muy bien en diseñar bucles agénticos autónomos arquitectónicos.

Los agentes pueden programar lo que les pidas. Saber cómo deberían programar y crear un sistema donde podamos validar la calidad del código es la única forma realista de crear una arquitectura que perdure.

P.D.: Hoy no hay P.D.