Deja de Dar Prompts a tu Agente de Codificación. Crea el Bucle que los Genera en su Lugar

Ya no deberías estar solicitando a los agentes de codificación. Deberías estar diseñando bucles que soliciten a tus agentes. Suena como una frase trivial, pero apunta al cambio más grande en cómo los buenos ingenieros trabajan con la IA en este momento. Las personas que están obteniendo un verdadero provecho de los agentes de codificación de IA dejaron de tratar al agente como un compañero de chat. Lo tratan como un trabajador dentro de un bucle que ellos construyeron.

En resumen

Un bucle de agente de codificación es una estructura de control que ejecuta un agente repetidamente: genera un cambio, lo ejecuta, verifica el resultado contra una señal estricta, retroalimenta el fallo y repite hasta que la verificación pasa o se alcanza un límite. El agente no es la parte difícil. La puerta de verificación sí lo es. Un bucle con una puerta vaga («se ve bien, inténtalo de nuevo») se desvía y alucina un «hecho». Un bucle con una puerta determinista (una prueba fallida, una falta de coincidencia de esquema, un contrato roto) converge. Para el trabajo de API y backend, tu suite de pruebas automatizadas y las verificaciones de contrato son esa puerta, por lo que las pruebas de API pertenecen al centro de un flujo de trabajo agéntico, no añadidas al final.

De solicitar a diseñar bucles

La mayoría de las personas se encuentran con la codificación de IA a través de un cuadro de chat. Escribes una solicitud, lees la respuesta, copias lo que funciona y vuelves a escribir. Eso es solicitar. Está bien para una función puntual o una explicación rápida. Se desmorona en el momento en que la tarea requiere más de una ronda de retroalimentación para hacerse correctamente, lo cual es la mayoría del trabajo real.

Aquí está el problema con solicitar manualmente. Tú eres el bucle. Lees la salida, detectas el error, decides qué decir a continuación, pegas el error de nuevo. Cada iteración espera a un humano. El agente puede generar código en segundos, luego permanece inactivo durante minutos mientras cambias de contexto, te desplazas y escribes. Te conviertes en la parte lenta de un sistema rápido.

Diseñar un bucle invierte eso. En lugar de ser lo que lee la salida y decide la siguiente solicitud, construyes un arnés que lo hace automáticamente. El agente escribe código. Un script lo ejecuta. El resultado se captura. Si falla, el fallo vuelve directamente al agente como la siguiente solicitud. No hay humanos en el bucle interno. Intervienes solo en los extremos: para establecer la tarea, para aprobar el resultado, para detener la ejecución si se desvía. El propio artículo de Anthropic sobre la construcción de agentes efectivos señala lo mismo con otras palabras. La victoria proviene del entorno que conectas alrededor del modelo, no de una única solicitud más inteligente.

El cambio de modelo mental es pequeño pero total. Deja de preguntar «¿qué le debo decir al agente?» Empieza a preguntar «¿qué bucle haría que el agente se lo dijera a sí mismo?»

Qué es realmente un bucle de agente de codificación

Quitando el bombo, un bucle de agente de codificación tiene cinco partes. Si falta una, el bucle nunca termina o termina mal.

1. Una especificación de tarea. Una descripción clara y escrita de lo que significa «hecho». No «haz que funcione», sino «el endpoint POST /orders devuelve 201 con el pedido creado, valida el cuerpo contra el esquema y rechaza campos faltantes con 422».
2. El agente. El modelo más sus herramientas: leer archivos, escribir archivos, ejecutar comandos de shell. Esta es la parte en la que todo el mundo se obsesiona y la que menos controlas.
3. Un paso de acción. El agente realiza un cambio, luego algo lo ejecuta. Pruebas, una compilación, una verificación de tipos, una solicitud contra un endpoint en vivo.
4. Una puerta de verificación. Una verificación determinista que devuelve éxito o fallo con una razón concreta. Este es el volante. Pasaremos la mayor parte de esta publicación aquí.
5. Una condición de terminación. ¿Cuándo se detiene el bucle? La puerta pasa, o alcanzas un recuento máximo de iteraciones, o superas un presupuesto de costos. Un bucle sin salida es un proceso descontrolado, no un flujo de trabajo.

En pseudocódigo, el patrón completo cabe en unas pocas líneas:

task = load_spec("orders-endpoint.md")
for attempt in range(MAX_ITERATIONS):
    agent.run(task, feedback=last_result)   # generar
    result = run_verification()             # ejecutar + verificar la puerta
    if result.passed:
        break                               # terminar: éxito
    last_result = result.failures           # retroalimentar el fallo
else:
    escalate_to_human(last_result)          # terminar: rendirse

