Dos referentes técnicos coinciden públicamente en la misma idea: Boris Cherny, creador de Claude Code en Anthropic, y Peter Steinberger, founder de OpenClaw. Los dos apuntan a los loops como la próxima tendencia grande en agentes. La conversación se ha amplificado con un ensayo de Anatoli Kopadze que lleva 7 millones de views en X. La señal está alineada y vale la pena entender qué cambia.
Qué es un loop
Cambias el rol. En lugar de chatear con la IA como con un compañero, te conviertes en su manager. Le pasas un objetivo, instrucciones claras y un criterio de éxito. La IA ejecuta el plan, itera, verifica su propio trabajo y repite el ciclo. Una vez montado el loop, corre solo, sin ida y vuelta constante con el humano.
La diferencia con un agente clásico es sutil pero importante. Un agente tradicional ejecuta una secuencia de pasos. Un loop ejecuta esa secuencia, mira el resultado, decide si cumple, y si no, vuelve a empezar con la información nueva que ha aprendido. La iteración con memoria es lo que cambia el juego.
La pieza crítica: la verificación
Esto es lo que separa un loop útil de un quemador de tokens. Si no defines qué significa 'éxito' para tu agente, el loop puede generar output basura indefinidamente y consumir tu plan en horas. La verificación es el guardrail.
Verificadores típicos por dominio:
- Código: tests unitarios que pasan, linter limpio, build verde.
- Contenido: un evaluador LLM con rúbrica explícita (tono, longitud, ausencia de paralelismos negativos, etc.).
- Análisis de datos: validación contra un dataset de control con resultados conocidos.
- Investigación: cada claim respaldado por una cita que existe y dice lo que el agente afirma.
Si no puedes definir el verificador, no estás listo para un loop. Estás listo para una sesión interactiva.
Cuándo no sirve
Tres limitaciones honestas:
- Requiere saber programar lo suficiente para montar el bucle y el verificador. No es para no técnicos todavía.
- Puede ser caro en tokens. Un loop mal calibrado consume 5-10x lo que costaría la query manual equivalente. Si tu factura de API ya es alta, monitoriza el coste por ejecución desde el día uno.
- Muchas tareas son one-shot. Escribir un email puntual no necesita loop. El setup mata el ROI si no vas a repetir el patrón 20+ veces.
Ejemplos aterrizados
Loop útil: 'revisa este repositorio cada noche, encuentra funciones sin tests, escribe los tests, ejecuta la suite, si pasan haz commit, si fallan reescribe hasta 3 veces y abre PR si no consigues que pase'. El criterio de éxito es objetivo (pass/fail de la suite), el coste por iteración es predecible y el resultado es accionable (commits y PRs reales).
Loop inútil: 'mejora esta landing'. No hay criterio de éxito medible. El agente puede iterar 50 veces sin acercarse a nada concreto. Convertirlo en útil pasa por meter el criterio: 'mejora esta landing hasta que el conversion rate del A/B test pase del 3% al 4%'. Eso ya es un loop con verificador, aunque cada iteración tarde una semana.
Por qué pasa ahora
El patrón ya está implementado de facto en Claude Code (con auto-fix de errores y agent mode), en Cursor (con composer agent) y en Cline. Lo que está cambiando es que la idea se está articulando como categoría conceptual, no como feature aislada. Cuando los referentes técnicos coinciden en nombrar algo, el ecosistema construye herramientas alrededor de ese nombre. Espera ver en los próximos 3-6 meses frameworks específicos para 'loop building' separados de los SDK de agentes genéricos.
Qué hacer
- Si trabajas con Claude Code o un setup tipo agent SDK: identifica las 3 tareas que repites más esta semana y diseña el verificador para una de ellas. Si puedes escribir el verificador en una frase, conviértela en loop el próximo lunes.
- Si lideras un equipo técnico: pide a tus seniors que documenten qué workflows internos serían candidatos a loop y cuál sería el verificador. Es un ejercicio barato que clarifica dónde está el ROI real de los agentes vs el de la asistencia interactiva.
- Si no programas pero gestionas equipo: empieza a usar el lenguaje. 'Loop con verificador' es el nivel correcto de abstracción para pedir automatizaciones a tu CTO. Mejor que 'quiero un agente que haga X'.