Loop Engineering: The Guide for AI Agents

Puntos clave

1. Definición en una frase. el loop engineering construye sistemas que instruyen a los agentes de forma programada y orientada a un objetivo, en lugar de escribir prompts individuales. El apalancamiento se desplaza de la calidad de un prompt al diseño del sistema.
2. Dos niveles de bucle. el bucle interno (percibir-razonar-actuar-observar en cada turno, ya nativo en los agentes) frente al bucle externo que se diseña (planificación, ayudantes, trabajo que se autoalimenta, persistencia a lo largo de muchos turnos).
3. Filiación en tres capas. (cada una engloba a la anterior): Prompt Engineering (1 instrucción) → Context Engineering (contenido de la ventana) → Loop Engineering (sistema que decide qué instruir, cuándo, y si el resultado es aceptable). El prompt y el contexto siguen siendo esenciales — un mal prompt simplemente produce mal trabajo más rápido.
4. Origen del término. popularizado por Addy Osmani (Google) en junio de 2026, apoyándose en observaciones de Peter Steinberger ("you should be designing loops that prompt your agents") y Boris Cherny (responsable de Claude Code en Anthropic: su foco se desplazó a escribir bucles en lugar de instruir directamente).
5. Técnica Ralph. (Geoffrey Huntley, principios de 2026, llamada así por Ralph Wiggum): ejecutar el agente en un bucle while simple, el mismo prompt en cada iteración, contra una especificación escrita, con contexto nuevo en cada turno. La innovación no evidente es el reinicio del contexto (evita la degradación de las sesiones largas). La inteligencia proviene de especificaciones claras + resultados verificables + memoria externa (PLAN.md, STATUS.md), no de ejecuciones heroicas.
6. El loop engineering convierte a Ralph en producto. el while se convierte en una automatización programada, los reinicios se convierten en worktrees/sub-agentes, la comprobación "ALL TASKS DONE" se convierte en una condición /goal verificada por un modelo independiente.
7. 5 bloques constitutivos + memoria. (1) Automatizaciones (disparadores programados de descubrimiento/triage); (2) Worktrees (agentes paralelos sin colisiones); (3) Skills (conocimiento documentado del proyecto); (4) Plugins/conectores (MCP, acceso a herramientas reales); (5) Sub-agentes (separación entre generación y verificación); (6) Memoria (markdown, tableros Linear/GitHub — fuera de la ventana de contexto). "Agents forget. Repositories remember."
8. Claude Code y Codex integran los 5 bloques constitutivos + memoria. bajo nombres distintos pero estructuras idénticas → diseñar bucles que sobrevivan a un cambio de herramienta.
9. Automatizaciones. Codex (pestaña Automations, ejecuciones que van a una bandeja de Triage, las ejecuciones vacías se autoarchivan); Claude Code (/loop + hooks + integración con GitHub Actions). Primitiva clave en sesión = /goal: mantiene el trabajo hasta que la condición especificada es verificablemente cierta, un modelo aparte, más pequeño, evalúa la finalización en cada turno (el agente no se autoevalúa).
10. Estado a mediados de 2026. /goal se lanzó en Claude Code v2.1.139 (11 de mayo de 2026), la rama 2.1.x con Opus 4.8 como modelo por defecto además de flujos de trabajo dinámicos que orquestan grandes flotas de sub-agentes; Codex añadió /goal en CLI 0.128.0. Los profesionales reportan agentes trabajando sin supervisión durante decenas de horas → las condiciones de parada se convierten en el elemento más crítico.
11. Redactar las condiciones de parada como contratos. estado final + prueba + restricciones + límite de turnos/presupuesto. Ej.: "cobertura de src/billing ≥ 90 %; npm test sale con código 0; ninguna API pública modificada; parar tras 25 turnos o 5 $."
12. Tres prácticas para bucles fiables. (equipos de Claude Code): preservar los errores (para que el bucle aprenda en lugar de repetirlos), incorporar la verificación desde el inicio, tratar los tests en rojo / la CI en rojo como señales de honestidad. Un bucle sin prueba de fallo siempre cree haber tenido éxito.
13. Worktrees. = aislamiento real de git (directorios separados en ramas distintas, historial compartido). Pero "You remain the ceiling": la capacidad de revisión humana, no el número de worktrees, determina cuántos agentes se ejecutan realmente en paralelo.
14. Sub-agentes maker-checker. = el cambio estructural más potente: un agente verificador adversarial (modelo potente, razonamiento elevado, instruido para rechazar todo lo no probado) que filtra el trabajo antes de la revisión humana. Los modelos que califican su propio trabajo son demasiado indulgentes.
15. Escala de madurez (niveles 0→4). 0 Manual → 1 Triage (hallazgos en markdown, sin código) → 2 Draft (correcciones en ramas aisladas) → 3 Verified PR (sub-agente verificador como filtro) → 4 Auto-merge (categorías de bajo riesgo con CI en verde). Subir de nivel solo si el nivel actual produce un trabajo que uno mismo habría hecho.
16. 3 riesgos que se agravan (no disminuyen). la verificación sigue siendo responsabilidad propia ("terminado" es una afirmación, no una prueba); la deuda de comprensión se acelera (el código se despliega más rápido de lo que se comprende); la renuncia cognitiva (aceptar resultados sin juicio) — dos personas que construyen el mismo bucle obtienen resultados opuestos según si lo usan para avanzar en un trabajo que comprenden o para evitar comprenderlo.
17. Vigilar los tokens. los bucles programados + los modelos verificadores tras cada turno consumen tokens rápidamente. Empezar con cadencias lentas y condiciones estrictas, monitorizar los costes durante varios días, escalar solo tras probar un trabajo fusionado útil.
18. Seguridad. los bucles autónomos con conectores tocan producción → se requieren barreras de seguridad, permisos y registro de auditoría.