Ingeniero de Google te enseña qué es la Ingeniería de Bucle. Cinco bloques + memoria externa, la materia obligatoria de IA para 2026

Loop Engineering es un sistema que ejecuta automáticamente un proxy de prompt, está compuesto por cinco bloques: Automatizaciones, Worktrees, Skills, Plugins/Connectors, Sub-agents, además de una memoria externa. Este texto proviene del ingeniero de software de Google Addy Osmani.
(Resumen previo: ¿Anthropic en Claude Fable 5 ha añadido detección de distilación, puede bloquear modelos open source chinos?)
(Información adicional: Anthropic: líder en modelos de IA en EE.UU. frente a China para proteger la democracia, propone que los ataques de distilación sean delitos penales)

Índice de este artículo

Alternar

• Los cinco bloques, con algunas notas
• Automatizaciones: el latido del corazón del ciclo
• Worktrees: no dejes que lo paralelo se vuelva caos
• Skills: finalmente ya no tienes que repetir tu proyecto cada vez
• Plugins y connectors: el ciclo extiende la mano a tus herramientas reales
• Sub-agents: separar a quien hace y a quien revisa
• Cómo es un ciclo
• Lo que un ciclo aún no hace por ti
• Montar un ciclo, pero seguir siendo ingeniero

Loop engineering es reemplazar ese “proxy de prompt hecho a mano” por un sistema diseñado por ti para hacer esa tarea. Lo que llamamos “ciclo” aquí puede entenderse como un objetivo recursivo: tú defines el propósito, la IA itera repetidamente hasta completarlo. Creo que esta será quizás nuestra forma futura de colaborar con agentes de codificación.

Pero, antes que nada, esto todavía está en una etapa muy temprana, tengo dudas propias, y debes tener mucho cuidado con el costo de tokens. Quiero desglosar esto: qué es, y qué implica.

Peter Steinberger dijo recientemente: “Ya no deberías hacer prompt a tu agente de codificación. Deberías diseñar un ciclo que haga prompt a tu agente.” Boris Cherny, responsable de Claude Code en Anthropic, también dijo algo similar: “Ya no hago prompt a Claude. Dejo que el ciclo corra y decida qué hacer, haciendo prompt a Claude por sí mismo.”

Hace casi dos años, obtener resultados de un agente de codificación dependía de escribir un buen prompt y proporcionar suficiente contexto. Escribir una parte, leer la respuesta, escribir la siguiente. El agente es una herramienta, y tú lo controlas de principio a fin, en una serie de rondas. Esa etapa casi terminó, al menos así lo creen algunos.

Ahora, lo que haces es montar un pequeño sistema: busca trabajo, asigna tareas, revisa lo que se ha hecho, decide qué sigue, y lo hace llamando al agente en lugar de hacerlo tú mismo. Antes, escribí sobre su par cercano, “agent harness engineering”, que era crear un entorno para ejecutar un solo agente, un “modelo de fábrica de software”.

Loop engineering es un nivel superior al harness: el harness sigue allí, pero ahora corre automáticamente, genera asistentes, se alimenta a sí mismo.

Para mi sorpresa, esto ya no es solo una cuestión de herramientas. Hace un año, para crear un ciclo, tenías que apilar muchos scripts bash, mantenerlo tú solo, era algo personal. Ahora, estos componentes están integrados directamente en el producto. La lista de Steinberger casi coincide con la app Codex, y también casi con Claude Code. Cuando ves que la forma en realidad es la misma, dejas de pelearte por “qué herramienta usar” y simplemente diseñas un ciclo que funcione en cualquier herramienta.

Los cinco bloques, con algunas notas

Un ciclo necesita cinco cosas, más una memoria. Primero las enumero y luego las relaciono.

2. Automations: disparos programados para discovery y triage automáticos.
3. Worktrees: evitar que los agentes paralelos se pisoteen.
4. Skills: codificar el conocimiento del proyecto que antes solo se podía adivinar.
5. Plugins y connectors: conectar el agente a tus herramientas existentes.
6. Sub-agents: un que genera ideas, otro que revisa.

