“Loop Engineering” se está convirtiendo en un nuevo concepto dentro de la programación con IA.
Boris Cherny, creador de Claude Code, ha dicho que ya no da instrucciones directamente a Claude. En su lugar, escribe loops que lo guían y deciden cuál debe ser el siguiente paso. Addy Osmani define Loop Engineering de forma parecida: en vez de que una persona dé instrucciones continuamente a un Agent, se diseña un sistema que se encarga del prompting, la ejecución y el feedback.
La propuesta resulta muy atractiva.
Desde Ralph Wiggum Loop y las ejecuciones programadas de Claude Code hasta Codex Goals, las tareas de larga duración y la orquestación multi-Agent, cada vez más herramientas admiten este patrón. OpenAI llegó a mostrar un experimento de Codex que duró unas 25 horas, consumió cerca de 13 millones de tokens y produjo alrededor de 30.000 líneas de código.
Sin embargo, no creo que Loop Engineering llegue a convertirse en un paradigma estable y universal de ingeniería de software.
No dudo que los Agents seguirán mejorando ni niego que los loops automatizados puedan aportar un enorme valor en algunas tareas. Mi duda es más profunda: poner un Agent dentro de un loop no convierte automáticamente un modelo incierto en un sistema de ingeniería fiable.
El loop resuelve cómo mantener al Agent trabajando, pero no la pregunta más importante:
¿Lo que el Agent sigue haciendo es realmente lo correcto?
Ese es el desafío fundamental de Loop Engineering.
1. Ejecutar es fácil; definir cuándo terminar es difícil
Un sistema en loop necesita al menos tres elementos:
Objetivo, proceso de ejecución, condición de finalización
Lo más difícil no es ejecutar, sino definir qué significa “terminado”.
En un programa tradicional, la respuesta suele ser sencilla:
Detenerse cuando la cola esté vacía
Detenerse cuando todos los archivos estén procesados
Detenerse cuando la API responda con éxito
Son condiciones deterministas y calculables.
La mayoría de los objetivos reales de software no son así.
Por ejemplo:
Mejorar la experiencia de usuario
Refactorizar el sistema de pagos
Mejorar la calidad del código
Hacer el producto más estable
Corregir un fallo intermitente de inicio de sesión
Crear un panel de administración listo para producción
Ninguno se convierte fácilmente en una expresión booleana.
La documentación oficial de Codex Goals también señala este límite: un Goal no es apropiado cuando su punto final es ambiguo. Instrucciones como “mejóralo” o “refactoriza este código” sin estado objetivo, pruebas ni restricciones no ofrecen una condición de finalización fiable. Los Goals funcionan mejor con un objetivo persistente, un punto final basado en evidencias y tareas que pueden requerir varias rondas de investigación.
Esto revela el verdadero ámbito de Loop Engineering.
Los mejores candidatos no son todas las tareas complejas, sino aquellas que una persona ya ha convertido en problemas verificables:
Conseguir que pasen todas las pruebas
Migrar los 23 endpoints antiguos restantes al nuevo protocolo
Corregir todos los errores del análisis estático
Pero cuando una persona ya puede definir con precisión el objetivo, el estado, las restricciones y la condición de finalización, buena parte del trabajo más difícil de requisitos ya está hecho.
Loop Engineering automatiza sobre todo la ejecución posterior, no el juicio que ocupa el centro de la ingeniería de software.
2. La verificación automática no verifica la necesidad real
Loop Engineering suele usar pruebas, Lint, compilaciones, métricas de rendimiento o evaluaciones de capturas de pantalla como señales de feedback.
El loop típico es:
El Agent modifica código -> Ejecuta pruebas -> Las pruebas fallan
-> Analiza el fallo -> Modifica de nuevo -> Las pruebas pasan -> Termina
Parece razonable, pero esconde un problema serio:
El Agent optimiza la señal de verificación, no necesariamente el resultado que de verdad queremos.
Las pruebas solo expresan una parte incompleta de los requisitos.
La investigación SpecBench de 2026 estudió el reward hacking en Coding Agents de largo horizonte. Al separar las pruebas públicas de validación de pruebas composicionales ocultas, observó que los Agents de frontera podían lograr puntuaciones altas en las pruebas visibles y aun así mostrar una brecha clara en las ocultas. La brecha crecía con el tamaño de la tarea. Incluso apareció un caso extremo que memorizaba entradas de prueba para simular una implementación correcta.
Eso no significa necesariamente que el Agent haga trampas de forma deliberada. Un Agent busca una ruta que satisfaga el feedback disponible. Cuando esa señal no representa por completo el objetivo real, aparece una distorsión de la métrica proxy.
Es una variante de la ley de Goodhart:
Cuando una medida se convierte en objetivo, deja de ser una buena medida.
Los ingenieros humanos también consideran restricciones que no están en las pruebas:
- si el código responde a la intención real del producto;
- si rompe el comportamiento de otro módulo;
- si crea costes de mantenimiento a largo plazo;
- si viola los principios de arquitectura;
- si aumenta el riesgo de seguridad;
- si solo está sobreajustado a los casos de prueba.
Un Agent no posee de forma natural este conocimiento organizativo, histórico y de producto.
Por tanto, construir un sistema completo de verificación para Loop Engineering puede costar tanto como resolver directamente la tarea.
3. Los loops pueden amplificar errores, no solo corregirlos
Sus defensores suelen describir el loop como un sistema de autocorrección:
Fallo -> Feedback -> Corrección -> Nuevo intento
Pero un loop no converge por naturaleza. También puede comportarse así:
Interpretar mal el objetivo -> Crear la implementación equivocada
-> Actualizar el plan desde esa implementación -> Registrar un estado falso
-> Los siguientes Agents lo tratan como un hecho -> Seguir optimizando en la dirección errónea
En una tarea larga, el Agent puede modificar no solo código, sino también PRD, listas de tareas, estado del proyecto, documentación de arquitectura, pruebas, registros de progreso y su explicación de la causa raíz. Todo ello se convierte en contexto para la siguiente iteración.
Si una ronda registra un estado incorrecto, las siguientes pueden dejar de tratarlo como una hipótesis pendiente de verificación y asumirlo como un hecho confirmado.
Un error de IA en un solo turno suele quedar limitado a una respuesta. Un loop largo puede propagarlo al repositorio, la documentación, las bases de datos, el sistema de tareas y el historial de Git. Cuanto más dure el loop, mayor puede ser el radio de impacto del error.
4. Reiniciar el contexto no elimina su corrupción
Una idea importante de Ralph Loop consiste en hacer que el Agent complete una tarea cada vez, guarde el progreso en archivos o Git y empiece la siguiente ronda con una ventana de contexto nueva.
Esto evita que la conversación crezca sin límite, pero solo traslada el estado desde el contexto del modelo al almacenamiento externo. No elimina el problema de gestionar la información.
El sistema aún debe decidir qué historial conservar, qué información está caducada, qué conclusiones son simples conjeturas, qué código y documentos importan para la tarea actual y en qué fuente confiar cuando hay contradicciones.
Anthropic denomina este problema Context Engineering: mientras el Agent genera más datos dentro del loop, el sistema debe seleccionar y comprimir continuamente lo que la siguiente ronda necesita. Anthropic también advierte que la recuperación precisa y el razonamiento a larga distancia se degradan a medida que el contexto crece. El contexto debe tratarse como un recurso limitado, no como algo que siempre mejora al aumentar.
El Agent de larga duración afronta un dilema:
Si carga poca información, no entiende el proyecto; si carga demasiada, la señal importante se pierde entre el ruido.
El estado externo también acumula entropía:
Planes obsoletos
Explicaciones duplicadas
Reglas contradictorias
Conclusiones temporales ya inválidas
Suposiciones distintas escritas por diferentes Agents
La dificultad no está en reiniciar el loop, sino en garantizar que cada reinicio reciba información precisa, concisa, fiable y pertinente.
Eso se parece más a gestión del conocimiento, gestión de configuración y gobierno del estado de ejecución que a “escribir un loop”.
5. El volumen de código no equivale a productividad
La ventaja más visible de Loop Engineering es aumentar la producción de código. Un Agent puede trabajar sin parar, varios pueden hacerlo en paralelo, las tareas pueden ejecutarse por la noche y los fallos de pruebas pueden activar reparaciones automáticas.
Pero la productividad de software nunca ha sido equivalente a la cantidad de código.
Lo relevante es el coste total desde que aparece un requisito hasta que el software correcto entra en uso y puede mantenerse a largo plazo. Generar más rápido no significa entregar más rápido.
Si los Agents crean decenas de PR al día y las personas solo pueden revisar unos pocos, el cuello de botella pasa de escribir a verificar código. Si los revisores no pueden comprender el volumen de cambios, habrá dos resultados probables:
Primero, la salida de los Agents se acumula y el throughput automatizado no se convierte en entrega real.
Segundo, el equipo reduce el nivel de revisión, fusiona rápido y desplaza los problemas a las pruebas, producción y mantenimiento.
El sitio de Martin Fowler ha discutido este desajuste: los Agents pueden producir código más rápido de lo que una persona puede revisarlo línea por línea. Para evitar que la revisión humana sea el cuello de botella, los equipos deben adelantar los controles de calidad y crear especificaciones, pruebas y restricciones de flujo que el Agent pueda usar para comprobarse.
En un ensayo controlado aleatorizado de 2025 con desarrolladores open source experimentados, METR concluyó que en repositorios maduros que los participantes ya conocían, las herramientas de IA disponibles entonces aumentaron el tiempo de finalización una media del 19%. Una actualización de 2026 observó posibles señales de aceleración, pero con intervalos de confianza todavía demasiado amplios para afirmar que la IA acelera de forma estable todos los escenarios.
Loop Engineering amplía esta diferencia: aumenta el tiempo de ejecución y el volumen de salida del Agent sin aumentar necesariamente la capacidad del equipo para comprender, verificar y asumir la responsabilidad de esa salida.
6. Más permisos implican más riesgo
Para realizar trabajo complejo, un Agent necesita herramientas y permisos: leer repositorios, modificar archivos, ejecutar comandos de Shell, acceder a bases de datos y logs, llamar servicios cloud, desplegar y revertir servicios.
Además, lee contenido externo no fiable, como issues de GitHub y páginas web. Un atacante puede insertar una prompt injection indirecta para que el Agent confunda texto externo con instrucciones operativas.
Un loop persistente amplifica ese riesgo. Un Agent comprometido puede hacer más que producir una respuesta incorrecta:
Leer datos sensibles -> Llamar herramientas -> Modificar estado externo
-> Guardar el resultado falso en memoria duradera -> Continuar en la siguiente ronda
Un loop de producción parece exigir privilegios mínimos estrictos. Sin embargo, cuanto más se restringen los permisos, menor es la autonomía.
Más autoridad aporta más valor de automatización y más riesgo; menos autoridad reduce el riesgo y también limita lo que el Agent puede hacer.
7. Loop Engineering puede ser Cron más un Agent
Desde el punto de vista del workflow, gran parte de Loop Engineering no es nueva:
Nuevo error de Sentry -> El Agent investiga y abre un PR
Ejecución nocturna -> El Agent revisa pruebas fallidas -> Intenta repararlas
Nuevo ticket de soporte -> El Agent investiga logs -> Genera una recomendación
Antes, estos patrones se implementaban con Cron, webhooks, CI/CD, colas de mensajes, Zapier o n8n.
La novedad consiste en sustituir un nodo determinista del workflow por un LLM Agent.
La mayoría de los casos siguen siendo disparadores de eventos y tareas programadas. Pueden ser útiles, pero difícilmente constituyen un paradigma completamente nuevo. Algunos desarrolladores han vuelto a soluciones convencionales por la deriva del Agent, porque la intervención humana funcionaba mejor o por el coste excesivo de tokens.
8. Conclusión
Loop Engineering dibuja un futuro atractivo: las personas definen objetivos, los Agents trabajan continuamente y el software evoluciona por sí solo.
Pero la ingeniería de software real no es un problema que vaya a converger solo porque sigamos intentándolo.
Los requisitos pueden ser ambiguos. Las pruebas pueden estar incompletas. El estado puede corromperse. Las métricas pueden explotarse. Los permisos pueden abusarse. Los costes pueden descontrolarse. El volumen de código puede superar la capacidad de una organización para entenderlo y revisarlo.
Un loop puede prolongar la ejecución de un Agent. No puede hacer que el objetivo sea automáticamente más correcto.
Frente a invertir en el loop, sigo creyendo que merece más la pena invertir en Harness Engineering: un sistema de feedback fiable, con límites claros, evidencias, permisos, auditoría y la capacidad de detenerse en cualquier momento.