Bucles: la primitiva agéntica en la que todo convergió

Todos los caminos llevaron a /goal

En el lapso de unos pocos meses, cada herramienta de codificación agéntica importante convergió de forma independiente en el mismo primitivo exacto: un bucle autónomo que toma un objetivo y se ejecuta hasta que decide que ha terminado.

• Claude Code lanzó /goal.
• OpenAI Codex lanzó /goal.
• Antigravity construyó todo su modelo en torno a bucles.
• GitHub Copilot lanzó Rutinas y Automatizaciones.

Cuatro equipos, cuatro bases de código, cuatro conjuntos de incentivos. Un primitivo. Cuando Boris Cherny, el creador de Claude Code, describe cómo trabaja ahora, la frase es reveladora:

“Dejó de escribir código. Escribe bucles.”

Esto no es una coincidencia. Cuando equipos independientes bajo presión competitiva llegan a la misma abstracción, eso es evidencia de un primitivo genuino, de la misma manera que map y reduce fueron primitivos genuinos. La pregunta interesante no es por qué ocurrió la convergencia. Es qué haces con ella. Porque si todo el mundo tiene el bucle, el bucle en sí no vale nada. El Episodio 1 de Agents, Orchestrated trata sobre dónde se movió el valor real.

Qué es realmente un bucle

“Ejecutar hasta terminar” no es un bucle. Es una esperanza con un tiempo de espera. Un bucle bien formado tiene tres partes, y he descubierto que nombrarlas explícitamente es la forma más rápida de detectar uno mal diseñado.

Resultado. Cómo se ve el éxito. Este es el estado objetivo que el agente intenta alcanzar, y la palabra clave es estado. No una tarea (“refactorizar el módulo de autenticación”) sino un punto final verificable (“todas las pruebas de autenticación pasan y el módulo exporta la misma interfaz pública”). Si no puedes establecer el resultado como algo verificable, aún no tienes un bucle. Tienes una sensación.

Prueba. Cómo sabes que ha terminado. Este es el paso de verificación: las pruebas pasan, la salida coincide con la especificación, la diferencia es correcta. Aquí es donde la mayoría de los bucles fallan, y lo hacen en silencio. Un agente que declara victoria por su propia cuenta declarará victoria, sea o no correcto el trabajo. La prueba tiene que ser algo que el agente no pueda generar por el simple hecho de querer que sea verdad.

Barandilla. Lo que evita el descontrol. La condición de salida, el presupuesto o la puerta humana que impide que el bucle gire para siempre. Sin ella, un bucle que no puede alcanzar su resultado no se detiene. Quema tokens, muta el estado y reintenta hasta que algo externo interviene. La barandilla es lo que hace que el modo de fallo sea aburrido en lugar de costoso.

Resultado, prueba, barandilla. Cada bucle que he visto en producción tiene los tres. Cada bucle que he visto fallar carecía de al menos uno, generalmente la prueba.

Cuatro tipos de bucles

No todos los bucles son iguales, y un marco de trabajo hizo que todo el espacio fuera legible para mí. Dos ejes lo definen: dónde se ejecuta el bucle (en tu sesión o en la nube) y qué controla su salida (un disparador o una verificación).

Eso te da cuatro cuadrantes:

	Controlado por disparador	Controlado por verificación
En sesión	Ejecución ad-hoc	Ejecución orientada a objetivos
En la nube	Tarea programada	Agente autónomo

Ejecución ad-hoc (en sesión, controlado por disparador). El usuario lo inicia, el agente se ejecuta hasta que se agota el tiempo o el presupuesto, y se detiene cuando tú lo detienes. Este es el uso más común de agentes hoy en día. Es útil, pero el humano es la capa de verificación, lo que significa que no escala más allá de la atención humana.

Ejecución orientada a objetivos (en sesión, controlado por verificación). El agente se ejecuta hasta la prueba de finalización. Esto es /goal. El agente propone que ha terminado, el paso de verificación comprueba, y el bucle solo sale con evidencia. Este es el bucle que puedes auditar, porque la condición de salida es inspeccionable a posteriori.

Tarea programada (en la nube, controlado por disparador). Cron lo dispara, el agente se ejecuta por un tiempo fijo, y no hay ningún bucle de verificación en absoluto. Aquí es donde gran parte del marketing de “agente autónomo” reside discretamente: una tarea cron con gabardina.

Agente autónomo (en la nube, controlado por verificación). Alojado en la nube, orientado a objetivos, de larga ejecución. Aquí es hacia donde se dirige el trabajo agéntico, y yo diría que solo funciona si la capa de verificación es sólida. Todo lo demás en ese cuadrante es una tarea programada que ocasionalmente tiene suerte.

El marco de trabajo se justifica porque separa dos cosas que la gente confunde: dónde se ejecuta el agente y por qué se detiene. Las preguntas sobre autonomía son casi siempre preguntas disfrazadas de “por qué se detiene”.

La ventaja competitiva es la verificación, no la autonomía

La convergencia es emocionante, y entiendo por qué las demostraciones se centran en la autonomía. Pero la autonomía por sí sola no es una ventaja competitiva. Todos los laboratorios la tienen ahora. Cuatro herramientas que lanzan el mismo primitivo en el mismo trimestre es prueba de que el primitivo es una mercancía.

La ventaja competitiva es lo que sucede dentro del bucle cuando cree que ha terminado. Una capa de verificación que detecta salidas incorrectas, revierte errores y produce un registro de auditoría es la diferencia entre una demostración y un producto. Trabajo con instituciones financieras, y la primera pregunta nunca es “cuán autónomo es”. Es “muéstrame por qué hizo eso”, y el bucle que no puede responder no es una capacidad, es una responsabilidad.

Esa es la tesis de todo el episodio, y honestamente de toda la serie: el bucle que puedes auditar es el único que se lanza.

Lo que no llegó a la publicación de LinkedIn

El episodio en sí fue construido con el primitivo que describe, y esa parte merece la versión honesta.

El EP 01 se lanzó como un gráfico en movimiento de aproximadamente 58 segundos, 4:5, con voz en off del presentador, construido con mi habilidad de estudio de videos explicativos y el primitivo /goal de Claude Code ejecutándose contra una especificación escrita. Lo que significa que las tres partes del bucle fueron mías para diseñar: el resultado fue la especificación, la prueba fue un pase de verificación de fotogramas fijos que comprobó que los fotogramas renderizados realmente mostraban los subtítulos bloqueados, y la barandilla fui yo, observando la ejecución.

Dos notas honestas. Primero, el paso de prueba es la razón principal por la que se lanzó el video. El bucle ingenuo produce felizmente un mp4 que existe y es incorrecto; solo la verificación a nivel de fotograma contra la especificación detectó la desviación de subtítulos y tiempos. Segundo, esta fue una ejecución en sesión, orientada a objetivos, no el cuadrante de nube autónoma al que apunta el marco de trabajo. Yo era la puerta humana. No voy a describir una ejecución supervisada como autonomía, porque la brecha entre esos dos cuadrantes es exactamente la capa de verificación de la que trata este episodio.

La especificación, la configuración del bucle y la salida están todos en el repositorio, para que puedas verificar las afirmaciones contra el artefacto.

Registro de lanzamiento

• Formato: Gráfico en movimiento de ~58s, 4:5, voz en off del presentador
• Construido con: Claude Code /goal contra una especificación escrita
• Pipeline: habilidad de estudio de videos explicativos
• Renderizador: Remotion
• Verificación: comprobaciones de fotogramas fijos de la salida renderizada contra la especificación bloqueada
• Repositorio: letmereviewyourcode/what-are-loops