Ese bucle es la idea completa. El agente genera, la puerta juzga, el fallo se convierte en la siguiente solicitud, y todo el proceso se ejecuta hasta que esté en verde o se agoten los intentos. La variante que la gente comparte en línea como la técnica «Ralph» es esta con `MAX_ITERATIONS` establecido alto y la especificación escrita de forma concisa. Si has leído nuestro análisis de la arquitectura del arnés del agente, este es el arnés en su forma más pequeña y honesta.

Por qué la solicitud de una sola vez choca con un muro

Una sola solicitud asume que el modelo lo hace bien la primera vez, o que detectarás lo que hizo mal. Ambas suposiciones fallan a escala.

Los modelos son fuertes generando código plausible y débiles sabiendo si ese código es correcto. Escribirán un endpoint que parece correcto, compila y devuelve silenciosamente el código de estado incorrecto en un caso límite. En un chat, quizás no lo notes hasta que lo haga la producción. El modelo no tiene retroalimentación que le diga que el caso límite falló, por lo que informa con confianza que tuvo éxito. Esa brecha entre «parece hecho» y «está hecho» es exactamente donde los bucles demuestran su valía.

Un bucle cierra la brecha negándose a aceptar la propia opinión del modelo sobre su trabajo. El agente no puede decir que ha terminado. La puerta lo dice. Ejecuta las pruebas; si están en rojo, la tarea no está hecha, punto final, y la salida en rojo es lo siguiente que lee el agente. La confianza del modelo deja de importar. Solo importa la señal.

También hay un ángulo de productividad. La solicitud manual limita tu rendimiento a un agente que estás observando activamente. Los bucles te permiten ejecutar varios a la vez, cada uno trabajando en su propia tarea contra su propia puerta, porque ninguno de ellos te necesita en el ciclo interno. Ese es el salto al que se refiere nuestro artículo sobre flujos de trabajo de agente dinámicos y paralelos: una vez que el bucle está automatizado, escalas añadiendo bucles, no escribiendo más rápido.

La parte que todos subestiman: la puerta de verificación

Aquí está la incómoda verdad. La mayoría de los flujos de trabajo de agentes fallidos no fallan porque el modelo fuera demasiado débil. Fallan porque la señal de retroalimentación era demasiado blanda.

Piensa en lo que hace la puerta. En cada iteración, le dice al agente una de dos cosas: pasaste, detente; o fallaste, aquí está la razón exacta. La calidad de «aquí está la razón exacta» determina si la siguiente iteración mejora o divaga. Alimenta al agente con un rastreo de pila preciso que apunte a la línea 42 y a la aserción que explotó, y corregirá lo correcto. Dale «algo parece raro, por favor, revísalo», y adivinará, a menudo empeorando el código mientras suena más confiado.

Las puertas deterministas convergen. Las puertas difusas se desvían. Ese es todo el juego.

¿Qué hace una buena puerta?

• Es binaria y reproducible. Misma entrada, mismo veredicto, siempre. Nada de «depende de cómo se sienta el modelo hoy».
• Falla ruidosamente con una razón. Un nombre de prueba, una diferencia esperado-vs-actual, un número de línea, un código de error. La razón es la siguiente solicitud, por lo que debe ser específica.
• El agente no puede editarla silenciosamente. Si el agente puede cambiar la prueba para que pase, la puerta es teatro. Protege la puerta. Trátala como la especificación, no como código que el agente posee.
• Se ejecuta lo suficientemente rápido para un bucle. Una puerta que tarda 20 minutos limita tu velocidad de iteración. Los bucles ajustados necesitan verificaciones rápidas.

Las buenas puertas ya existen en cada base de código madura. Pruebas unitarias. Verificadores de tipos. Linters. Compiladores. Validadores de esquemas. Pruebas de contrato. Estos son oráculos deterministas. Fueron construidos para decir a los humanos «esto está mal y aquí está el porqué», que es precisamente la señal que necesita un bucle de agente. No tienes que inventar la puerta. Tienes que apuntar el bucle a las puertas en las que ya confías y escribir nuevas donde la cobertura sea escasa. Si nunca has formalizado esa capa, nuestra guía sobre qué son realmente las pruebas automatizadas es una buena base antes de conectarla a un bucle.

Para el trabajo de API y backend, tu suite de pruebas es el bucle

Aquí es donde la idea abstracta se vuelve concreta para cualquiera que construya servicios. Cuando un agente escribe un endpoint de API, ¿cuál es la verdad fundamental que dice que funciona? No el resumen del modelo. El comportamiento real del endpoint bajo prueba: códigos de estado correctos, cuerpo de respuesta que coincide con el esquema, autenticación impuesta, entrada inválida rechazada, el contrato respetado.

