Loop engineering: la evolución del prompt engineering

Hoy me gustaría escribir sobre un tema un poquito más técnico, pero que sin dudas deben haber visto mucho en estos días: loop engineering.

¿Qué hay detrás de este concepto que se puso en agenda luego de las recientes declaraciones de Boris Cherny, head de Claude Code?

"I'm no longer prompting Claude. I'm just running a loop that prompts him and then thinks about what to do next. My job is to write loops."

Lo que hay detrás de este término no es nada nuevo para quienes amamos la tecnología: es la búsqueda de la automatización y de evitar tareas repetitivas. Y parece ser la evolución natural al prompt engineering.

Del prompt al loop

Durante un buen tiempo, la forma de trabajar con IA fue conversacional: yo escribo, la IA responde, yo leo, yo decido el siguiente paso. El prompt engineering se ocupó de mejorar esa conversación: cómo escribir mejor cada instrucción, cómo dar mejor contexto, cómo pedir las cosas para obtener mejores resultados.

El loop engineering propone otra cosa: en lugar de escribir cada prompt, diseño el proceso que va a ejecutar esos prompts por mí, de forma programada y en base a un objetivo. Dejo de estar dentro del loop, dando la instrucción turno a turno, y paso a diseñar el mecanismo que lo hace en mi lugar.

Addy Osmani, quien popularizó y le dio nombre al concepto hace unos días en este post, lo resume así: un loop puede pensarse como un objetivo recursivo, donde defino un propósito y la IA itera hasta completarlo.

Las 6 partes de un buen loop

Osmani plantea que un loop bien diseñado tiene seis componentes:

1. Automatizaciones. Un timer que arranca el trabajo solo, sin que yo tenga que apretar un botón.

2. Worktrees. Áreas de trabajo separadas, para que dos asistentes de IA no se pisen entre sí.

3. Skills. Instrucciones guardadas que le enseñan a la IA cómo hago yo una tarea, para que deje de adivinar.

4. Conectores. Conexiones a las herramientas reales que ya uso (Gmail, Slack, Notion, GitHub, etc.).

5. Sub-agentes. Una IA hace el trabajo, otra distinta lo revisa. 

6. Memoria. Un archivo de notas que vive fuera del chat y recuerda qué se hizo y qué falta.
   

En la práctica, esto se traduce en automatizaciones, worktrees, skills, conectores, subagentes y memoria. Y lo interesante es que tanto Claude Code como Codex ya tienen las piezas para armar las seis partes.

En Claude, por ejemplo, esto se ve con comandos como /goal, que define una condición de éxito y deja que la IA itere hasta cumplirla, y /loop, que repite un prompt en un intervalo definido. Veámos ejemplos de estos comandos:

$ /goal all tests in test/auth pass and the lint step is clean
$ /loop 5m check if the deployment at localhost:3000 is responding and tell me the HTTP status code

Un ejemplo concreto: procesar fotos de facturas

Para bajarlo a tierra, pensemos en una tarea bien cotidiana: cargar gastos a partir de fotos de recibos.

Tengo una skill, ObtenerGasto, que recibe la imagen de un recibo o factura, extrae los metadatos clave y los agrega a una planilla Excel (creándola si no existe).

El objetivo del loop es simple: que revise una carpeta donde voy dejando las fotos de los recibos, y mientras haya imágenes sin procesar, use esa skill y me deje una nota en Notion con el resumen.

En la carpeta donde tienes las fotos de los recibos, abre una sesión de Claude (puede ser usando Claude CLI o las "Rutinas" en el IDE de Claude)

El /goal quedaría más o menos así:

Revisá esta carpeta y listá todos los archivos de imagen (jpg, jpeg, png, heic, pdf). 

Si no existe la subcarpeta /procesados/, creala. 

Para cada archivo encontrado, lanzá un thread independiente que: 

1) lea el archivo de imagen, 
2) llame a la skill "ObtenerGasto" pasándole la imagen, 
3) si la skill termina exitosamente, mueva el archivo a /procesados/, 
4) si la skill falla, registre el nombre del archivo y el error, deje el archivo en su lugar y continúe con los demás. 

Seguí procesando hasta que no haya más imágenes. 

Cuando todos finalicen, armá una nota en mi página "Notas rápidas" de Notion con: cuántos archivos se encontraron, cuántos se procesaron exitosamente, y la lista de los que fallaron y por qué.

/goal en Claude CLI

Lo lindo de este ejemplo es que muestra el patrón completo:

1. el loop descubre el trabajo (los archivos en la carpeta),

2. lo ejecuta (llama a la skill),

3. lo verifica (éxito o error),

4. y deja un registro fuera del chat (la nota en Notion) para que la próxima ejecución sepa qué quedó pendiente.

Si quiero ir un paso más allá, puedo pedir que cada archivo se procese en un subagente independiente, todos en paralelo, en lugar de uno por uno.

Revisá esta carpeta y listá todos los archivos de imagen (jpg, jpeg, png, heic, pdf). 

Si no existe la subcarpeta /procesados/, creala. 

Para cada archivo encontrado, lanzá un subagente independiente usando la herramienta Agent (subagent_type: general-purpose), uno por archivo, todos en paralelo (múltiples llamadas a Agent en el mismo turno, no una por una). 

A cada subagente dale un prompt autocontenido con: 

- La ruta absoluta del archivo de imagen. 
- La instrucción de llamar a la skill "ObtenerGasto" pasándole esa ruta. 
- Qué hacer si la skill termina bien: mover el archivo a /procesados/. 
- Qué hacer si falla: NO mover el archivo, y devolver el nombre del archivo + el motivo del error como resultado del subagente.

Esperá a que todos los subagentes terminen. Con los resultados, armá una Nota en mi página Notas rápidas de Notion con: cuántos archivos se encontraron, cuántos se procesaron exitosamente, y la lista de los que fallaron y por qué.

Y ahí aparecen las tres buenas prácticas que considero más relevantes:

1. definir un estado final medible (un resultado de prueba, un código de salida, una cola vacía)

2. establecer una verificación clara (cómo se va a comprobar que funcionó)

3. poner restricciones que importan (qué cosas no deberían cambiar en el camino)

Lo que no cambia

Más allá de lo técnico, hay algo que me parece central y que vale la pena destacar: un loop mal diseñado no nos hace más eficientes, simplemente multiplica el error a una velocidad mayor, con menos personas mirando. La verificación sigue siendo nuestra responsabilidad. Y si dejamos de entender lo que el sistema produce, lo que ganamos en velocidad lo perdemos en criterio.

Por eso el loop engineering no me parece una forma de desentendernos del trabajo, sino una forma distinta de seguir presentes en él: ya no escribiendo cada instrucción, pero sí diseñando, con cuidado, las condiciones bajo las cuales la IA puede actuar sin que estemos mirando cada paso.

¡Hasta la próxima! PD: Si te interesa el liderazgo, la innovación, la tecnología y cómo potenciar equipos multiculturales, te invito a seguirme en Substack. Suscríbete aquí y recibí al instante cada nuevo post de esta serie. 🚀🌍