LLM11 – Cerrando el bucle

Una de las frases que repito más veces en estos últimos meses es que la manera correcta de usar agentes de IA no es «ir más rápido» sino «ir más seguro».

Esto significa invertir en todas estas áreas en las que habitualmente no hemos tenido tiempo —documentación, tests, automatizaciones— y también implica darle a los propios agentes la manera de verificar su trabajo.

¿Qué entendemos por verificar el trabajo?

Desde hace un año con Sonnet 3.7, los agentes no solamente ejecutan herramientas, sino que pueden aplicar razonamiento sobre el resultado de estas herramientas, y siempre va a ser más eficiente que el agente «vea» el resultado por sí mismo. Más que lo que podamos decirle nosotros, volviendo a la idea de show, not tell (mostrar, no decir).

Sin embargo los agentes no tienen (aún) contexto infinito sobre nuestro código, y es nuestra responsabilidad, si queremos aprovecharlos al máximo y ser eficientes, crear ciertas reglas y herramientas para que los agentes vean el resultado de su trabajo, y que llegue a nosotros en mejor estado.

Esas reglas y herramientas las podemos definir en el contexto de un término que aplica de manera bastante interesante, y es el de los bucles OODA.

El bucle OODA

Soy un fan de la serie de novelas de acción de Mark Greaney, y en la novela «The Chaos Agent» publicada en 2024 el protagonista se enfrenta a una IA malvada, y uno de los conceptos que se usan en el libro en el contexto de drones autónomos es el del bucle OODA (Observe, Orient, Decide, Act). Es un concepto que viene del combate aéreo y que se resume en «el lado con mejor observación gana, no el lado con mejores armas».

Con esa idea en mente, nuestro agente necesita capacidad de observación y orientación para poder avanzar, contexto para poder decidir y actuar, y volver a observar y orientarse para ver el resultado de sus acciones.

En este artículo veremos cómo implementar estos bucles a tres niveles, que llamaremos nivel local, nivel de ejecución y nivel de integración.

Local

Lo primero que necesita el agente es saber si el código funciona, y para eso lo más eficiente es decirle a nuestro agente, ya sea en un fichero README, o en un fichero AGENTS.md (Claude Code sigue usando CLAUDE.md), cómo resolver las dependencias de nuestra aplicación y cómo ejecutarlas.

Además de compilar, en un ciclo «local» podemos ejecutar pruebas unitarias, y hacer análisis de cobertura de código para confirmar que tenemos tests que cubren las nuevas características.

De hecho le podemos pedir a nuestro agente que cree estas instrucciones o agregar cobertura de código si no la teníamos:

Add run and test instructions to CLAUDE.md, and add a «run all tests first» instruction in the CLAUDE.md file. Add coverage testing and make sure new code is tested by 80%, add coverage instructions to Claude.md

Por tanto, podemos definir que la tarea está completada cuando compila, pasa tests, y el código nuevo tiene tests asociados que no bajan la cobertura. El agente compilará el código, verá errores y se recuperará. Ejecutará los tests, corregirá las regresiones y, cuando la cobertura falle por el nuevo código añadido, actualizará los tests.

Para ver el bucle en funcionamiento, una vez establecido, escribí esta tarea:

make the tasks editable

El resultado fue un cambio en la UI, los tests actualizados y un informe que me confirmaba que la cobertura de código era correcta.

Ejecución

En el siguiente bucle, nuestro agente necesita saber si el código se puede ejecutar más allá de los tests unitarios, es decir, si la aplicación funciona de manera local.

Si tenemos un servicio que nos proporciona una API, le podemos decir a nuestro agente cómo ejecutar un servidor en local, el tipo de URLs a las que accedemos, y el formato de las mismas.

Si tenemos un frontal visual, aquí entran en juego herramientas como el MCP de playwright o el CLI de agent-browser de vercel, que permiten interactuar con el navegador directamente desde el agente.

let’s add support for the agent-browser cli, execute it and add it to claude.md

Este último comando no solamente ejecutó agent-browser, sino que hizo un primer barrido por la web y agregó las URL relevantes.

