🔁 Loop Engineering

Descubrir el siguiente fragmento de trabajo → planificar → actuar → comprobar el resultado → continuar o parar. Este es el loop agéntico, y cabe en una hoja.

Porque diseñar el ciclo sustituye escribir un prompt tras otro. Dejas de decir “haz esto” y pasas a decir “repite hasta que quede así”.

El loop es un grafo con ciclo. Los cinco pasos son nodos; las transiciones son aristas; «parar» es la única arista que sale del ciclo.

La regla que indica cuándo terminó el loop. Puede ser «la prueba pasó», «dos vueltas sin mejoras», «gastó X dólares» o «un humano aprobó».

Un bucle sin condición de parada no es un agente, es un grifo abierto. Y casi siempre la parada necesita capas: criterio normal + límite + una persona.

Detenerse por éxito ≠ detenerse por abandono. Ambas opciones deben existir, y la de abandono debe avisarle a alguien.

En cada vuelta, el agente lleva consigo algo: el historial, lo que ya intentó, lo que aprendió. Ese es el estado del loop.

Cargar demasiado satura la ventana de contexto y el agente empieza a confundirse con su propio rastro. Cargar muy poco hace que repita errores que ya cometió.

Decide explícitamente qué pasa entre vueltas: ese es el embrión del esquema de estado que la Trilha 4 formalizará.

Ejecutar el mismo prompt en bucle hasta alcanzar el objetivo: la versión más «digerible» de la ingeniería de bucles, popularizada a partir del método Ralph, de Geoffrey Huntley.

Porque fue ella la que se convirtió en el rostro de la técnica — y la versión simple terminó representando la idea completa. Mucha gente empezó allí y evolucionó; mucha gente se quedó allí.

La versión simple no es la versión equivocada; es la versión incompleta. La verdadera ingeniería de loops consiste en diseñar el ciclo e la prueba de salida.

Bucle cerrado mide el resultado y usa esa medida para corregir la siguiente vuelta. Bucle abierto solo repite, sin mirar el efecto.

Sin retroalimentación no tienes un agente, tienes un cron job costoso. La retroalimentación es lo que hace que el loop converja en vez de solo gastar.

Cerrado = mide y corrige. Y la calidad de la medición se convierte en el techo de la calidad del loop — el tema del módulo 2.2.

Un loop externo que decide qué hacer y, dentro de cada vuelta, un loop interno que ejecuta. Ej.: «para cada archivo de la lista, refactoriza hasta que pasen las pruebas».

Aquí es donde el bucle empieza a convertirse en grafo sin que te des cuenta: cada vuelta del externo es un nodo; el bucle interno es lo que se ejecuta dentro de ese nodo.

El bucle anidado es el puente natural hacia el grafo. Cuando los elementos internos necesitan comunicarse entre sí, el bucle externo ya no es suficiente.

El verificador es el paso que decide «¿ya está bien?». Define qué persigue el ciclo y, por lo tanto, el límite de calidad que puede alcanzar.

Un loop con un prompt promedio y un verificador excelente converge hacia algo bueno. Un loop con un prompt excelente y un verificador débil converge hacia algo que parece bueno.

Invierte donde está el cuello de botella. En la práctica: escribe el verificador antes del prompt.

Compila → lint → prueba automatizada → otro modelo que evalúa → humano. Cada escalón cuesta más y detecta un tipo distinto de error.

No eliges uno: los apilas. Ejecuta los baratos en cada vuelta y los caros solo cuando los baratos hayan pasado.

Verificador determinista (prueba) > verificador probabilístico (modelo) siempre que exista uno. Que el modelo juzgue es el último recurso, no el primero.

Cuando el mismo agente, en la misma conversación, escribe y después «revisa», casi siempre aprueba. Ya está convencido: el razonamiento que produjo el texto está ahí mismo.

Es el defecto más común y más invisible del bucle único. El informe dice “revisado”, y nadie revisó nada.

