¿Por qué la programación con IA sigue siendo inestable? Loop Engineering puede ser el siguiente paso

La conversación reciente sobre “Loop Engineering”, impulsada por el autor de OpenClaw, parece a primera vista otra nueva forma de practicar AI Coding. Pero, en el fondo, se parece más a redescubrir un camino que la comunidad de Kubernetes ya recorrió hace más de una década: usar un bucle de control con retroalimentación continua para acercar el sistema a su estado deseado.

Si ordenamos la evolución de las herramientas de programación con IA durante los últimos dos años, aparece una ruta bastante clara: de Prompt Engineering a Context Engineering, y ahora a Loop Engineering. Al principio, todos se preocupaban por escribir mejores prompts. Después quedó claro que lo que realmente afecta el rendimiento de un Agent es el contexto, las herramientas, la memoria y el entorno. Luego la pregunta cambió otra vez: incluso con suficiente contexto, el Agent sigue siendo inestable. ¿Qué hacemos?

La respuesta no es hacer que el modelo “piense bien” en un solo intento. Es ponerlo dentro de un bucle de observación, acción, verificación y corrección hasta que converja gradualmente.

Esa es exactamente la visión básica de Kubernetes.

De una llamada única a un bucle continuo

El desarrollo de software real nunca ha sido una inferencia única. Normalmente ocurre así:

1. Leer el código.
2. Entender el objetivo.
3. Modificar la implementación.
4. Compilar o ejecutar pruebas.
5. Encontrar la desviación.
6. Seguir corrigiendo.
7. Hacer Review.
8. Corregir de nuevo.
9. Parar cuando se alcanza un estado aceptable.

Esto no es “prompt -> answer”. Es “goal -> loop -> evaluation -> feedback”. El valor de Loop Engineering está ahí: deja de entender AI Coding como generación automática de código y lo entiende como convergencia automática hacia un objetivo.

Algunas prácticas tempranas ya están cerca de esta dirección. Por ejemplo, usar un bucle para despertar repetidamente a Claude Code, hacer que relea el repositorio, los archivos de planificación y el estado de Git, y luego avanzar una tarea pequeña. Hay una lección clave aquí: los Agents olvidan, los repositorios no. El historial de conversación no es fiable; el estado persistido en disco es el hecho del que puede depender la siguiente ronda.

Kubernetes ya demostró este patrón

Muchas personas entienden Kubernetes como una plataforma de orquestación de contenedores, pero su contribución más profunda fue llevar la teoría de control a la ingeniería de software.

Lo que hace un Kubernetes controller puede resumirse en cuatro pasos:

1
2
3
4
5

Desired State
  -> Observe
  -> Compare
  -> Act
  -> Repeat

Es decir, un Reconciliation Loop. El controller revisa una y otra vez si el estado real coincide con el estado deseado. Si no coincide, sigue ajustando.

Por ejemplo, cuando declaras:

1

replicas: 3

No le dices a Kubernetes “arranca el primer Pod, luego el segundo, luego el tercero”. Solo declaras el estado deseado. Cuántas réplicas existen ahora, qué Pods murieron y si hay que reponerlos son decisiones que el controller toma dentro del bucle.

AI Coding está formando una estructura parecida. Ya no das instrucciones paso a paso al Agent para abrir un archivo, modificar una función y añadir una prueba. Declaras un objetivo: corrige este problema de concurrencia y asegúrate de que las pruebas pasen. El Agent observa el repositorio, modifica código, ejecuta verificaciones, lee la retroalimentación y continúa con la siguiente ronda.

El Prompt se está convirtiendo en Spec.

Componentes de Loop Engineering

Un sistema usable de Loop Engineering suele incluir varios tipos de componentes:

• Disparadores automáticos: timers, cron, webhooks y GitHub Actions, para que el bucle no dependa de que una persona pulse un botón.
• Espacios de trabajo aislados: Git worktree y mecanismos similares que permiten a varios Agents trabajar en paralelo sin pisarse.
• Conocimiento del proyecto: SKILL.md, AGENTS.md, documentos de especificación y archivos de tareas que convierten la experiencia en contexto reutilizable.
• Conexiones con herramientas: MCP, plugins, CI/CD, sistemas de issues y bases de datos para que el Agent pueda observar el entorno real.
• Sub-Agents: separar maker, checker y reviewer para evitar que el modelo se evalúe a sí mismo.
• Estado externo: Markdown, issues, commits de Git o tableros de tareas que registran el progreso y permiten matar, reiniciar y reanudar el bucle.

Estos componentes, juntos, se parecen a un control plane para la era de la IA. El modelo es solo el ejecutor. Lo que realmente determina la capacidad del sistema es cómo se organiza el bucle, cómo se conserva el estado y cómo entra la retroalimentación en la siguiente ronda.

Más que las similitudes, importan las diferencias

Loop Engineering y los controladores de Kubernetes se parecen en su estructura, pero no son equivalentes. La diferencia más importante es esta: Kubernetes controla un sistema relativamente determinista, mientras que un bucle con LLM controla un sistema probabilístico.

Cuando Kubernetes crea un Pod, el resultado suele ser predecible, observable y reintentable. Cuando un LLM recibe la misma instrucción, “corrige el problema de concurrencia del sistema de pagos”, hoy puede cambiar una cosa y mañana otra. Claude y GPT también pueden proponer soluciones completamente distintas.

Esto trae varios problemas difíciles:

