🔄 Diseña el ciclo de ejecución
Un agente trabaja en ciclo: observar → entender → planificar → ejecutar → probar → evaluar → corregir → repetir. Lo que separa un ciclo de ingeniería de uno de esperanza es la etapa de evaluar: es ahí donde se decide si la siguiente vuelta tiene sentido.
Cómo leer: el círculo de la izquierda es el loop; las tres cajas de la derecha son las únicas formas de salir de él. Si tu loop hoy solo tiene la primera (éxito), no tiene salida cuando las cosas salen mal — y es exactamente ahí cuando consume el presupuesto toda la noche.
🆕 ¿Nuevo por aquí?
Loop aquí es el ciclo automático que el agente ejecuta por su cuenta entre una instrucción tuya y la siguiente. Condición de parada es la regla que cierra el ciclo. Rollback es deshacer lo que se hizo; fallback es seguir un camino alternativo cuando falla el principal. Son cosas diferentes: uno vuelve, el otro busca otra ruta.
Evaluar
La etapa que casi desaparece
Señal nueva
Cada vuelta necesita una
Tres resultados
Éxito, límite, abandono
Medible
Un loop ciego implica un costo ciego
🎯 Establece un objetivo verificable y un estado persistente
El agente necesita saber qué debe alcanzar, en términos que un comando pueda responder. Y el sistema necesita registrar lo que ya se hizo, para que una interrupción no lo eche todo a perder.
✓ Objetivo que cierra el loop
- ✓"npm test devuelve 0 y la prueba X, que hoy falla, pasa».
- ✓"El lint no reporta ninguna incidencia nueva."
- ✓"Ningún archivo fuera de src/x/ aparece en el diff."
✗ Objetivo que nunca se alcanza
- ✗"Haz que el módulo sea más robusto."
- ✗"Sigue mejorando hasta que quede bien."
- ✗"Corrige todos los problemas que encuentres."
Estado mínimo que vale la pena registrar entre iteraciones
tentativa: 2 de 3 hipótese atual: chave de idempotência não considera o valor já tentado: (1) índice único simples — falhou, mesma duplicidade arquivos tocados: src/pagamentos/idempotencia.ts, tests/idempotencia.test.ts último resultado: 128 passaram, 1 falhou
Con esto por escrito, cualquier persona (o el propio agente después de una interrupción) puede retomar sin repetir lo que ya falló.
El comando decide
No la impresión
Hipótesis
Cada vuelta tiene una
Ya intentado
Evita repeticiones
Retomable
Una interrupción no reinicia todo
🛑 Define las condiciones de detención
Todo loop debe saber cuándo terminar. Hay tres salidas —y la tercera, detenerse por falta de progreso, es la que casi nadie implementa.
Éxito
Se alcanzó el objetivo verificable y se registró la evidencia (salida real del comando). El ciclo termina y entrega el resultado para revisión.
Límite alcanzado
Se agotaron los intentos, el tiempo o el costo. El loop termina, conserva el estado e informa lo que intentó; el trabajo parcial no se pierde.
Sin progreso (la salida olvidada)
Dos intentos seguidos con el mismo fallo, o el diff empezó a crecer sin que avance la prueba. El ciclo se detiene y pregunta — resultado válido, no fracaso.
⚠️ Atención
El agente acorralado tiende a «resolver» el fallo de la manera equivocada: relajando la aserción, marcando la prueba como omitida o capturando la excepción en silencio. Si el loop puede editar pruebas, puede redefinir su propio criterio de éxito: prohíbelo explícitamente.
Éxito
Con evidencia adjunta
Límite
Conserva lo parcial
Detener y preguntar
Es un resultado válido
Prueba intocable
Si no, el criterio desaparece
💸 Controla los intentos, el tiempo y el costo
El límite de intentos evita que el agente repita la misma acción. El límite de costo controla el consumo de tokens, tiempo y recursos. Juntos convierten un riesgo abierto en un valor predecible por tarea.
🧪 Ejercicio copiable — ciclo de corrección de errores con límite
Objetivo: ejecutar un ciclo real de corrección con una condición de parada y sin editar pruebas. Usa un bug real de tu repositorio.
Bug: <descreva o comportamento errado> Como reproduzir: <passos ou comando> Siga EXATAMENTE este loop, sem pular etapas: 1. reproduza o erro e cole a saída real; 2. localize a causa e escreva a hipótese em uma frase; 3. escreva um teste NOVO que falha por causa desse bug (não altere testes existentes); 4. implemente a MENOR correção que faz esse teste passar; 5. rode <comando de teste> e cole a saída real completa; 6. me mostre o diff. Limites (obrigatórios): - no máximo 3 tentativas de correção; - se a mesma falha aparecer 2 vezes seguidas, PARE e me diga o que tentou; - não altere nem remova nenhum teste existente; - não adicione dependências; - no máximo 5 arquivos alterados. Se qualquer limite for atingido, pare e relate o estado — não continue.
Cómo verificar: revisa tres cosas en el resultado: (1) existe una prueba nueva que fallaba antes; (2) no se modificó ninguna prueba anterior (git diff --stat en los archivos de prueba); (3) la salida pegada es la real, no un resumen. Si el agente se detuvo por alcanzar el límite, el ejercicio también salió bien: el loop funcionó.
Mismo error 2x
Cambia la estrategia
Corrección menor
Mantiene el diff revisable
Salida real
El resumen no es evidencia
Costo por tarea
Se convierte en un número predecible
↩️ Prepara el rollback y el fallback
Rollback permite volver al estado anterior. Fallback define una alternativa cuando la ruta principal no funciona. Donde no hay rollback, no debería haber autonomía.
🧯 Reversibilidad según el tipo de acción
- •Barato de deshacer: commit en una branch, archivo nuevo, container descartado. Puede ser autónomo.
- •Costoso de revertir: migración de base de datos, cambio de contrato de API pública. Exige un plan de rollback por escrito antes.
- •Imposible de deshacer: correo enviado, pago procesado, dato eliminado sin backup. Siempre con una persona.
💡 Consejo práctico
Antes de autorizar cualquier loop autónomo, responde: "si esto sale mal a las 3h de la mañana, ¿cuál es el comando exacto para deshacerlo?". Si no puedes responder en una línea, el loop todavía no puede ejecutarse solo.
Rollback
Volver al estado anterior
Alternativa
Rodea el camino
Migración
Reversible o no se hace
Autonomía
Limitada por la reversión
🙋 Incluye la aprobación humana en el momento adecuado
La aprobación humana interrumpe el loop antes de las acciones críticas. Si se coloca en todas partes, se convierte en un sello automático; colocada en el punto correcto —inmediatamente antes de lo irreversible— es el último control real que tienes.
✓ Aprobación que funciona
- ✓Pocas, y siempre antes de algo irreversible
- ✓Con evidencia adjunta: diff, resultado de pruebas, plan de rollback
- ✓Con un "no" fácil: rechazar debe costar menos que aprobar
- ✓Registrada: quién aprobó, cuándo y con base en qué
✗ Aprobación decorativa
- ✗Una por paso; nadie lee a partir de la quinta
- ✗Sin evidencia: «¿apruebas?» junto con un resumen del propio agente
- ✗Después de que ya está hecho ("ya lo apliqué, ¿confirmas?")
- ✗Para cambios triviales y reversibles que podrían ser automáticos
Verificación rápida: el loop intentó la misma corrección dos veces y falló igual en ambas. ¿Qué debe pasar?
Antes del daño
Nunca después
Con evidencia
No por confianza
Pocas
Muchas se vuelven un simple trámite
Registrada
Quién, cuándo, por qué
📌 Resumen del módulo
Próxima ruta:
Ruta 3 - Flujo y calidad: automatizaciones, revisión de código con IA y quality gates.