La revisión exige contexto limpio: quien juzga no puede ver cómo se hizo el trabajo, solo el resultado y el criterio. Esta es una de las razones por las que existe el grafo.

Todo verificador compara el resultado con alguna referencia: una prueba que pasa, un ejemplo aprobado, una regla escrita, un número objetivo.

Si la referencia es vaga («que quede bien»), el verificador se vuelve una opinión y el bucle, una cuestión de suerte. Una referencia concreta es lo que hace que la verificación sea repetible.

Escribe la referencia antes de ejecutar. Si no puedes escribirla, probablemente aún no sabes qué quieres — y ningún loop lo resolverá.

Pruebas que dejan de cubrir lo que cambió, datos que envejecen, definiciones de métricas que cambian por debajo sin que nadie avise. El panel sigue en verde.

Es la falla más silenciosa de todas: la medición pasa de “comprobar la realidad” a “comprobar el documento” — una cifra cotejada con otra cifra.

El verificador también necesita mantenimiento y auditorías periódicas. ¿Quién revisa al revisor? Alguien tiene que hacerlo.

Antes de escribir el prompt del agente, escribe cómo sabrás que acertó. Prueba el verificador con un resultado deliberadamente malo y comprueba si lo rechaza.

Un verificador que nunca rechaza nada no está verificando. Probarlo con un caso fallido conocido es la única forma de saber si funciona.

Primero, el verificador = la misma lógica que escribir la prueba antes que el código. Y luego se convierte en un en el de tu grafo.

Un loop solo ve su métrica, y por eso va a encontrar todos las formas de bajar este número, incluso las que traicionan su propósito.

Esto no es un mal funcionamiento: es el loop haciendo exactamente lo que le pediste, con un número que se desconectó silenciosamente de la realidad que representaba.

Cuando una medida se convierte en objetivo, deja de ser una buena medida. Una métrica por sí sola siempre termina siendo manipulada.

El loop persigue una referencia, pero nada dentro de él puede preguntarse si esa referencia es correcta. El termostato mantiene 20 grados; no puede preguntarse si 20 es la temperatura adecuada.

Un agente perfectamente ejecutivo puede pasar meses optimizando lo equivocado con excelencia. Y nadie dentro del loop puede darse cuenta.

Cuestionar el objetivo requiere a alguien afuera del loop: un nodo arriba, en el grafo, o una persona.

El loop de velocidad choca con el de calidad; el de contratación presiona al de cultura. Como dos aires acondicionados mal configurados: uno calienta, el otro enfría, los dos «funcionando».

Examinado por separado, cada loop pasa la revisión. La mentalidad de un solo loop no tiene vocabulario para describir la colisión.

La colisión entre bucles solo aparece cuando dibujas las aristas entre ellos — es decir, cuando lo conviertes en un grafo.

Los sensores se desajustan, los pipelines de datos se deterioran, la definición de la métrica cambia sin que te des cuenta. La verificación pasa de comprobar la realidad a comparar un documento con otro.

Es la falla más silenciosa: no hay alarma, porque la alarma depende de la misma medición que falló.

Necesita una verificación externa y periódica frente a la realidad. Nadie supervisa al supervisor por cuenta propia.

En un loop único, todo sucede en la misma ventana: HTML bruto de la búsqueda, medio borrador, razonamiento antiguo… todo flotando junto al momento de decidir.

Esta mezcla es lo que produce la revisión falsa del módulo 2.2 y hace que el agente “olvide” la instrucción original de arriba.

El contexto limpio por rol es uno de los beneficios concretos y medibles del grafo: no es retórica.

Un loop lee las fuentes una por una porque un loop es, por definición, algo que ocurre una cosa después de otra. No puede abrir diez frentes y reunirlos después.

Este es el único límite del loop que ningún prompt mejor lo resuelve. Y por eso es el argumento más honesto a favor del grafo.

Abrir en N y unir (fan-out / fan-in) es una primitiva de grafo. Un loop no puede hacerlo, por bien escrito que esté.