TL;DR
· En junio de 2026, varios profesionales de la programación con IA propusieron casi simultáneamente la Ingeniería de Bucles (Loop Engineering). Stripe ya utiliza Minions para fusionar más de 1300 PRs generados por IA cada semana.
· Este método ya no depende de que los humanos den indicaciones paso a paso, sino que permite que el sistema descubra tareas automáticamente, las transfiera, las verifique, guarde el estado y pase a la siguiente ronda.
· La fiabilidad sigue dependiendo de evaluadores independientes, compuertas estrictas y revisión humana. La deuda de verificación y la degradación de la comprensión pueden amplificar los riesgos en sentido inverso.

Recientemente, un ingeniero de Anthropic publicó un documento de 11 páginas sobre «Ingeniería de Bucles en Sistemas de Agentes», situando la Ingeniería de Bucles (Loop Engineering) después de la Ingeniería de Prompts, la Ingeniería de Contexto y la Ingeniería de Arneses, considerándola el método clave para que la programación con IA entre en la siguiente fase.

Este documento ha llamado la atención porque coincide justo con el punto de inflexión en los debates sobre programación con IA de junio de 2026. Addy Osmani, Boris Cherny y Peter Steinberger, casi en la misma semana, denominaron a esta nueva fase de la programación con IA como Ingeniería de Bucles, mientras que el pipeline Minions de Stripe ya fusiona más de 1300 Pull Requests generados por IA cada semana con un enfoque similar.

Este número es importante no porque la IA haya escrito unas líneas de código más, sino porque el centro de gravedad del desarrollo de software está pasando de «los humanos le dicen al modelo qué escribir» a «los humanos diseñan un sistema que se pone en cola, toma tareas, escribe código, verifica resultados, guarda el estado y continúa ejecutándose por sí mismo».

En el último año, la narrativa en torno a las herramientas de programación con IA se ha centrado principalmente en la capacidad del modelo: autocompletado de código más preciso, ventanas de contexto más largas, agentes capaces de realizar tareas más complejas de una sola vez. Pero la Ingeniería de Bucles trata de otra cosa: cuando generar código en sí mismo es cada vez más barato, lo que los ingenieros realmente tienen que diseñar se convierte en un bucle que pueda funcionar de manera sostenible. La máquina puede producir continuamente propuestas de solución, y los humanos deben decidir qué resultados son fiables, cuáles deben bloquearse y qué costes a largo plazo se están ocultando.

Recientemente, un ingeniero de Anthropic publicó un documento de 11 páginas sobre «Ingeniería de Bucles en Sistemas de Agentes», situando la Ingeniería de Bucles (Loop Engineering) después de la Ingeniería de Prompts, la Ingeniería de Contexto y la Ingeniería de Arneses, considerándola el método clave para que la programación con IA entre en la siguiente fase. Este artículo toma precisamente ese documento como punto de partida, combinando discusiones públicas de Boris Cherny, Addy Osmani y otros, así como el caso de Stripe Minions que fusiona más de 1300 PRs generados por IA cada semana, para explicar qué es realmente la Ingeniería de Bucles, por qué de repente se discute en toda la red, y qué es lo que realmente cambia: no es escribir código, sino la verificación, la programación y el juicio en el desarrollo de software.

La programación con IA pasa de «una sola indicación» a «bucles continuos»

La Ingeniería de Bucles se sitúa después de la Ingeniería de Prompts, la Ingeniería de Contexto y la Ingeniería de Arneses, como la cuarta capa de la pila de ingeniería de IA.

La Ingeniería de Prompts resuelve «cómo preguntar»; la Ingeniería de Contexto resuelve «qué mostrar al modelo»; la Ingeniería de Arneses resuelve «cómo integrar una ejecución del modelo en herramientas, pruebas y flujos de trabajo». La Ingeniería de Bucles va un paso más allá: el sistema no solo ejecuta una tarea, sino que puede reiniciarse en un tiempo fijo o bajo condiciones desencadenantes, utilizando el resultado anterior como entrada para la siguiente ronda.

Un bucle completo suele contener cinco acciones.