• Ejecutor incierto: la misma entrada no garantiza la misma salida.
• Convergencia no demostrable: el bucle puede cambiar cosas repetidamente, quedarse girando o incluso romper algo que ya estaba arreglado.
• Juicio de finalización poco fiable: que el modelo diga “tarea completada” no significa que la tarea esté realmente completada.
• Objetivos ambiguos: “optimizar el sistema de pagos” puede referirse a rendimiento, estabilidad, seguridad o mantenibilidad.
• Verificación costosa: que las pruebas pasen no significa que no haya regresión de rendimiento, vulnerabilidad de seguridad o deuda de arquitectura.

Por eso AI Coding es más difícil que un Kubernetes Operator. No solo necesita reconciliación; también necesita una definición de objetivos y un sistema de evaluación más fuertes.

Maker-Checker como Admission Controller

¿Por qué cada vez más sistemas de Agents separan maker y checker? La razón es simple: no se puede confiar por completo en el ejecutor.

El Agent que escribe código puede autoconfirmarse. Puede decir “ya está corregido” sin haber ejecutado suficientes pruebas. Puede decir que la solución es más limpia mientras introduce un nuevo riesgo. Por eso hace falta otro rol independiente que lo inspeccione: ejecutar pruebas, revisar el diff, hacer escaneos de seguridad, leer logs y decidir si el objetivo se cumplió de verdad.

Esto tiene una intuición de ingeniería parecida a Admission Controller y Validating Webhook en Kubernetes: no dejes que una acción entre directamente en el sistema. Haz que pase primero por política, validación y restricciones.

Los sistemas futuros de Agents probablemente tendrán más capas:

1
2
3
4
5

Maker
  -> Checker
  -> Reviewer
  -> Policy Engine
  -> Human

Esto no complica el flujo por gusto. Añade un sistema de control alrededor de un ejecutor probabilístico.

El verdadero límite está en Goal y Evaluation

El núcleo de Loop Engineering no es solo diseñar bucles. En un nivel más profundo, lo que intenta resolver es Goal y Evaluation.

Kubernetes funciona de forma estable porque el Desired State está formalizado. La condición de finalización de replicas: 3 es clara: el número real de réplicas es 3. No hay juicio estético ni un “más o menos terminado”.

El mayor problema de AI Coding está justo ahí. Muchos objetivos son difusos:

• “Ayúdame a optimizar este sistema.”
• “Refactoriza el módulo de usuarios.”
• “Corrige el problema de estabilidad en producción.”
• “Haz que este código sea más fácil de mantener.”

Si esos objetivos no se dividen en condiciones observables, verificables y con un punto claro de parada, el bucle tendrá problemas para converger. El Agent no sabe cuándo continuar ni cuándo detenerse.

Una forma más razonable debería parecerse a esto:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

goal:
  description: "Corregir el problema de concurrencia del sistema de pagos"
  metrics:
    correctness:
      unit_test_pass_rate: "100%"
      integration_test_pass_rate: "100%"
    performance:
      latency_p99: "< 100ms"
      throughput: ">= 1000 tps"
    safety:
      critical_vulnerability: 0
      data_race: 0

evaluation:
  layers:
    - unit_test
    - integration_test
    - e2e_test
    - benchmark
    - static_analysis
    - security_scan
  judge:
    model: "independent-checker"
    threshold: "all_layers_pass"

loop:
  max_iterations: 20
  strategy: "exponential_backoff"

En este punto, lo que escribimos ya no es solo un prompt. Se parece más a un Agent CRD. Los campos realmente importantes ya no son si elegimos Claude o GPT, sino goal.metrics y evaluation.layers.

Los ingenieros de software se parecerán más a ingenieros de sistemas de control

Este cambio no significa necesariamente que la IA vaya a reemplazar directamente a los ingenieros. Lo más probable es que cambie el centro de gravedad del trabajo de ingeniería.

Antes, los ingenieros escribían principalmente código. En el futuro, dedicarán más tiempo a diseñar objetivos, validación, estado y retroalimentación:

• Traducir intenciones de negocio vagas en objetivos que puedan converger.
• Diseñar Evaluation Pipelines de varias capas.
• Mover la memoria del Agent fuera de la conversación y llevarla a repositorios, tableros de tareas y estado persistente.
• Definir los límites entre maker, checker y reviewer.
• Definir condiciones de parada y estrategias de reintento.
• Decidir qué debe seguir siendo confirmado por una persona.

Prompt Engineer puede ir perdiendo protagonismo, no porque los prompts no sirvan, sino porque escribir prompts se volverá una parte sistematizada. Las capacidades más escasas serán Goal Engineering y Evaluation Engineering.

Conclusión

Loop Engineering no es un concepto nuevo que aparece de la nada. Se parece más al regreso de la teoría de control, las máquinas de estado, los sistemas de retroalimentación, los Kubernetes controllers y el Operator Pattern en la era de AI Coding.

Podemos entender este cambio en cuatro capas:

1. Similitud estructural: Loop se parece a Operator.
2. Similitud de implementación: Agent se parece a Controller.
3. Similitud esencial: Goal se parece a Spec, Evaluation se parece a Status.
4. La capa más importante: AI Coding no es automatizar la escritura de código, sino automatizar el avance hacia un objetivo.

Todo sistema que avanza automáticamente hacia un objetivo termina volviendo a la teoría de control: si el objetivo es claro, si el estado es observable y si la retroalimentación es precisa.

Por eso, la pregunta más importante para la ingeniería de software AI Native en la próxima década quizá no sea “qué modelo es más fuerte”. Tal vez sea: cuando el software empiece a modificarse a sí mismo, ¿cómo deberíamos diseñar el bucle de control que lo limita, lo verifica, lo corrige y finalmente decide si podemos confiar en él?