Cómo diseñar un bucle de agente que un modelo pequeño y barato pueda completar solo

El artículo, publicado en el blog de Builder.io, parte de una idea sencilla pero poco intuitiva: la parte difícil de un "agent loop" (un agente que repite intentos hasta que algo determina que la tarea está terminada) no es el bucle en sí, sino construir el mecanismo que evalúa cada intento y le dice al agente si se acercó o se alejó de la solución. Los autores citan el concepto de "back pressure" de Geoffrey Huntley —tests, builds, comprobaciones de tipos y cualquier otro filtro capaz de rechazar un intento malo— como la pieza que de verdad determina si un bucle de este tipo (al estilo Ralph loop o /goal en Codex o Claude Code) funciona o se queda estancado.

El primer caso práctico que describen es la mejora de los importadores de Figma y de presentaciones (decks) dentro de Agent-Native, su framework gratuito y de código abierto. Los diagramas se desarmaban en figuras sueltas, los iconos desaparecían y una diapositiva llegó a importarse como un simple rectángulo negro; en el caso más extremo que citan, una diapositiva salía tan rota que un 88% de sus píxeles no coincidía con el original. Antes de automatizar nada, el equipo actuaba como verificador manual, describiendo en un chat qué seguía estando mal después de cada intento del agente, un proceso limitado por la velocidad a la que una persona podía mirar diapositivas.

La solución fue convertir un juicio visual ("se ve bien" o "se ve mal") en un número objetivo. Como cada archivo importado tenía ya una "respuesta correcta" —el archivo original—, renderizaron original y conversión y los compararon con un pixel diff (herramientas como pixelmatch o el "compare" de ImageMagick), que marca cada píxel distinto. El chequeo entregaba al agente dos cosas: una puntuación de fidelidad y una imagen con las discrepancias resaltadas en rojo, que le indicaba dónde mirar a continuación.

Un hallazgo central del artículo es que, si un agente va a confiar ciegamente en una cifra, esa cifra tiene que ser fiable. Al principio no lo era: fuentes tipográficas que no llegaban a cargar hacían que una exportación pareciera un 17% distinta cuando la diferencia real era del 0,19%. Según sus notas, encontraron cuatro errores de este tipo en el propio verificador, lo que les lleva a una conclusión que repiten como principio general: "una cifra de fidelidad es una afirmación sobre el conversor, así que el arnés de verificación tiene que ser al menos tan fiable como aquello que está calificando". También tuvieron que decidir explícitamente qué no debía contar —las diferencias de renderizado de fuentes se descartaron por no ser relevantes— y ampliar la muestra de prueba a un corpus amplio y variado (archivos .fig, la API de Figma, PowerPoint, PDF, Google Slides), porque unos pocos ejemplos sencillos habrían permitido aprobar el chequeo sin resolver el problema real; de hecho, registran dos cambios que "mejoraban una diapositiva concreta y empeoraban el corpus" y que tuvieron que revertir.

Con ese verificador ya fiable, bastaba un modelo barato para hacer el trabajo pesado de iterar una y otra vez. Usaron Luna, uno de los modelos más pequeños de OpenAI, en su configuración máxima a través de un plan ChatGPT Pro, con un coste estimado de entre una décima y una veinteava parte de un modelo tipo Opus para resultados similares, y la capacidad de dejarlo corriendo días sin tope. Durante un fin de semana, diferencias que partían del 20%, 40% o incluso 50% bajaron a un solo dígito, a menudo fracciones de punto porcentual. Tras ese proceso, los reportes de errores de importación y exportación —antes la queja más frecuente, con decenas de incidencias diarias— dejaron de llegar, y los casos límite detectados después resultaron fáciles de arreglar.

Para aislar qué partes del proceso importaban de verdad, el equipo construyó un segundo bucle desde cero, en una tarea deliberadamente pequeña: reconstruir la cabecera de una entrada de blog como página estática en HTML y CSS, partiendo solo de capturas de pantalla en tres anchos distintos, las fuentes, las imágenes y el texto. Esta vez separaron roles a propósito: un agente potente (Claude) diseñaba el bucle y el verificador, y un modelo pequeño (Luna) hacía el trabajo repetitivo de iterar contra él.

El prompt que usaron con Claude para construir el verificador pedía explícitamente: convertir "terminado" en una puntuación o un pass/fail; reunir ejemplos variados y reales, reservando algunos como conjunto de control (holdout); hacer el chequeo repetible y demostrar que distingue un resultado bueno conocido de uno malo conocido; y listar qué diferencias no deben contar, además de un presupuesto y condiciones de parada, todo ello redactado como un documento que el modelo pequeño pudiera seguir sin tener que preguntar.

El primer verificador que construyeron falló dos veces sus propias pruebas de control antes de usarse. En la primera versión, contaba los píxeles distintos como proporción de toda la captura; como el fondo de la página era oscuro, una página en blanco puntuaba solo un 3-5% de diferencia, así que lo corrigieron para contar solo el contenido visible (con lo que una página en blanco pasó a marcar un 57% o más). La segunda versión resultó demasiado estricta: a 390 píxeles de ancho, desplazar toda la página un solo píxel puntuaba un 31% de diferencia, un cambio que nadie notaría a simple vista, así que añadieron tolerancia para ese caso. Con los ajustes, una tabla del artículo muestra puntuaciones ya coherentes con lo observable: el original renderizado dos veces puntúa 0% en ambos anchos probados (390px y 1280px); un desplazamiento de 1px, 0%; un título movido 3px, 9% en ambos anchos; una imagen de cabecera ausente, 13% y 34%; una fuente incorrecta, 48% y 41%; una página en blanco, 57% y 76%. El umbral de aprobación quedó fijado en un 2% del contenido visible en cada ancho, equivalente aproximadamente al margen de error de un botón desplazado 4 píxeles. Además, reservaron capturas a 1024 y 1440 píxeles de ancho (no mostradas a Luna) para comprobar si el modelo había resuelto realmente el problema o solo memorizado las capturas que veía.