Luego, la sexta cosa: la memoria. Un archivo markdown, o un tablero Linear, cualquier cosa que exista fuera de una sola conversación y sirva para registrar “qué se hizo, qué sigue”. Suena tonto, pero es la trampa en la que confían todos los agentes de larga duración: los modelos olvidan todo entre ejecuciones, por eso la memoria debe estar en disco, no en el contexto. Los agentes olvidan, los repos no.

Ahora, estos cinco componentes están en dos productos.

| Término original | | --- | El rol en el ciclo |
Codex app |
Claude Code |
| --- | --- | --- | --- |
| Automations |
Disparadores y distribución automática |
Pestaña de Automatizaciones: seleccionar proyecto, prompt, frecuencia, entorno; resultados en Triage; /goal para correr hasta terminar |
Tareas programadas, cron, /loop, /goal, hooks, GitHub Actions |
| Worktrees |
Aislar desarrollo paralelo |
Cada hilo tiene su worktree |
git worktree, --worktree, aislamiento en subagent: worktree |
| Skills |
Codificar conocimiento del proyecto |
Agent Skills (SKILL.md), llamado por $nombre o implícitamente |
Agent Skills (SKILL.md) |
| Plugins / connectors |
Conectar con tus herramientas |
Connectors (MCP) + plugins de distribución |
Servidores MCP con plugins |
| Sub-agents |
Generar ideas y verificar |
Definidos en .codex/agents/ con TOML |
En .claude/agents/ con Task subagents y equipos |
| State |
Seguir estado de tareas |
Markdown o conectando Linear |
Markdown (AGENTS.md, archivos de progreso) o conectando Linear |

Los nombres varían, pero la capacidad esencial es la misma. Los iré desarrollando uno por uno, porque, sinceramente, el diablo está en los detalles: si el ciclo se mantiene estable o se filtra, todo depende de estos detalles.

Automatizaciones: el latido del ciclo

Automations es lo que realmente hace que un “ciclo” sea un ciclo, y no solo “algo que hiciste una vez”. En Codex app, creas uno en la pestaña de Automatizaciones, eliges proyecto, prompt, frecuencia, entorno (local o background). Los descubrimientos se envían a Triage, los no descubiertos se archivan automáticamente, y eso es muy cómodo.

En OpenAI, lo usan para tareas rutinarias pero necesarias: distribuir issues diarios, resúmenes de fallos en CI, briefing de commits, rastrear bugs introducidos la semana pasada. Automation puede llamar skills, así tus tareas periódicas se mantienen: solo disparas $nombre_skill, en lugar de pegar un montón de instrucciones en un cron que nadie actualiza.

Claude Code llega a lo mismo, pero con rutas distintas: mediante cron y hooks. Puedes usar /loop para que prompts o comandos se repitan en intervalos, programar cron, usar hooks en puntos específicos del ciclo de vida del agente, o subir todo a GitHub Actions para que siga corriendo tras cerrar la laptop. La idea es la misma: defines una tarea automática, le das ritmo, y la automatización te la presenta sin que tengas que revisar manualmente.

Hay otra orden en la misma sesión que vale la pena entender, y esta se acerca más a lo que trata todo el artículo. /loop repite en intervalos. /goal corre hasta que se cumple la condición que escribiste, y cada ciclo lo evalúa un modelo menor para decidir si terminó, así que “escribir código” no es “hacer una evaluación”.

Por ejemplo, si le dices “que pasen todas las pruebas en auth/test y que esté limpio de lint”, se detiene. Codex también tiene /goal, que corre varias rondas hasta que se cumple una condición verificable, y puede pausar, reanudar, limpiar. La misma orden, dos herramientas, mismo patrón.

Eso es “hacer visible el trabajo”. Lo que falta en un ciclo es “hacer algo con esas tareas”.

Worktrees: no dejes que lo paralelo se vuelva caos

