En julio de 2026, el campo de la programación de IA experimentó un cambio significativo. Peter Steinberger anunció en la plataforma X el fin de la era de la ingeniería cíclica, dirigiendo a la industria hacia la ingeniería de grafos. La ingeniería cíclica derivaba del método Ralph de Geoffrey Huntley, que evitaba las limitaciones de la ventana de contexto haciendo que los agentes de IA se ejecutaran continuamente hasta alcanzar un objetivo. Entre abril y mayo de 2026, herramientas como Codex y Claude Code lanzaron funcionalidades de "Goal", logrando la comercialización de la ingeniería cíclica. Actualmente, la industria está explorando ingenierías de grafos más complejas, que implican el diseño coordinado de grafos organizativos y grafos de trabajo.

Autor del artículo, fuente: Cuenta oficial de WeChat InfoQ (ID: infoqchina)

¿Aún estamos discutiendo el ciclo, o ya pasamos a la gráfica?

El 18 de julio de 2026, Peter Steinberger anunció silenciosamente el fin de la era de la ingeniería cíclica en la plataforma X con esta frase. La publicación obtuvo 2,6 millones de visitas en los dos días siguientes a su publicación.

Hace seis semanas, obtuvo 8,4 millones de visitas con "diseñar ciclos que puedan sugerir a los Agentes", haciendo que los desarrolladores de todo el mundo se dieran cuenta de que la era de la ingeniería de prompts está llegando a su fin y que la ingeniería de ciclos es el nuevo rumbo.

Dos publicaciones, con un total de más de 11 millones de visitas, llevaron la discusión más popular en el campo de la programación de IA al siguiente nivel.

El auge del ciclo

En el último mes, "Loop Engineering" se ha convertido rápidamente en un concepto popular en el campo de la programación de IA.

Pero su verdadero origen se remonta a un año atrás. En julio de 2025, el ingeniero de software Geoffrey Huntley propuso un método al que llamó "Ralph": un simple bucle de Bash que hace que Claude ejecute repetidamente una tarea hasta alcanzar el objetivo:

mientras :; do cat PROMPT.md | claude-code ; done

El núcleo del método Ralph consiste en eludir los límites de la ventana de contexto. En ese momento, a mediados de 2025, el tamaño máximo de la ventana de contexto era de 200.000 tokens, lo cual era insuficiente para tareas más complejas, por lo que era necesario dividir la ejecución del agente en unidades más pequeñas y ejecutarlas una por una.

En este contexto, el método de Ralph funciona de la siguiente manera:

• Establezca un objetivo para el proyecto y ejecute o vuelva a ejecutar el agente continuamente hasta alcanzar el objetivo.
• Persistir el trabajo completado en el sistema de archivos en formato “comprimido”, por ejemplo, guardándolo como registro o plan actualizado.
• Use a completely new context to start the Agent, minimizing "context corruption."
• Cuando sea necesario, permita que cada agente agregue o modifique el "plan general".

Huntley utilizó este método para construir un lenguaje de programación desde cero, validando su viabilidad. Pero no fue hasta la aparición de modelos más potentes que se volvió popular rápidamente en la comunidad de desarrolladores.

El auge de Loop también se debe a algunos desarrolladores clave de Anthropic y OpenAI. Al principio, en la conferencia de desarrolladores de Anthropic, Boris Cherny, creador de Claude Code, dijo: “Ya no le doy instrucciones a Claude. Ejecuto algunos bucles que son los que le dan instrucciones a Claude y deciden qué hacer a continuación. Mi trabajo es escribir bucles.”

Luego, Peter Steinberger también publicó una entrada instando a los desarrolladores a dejar de proporcionar directamente indicaciones a los Agentes de programación: “Recordatorio mensual: ya no deberías estar sugiriendo directamente a los Agentes de programación. Deberías diseñar ciclos que puedan sugerir a los Agentes.”

El ex ingeniero de Google, Addy Osmani, luego escribió un artículo titulado “Loop Engineering”, en el que lo resume como: “La ingeniería de bucles consiste en salir del papel de proporcionar directamente prompts a los Agentes y en cambio diseñar un sistema que realice esta tarea por ti.”

La idea está clara, el nombre está definido y la infraestructura ha avanzado rápidamente.

Entre abril y mayo de 2026, Codex, Claude Code y Hermes lanzaron el comando /goal, convirtiendo productos de bucles escritos a mano en un solo comando.

Six months after Ralph began widespread adoption, Codex released the goal feature.

El documento de Codex establece: "Los Objetivos son metas persistentes en Codex que permiten que una secuencia de conversación avance hacia un resultado claro a través de múltiples interacciones. Un Objetivo proporciona a Codex una condición de finalización: qué estado debe cumplirse, cómo verificar el éxito y qué restricciones deben mantenerse siempre."

El documento especifica especialmente: "Las instrucciones generales expresan: haz esto a continuación. El objetivo expresa: continúa trabajando hasta que este resultado sea válido."

En las solicitudes normales, Codex procesa la instrucción actual, informa los resultados y luego espera el siguiente paso. Al usar una Meta, se adjunta un objetivo persistente al hilo. Al finalizar un ciclo de ejecución, puede revisar la evidencia actual y determinar si el objetivo ya se ha cumplido. Si la respuesta es negativa y la Meta sigue activa y no se ha agotado el presupuesto, Codex puede continuar trabajando desde el estado más reciente.

Por ejemplo: "Reducir la latencia p95 en la prueba de referencia del proceso de pago por debajo de 120 milisegundos, asegurando que el conjunto de pruebas de corrección siempre pase."