Cada uno de ellos es verificable, automáticamente, con un resultado determinista. Lo que significa que tu suite de pruebas de API ya tiene exactamente la forma de la puerta de verificación que necesita un bucle de agente. Estuviste construyendo la puerta todo el tiempo; solo lo llamaste pruebas.

Un bucle concreto para el trabajo de endpoints se ve así:

1. El agente lee la especificación de la tarea y la definición de OpenAPI, luego escribe o edita el endpoint.
2. El arnés ejecuta la suite de pruebas de API contra el servicio en ejecución: aserciones de estado, validación de esquema JSON en cada respuesta, verificaciones de contrato contra la especificación.
3. Los fallos regresan estructurados. «Se esperaba 422 en `customer_id` faltante, se obtuvo 500.» «El campo de respuesta `total` es una cadena, el esquema dice número.» «El endpoint `/orders/{id}` en la especificación no tiene implementación.»
4. Ese fallo estructurado se convierte en la siguiente solicitud del agente. Corrige la brecha específica.
5. Repite hasta que la suite esté en verde, luego pasa a un humano para revisión.

La clave es que la retroalimentación en el paso 3 es precisa y generada por máquina, no una sensación. Eso es lo que mantiene el bucle convergiendo en lugar de divagando. Las pruebas de contrato y esquema-primero importan más que nunca aquí, porque la especificación OpenAPI se convierte en la fuente compartida de verdad de la que leen tanto el agente como la puerta. La desviación entre el código y la especificación deja de ser un problema de documentación lento y se convierte en una puerta roja instantánea.

Este es el papel que Apidog desempeña en un flujo de trabajo agéntico. Es una plataforma de API todo en uno donde el diseño, el esquema, el servidor simulado y las pruebas automatizadas residen en un solo lugar, lo que significa que la puerta y la especificación permanecen sincronizadas por defecto. Apuntas el bucle a un escenario de prueba de Apidog, el agente obtiene un aprobado/fallo validado por esquema en cada iteración, y el servidor simulado sustituye las dependencias que aún no están construidas para que el agente pueda trabajar contra un objetivo estable. Los equipos que ya ejecutan este patrón conectan el acceso a herramientas del agente a través de algo como el depurador de agentes de IA de Apidog para que el agente pueda acceder e inspeccionar endpoints de la misma manera que lo haría un probador humano. Descarga Apidog si quieres construir la puerta visualmente en lugar de crear un ejecutor de pruebas manualmente.

Construye hoy mismo un bucle API autocorregible mínimo

No necesitas un framework para empezar. Necesitas una especificación, un comando de prueba y unas pocas líneas de código de conexión. Aquí tienes la versión más pequeña que realiza un trabajo real.

Paso 1: escribe la especificación como la intención de la puerta. Pon el contrato en un archivo OpenAPI y el comportamiento en casos de prueba. El agente lee ambos. Esto también sirve como documentación, así que no es trabajo desechable.

Paso 2: elige un comando de prueba que salga con un valor distinto de cero en caso de fallo. Cualquier cosa funciona siempre que el código de salida sea honesto. Una suite de pytest, una ejecución de Newman, un escenario de prueba de Apidog CLI. El bucle solo se preocupa por el aprobado/fallo más la salida capturada.

# la puerta, como un solo comando
apidog run ./tests/orders-suite --reporter json > result.json

Paso 3: conecta el bucle. Ejecuta el agente, ejecuta la puerta, ramifica según el resultado.

MAX_ITERATIONS = 8
feedback = None
for attempt in range(MAX_ITERATIONS):
    run_agent(task="implement orders API per spec", feedback=feedback) # implementar API de pedidos según la especificación
    gate = subprocess.run(["apidog", "run", "./tests/orders-suite",
                           "--reporter", "json"], capture_output=True)
    if gate.returncode == 0:
        print(f"green on attempt {attempt + 1}") # verde en el intento
        break
    feedback = parse_failures(gate.stdout)   # el siguiente prompt se escribe solo
else:
    print("8 attempts, still red; escalating to a human") # 8 intentos, todavía en rojo; escalando a un humano

Paso 4: protege la puerta. Mantén los archivos de prueba y la especificación fuera del conjunto de archivos que el agente puede editar. Si puede reescribir la prueba para que pase, has construido una máquina para falsificar el progreso.

Paso 5: limita el costo. Limita las iteraciones. Limita el gasto. Registra cada intento para que puedas ver si el bucle converge o se agita. Si estás observando el gasto de tokens, nuestras notas sobre cómo reducir los costos de tokens del agente se aplican directamente, porque un bucle que no converge quema el presupuesto rápidamente.

