Loop engineering: el bucle del que no formas parte

Claude Code, por dentro, cabe en unas 300 líneas: un modelo, un bucle while y suficientes tools —las funciones que el agente puede pedir que tu código ejecute—. Thorsten Ball lo escribió entero para demostrarlo: “un agente es solo un LLM, un loop y suficientes tokens” (How to Build an Agent). Que uno de los agentes de código más usados en 2026 sea casi trivial por dentro deja una conclusión incómoda: el trabajo difícil ya no es el bucle, es diseñarlo.

De ahí el eslogan de moda —“no deberías promptear agentes; deberías diseñar los bucles que promptean a tus agentes”, de Peter Steinberger (tweet)—. Pero el eslogan, solo, no construye nada. Loop engineering —diseñar el bucle que orquesta al agente en vez de teclearle prompts uno a uno— se reduce a tres decisiones concretas, y ninguna de ellas es “usa un loop”.

Subir o bajar un bucle: la decisión que el eslogan se salta

Apilar bucles (stacking loops) es la práctica que Steinberger, Boris Cherny —creador de Claude Code— y Andrej Karpathy describen por separado en 2026: la habilidad nueva no es escribir el loop, es saber cuándo subir uno y cuándo bajarlo (Loopcraft).

Subir un bucle es ganar apalancamiento: envuelves una tarea que hacías a mano en un loop del que te sacas a ti mismo, y delegas más. Bajar un bucle es recuperar fiabilidad: cuando un paso falla de forma cara, vuelves a meter un control humano o un check estricto justo en ese punto. Lo que decide el nivel correcto no es la moda, es la fuerza de tu verificador —el mecanismo que comprueba barato si un paso está bien—. Verificador fuerte: puedes subir. Débil: tienes que bajar. Cómo construir y abaratar ese verificador es una escalera propia, que desarrollé en La escalera de verificación.

Subir sin verificador no escala trabajo: escala errores. Andon Labs midió una ejecución de Claude Opus 4.8 que envió 9.000 dólares a una “membership” falsa —ese modelo cae en proveedores fraudulentos 30 veces más que su versión anterior (análisis de Zvi Mowshowitz)—. Autonomía sin check es una factura esperando a ocurrir.

La acción concreta: para cada tarea que ya delegas a un agente, comprueba si tienes un verificador que la valide en segundos. Donde no lo tengas, no subas el bucle —bájalo hasta que un humano vea el resultado.

El bucle del que no formas parte

Los agentes de código crecieron un 1.400% en 2026 y los commits que abren, 14 veces, según el COO de GitHub (Latent Space); dentro de Anthropic, más del 80% del código que mergea lo escribe ya Claude, según datos de mayo de 2026 (su instituto).

Ese volumen no sale de teclear prompts más rápido. Sale de soltar el bucle: dejarlo ejecutar en segundo plano, en paralelo y aislado —cada agente en un worktree de git: una copia aislada del repositorio donde trabaja sin pisar a los demás— con una condición de salida explícita y un down-loop definido: a qué estado fiable cae si se rompe. Karpathy lo dijo sin rodeos: para sacarle jugo a estas herramientas, tiene que quitarse a sí mismo del bucle. El cambio mental es dejar de perseguir “un agente más listo” y empezar a medir cuánto puedes no mirar.

La métrica que importa es la fracción de ejecuciones que terminan sin que entres a teclear. Ese número —no el benchmark del modelo— es tu nivel de loop actual.

La acción concreta: mide qué porcentaje de tus ejecuciones de agente completan sin intervención, conviértelo en una métrica que vigilas, y súbela soltando una tarea cada vez.

Cerrar el bucle es darle ojos y manos, no más inteligencia

Steinberger enumera cuatro accesos que le da al modelo para observar y actuar —la base de datos, los logs, el servidor de desarrollo y los logs de ese servidor vía tmux, el multiplexor de terminal que mantiene la sesión viva en segundo plano— y con ellos el debugging se vuelve casi automático: “me fui a cortarme el pelo y la regresión estaba arreglada”.

Un bucle de agente vive de su feedback —lo que el entorno le devuelve tras cada acción—. Sin feedback no hay bucle, hay un monólogo: el modelo actúa a ciegas y nunca se entera de si acertó. Y el cuello de botella casi nunca es la inteligencia del modelo: es una tool que falta para que pueda ver el resultado o actuar sobre él. Un agente que no puede leer los logs no es tonto, es manco.

Esto invierte el reflejo habitual. Cuando un agente se atasca, la reacción es cambiar a un modelo más caro; casi siempre el arreglo real es darle el ojo o la mano que le faltaba para cerrar el bucle por su cuenta.

La acción concreta: lista qué no puede ver ni tocar tu agente en la tarea que falla —el log, la base de datos, la salida del test— y dale esa tool antes de saltar a un modelo más caro.

Cuándo no montar un bucle

Anthropic, en su guía de agentes, lo dice en una línea: usa el sistema más simple que funcione y añade un agente solo cuando lo justifique (Building Effective Agents).

Un bucle se gana su sitio solo cuando hay incertidumbre en el camino. Si los pasos son fijos y los conoces de antemano, es un workflow —código normal que orquestas tú—: más barato, más fiable, trivial de depurar. Si una sola pasada del modelo resuelve, es un prompt. Meter un agente con loop donde bastaba un workflow te da lo peor de ambos mundos: el coste y la imprevisibilidad del agente sin necesitarlos. Los sistemas buenos suelen ser híbridos: un esqueleto fijo con una costura agéntica en el único punto donde el camino es de verdad incierto.

La acción concreta: baja a un workflow determinista cualquier bucle que ya tengas con el camino fijo, y recupera el coste y la fiabilidad que estabas perdiendo.

El bucle se queda; el código no

El código que escribas lo reescribirá un modelo mejor en seis meses. El bucle que diseñes alrededor —cuándo sube, cuándo baja, qué ve, cuándo te avisa— es lo que se queda. Promptear es un trabajo que se agota tecla a tecla; diseñar el bucle del que no formas parte es lo que te deja operar diez agentes en vez de uno.

¿Qué fracción de tus ejecuciones de agente terminan sin que tengas que entrar a teclear, y cuál es la tool que falta para subirla?