La irracional eficiencia de los bucles de agentes LLM y el uso de herramientas

• A partir de la experiencia de desarrollo de Sketch, un asistente de programación con IA, se destaca la implementación concisa de una estructura de bucle que combina LLM con uso de herramientas
• Con solo 9 líneas de código de bucle, modelos LLM recientes como Claude 3.7 Sonnet resuelven rápidamente problemas reales
• Incluso con una sola herramienta de propósito general como bash, se puede automatizar una parte considerable de las tareas repetitivas y complejas de los desarrolladores
• No solo para resolver problemas: al conectar herramientas adicionales se puede mejorar la calidad y la velocidad de iteración en edición de texto o tareas especializadas
• Cada vez se incorporan más bucles de agentes LLM personalizados a la automatización del trabajo diario de los desarrolladores

---

Introducción: experiencia de desarrollo y proyecto Sketch

• Philip Zelikow y sus colegas se sorprendieron por la alta eficiencia de una estructura simple de bucle de agente que combina LLM con uso de herramientas mientras desarrollaban Sketch, una herramienta de apoyo a la programación basada en IA
• La estructura central consiste en apenas 9 líneas de código de bucle, que envían al API del LLM el system prompt, el historial de conversación y el mensaje más reciente
• El LLM genera una salida y, si es necesario, devuelve tool_calls (solicitudes de llamada de herramientas)

Integración de LLM y uso de herramientas

• El "uso de herramientas (tool use)" significa que el LLM devuelve una salida que se ajusta a un esquema predefinido, y que mediante el system prompt y los prompts de descripción de herramientas se le permite acceder a herramientas de propósito general como bash
• Los LLM más recientes (por ejemplo, Claude 3.7 Sonnet) automatizan rápidamente una amplia variedad de problemas incluso con una sola herramienta de propósito general, y algunos pueden resolverse incluso en una sola ejecución ("one shot")
• Antes había que buscar y pegar comandos complejos de git y hacer merges manualmente, pero ahora basta con pedírselo a Sketch para resolverlo al instante
• Incluso múltiples errores de type check que aparecen tras cambiar tipos fueron resueltos automáticamente por Sketch por primera vez
• El bucle de agente funciona de manera continua y adaptativa: si una herramienta no está instalada, la instala automáticamente y también se ajusta a diferencias en opciones de comandos
• Durante el uso, a veces el LLM hace sugerencias inesperadas como "omitir las pruebas" cuando fallan los tests, pero en general la calidad de la automatización del trabajo ha mejorado

Diversificación y especialización de herramientas

• Sketch comprobó que usar herramientas adicionales además de bash (por ejemplo, herramientas de edición de texto) mejora la calidad del trabajo y hace más eficiente el flujo de trabajo de desarrollo
• Resulta más difícil de lo esperado que un LLM modifique texto con precisión usando sed y similares, y se percibe que las herramientas con enfoque de editor visual son superiores

Perspectivas futuras y cambios en el flujo de trabajo

• Se espera que la estructura de bucle de agente se use cada vez más para tareas repetitivas del día a día de los desarrolladores que antes eran difíciles de manejar con herramientas de automatización de propósito general
• Por ejemplo, en tareas molestas y repetitivas como analizar la correlación entre stack traces y commits de git, el LLM puede hacer rápidamente una primera pasada
• En el futuro, es razonable esperar que más bucles de agentes LLM personalizados y de un solo uso se utilicen desde el directorio bin/ y otros entornos de los desarrolladores
• Los usuarios solo necesitan preparar el bearer token que deseen para experimentar fácilmente en su propio entorno

Enlaces de referencia

• El contenido también fue publicado en el blog de philz.dev
• Se puede consultar más información del proyecto y temas relacionados en sketch.dev, merde.ai y pi.dev

[GN⁺]

Opinión de Hacker News