Ese es un bucle autocorregible que funciona. El agente escribe, la suite juzga, los fallos guían, y obtienes un endpoint en verde o una escalada limpia en lugar de una mentira confiada.

Diseñando buenos bucles: los errores que muerden

Algunos patrones separan los bucles que funcionan de los bucles que desperdician dinero en silencio.

• Dejar que el agente califique su propia tarea. Si la única verificación es «agente, ¿terminaste?», no tienes un bucle, tienes un chatbot con pasos adicionales. La puerta debe ser externa al agente.
• Una puerta demasiado tosca. «Las pruebas pasan» con tres pruebas superficiales significa que el agente satisface tres pruebas y envía errores en todo lo no cubierto. La calidad del bucle está limitada por la cobertura de la puerta. Pruebas escasas, resultados escasos.
• Sin guardia de terminación. Los bucles sin un recuento máximo de iteraciones y un límite de costos pueden ejecutarse indefinidamente en una tarea que el modelo no puede resolver. Siempre establece una salida y siempre escala a un humano cuando falla.
• Puertas lentas. Una suite de integración de 15 minutos es una buena verificación nocturna y un bucle interno terrible. Mantén una puerta rápida para el bucle y una puerta exhaustiva para la fusión. Simula dependencias externas para que el bucle no espere a un tercero inestable.
• Especificaciones mutables. Si el agente edita el archivo OpenAPI para que coincida con su código con errores, la prueba de contrato pasa por la razón equivocada. La especificación es la constitución. El agente trabaja bajo ella, no sobre ella.
• Una tarea gigante. Un bucle que mastica «construir todo el servicio» rara vez converge. Descompón en tareas del tamaño de un endpoint, cada una con su propia puerta. Los bucles pequeños terminan; los grandes se agitan.

La mayoría de estos se reducen a la misma disciplina: invierte en la señal, no en la solicitud. Los patrones de conexión y los modos de fallo aquí coinciden con lo que cubrimos en la conexión de herramientas en el flujo de trabajo agéntico, y son válidos ya sea que tu agente sea Claude Code, Cursor, Codex o algo que hayas construido tú mismo.

Hacia dónde se dirige esto

La frase «deja de solicitar, empieza a hacer bucles» es una instantánea de una tendencia más larga. La habilidad que se está volviendo valiosa no es la creación de solicitudes (prompt-craft). Es la creación de bucles (loop-craft): escribir especificaciones claras, construir puertas deterministas, elegir condiciones de terminación y decidir qué puede y qué no puede tocar el agente. Eso está más cerca del diseño de sistemas que de la ingeniería de solicitudes, y recompensa a los ingenieros que ya piensan en términos de pruebas, contratos y CI.

También cambia el valor de una buena infraestructura de pruebas. Durante años, las pruebas automatizadas fueron un seguro que esperabas no necesitar nunca. En un flujo de trabajo agéntico, se convierten en el mecanismo de dirección, lo que convierte un generador rápido pero poco fiable en un sistema que converge en lo correcto. Los equipos que ya tienen una sólida cobertura de pruebas automatizadas y contratos limpios son los que conectan agentes y obtienen un apalancamiento inmediato. Los equipos sin ella obtienen una forma rápida de generar código confiado y no probado.

Así que el movimiento práctico no es perseguir un modelo mejor o una solicitud más inteligente. Es construir la puerta. Ajusta tus especificaciones. Haz que tus pruebas de API sean deterministas y rápidas. Mantén tu esquema como la fuente de verdad. Luego envuelve un bucle alrededor y deja que el agente dé vueltas hasta que la puerta se ponga verde.

La conclusión

El cambio es fácil de expresar y difícil de interiorizar. No te mejores pidiendo a tu agente de codificación. Mejora en el diseño del bucle que lo solicita y en la señal de retroalimentación sobre la que se ejecuta ese bucle. El agente es un generador rápido sin un sentido fiable de si está en lo correcto. El bucle, a través de una puerta determinista, proporciona ese sentido. Para cualquiera que construya APIs, ya posees la puerta. Tu suite de pruebas, tu esquema y tus contratos son la verdad fundamental que convierte un generador ansioso en un sistema que converge en lo correcto.

Empieza pequeño. Escribe una especificación concisa, apunta un bucle a una suite de pruebas de API rápida, protege la puerta, limita las iteraciones y observa cómo un agente convierte un endpoint en rojo a verde sin ti en el bucle interno. Luego construye el siguiente bucle. Si quieres que la puerta sea visual, consciente del esquema y compartible entre tu equipo, Apidog te ofrece el diseño, la simulación y las pruebas automatizadas en un solo espacio de trabajo; descárgalo y haz que tus pruebas sean lo que impulse a tus agentes.