La siguiente tarea combinaba colores e interacción visual, donde era importante que el agente viera la página:

let’s add support for drag-and-drop, and have todo-doing and done tabs have a different tab background, that should change when moving across option

En mi caso se limitó a crear tests, así que tuve que insistir:

use agent-browser to manually test as part of the workflow and add it to CLAUDE.md

Al cerrar este bucle, el agente no solamente ve el resultado del código o el de los tests, sino que puede manipular la aplicación e interpretar imágenes, lo cual incluso nos permite solucionar uno de los problemas que encontré al principio de esta serie y que vimos con LLM2, cuando los LLMs eran «ciegos».

Integración

Hasta ahora hemos visto bucles «locales» es decir, compilar y ejecutar la aplicación en nuestra propia máquina, pero también podemos darle una vuelta de tuerca adicional, desplegar la aplicación en un entorno controlado y ejecutar pruebas de integración.

Para hacer este proceso realista, he ampliado mi aplicación de ejemplo combinando GitHub Actions como herramienta de CI/CD y AWS como destino de despliegue.

Tras varios intentos con la CLI de AWS y tras lograr conectar AWS con Github, logré una ejecución exitosa dentro de la primera pull request, y no solamente pude ver como los test pasaban a través de la cli de GitHub, sino que además pude acceder a la URL usando agent-browser y comprobar que funcionaba.

Para agregar los tests de integración recurrí a Playwright:

now that we have deployment infrastructure, let’s add those playwright tests and expand the Github action.

El proceso final es el siguiente: Creamos el cambio, probamos localmente, creamos una pull request, la pull request ejecuta una «GitHub action» que despliega la aplicación en una cuenta de AWS, se ejecutan tests con Playwright y se apaga la aplicación. El resultado de este proceso lo podemos ver en la PR #3.

Skills y determinismo

El paso final de este proceso es darle determinismo, ya que por una parte tenemos el contexto en CLAUDE.md, pero queremos pasos concretos y reproducibles que definan el comportamiento del agente en estos bucles, y aquí es donde entran en juego las Skills. Las lecciones aprendidas durante este proceso las podemos ver documentadas en la PR #2.

Tras pedirle a Claude que preparara una Skill con lo aprendido en esta sesión, tuvo como resultado este bucle, que hemos denominado delegate:

$ARGUMENTS (task description)
    → explore codebase (understand what to touch)
    → plan + implement
    → npm test (fix if failing, maintain coverage)
    → if UI changed: agent-browser smoke-through
    → git checkout -b <branch>, commit, push
    → gh pr create

Un último cambio para pedirle que vigilara el resultado de gh pr create y ya estábamos listos. La prueba de fuego fue pedirle una tarea un poquito más compleja y «dejarlo hacer»:

/delegate I want to be able to switch from a list view to a kanban view, where the status in the
  list view can be changed by selecting a dropdown. Also in the list view we need to have sorting
  options, sort by update time, by title (alphabetically) or by status (alphabetically)

El resultado fue la PR #4: vista de lista con dropdown de estado, tres opciones de ordenación, edición inline de títulos, y 19 tests nuevos — todo con cobertura por encima del 80% y verificación visual con agent-browser.

Conclusiones

En 1994, Pirelli anunciaba sus neumáticos diciendo que «La potencia sin control no sirve de nada». 30 años después tenemos herramientas increíblemente potentes, pero sin el control adecuado son una fuente casi segura de código inmanejable y bugs. Por eso el mantra que comentaba al principio del artículo: no ir más rápido, ir más seguro.

En la práctica se resume en agregar esta infraestructura para que, cuando el código llega a nuestras manos, ya está compilado, ha pasado los tests, se ha podido inspeccionar visualmente y ha superado las pruebas de integración.

Sigue siendo nuestra responsabilidad que nuestro código funcione y entender cómo funciona, como mencionaba Simon Willison, pero los bucles nos dan un punto de partida para esa conversación, la discusión y el debate.

¿Y tú, has implementado bucles para trabajar con tus agentes?