• Quiero recomendar mucho también esta entrada de blog. Es una versión que trata el mismo punto con mucho más detalle y de forma más convincente. El autor realmente construyó por sí mismo un agente de código desde cero. Ver https://ampcode.com/how-to-build-an-agent. Es una experiencia realmente sorprendente ver lo bien que un LLM puede manejar tareas muy diversas dentro de un loop donde puede invocar herramientas. Claro, no es perfecto, y hay problemas como no llegar al 100% de confiabilidad. Aun así, creo que al menos hay algo digno de admiración. Si lo pruebas tú mismo, puedes seguirlo en menos de 30 minutos. Es una parte del fenómeno que permite sentir asombro sin perder un escepticismo saludable sobre si la IA es efectiva para un uso específico. Esta "efectividad anormal" de poner un LLM dentro de un loop es la razón por la que ahora están saliendo tantos agentes de generación de código: Claude Code, Windsurf, Cursor, Cline, Copilot, Aider, Codex, etc., además de muchísimos proyectos que los replican. Es también la razón por la que no hay una receta secreta: el 95% de la magia al final está en el propio LLM y en que fue fine-tuned para hacer llamadas a herramientas. Es algo que el desarrollador principal de Claude Code reconoció con franqueza en una entrevista reciente. Claro, hace falta mucho trabajo para que estas herramientas funcionen bien, pero en el fondo casi todas comparten la misma estructura central simple
  • Llevaba muchísimo tiempo buscando un texto así, así que de verdad se agradece. Mucha gente ve los Agents y reacciona con algo como: "¿seguro que no podrán resolver problemas realmente complejos?", pero a mi parecer ese no es el punto central de los agentes. Los LLM funcionan muy bien con mucho contexto, y los agentes son una estructura en la que el LLM consigue más contexto para mejorar la calidad de sus respuestas
  • Mi experiencia es que no se me ocurren muchas tareas que un LLM pueda hacer bien por sí solo dentro de un loop durante más de unas cuantas vueltas sin instrucciones adicionales. Después de varias iteraciones, siempre termina apareciendo una situación donde tengo que intervenir
  • Hay un tutorial donde hicieron algo parecido usando una librería de abstracción de grafos llamada pocketflow. Lo probé y me gustó mucho porque en verdad es bastante simple. https://github.com/The-Pocket/PocketFlow-Tutorial-Cursor/blob/main/blog.md
  • Apenas ahora me di cuenta de que el autor es Thorsten Ball. Recuerdo haber leído con mucho gusto su "hacer un interpreter". Creo que ahora yo también voy a intentar hacer un agente
  • Antes de abrir el enlace de arriba, me puse a pensar si debía agregar ?utm_source=hn&utm_medium=browser
• Hoy intenté por primera vez hacer "vibe-coding" directamente con GPT-4o y 4.1. Era un flujo manual donde iba metiendo en loop errores de compilación, advertencias y sugerencias por medio de la interfaz de canvas. El archivo era pequeño, unas 150 líneas. Empecé con 4o, pero usó paquetes obsoletos. Incluso cuando se lo señalé, no actualizó todos los usos y tuve que corregirlo a mano. Luego sugerí un cambio de lógica y terminó destruyendo por completo la sintaxis, y ya nunca pudo recuperarse. Aunque seguía pegándole errores de compilación, no entendía el problema de sintaxis y solo arreglaba partes aleatorias del código. Entonces pensé que tal vez 4.1 lo haría mejor, pero 4.1 directamente se negó a usar el canvas y solo me dio explicaciones. Era del estilo de "hazlo tú mismo". Después de insistir bastante, por fin soltó código en el canvas, pero esta vez era una versión recortada con cosas como "// omitted for brevity", así que no servía. Ahí me rendí. Me pregunto si los agentes resuelven este problema. Por ahora, mi impresión es que esta experiencia está completamente rota, y en ese estado me preocupa muchísimo darles acceso a bash
  • El hecho de que "usara paquetes obsoletos" se debe a que el corte temporal de los datos de entrenamiento del modelo quedó atrás. Es algo a lo que siempre hay que prestar atención al usar LLM. En ChatGPT he estado cambiando bastante a o4-mini-high. Ese modelo puede encontrar documentación reciente con la función de búsqueda. Si le pides "consulta la versión más reciente de la librería X y úsala", a menudo lo resuelve bien. Hace poco tuve una tarea para convertir parte de un código JavaScript a las librerías recomendadas más recientes por Google, y al pegar el código anterior y pedirle que lo portara a la nueva librería, buscó la documentación y lo hizo correctamente. https://simonwillison.net/2025/Apr/21/ai-assisted-search/#lazily-porting-code-to-a-new-library-version-via-search
  • GPT 4.1 y 4o sacan puntajes muy bajos en el benchmark de programación de Aider. En experiencia de uso real, el resultado empieza a ser útil cuando anda por encima del 70%. Aun así, para cosas complejas hace falta bastante apoyo. Con el uso uno va agarrando intuición sobre qué funciona y qué no. https://aider.chat/docs/leaderboards/
  • Puede molestar escuchar lo de "skill issue", pero usar LLM definitivamente es un campo que requiere una habilidad aparte. Entender las fortalezas y debilidades de distintas herramientas, experimentar con varias técnicas y practicar son partes esenciales. Si yo les diera acceso a bash, igual lo usaría solo dentro de un entorno de contenedores (docker)
  • Eso no se puede llamar vibe coding. Para hacer vibe coding necesitas una herramienta donde los cambios al código se apliquen automáticamente. Si vas dando feedback manual uno por uno, te quedas atorado con los errores. La esencia del vibe coding es poder deshacer, volver a ejecutar y probar o descartar distintas soluciones con facilidad. Para vivir esa experiencia hace falta tooling
  • Hace poco construí en VSCode, con el plugin de Cline y Claude, un prototipo de app Android "desde cero". Empecé desde la plantilla base que da Android Studio, y generó miles de líneas de código sin un solo error de compilación. La app funcionó tal como esperaba, y los pocos bugs que aparecieron no eran culpa del LLM sino de comportamientos rarísimos de la API de Android. Le señalé los bugs al LLM y le pasé salida de mensajes de depuración, y los corrigió por su cuenta. Al principio las correcciones fueron algo torpes, pero tras unas cuantas rondas de feedback terminó resolviéndolo bien. Si pones en loop un agente que escriba código y otro que lo revise, da la impresión de que esto también podría manejarse mejor de forma más general
