La primera vez que usas un agente de código, parece que la parte importante es el prompt. Le dices qué quieres, esperas unos segundos, modifica archivos y devuelve una respuesta.
Pero cuanto más lo uso, menos me interesa el prompt aislado. Lo interesante aparece cuando el agente no solo ejecuta una orden, sino que entra en un ciclo: planifica, cambia algo pequeño, observa el resultado y decide si seguir o parar.
Un bucle, en este contexto, necesita tres piezas sencillas: un objetivo, una acción y una condición de parada. Sin objetivo, el agente solo se mueve. Sin verificación, no sabe si avanzó. Sin parada, puede seguir iterando aunque ya no aporte nada.
Ese ciclo es un Agent loop. No es magia. Se parece más a una versión práctica de razonar, actuar y observar: el agente intenta algo, mira qué pasó y usa esa señal para acercarse al resultado que queríamos desde el principio.
Plan
Define el resultado esperado, el primer intento y cómo se va a comprobar.
Maker
Hace el cambio mínimo que puede acercar el estado actual a ese resultado.
Checker
Observa señales concretas: build, rutas, voz, diseño, riesgo o evidencia visual.
Stop
Para cuando el criterio se cumple, el riesgo sube o la siguiente iteración ya no compensa.
La promesa habitual de los agentes es velocidad. Pero la velocidad sin una forma de evaluación solo amplifica el desorden. Puedes generar más código, más commits, más explicaciones y aun así estar menos seguro de lo que cambió.
Por eso el centro del loop no es repetir. Es tener una forma de medir si cada intento se acerca al resultado esperado. En tareas de código, esa señal puede ser un build que pasa, una prueba, una captura visual, una revisión de otro agente o una checklist escrita antes de empezar.
El agente no sustituye el criterio: lo fuerza a volverse explícito. Si no puedes explicar cómo se revisa un resultado, probablemente tampoco sabes qué significa que esté “bien”.
1. Instrucciones
En este proyecto, OpenCode carga AGENTS.md y .opencode/LOOPS.md. Ahí vive el contrato: usar npm, no tocar dist, verificar con build y proteger la voz visual del portfolio.
2. Agentes
El maker-checker separa quien produce de quien evalúa. Es una versión simple del patrón evaluator-optimizer: un intento, feedback, otro intento y una decisión de parada.
3. Comando
/goal-loop empaqueta la intención humana en un loop acotado: objetivo, verificación, feedback, límite de iteraciones y condiciones de parada antes de tocar archivos.
Goal: [resultado esperado]
Act: cambia solo lo más valioso ahora
Observe: mira señales concretas [build, rutas, voz, UX]
Feedback: qué falta para acercarse al resultado
Stop: criterio cumplido, límite alcanzado o bloqueoNo todo necesita un loop. Para una corrección pequeña, puede ser burocracia. Para una decisión de producto, puede dar una falsa sensación de objetividad. Y para investigación, el checker puede ser tan sesgado como la persona que escribió la rúbrica.
También hay un coste: más pasos, más latencia y más superficie para que un error se propague. Si el criterio de parada es vago, el loop no mejora el trabajo; solo lo alarga.
Mi hipótesis no es que los loops hagan mejores ingenieros por defecto. Es más modesta: obligan a separar producción de evaluación. Y esa separación empieza a importar cuando una herramienta puede producir más rápido de lo que nosotros podemos revisar.
Un loop solo tiene sentido si sabemos a dónde queremos llegar.