El primer paso es descubrir trabajo, por ejemplo, escanear fallos de CI, issues abiertos, confirmaciones de código o tareas pendientes; el segundo paso es la transferencia de tareas, organizando las tareas en un contexto que el modelo pueda procesar; el tercer paso es la verificación independiente, comprobando si el código producido por el modelo realmente se ejecuta, pasa las pruebas e introduce efectos secundarios; el cuarto paso es la persistencia de resultados, escribiendo el estado, los juicios y los asuntos pendientes en archivos o sistemas; el quinto paso es la programación del bucle, permitiendo que la siguiente ronda continúe en el momento adecuado.

Lo más importante aquí no es la «generación», sino la «verificación». Si un bucle solo hace que el modelo escriba código constantemente, y luego deja que el mismo modelo alabe sus propios resultados, es fácil que se convierta en un «bucle de asentimiento»: cada ronda parece avanzar, pero en realidad solo envuelve los errores de forma más completa.

El bucle de triaje matutino de Osmani es un ejemplo a nivel personal: el sistema lee automáticamente cada día los fallos de CI del día anterior, los issues abiertos y las confirmaciones recientes, genera un archivo de estado y coloca los asuntos que no puede manejar en la bandeja de entrada humana. Su valor no es tomar todas las decisiones por el ingeniero, sino realizar un cribado inicial antes de que el ingeniero se despierte, dejando la atención para las partes que realmente requieren juicio.

Los 1300 PRs de Stripe: la fiabilidad proviene de las restricciones, no del modelo

El pipeline Minions de Stripe es el caso empresarial más impactante en esta ronda de discusiones: fusiona más de 1300 Pull Requests generados por IA cada semana, y el código en sí no ha sido escrito línea por línea por humanos.

Pero esto no significa que Stripe haya dejado el sistema de producción a merced de un gran modelo para que actúe libremente. Al contrario, la clave de Minions reside en un proceso altamente controlado: un orquestador determinista monta primero el contexto, extrayendo información de tareas de Jira, búsqueda de código y herramientas internas; el LLM se encarga de generar código; luego, mediante linters codificados, compuertas de confirmación y revisión humana final, se decide si se puede fusionar.

En otras palabras, la fiabilidad no proviene de que «el modelo se haya vuelto repentinamente lo suficientemente inteligente», sino de una serie de restricciones. El modelo propone cambios candidatos, el sistema se encarga de limitar a qué puede acceder y qué comprobaciones debe superar, y los humanos deciden finalmente si se integra en la rama principal.

Esta es también la diferencia entre la Ingeniería de Bucles y los scripts comunes de programación con IA. Los scripts comunes suelen centrarse en «hacer que el modelo complete la tarea»; los sistemas de bucle deben considerar de dónde vienen las tareas, cómo manejar los fallos, cómo conservar el estado, cómo controlar el presupuesto y quién impide que los errores entren en el entorno de producción.

Sin estas restricciones, 1300 PRs por semana no son un salto de eficiencia, sino una posible máquina de generar deuda técnica.

El generador y el evaluador deben estar separados

Un diseño central de la Ingeniería de Bucles es separar el generador del evaluador.

El generador se encarga de escribir código, modificar archivos y presentar resultados candidatos. El evaluador se encarga de detectar errores, y preferiblemente debe asumir por defecto que el código tiene problemas. Ambos no pueden ser realizados por el mismo «agente optimista», porque los modelos tienden a aprobar su propia producción cuando se autoevalúan, especialmente cuando la descripción de la tarea es vaga, la cobertura de pruebas es insuficiente o el contexto está incompleto.

Un evaluador independiente puede ser más simple, más escéptico y más fácil de ajustar. No necesita resolver problemas de forma creativa, solo necesita verificar si la página se abre, si las pruebas pasan, si los casos límite se rompen y si el código cumple las reglas establecidas. Algunas prácticas hacen que el evaluador utilice herramientas de automatización del navegador para hacer clic realmente en la página, en lugar de solo leer el código y emitir un juicio.