Si ejecutas más de un agente a la vez, los archivos empiezan a chocar, y eso causa fallos. Dos agentes editando el mismo archivo, como dos ingenieros haciendo commit en la misma línea sin coordinarse, duele. git worktree resuelve esto: crea un directorio de trabajo separado, con su propia rama, compartiendo el mismo historial del repo, así un agente no pisa lo que otro está editando físicamente.

Codex soporta worktree de forma nativa, así varios hilos pueden trabajar en el mismo repo sin colisiones. Claude Code usa git worktree, la bandera --worktree (para que una sesión tenga su propio checkout), y la configuración de aislamiento en subagent: cada asistente obtiene un checkout limpio, y se limpia al terminar. En el artículo “the orchestration tax” hablé desde la perspectiva humana: worktree elimina colisiones mecánicas, pero tú eres el límite, tu capacidad de revisión determina cuántos puedes correr realmente, no la herramienta.

Skills: finalmente ya no tienes que repetir tu proyecto cada vez

Skills es lo que te permite no tener que volver a explicar tu contexto en cada sesión. Ambos usan el mismo formato: una carpeta con SKILL.md, que contiene instrucciones y metadatos, además de scripts, referencias, assets. En Codex, se ejecuta un skill cuando llamas con $ o /skills, o automáticamente si la tarea coincide con la descripción del skill — por eso una descripción precisa y simple vence a una bonita y compleja. En Claude Code, funciona igual, ya expliqué este patrón en el artículo “agent skills”.

Skills también es “donde se guarda la intención sin tener que pagarla de nuevo”. En el artículo “the intent debt” propuse que los agentes, en cada sesión, hacen una conjetura confiada para llenar los huecos de la intención. Skills es poner esa intención afuera — en convenciones, pasos de construcción, “no hacemos eso porque en el evento anterior…” — y que el agente la lea en cada ejecución. Sin skills, cada ciclo empieza desde cero, con toda la reingeniería. Con skills, la acumulación es exponencial.

Una cosa importante: skill es formato de escritura, plugin es la forma de distribuir. Cuando compartes un skill entre repos, o agrupas varios skills en un plugin, los empaquetas. Codex funciona así, Claude Code también.

Plugins y connectors: el ciclo extiende la mano a tus herramientas reales

Un ciclo que solo ve el sistema de archivos es muy limitado. Connectors, construidos sobre MCP, permiten que el agente lea issues, consulte bases de datos, llame APIs staging, envíe mensajes a Slack. Tanto Codex como Claude Code usan MCP, así que los connectors que hagas para uno, generalmente sirven para el otro. Los plugins agrupan connectors y skills, para que tus colegas puedan instalar toda la configuración de una vez, sin tener que reconstruirla de memoria.

Eso es la diferencia entre “el agente te dice ‘esto es la ley’” y “el ciclo hace PR, conecta tickets en Linear, y envía notificaciones cuando el CI pasa”. Los connectors hacen posible que el ciclo actúe en tu entorno real, no solo te diga qué podría hacer.

Sub-agents: separar a quien hace y a quien revisa

La estructura más útil en un ciclo es separar “quien escribe” y “quien revisa”. El modelo que escribe código se autoevalúa demasiado generosamente. Un segundo agente, con instrucciones distintas o incluso diferente modelo, puede detectar las autojustificaciones del primero.

Codex solo crea subagents cuando tú lo pides, corren en paralelo, y devuelven un resultado consolidado. En .codex/agents/ defines tus agentes en TOML, cada uno con nombre, descripción, instrucciones, y opcionalmente modelo y esfuerzo de razonamiento — tu auditor de seguridad puede usar un modelo potente con alto presupuesto, y tu explorador uno rápido y solo lectura. Claude Code usa .claude/agents/ con subagents y equipos, haciendo lo mismo: transmitiendo tareas entre agentes. Las formas comunes son: uno para explorar, otro para implementar, otro para verificar contra la especificación.