Este es un “criterio de finalización” lo suficientemente claro como para entregarse directamente al Agente. Luego, el Agente dividirá automáticamente la tarea, creará subagentes y continuará ejecutándose hasta completar el trabajo. El equipo de Codex se inspiró en el ciclo de Ralph para construir la infraestructura: coordinar múltiples agentes, evitar que se interfieran entre sí; gestionar el estado; ejecutar pruebas; iniciar y detener agentes; y posteriormente añadir funciones como la configuración de presupuesto.

Arquitectura de la función Goals

¿Cómo utilizan los desarrolladores el bucle?

¿Qué está realmente haciendo el desarrollador con el bucle? Según los comentarios de la comunidad, el escenario más común sigue siendo procesar tareas periódicas.

Pero la capacidad de ciclar va mucho más allá. Lo que realmente demuestra el valor de la ingeniería cíclica son algunas tareas a largo plazo más complejas que requieren iteración continua.

Por ejemplo, completar una migración masiva de código. El fundador de una startup, Rafel Mendiola, necesitaba convertir una aplicación React en React Native. El enfoque tradicional consistía en crear un Epic grande y luego dividirlo en 50 a 100 tickets, lo que hacía que establecer la infraestructura misma fuera desalentador.

Su alternativa era crear una Skill para que el Agente identificara automáticamente los bloques de código transferibles, realizara la conversión y rastreara el progreso, luego integrar esta Skill en una tarea Cron que se ejecutara cada 30 minutos. En comparación con gestionar un extenso plan de migración, este enfoque es mucho más ligero desde el punto de vista cognitivo.

Próxima parada: Graph

El problema del tweet de Peter en realidad apunta a una ruta de evolución.

Hace un año, la ingeniería de prompts era una habilidad clave. Para 2025 y principios de 2026, el enfoque se trasladó al diseño de ciclos. Ahora, lo que Peter apunta está aún más lejos: diseñar gráficos compuestos por múltiples ciclos, donde cada agente ejecuta su propio ciclo y se conecta a otros mediante dependencias.

La respuesta más destacada en la cadena de comentarios de este tuit proviene de Luis Catacora: “El ciclo tiene mucho margen de error. El gráfico te obliga a reconocer cuántas partes del flujo de trabajo aún no se han modelado realmente.”

Esta frase ilustra la diferencia entre ambos paradigmas. El bucle te permite posponer el diseño de la arquitectura: primero, haz que un agente realice todo el trabajo hasta que ya no pueda manejarlo. El grafo requiere que definas por adelantado toda la estructura: quién se encarga de qué, qué tareas dependen de otras y qué hacer si una rama falla. El bucle es una decisión diferida; el grafo es una decisión anticipada.

Shubham Saboo, product manager senior de IA de Google y autor del repositorio de código Awesome LLM Apps (con más de 124.000 estrellas en GitHub), ofreció otro desglose, distinguiendo dos niveles: “El organigrama persistente define quién es responsable de qué área y mantiene el contexto; el mapa de trabajo define qué se necesita hacer actualmente, y puede dividirse, combinarse, reordenarse o desaparecer directamente según la evidencia.”

¿Qué diablos es Graph?

Loop hace que el comportamiento del Agente sea programable. Graph hace que la organización del Agente sea programable.

El siguiente paso es la organización dinámica de Agentes: durante la ejecución de la tarea, el Graph reescribe automáticamente su propia estructura.

Preston Holmes: Al menos hay dos gráficos importantes. El primero es el que se muestra en tu gráfico, compuesto por agentes de larga duración que, como una defensa por zona, cada uno se encarga de un área. El segundo es el gráfico formado por el trabajo que necesita realizarse. Es dinámico y cambia constantemente.

Shubham Saboo: El "organigrama" persistente determina quién es responsable de cada área y se encarga de mantener el contexto. El "mapa de trabajo" determina qué tareas deben completarse actualmente. A medida que surgen nuevas evidencias, puede dividirse, combinarse, reordenarse o desaparecer por completo.

Esto es clave para un sistema multi-agente de producción: en realidad hay dos gráficos funcionando simultáneamente.

Organigrama (Org Graph): define “quién es responsable de qué”. Está compuesto por Agentes de larga duración, cada uno responsable de un dominio fijo, manteniendo el contexto, las capacidades especializadas y los permisos de herramientas de ese dominio. El organigrama es relativamente estable, similar a la estructura organizacional de una empresa.

Gráfico de trabajo (Work Graph): define “qué hacer ahora y cómo fluyen las tareas”. Se actualiza constantemente con nuevas tareas y evidencias, y puede dividirse, combinarse, reordenarse o cancelarse directamente. El gráfico de trabajo es más como un plan de proyecto generado en tiempo real.

Preston Holmes también considera que ambos gráficos son importantes y funcionan en escalas de tiempo diferentes. El gráfico de organización se diseña y despliega previamente; el gráfico de trabajo se genera dinámicamente para cada tarea y se descarta después de completarla.

Si el ciclo hace que el comportamiento del Agente sea programable, entonces el grafo hace que la organización del Agente sea programable. El siguiente paso son las organizaciones dinámicas de Agentes: durante la ejecución de la tarea, el grafo reescribe automáticamente su propia estructura.

Desde redactar bien el Prompt, hasta diseñar el Loop y construir el Graph, el foco de la capacidad de programación de IA sigue elevándose. Los desarrolladores cada vez necesitan menos preocuparse por cómo interactuar con un solo Agente, y más por cómo diseñar la estructura de colaboración entre Agentes.