Dejar de promptear. Diseñar el sistema que lo hace.
Empezar con el test →"No prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."
Boris Cherny — Head of Claude Code, Anthropic
"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."
Peter Steinberger — PSPDFKit / Buildwatch
Loop Engineering es el término que está usando la industria para describir el siguiente nivel después del agente único. Addy Osmani (Google) lo definió esta semana. Anthropic lleva meses construyendo sobre ese principio internamente.
La mayoría de empresas todavía usa la IA como si fuese un becario al que hay que dictarle cada paso. Le pides una cosa, revisas, corriges, vuelves a pedir. Sigues siendo tú quien opera el sistema.
Un loop cambia la relación. En vez de promptear cada paso, defines un objetivo, un ciclo de trabajo, una forma de comprobar si el resultado vale y una condición de parada. A partir de ahí, el agente ejecuta un circuito acotado.
Eso es Loop Engineering: diseñar el bucle donde trabaja el agente.
Un loop mal definido consume tokens, produce ruido y obliga a revisar más de lo que ahorra. Un loop bueno hace una tarea repetida, deja evidencia y se para antes de convertirse en un problema.
Antes de montar un loop, pasa este filtro. Marca lo que aplica a tu tarea.
Cuatro son obligatorias. Tres son las que evitan sustos.
Una frase concreta, observable y pequeña. Si cabe en una reunión estratégica, es demasiado grande. Si cabe en una tarea recurrente, empieza a tener forma de loop.
El agente necesita saber de dónde parte y dónde dejar rastro. Qué documentos puede usar, qué criterios respetar, qué decisiones ya están tomadas y dónde guardar el resultado.
Un loop sin estado repite trabajo. Con estado, el agente sabe qué hizo, qué falló y qué queda pendiente.
La secuencia que el agente repite. Si tiene veinte pasos, suele estar mal pensado. Una versión simple:
Cómo comprobamos si el output vale. Puede ser una prueba automática, una checklist o una revisión humana breve.
Sin eval, el loop genera cosas. Con eval, trabaja con criterio.
Cuando algo falla, el agente necesita saber qué hacer. Define una regla simple:
Lo que separa un loop útil de una máquina de gastar tokens. Un loop debe parar cuando:
Si no sabes cuándo debe parar, no debería empezar.
Hay acciones que se preparan, pero no se lanzan sin una persona delante. Requieren aprobación:
El loop hace el trabajo pesado. La responsabilidad sigue siendo tuya.
Usa esto como base cuando quieras diseñar un loop.
Nombre del loop: Objetivo: Qué resultado concreto tiene que conseguir el agente. Entrada: Qué información recibe en cada ciclo. Contexto: Qué documentos, criterios, reglas o herramientas puede usar. Ciclo: 1. 2. 3. 4. Eval: Cómo sabemos que el resultado es válido. Feedback: Qué hace si el resultado no pasa el eval. Condición de parada: Cuándo termina, cuándo reintenta y cuándo avisa. Salida: Dónde deja el resultado y con qué formato. Revisión humana: Qué acciones no puede ejecutar sin aprobación. Límite: Número máximo de vueltas, coste o tiempo permitido.
Buen primer loop: entrada recurrente, criterios definibles, ningún riesgo si se equivoca una vez.
El agente no tiene permiso para "gestionar el pipeline". Tiene permiso para procesar una lista, aplicar un criterio y entregar una propuesta ordenada. Tú decides si la usas.
Un loop no es peor por ser pequeño. Normalmente es mejor.
Si alguien del equipo no puede explicar el proceso en cinco minutos, el agente tampoco lo va a arreglar. Solo le dará velocidad al desorden.
Sin respuesta a "cómo sabemos que esto está bien", el loop depende de que tú revises cada salida. Y entonces has vuelto al punto de partida.
Si el agente no deja rastro de lo que ha intentado, cada vuelta empieza desde cero. Consume tiempo, tokens y paciencia.
Un loop necesita un máximo de vueltas, un máximo de tiempo o una razón clara para parar. Sin eso, estás confiando en que el agente tenga prudencia. Mala idea.
Primero que prepare. Luego que proponga. Más adelante, si el proceso está probado, más autonomía. Saltarse ese orden suele salir caro.
No montes una plataforma. Monta esto.
Pequeño, limitado, revisable. Justo como debería empezar.
No es hype. Son datos de producción.
El que siga prompting manual en 2026 no está usando IA de forma ineficiente. Está usando IA de la forma que era normal en 2024. Son dos años de distancia en un sector que se mueve cada cuatro meses.
Mándame el proceso con este formato y lo revisamos juntos.
Proceso: Cada cuánto se repite: Quién lo hace ahora: Qué entrada recibe: Qué salida produce: Cómo sabes que está bien: Qué riesgo tendría si falla:
La IA no arregla el caos. Lo recorre más rápido.
Escribir a José en LinkedIn →