Ya propuse esto dos veces: una llamada “orquesta de agentes de código”, otra “revisión adversarial de código”. En un ciclo, esto es especialmente importante, porque corre sin que lo mires — un verificador confiable es la única forma de estar tranquilo. Los subagents consumen tokens, porque cada uno corre modelos y herramientas, así que conviene usarlos donde realmente valga la pena: para obtener una segunda opinión. La orden /goal en Claude Code funciona así: un modelo nuevo decide si el ciclo termina, en lugar del modelo que escribió el código — “el que hace vs el que revisa” en la condición de parada.

Cómo es un ciclo

Uniendo todo, un solo hilo se vuelve un panel de control pequeño. La forma que uso habitualmente es así:

Un automation corre cada mañana en el repo. Usa un prompt que llama a un skill de triage, lee fallos en CI, issues abiertos, commits recientes, y escribe todo en un markdown o en un tablero Linear. Para cada hallazgo importante, ese hilo crea un worktree aislado, asigna un subagent para redactar la solución, y otro para revisar esa propuesta usando skills del proyecto y pruebas existentes.

Los connectors permiten abrir PR, actualizar tickets. Todo lo que no pueda hacer el ciclo, queda en la bandeja de triage. El archivo de estado es la columna vertebral, registra qué se probó, qué pasó, qué sigue abierto — así, la próxima mañana retomas desde donde quedó.

Al mirar hacia atrás, solo diseñaste una vez. Ninguna tarea fue solo tu prompt. Esa es la realización concreta de la frase de Steinberger. Y el mismo ciclo puede correr en Codex y Claude Code, porque los componentes son los mismos.

Lo que un ciclo aún no hace por ti

El ciclo cambia la forma del trabajo, pero no te elimina. Además, hay tres problemas que, a medida que el ciclo mejora, se vuelven más agudos en lugar de menos:

La validación sigue siendo tu responsabilidad. Un ciclo sin un verificador que lo supervise, es un ciclo en el que nadie revisa los errores. Separar el verificador del creador, hace que la “finalización” tenga sentido; pero “finalizar” es una afirmación, no una prueba. Como en “review in the age of AI”, tu trabajo sigue siendo entregar código que tú mismo confirmes que funciona.

Tu comprensión puede deteriorarse, si lo permites. Cuanto más rápido entregues “cosas que no son tuyas”, mayor será la brecha entre “lo que existe” y “lo que realmente tienes”. Eso es “debt of comprehension” (deuda de comprensión). Un ciclo fluido solo la acelera, a menos que leas lo que hace.

Sentirse cómodo es peligroso. Cuando el ciclo corre solo, te dan ganas de dejar de tener opiniones, aceptar lo que devuelve. Eso lo llamo “cognitive surrender” (rendición cognitiva). Diseñar un ciclo con juicio propio es la cura, pero dejar que corra solo, es un acelerador — la misma acción, resultados opuestos.

Montar un ciclo, pero seguir siendo ingeniero

Creo que esto será una predicción de hacia dónde vamos. Pero, si no reviso el código personalmente, o dependo solo del ciclo automático, la calidad del producto caerá. Probablemente caeré en una espiral descendente, cada vez más profundo.

Es decir, montar tu ciclo — pero no olvidar que también puedes simplemente hacer prompt a tu agente, y eso sigue siendo válido. Todo se trata de encontrar el equilibrio.

El ciclo también varía mucho según quién lo use. Dos personas con el mismo ciclo pueden obtener resultados completamente opuestos. Una lo usa para acelerar trabajos que entiende profundamente, otra para evitar entenderlos. La diferencia en cómo se usa, es la clave para entenderlo.

Por eso, diseñar un ciclo es más difícil que hacer prompt engineering. Cherny no dice que el trabajo sea más simple, sino que el punto de apalancamiento se ha movido.

Construye tu ciclo, pero como alguien que “quiere seguir siendo ingeniero”, no solo como alguien que “solo quiere apretar el botón de inicio”.