“Ya no hago prompts a Claude”
La frase es de Boris Cherny, responsable de Claude Code: “Ya no hago prompts a Claude. Tengo bucles que le hacen los prompts y deciden qué hacer. Mi trabajo es escribir bucles.” Peter Steinberger lo dijo casi igual. Y Addy Osmani lo ordenó en un término que lleva semanas circulando: loop engineering.
La idea es incómoda pero simple. Durante dos años, sacarle algo a un agente consistía en escribir un buen prompt y darle contexto. Escribías, leías la respuesta, escribías lo siguiente. El agente era una herramienta y la sostenías tú, turno a turno. Esa parte se está acabando. Ahora montas un sistema pequeño que encuentra el trabajo, lo reparte, lo revisa, apunta lo hecho y decide lo siguiente, y dejas que ese sistema pinche a los agentes en tu lugar.
No es una moda de herramienta. Es un cambio de dónde está tu palanca.
Las cinco piezas (y la memoria)
Según Osmani, un bucle se apoya en cinco piezas más un sitio donde recordar. Lo bueno es que ya no es un montón de bash que mantienes tú: las piezas vienen dentro de los productos, y son casi las mismas en Claude Code que en el Codex de OpenAI.
| Pieza | Su trabajo en el bucle |
|---|---|
| Automatizaciones | Descubren y clasifican trabajo en un horario, sin ti |
| Worktrees | Aíslan a cada agente para que dos en paralelo no se pisen |
| Skills | Escriben el conocimiento del proyecto que el agente adivinaría |
| Plugins y conectores | Enchufan el agente a tus herramientas reales (issues, BD, Slack) |
| Sub-agentes | Uno propone, otro verifica; el que escribe no se corrige a sí mismo |
| Memoria | Un fichero o tablero fuera de la conversación: qué está hecho, qué falta |
La automatización es el latido: lo que convierte una ejecución suelta en un bucle de verdad. En Claude Code la tienes con /loop para repetir en cadencia, tareas programadas, hooks, o un GitHub Action si quieres que siga corriendo con el portátil cerrado. Y hay una segunda pieza clave, /goal: sigue hasta que una condición que tú escribiste sea cierta de verdad, con un modelo aparte comprobando tras cada turno si el trabajo está hecho. El que escribió el código no es el que se aprueba.
Cómo se ve un bucle, en pseudocódigo
Sin magia. Un bucle es un lazo con una condición de parada verificable y un verificador que no seas tú:
# El agente no termina cuando "cree" que acabó, sino cuando algo objetivo lo confirma
while not objetivo_cumplido():
tarea = triage() # una automatización saca el trabajo del día
with worktree_aislado(): # nadie pisa a nadie en paralelo
borrador = agente_maker(tarea, skills=conocimiento_proyecto)
veredicto = agente_checker(borrador) # otro agente, a poder ser otro modelo
if veredicto.ok:
abrir_pr(borrador) # el conector actúa en tu entorno real
memoria.registrar(tarea) # el repo recuerda; el modelo olvida entre runs
else:
memoria.anotar_fallo(tarea, veredicto.motivo)
def objetivo_cumplido():
# La clave: la parada la decide un hecho, no una opinión del modelo
return tests_pasan("test/auth") and lint_limpio()El detalle que sostiene el montaje es la memoria en disco. El modelo olvida entre ejecuciones; el repositorio no. Por eso el estado vive en un markdown o un tablero, y mañana el bucle retoma donde lo dejó hoy. Suena demasiado tonto para importar, pero es el mismo truco del que dependen todos los agentes de larga duración.
Separar al que escribe del que revisa
Si te quedas con una sola idea de todo esto, que sea esta: separa al que hace del que comprueba. El modelo que escribió el código es demasiado benévolo corrigiéndose a sí mismo. Un segundo agente, con otras instrucciones y a poder ser otro modelo, pilla lo que el primero se convenció de que estaba bien.
Es lo que hace /goal por debajo: un modelo fresco decide si el bucle terminó, no el que hizo el trabajo. El patrón maker/checker aplicado hasta a la condición de parada. Cuesta más tokens, sí, así que gástalos donde una segunda opinión valga lo que pagas: en lo que se va a mergear, no en cada trivialidad.
Lo que el bucle no hace por ti
Aquí está la parte honesta. Un bucle más suave no te saca de la ecuación: te sube la exigencia, y hay tres problemas que empeoran, no mejoran, según el bucle se pule.
La verificación sigue siendo tuya. Un bucle corriendo solo es también un bucle equivocándose solo. Por eso separas al verificador, y aun así “hecho” es una afirmación, no una prueba. Tu trabajo es enviar código que confirmaste que funciona.
Tu comprensión se oxida si la dejas. Cuanto más rápido te entrega el bucle código que no escribiste, mayor la distancia entre lo que existe y lo que entiendes. Es deuda de comprensión, y un bucle suave la hace crecer más rápido salvo que leas lo que produjo.
Y la postura cómoda es la peligrosa. Cuando el bucle se ejecuta solo, tienta dejar de tener opinión y tragar lo que devuelva. Dos personas montan el mismo bucle y sacan resultados opuestos: una lo usa para ir más rápido sobre lo que domina; la otra, para no entender nunca el trabajo. El bucle no nota la diferencia. Tú sí.
Qué me llevo
Diseñar el bucle es más difícil que escribir un prompt, no más fácil. Ahora decides la condición de parada, quién verifica y qué pasa cuando algo falla mientras no miras. La palanca se movió del prompt al bucle, pero la ingeniería no desapareció: se concentró en el diseño y en la revisión.
Si quieres empezar hoy, coge una tarea repetitiva y verificable —triaje de issues, un chequeo diario de CI— y móntala como bucle con una condición de parada objetiva y un verificador aparte. Y móntalo como quien piensa seguir siendo el ingeniero, no como quien solo aprieta el botón.
Cómo lo veo yo
En mi día a día esto ya no es teoría. Lo uso para vigilar la seguridad de mi app de verificación de pagos en cripto: monté un bucle que lee los logs y, a partir de ahí, me genera issues con los posibles fallos que detecta. Yo solo entro a atacarlos por orden de prioridad. Es loop engineering de manual, la automatización descubre el trabajo y yo decido qué merece mi atención.
Para la velocidad ha sido brutal, paso casi de una feature al día. Lo que me explotó en la cara es justo lo que cuenta el artículo. Más features son más código, más código son más tests, y más tests son todavía más código. Si la única línea segura es la que no llegas a escribir, cada vuelta del bucle amplía la superficie que puedo romper. Fui perdiendo el control de lo que hacía poco a poco, casi sin darme cuenta.
Por eso mi línea la pongo en dos preguntas: cuán sensibles son los datos y cuán crítico es lo que toco. Si es arreglar un bug normal de la app, adelante, que el bucle corra. Si se toca el core financiero, revisión minuciosa a mano y cero permisos de push para los agentes. La velocidad está muy bien hasta que se cruza con el dinero de otra persona.