Ya no le doy instrucciones a Claude. Tengo bucles ejecutándose que le dan instrucciones a Claude y deciden qué hacer. Mi trabajo es escribir bucles.
— Boris Cherny, creador y director de Claude Code en Anthropic.
Durante aproximadamente dos años, la habilidad que todos perseguían era la ingeniería de prompts. Escribir un buen prompt, compartir suficiente contexto, leer el resultado, escribir el siguiente prompt. Sostenías el agente como una herramienta, un turno a la vez.
Esa era está llegando a su fin silenciosamente.
A mediados de 2026, tres voces convergieron en la misma idea con días de diferencia. Boris Cherny (Claude Code) dijo que su trabajo ahora es escribir bucles. Peter Steinberger (creador de OpenClaw) les dijo a millones de desarrolladores: "Ya no deberías estar dándole instrucciones a agentes de código. Deberías estar diseñando bucles que le den instrucciones a tus agentes." Y Addy Osmani (Google) le dio nombre al patrón en una publicación ampliamente compartida: Ingeniería de Bucles. Este artículo desglosa qué es realmente la ingeniería de bucles, los problemas que resuelve, cómo los resuelve, una demostración de código funcional que puedes ejecutar hoy, y las desventajas honestas que nadie menciona en los hilos de hype.
¿Qué es la Ingeniería de Bucles?
La ingeniería de bucles consiste en reemplazarte a ti mismo como la persona que le da instrucciones al agente. Diseñas un sistema que hace las instrucciones en tu lugar.
Un bucle es un objetivo recursivo: defines un propósito y una condición de parada verificable, y la IA itera, descubre trabajo, lo implementa, lo verifica, registra el progreso hasta que la condición se cumple. Ya no estás dentro del bucle. Estás por encima de él.
Piensa en la jerarquía de esta manera:
- Ingeniería de prompts: escribes una buena instrucción.
- Ingeniería de contexto: ensamblas la información correcta alrededor de la instrucción.
- Ingeniería del entorno del agente: construyes el entorno en el que se ejecuta un agente.
- Ingeniería de bucles: construyes el sistema que ejecuta el entorno en un temporizador, genera ayudantes, verifica su trabajo.
El flujo de trabajo anterior: escribir prompt → leer resultado → escribir siguiente prompt (tú eres el bucle).
El nuevo flujo de trabajo: diseñar bucle una vez → el bucle descubre trabajo → el bucle asigna agentes → el bucle verifica → el bucle registra el estado → repetir (tú revisas y diriges).
Los Problemas que Resuelve la Ingeniería de Bucles
Problema 1: Tú eres el cuello de botella
En la instrucción manual, no pasa nada a menos que escribas. Cada turno espera a un humano. Los agentes en 2026 pueden ejecutarse durante horas de forma autónoma; los modelos de clase Claude Opus se han ejecutado sin supervisión durante casi cinco horas en tareas difíciles, pero un chat impulsado por humanos los limita a tu velocidad de escritura y capacidad de atención. El agente está inactivo el 95% del tiempo, esperándote a ti.
Problema 2: Los agentes lo olvidan todo entre sesiones
Cada sesión comienza desde cero. El modelo vuelve a derivar las convenciones de tu proyecto, los pasos de compilación y las lecciones aprendidas con esfuerzo desde cero, o peor aún, llena los vacíos con suposiciones seguras. Eso es lo que Osmani llama deuda de intención: la intención no declarada que se paga (o se adivina) de nuevo en cada ejecución.
Problema 3: El agente califica su propio trabajo
Un agente que escribió el código es demasiado generoso al revisarlo. "Está listo" es una afirmación, no una prueba. Sin una verificación independiente, las ejecuciones autónomas acumulan errores en lugar de corregirlos.
Problema 4: Los agentes en paralelo chocan
En el momento en que ejecutas más de un agente en un repositorio, comienzan a sobrescribir los archivos del otro: el mismo desastre que dos ingenieros haciendo commit en las mismas líneas sin hablarse.
Problema 5: El trabajo recurrente nunca se automatiza
El triaje de fallos de CI, las actualizaciones de dependencias, la caza de tests inestables, el etiquetado de issues, las revisiones diarias de errores... este trabajo es aburrido, interminable y perfectamente adecuado para agentes. Pero nadie le da instrucciones a un agente para que lo haga cada mañana, porque tú tendrías que aparecer cada mañana para dar las instrucciones.
Cómo los Resuelve la Ingeniería de Bucles: Los Seis Componentes Clave
Un bucle que realmente se ejecuta sin supervisión no es un prompt largo. Es un sistema pequeño con cinco capacidades más una memoria. Sorprendentemente, tanto Claude Code como el Codex de OpenAI ahora incluyen las seis de forma nativa: la forma del bucle se ha vuelto independiente de la herramienta.
- Automatizaciones: el latido del corazón
Ejecuciones programadas que realizan descubrimiento y triaje por sí solas. Esto resuelve el Problema 5.
- Claude Code: /loop vuelve a ejecutar un prompt en un ritmo (desde intervalos de un minuto hasta ventanas de varios días), tareas programadas con cron, Rutinas para automatizaciones programadas en la nube, hooks de ciclo de vida o GitHub Actions para ejecuciones que sobreviven al cierre de tu portátil.
- Codex: la pestaña Automatizaciones: elige un proyecto, un prompt, un ritmo; los hallazgos llegan a una bandeja de entrada de Triaje; las ejecuciones vacías se archivan solas.
La primitiva asesina dentro de la sesión es /goal: sigue trabajando a través de los turnos hasta que una condición que escribiste sea verificablemente cierta ("todos los tests en test/auth pasan y el lint está limpio") y aléjate.
- Worktrees: aislamiento para el paralelismo
Los worktrees de Git le dan a cada agente su propio directorio de trabajo en su propia rama, compartiendo el historial del repositorio. Las ediciones literalmente no pueden chocar. Esto resuelve el Problema 4.
- Claude Code: git worktree, el flag --worktree, o isolation: worktree en un subagente para que cada ayudante obtenga un checkout fresco y autolimpiable.
- Codex: worktree integrado por hilo.
Los usuarios avanzados reportan ejecutar de 10 a 15 agentes en paralelo de esta manera.
- Skills: conocimiento del proyecto codificado
Un skill es una carpeta con un SKILL.md: tus convenciones, pasos de compilación y "no lo hacemos así por ese incidente" escritos una vez, leídos por el agente en cada ejecución. Esto resuelve el Problema 2. Sin skills, el bucle vuelve a derivar tu proyecto desde cero en cada ciclo. Con ellos, se acumula.
- Plugins y Conectores (MCP): manos en herramientas reales
Un bucle que solo ve el sistema de archivos es un bucle pequeño. Los conectores MCP le permiten leer tu rastreador de issues, consultar una base de datos, abrir el PR, actualizar el ticket de Linear y enviar un mensaje a Slack cuando la CI se ponga verde. Esta es la diferencia entre un agente que dice "aquí está la solución" y un bucle que entrega la solución.
- Subagentes: separa al creador del verificador
La idea estructural más importante de todo el patrón. Un agente (o modelo) escribe; un agente diferente con instrucciones diferentes verifica. Esto resuelve el Problema 3. /goal de Claude Code incorpora esto: un modelo separado califica si se cumple la condición de parada, por lo que el trabajador nunca califica su propio trabajo.
- Claude Code: subagentes en .claude/agents/, equipos de agentes.
- Codex: subagentes como TOML en .codex/agents/; por ejemplo, un modelo fuerte con alto esfuerzo de razonamiento como tu revisor de seguridad, un modelo rápido de solo lectura como tu explorador.
- Estado: la columna vertebral de la memoria
Un archivo markdown, un registro de progreso o un tablero de Linear: cualquier cosa que viva fuera de la conversación y registre lo que está hecho y lo que sigue. Suena demasiado simple como para importar. Es el único truque del que depende todo agente de larga duración: el modelo olvida entre ejecuciones; el repositorio no. Esto también resuelve el Problema 2 a nivel de tarea, y es lo que permite que la ejecución de mañana retome exactamente donde se detuvo la de hoy. Junto con las automatizaciones, disuelve el Problema 1: el bucle funciona mientras duermes.
Cómo se Ve un Bucle Real
Aquí está la forma de referencia (adaptada del bucle diario del propio Osmani):
- Una automatización se activa en el repositorio. Su prompt llama a un skill de triaje que lee los fallos de CI de ayer, los issues abiertos y los commits recientes, y escribe los hallazgos en STATE.md.
- Por cada hallazgo que vale la pena, el bucle abre un worktree aislado y envía un subagente creador para redactar la solución.
- Un subagente verificador revisa el borrador contra los skills del proyecto y los tests existentes.
- Los conectores abren el PR, vinculan el ticket y publican en Slack.
- Cualquier cosa que el bucle no pueda manejar termina en una bandeja de entrada de triaje, para ti.
- STATE.md registra lo que se intentó, lo que pasó y lo que aún está abierto. La ejecución de mañana se reanuda desde ahí.
Fuentes y lecturas adicionales: Addy Osmani, "Loop Engineering" (addyosmani.com); la cobertura de The New Stack sobre ingeniería de bucles; la charla informal de Boris Cherny en la conferencia Scale de Meta y la entrevista de CNBC; documentación de Claude Code sobre Rutinas (code.claude.com/docs/en/routines); documentación de Automatizaciones de OpenAI Codex.
Si construyes un bucle a partir de este artículo, ¡me encantaría verlo! Responde con lo que automatizaste primero.