Esto explica por qué la «verificación» es la parte más difícil del bucle de cinco pasos. La generación de código es cada vez más barata, pero demostrar que un código es realmente correcto sigue siendo caro. Especialmente en bases de código grandes, los errores no siempre se manifiestan de inmediato, y las pruebas no siempre cubren las rutas reales del negocio. Cuanto más rápido corre el bucle, más rápido se acumulan las suposiciones no verificadas.

Los costes ocultos se refuerzan mutuamente

El riesgo de la Ingeniería de Bucles no está en que pueda escribir código incorrecto, sino en que puede dificultar que el equipo se dé cuenta de que ha perdido la comprensión.

El primer tipo de coste es la deuda de verificación. Los errores no cubiertos por las pruebas se acumulan en el bucle hasta que estallan de forma concentrada en alguna fusión o puesta en producción. El segundo tipo es la degradación de la comprensión. La base de código se expande continuamente, pero el ingeniero no ha experimentado personalmente las decisiones clave de diseño, y su mapa mental se queda en versiones antiguas. El tercer tipo es la rendición cognitiva. Los humanos empiezan a aceptar por defecto la salida de la máquina, limitándose a aprobaciones formales. El cuarto tipo es la explosión del consumo de tokens. Los reintentos, subagentes, contextos largos y verificaciones múltiples hacen que la factura aumente rápidamente.

Estos cuatro costes se retroalimentan entre sí: las pruebas insuficientes generan deuda de verificación; al aumentar la deuda de verificación, los ingenieros son menos propensos a profundizar en la comprensión; la comprensión disminuida convierte la revisión humana en un mero sello de goma; y la revisión tipo sello de goma impulsa más reintentos automáticos y mayores costes.

Por lo tanto, el mismo conjunto de componentes de bucle puede producir resultados completamente opuestos en manos de diferentes ingenieros. Quienes tienen buen juicio y límites claros pueden utilizar el bucle para amplificar su comprensión del sistema, tratando a la máquina como una capa de ejecución incansable; quienes tienen un juicio débil o dependen en exceso de la automatización pueden, meses después, convertirse en «porteros» de su propio sistema, limitándose a aprobar o rechazar sin poder explicar por qué el sistema funciona así.

El código se vuelve barato, lo caro es el juicio

La Ingeniería de Bucles sitúa una tendencia a largo plazo en una posición más clara: el código, los planes, los PRs y el desglose de tareas se están volviendo casi gratuitos, pero «qué es realmente correcto» no se ha abaratado.

Para las empresas, esto significa que el enfoque de inversión en programación con IA puede pasar de comprar modelos más potentes a diseñar procesos más sólidos: límites de tareas, ensamblaje de contexto, evaluación independiente, persistencia de estado, límites de presupuesto, puntos de revisión humana, y cómo detener el bucle cuando ocurren anomalías. La capacidad del modelo sigue siendo importante, pero solo es una parte del sistema.

Para los ingenieros, el rol también está cambiando. Antes, el trabajo central era escribir código; ahora, cada vez más trabajo se convierte en revisar las respuestas candidatas producidas por la máquina: si cumplen los requisitos, si rompen la arquitectura, si solo parecen razonables, si trasladan la complejidad a los futuros mantenedores.

Esto no significa que los programadores hayan sido reemplazados. Al contrario, la Ingeniería de Bucles es más como un amplificador de juicio. Puede permitir que un ingeniero realice la cantidad de cambios que antes requería un equipo pequeño, pero también puede amplificar la pereza, la credulidad y la falta de verificación hasta convertirlas en incidentes de producción.

La verdadera bifurcación está en si los humanos conservan un juicio y un poder de veto suficientemente fuertes. La IA puede enviar PRs continuamente, pero si se fusionan, si deben subir a producción y si a largo plazo hundirán el sistema, sigue dependiendo de las personas.

Haga clic para conocer las vacantes en BlockBeats

Bienvenido a unirse a la comunidad oficial de BlockBeats:

Grupo de suscripción de Telegram: https://t.me/theblockbeats

Grupo de discusión de Telegram: https://t.me/BlockBeats_App

Cuenta oficial de Twitter: https://twitter.com/BlockBeatsAsia