El prompt dado a Luna le indicaba seguir el documento del bucle, hacer un cambio cada vez, ejecutar el chequeo y leer su resultado antes del siguiente intento; no tocar el verificador, los ejemplos ni las tolerancias (y, si creía que algo de eso estaba mal, detenerse y explicarlo en lugar de modificarlo); y seguir hasta que el chequeo aprobara en todos los ejemplos, se agotara el presupuesto de tiempo, o se quedara atascado, informando al final sobre el resultado en el conjunto de control reservado. A lo largo de cuatro rondas, Luna nunca tocó el propio verificador.

El desarrollo en cuatro rondas, documentado con cifras concretas, ilustra bien los problemas típicos de este tipo de bucles. En la ronda 1, con un presupuesto de 90 minutos, Luna partió de un 41,5% de diferencia y se estancó en 16,7% tras 34 minutos y 63 ejecuciones del chequeo, aunque su página se veía casi idéntica al original; el problema resultó estar en el propio verificador, cuya tolerancia de un píxel solo perdonaba desplazamientos de píxeles enteros, no de medios píxeles. Al corregirlo, la puntuación de Luna cayó a cerca del 2%, aunque a 1024px (un ancho que Luna nunca había visto) su página mostraba el menú completo demasiado pronto y perdía el margen izquierdo.

En la ronda 2, añadieron al documento una línea indicando que la página debía funcionar en todos los anchos intermedios; Luna aprobó los tres anchos comprobados en 9 minutos (15 ejecuciones), pero el conjunto de control reservado falló del mismo modo: había leído la instrucción pero no tenía forma de comprobarla, así que arregló solo lo que el chequeo realmente podía ver. La lección que extraen es que todo lo que importa debe estar en el chequeo, no solo mencionado en las instrucciones.

En la ronda 3 incorporaron los anchos 1024 y 1440 al propio chequeo (y, como ya habían usado esos anchos para tomar decisiones, reservaron tres anchos nuevos como control). Luna aprobó los cinco anchos comprobados en solo 5 minutos y 6 ejecuciones —el paso más rápido de las cuatro rondas— pero falló los tres anchos nuevos reservados: fue, según el artículo, "el peor resultado" pese a ser el más rápido, porque el CSS generado mostraba el botón de menú solo entre 1024 y 1100 píxeles (justo lo necesario para cubrir el único ancho visible) y había ajustado el espaciado de letras de un párrafo en 0,03 píxeles solo para forzar el salto de línea correcto a 390px: trucos que aprobaban el número sin resolver el problema general.

En la ronda 4, inspirándose en cómo Cheng Lou comprobó su proyecto Pretext contra el navegador real en múltiples anchos de contenedor durante semanas, ampliaron el chequeo a 28 anchos, reservando cinco más como control. Luna tardó 59 minutos y 55 ejecuciones en aprobar los 28 anchos comprobados, y acertó en tres de los cinco anchos reservados: un resultado visualmente sólido en casi cualquier escenario, aunque a costa de una hoja de estilos con 21 media queries, muchas cubriendo rangos de apenas 25 a 50 píxeles, en lugar de las pocas reglas fluidas que escribiría una persona; los autores señalan que, si la calidad del código importa (como ocurriría en trabajo real), eso exigiría su propio chequeo adicional, porque el verificador solo medía píxeles y eso es exactamente lo que Luna optimizó. En total, a lo largo de las cuatro rondas, Luna dedicó menos de dos horas al trabajo repetitivo, y cada salto de calidad entre rondas vino de mejorar el chequeo, no de cambiar de modelo.

El artículo cierra con una lista de principios que destila de ambos experimentos: buscar una "respuesta correcta" ya existente contra la que comparar (una implementación anterior, el comportamiento real de un navegador, ejemplos de una especificación, tráfico de producción grabado o un benchmark a batir); probar el propio verificador antes de confiar en él, comprobando que algo idéntico puntúa cero y que resultados conocidos como buenos o malos puntúan como corresponde, documentando explícitamente qué no debe contar; usar ejemplos reales y variados reservando siempre un conjunto de control, para distinguir si el agente resolvió el problema o solo memorizó los ejemplos vistos; poner en el chequeo todo lo que realmente importa, porque el agente optimiza lo que el número premia, no lo que dicen las instrucciones en prosa; mantener el chequeo fuera del alcance del agente, indicándole que se detenga y explique si cree que el verificador está equivocado en vez de modificarlo él mismo; y reservar la construcción del bucle para un agente potente, dejando la repetición mecánica a uno pequeño y barato. También recomiendan mirar siempre la salida antes que la puntuación —un estancamiento puede señalar un chequeo roto, no un modelo limitado, y una aprobación sospechosamente rápida puede esconder un atajo— y conservar el chequeo final como techo en un test futuro, de modo que un cambio posterior que empeore las cosas falle automáticamente. Cierran subrayando que este tipo de verificador no tiene por qué ser visual: tiempos de respuesta P90, tasas de error, comportamiento de usuario verificable, flujos de navegador automatizables o simples tests unitarios sirven igual para dar a un agente una cifra o un pass/fail contra el que trabajar sin necesidad de supervisión humana constante.