• He estado usando Claude Code, es decir, la interfaz de terminal de Sonnet 3.7, desde el día de su lanzamiento. He escrito una app CLI bastante grande, un sistema web full-stack y muchísimas utilidades. Igual que cuando antes lideraba equipos de programación, me he animado a intentar retos mucho más ambiciosos. En términos de estructura probablemente no sea tan distinto de otras herramientas, pero siento que Anthropic añadió muchas funciones tremendamente útiles. Nada es perfecto, y para obtener buena calidad de código todavía hace falta un esfuerzo parecido al de antes. Incluso cosas bastante complejas llegan a funcionar, aunque a veces luego se vuelve difícil agregar la siguiente funcionalidad. A medida que me fui acostumbrando a usarlo, el proceso de refactorización y ajustes se redujo muchísimo. No es una estructura de trabajo que vaya a desaparecer por completo. Me cuesta honestamente imaginar los problemas que describe kgeist. Claude a veces también toma decisiones distintas a las mías o actúa de forma tonta, pero nunca al punto de querer abandonarlo. Casi siempre entrega resultados bastante buenos, y es enorme cuánto trabajo mental me quita de encima. Además, refactoriza increíblemente bien. Si reviso el código de forma periódica y le pido a Claude que me explique maneras mejores de hacerlo, la complejidad baja muchísimo. Incluso peticiones como "cambia la estructura de datos" las resuelve de inmediato. Es una función muy impresionante. Y por diversión abrí un directorio de archivo con 30 años de desorden no relacionado con código. Preguntas como "¿qué hay en este directorio?", "lee mi currículum viejo y reescríbelo", "¿cómo se llaman mis hijos?" y cosas así fueron realmente sorprendentes. Aun estando en una fase temprana, me tiene muy feliz
  • Hace poco tuve una situación en la que había que resolver de una sola vez la definición de estructuras de datos remotas, la especificación de la API, la implementación de parseo y almacenamiento, y la presentación al usuario. Claude manejó todo eso bien al mismo tiempo, y pude ver de inmediato cómo pequeños cambios en ambos extremos afectaban la capa intermedia. Fui iterando distintas ideas con rapidez hasta encontrar la mejor solución. Me sorprendió poder explorar varias capas de alta complejidad a gran velocidad de iteración, y además de mejorar la productividad, eso también elevó mi comprensión estructural de todo el sistema
  • La refactorización mencionada arriba de verdad es una tarea muy placentera. Funciones que antes era difícil siquiera meter en un sprint ahora se resuelven en 5 minutos. Se siente como si hubiera un equipo listo esperando mis instrucciones en cualquier momento. Si no me gusta el resultado, puedo rechazarlo al instante, y parece que desaparecen también las revisiones innecesarias y la preocupación por calendarios
• Me desespera mucho cuando el LLM a veces dice algo como: "ah, esta prueba no pasa... mejor la saltamos". Aquí hay una idea interesante. Correr junto al LLM principal otro LLM independiente y en paralelo que haga cumplir políticas para que el principal actúe según las instrucciones. Por ejemplo, el LLM auxiliar podría manipular la probabilidad de salida para que después de "let's just" no pueda aparecer la palabra "skip". Es decir, si prohíbes "skip", puedes redirigir al LLM fuera de un comportamiento no deseado. Funcionaría un poco como el modo JSON o la salida estructurada, pero con un LLM auxiliar controlando la política de forma dinámica y en tiempo real. Si esto funcionara bien, podría ampliarse para incluir en el prompt del auxiliar toda clase de violaciones de política, como borrar código de pruebas para hacerlas pasar o generar comentarios inútiles, y que ese LLM secundario supervise y controle todo en tiempo real. Me pregunto qué opinaría el equipo de Outlines sobre una arquitectura así
  • Si un LLM puede revisar la salida de otro LLM, uno se pregunta si un LLM de "mixture of experts" podría asignar uno de sus algoritmos especializados a vigilar y auditar a otro. O quizá separar un hilo de razonamiento para que verifique su propia salida, o incluso, si hiciera falta, poner otro hilo adicional que verifique también a ese verificador para reforzar todavía más el sistema
  • En este contexto también se puede imaginar una estructura donde, si el LLM principal empieza a irse en mala dirección, el LLM supervisor "rebobine" el modelo hasta ese punto; por ejemplo, si detecta "let's just skip the test", hacer rollback después de "just " y seguir aplicando bias para impedir ciertas palabras. Para hacer algo así, el proveedor del modelo que uses podría ser muy limitante, y OpenAI en particular últimamente parece bastante hostil a este tipo de funciones avanzadas para usuarios power
• Hoy en la mañana usé cursor para extraer una parte compleja del loop principal de un prototipo de juego y generar automáticamente un conjunto de pruebas para esa parte. En total fueron 341 pruebas que cubren toda la matemática central y los componentes clave. A veces se siente como arrear gatos, pero mientras más restricciones concretas le doy —qué funciones usar, en qué lugar, archivos plantilla, qué evitar— mejor va saliendo el resultado. Terminé con 3500 líneas de código de pruebas que no tuve que escribir yo, y si algo sale mal siempre puedo borrarlas y regenerarlas. También me ha ayudado muchísimo con cosas como ajustar la curva de dificultad y variaciones de misiones
  • En mi experiencia, la generación automática de pruebas es el mejor caso de uso de los LLM. Elimina de un golpe horas o días de trabajo tedioso y repetitivo. Además cubre automáticamente muchos edge cases que quizá yo no habría imaginado, y hasta aumenta la seguridad del código. Es una función excelente en muchos sentidos
• Últimamente me tiene muy emocionado la capacidad de los LLM para usar herramientas. En realidad este truco no es nuevo; lo vi por primera vez hace 2 años en el paper de ReAcT. Después se usó en los plugins de ChatGPT, MCP y demás, y ahora la mayoría de los modelos se entrenan pensando en tool calls o function calling. Lo interesante hoy es cuánto mejoró el rendimiento. El excelente desempeño de búsqueda de o3/o4-mini también se basa en esa capacidad de tool calling. Qwen3 4B (Ollama 2.6GB, corre bien incluso en Mac) también lo hace bien. Ayer di un workshop en PyCon US sobre cómo construir software basado en LLM, y a raíz de eso añadí funcionalidad de uso de herramientas a mi herramienta de línea de comandos para LLM. Ver https://building-with-llms-pycon-2025.readthedocs.io/en/latest/tools.html. Ahora con mi paquete LLM ya puedo resolver de forma confiable cosas como "contar cuántas veces aparece la R en strawberry" con un one-liner de shell
  • Me encanta esa combinación extraña entre lo divertido y lo potente que da esta función
  • Me pregunto si grabaron el workshop
• Tengo curiosidad por saber qué agent consume más tokens. Cline parece estar arriba en la lista, y roo da la impresión de usar menos que cline. Quisiera saber si hay algún agent donde puedas configurar directamente el estilo de interacción, y cómo se compara Claude code frente a otros agents
• Lo inquietante es eso de "si no tiene la herramienta necesaria, la instala". El LLM es demasiado 'obediente' y está estructurado para ejecutar de inmediato en cuanto alguien se lo pide. Esto es una preocupación de seguridad todavía más grave que SQL injection
  • A veces me pregunto cuándo ocurrirá el primer desastre grande basado en agents. (Sobre todo por el ambiente del mercado de IA, donde todo está saliendo a toda velocidad.) Me preocupa que con el tiempo termine ocurriendo una catástrofe difícil de revertir
• Parece que el título está inspirado en el paper de Eugene Wigner "The Unreasonable Effectiveness of Mathematics in the Natural Sciences"
  • Ese paper puede ser el origen, pero yo diría que ya desde hace mucho es una expresión convertida en meme. https://scholar.google.com/scholar?q=unreasonable+effectiveness
  • Yo más bien pensé que el título venía del "Unreasonable Effectiveness of RNNs" de Karpathy en 2015. Aunque claro, también puede suponerse que Karpathy a su vez lo retomó del paper de Wigner. https://karpathy.github.io/2015/05/21/rnn-effectiveness/
  • Cada vez que veo un titular con "unreasonable effectiveness", casi siempre siento que no puedo estar muy de acuerdo con la conclusión del autor. Incluyendo el paper de Wigner. Ya me da una vibra tipo ley de Betteridge
• En nuestra empresa construimos herramientas para darle más contexto al chatbot de IA embebido en nuestro producto. Agregamos funciones como registros de actividad reciente, definición del objeto actual, búsqueda y exploración de artículos de ayuda, entre otras. Y aun después de varios meses, la calidad del chatbot sigue sorprendiéndonos. Si el chatbot responde algo mal, nuestro proceso es actualizar de forma más específica los artículos de ayuda relevantes