# Dale el error a tu agente de código y luego hazte a un lado La mayor diferencia entre un agente de código que es útil y uno que te saca de quicio casi nunca es el modelo. Es si cerraste el ciclo. Un agente que escribe código y se detiene está adivinando. Un agente que ejecuta el código, lee el error real e intenta de nuevo hasta que los tests pasan juega en otra liga: las tasas de corrección superan el 90% en un par de iteraciones. El agente solo puede arreglar lo que puede ver, así que lo de mayor impacto que puedes hacer es darle ojos. Aquí te explico exactamente cómo. - **Author:** Fedor Chishchin - **Published:** 2026-06-12 - **Tags:** methodology, agents - **Source:** https://fedorthinks.com/es/blog/give-your-agent-the-error --- Si has usado agentes de código, conoces las dos experiencias tan distintas. A veces el agente se siente como magia; otras veces te entrega con toda confianza código roto y terminas gastando más tiempo arreglándolo del que ahorraste. La gente asume que la diferencia es el modelo: uno más inteligente lo haría mejor. Casi nunca es el modelo. Es si el agente pudo _ver qué pasó cuando su código se ejecutó_. Este es el hábito de mayor impacto en la programación con agentes, y es casi vergonzosamente simple: **deja que el agente ejecute el código, muéstrale el error real y deja que lo intente de nuevo.** Cuando cierras ese ciclo, los números se mueven mucho. La investigación sobre la recuperación de errores en agentes encuentra que devolver el [stack trace fallido al contexto del agente y dejarlo iterar hasta que los tests pasen](https://dev.to/rileycraig14/20-most-impactful-ai-research-papers-right-now-curated-via-neural-search-5ab3) lleva las tasas de corrección a más del 90% en un par de intentos — y un sistema de autocorrección resolvió por su cuenta el [88% de toda una clase de errores en tiempo de ejecución](https://www.buildmvpfast.com/blog/debugging-ai-agents-production-error-recovery-self-healing-2026). El agente no se volvió más inteligente. Pudo mirar la falla. ## El agente solo puede arreglar lo que puede ver Aquí está toda la idea en una línea, de boca de quienes construyen estos flujos de trabajo: si el agente [no puede ver el error, no puede arreglarlo](https://kilo.ai/articles/beyond-autocomplete) — si no puede ver la salida del test, ni siquiera sabe que algo está roto. Un agente que escribe código y se detiene hace el equivalente a escribir un ensayo con los ojos cerrados y nunca releerlo. Por supuesto que se equivoca la mitad de las veces; no tiene retroalimentación. Un desarrollador humano no trabaja así. Escribes algo, lo ejecutas, lees el traceback, dices «ah, null en la línea 42» y lo arreglas. Ese ciclo de ejecutar-leer-arreglar es la mayor parte de lo que realmente es programar. Un agente que solo hace el primer paso —escribir— se está perdiendo la parte donde el trabajo queda correcto. Dale el ciclo y empieza a comportarse como un desarrollador en lugar de un autocompletado. ## Buena retroalimentación vs. ruido Un detalle que vale la pena hacer bien: no toda la retroalimentación de errores es igual. «Los tests fallaron» no le dice casi nada al agente. La versión específica y accionable — ["Expected 200, got 401" con el número de línea y el stack trace](https://kilo.ai/articles/beyond-autocomplete) — le dice exactamente qué perseguir. Las fallas vagas producen suposiciones vagas; las fallas precisas producen correcciones precisas. Así que cuando conectes el ciclo, pasa la salida _real_: el traceback completo, los números de línea, la aserción exacta que falló. No le resumas el error al agente — el detalle es la señal. ## Cómo hacerlo de verdad Esto no es teórico, y no necesitas nada sofisticado. Las buenas herramientas de agentes — Claude Code, Codex, Cursor y otras— ya pueden ejecutar tests, leer las fallas y arreglar en un solo ciclo. Tu trabajo es asegurarte de que lo hagan: - **Déjalo ejecutar, no solo escribir.** Dale al agente una forma de correr el código o los tests él mismo. Un agente sin forma de ejecutar nada está adivinando para siempre. - **Haz que los tests sean la meta, no una sugerencia.** «Haz que esto pase» es un objetivo contra el cual el agente puede verificar. Sin un test no hay nada sobre lo cual cerrar el ciclo — por eso [el propio «funciona» de un agente no vale nada](/blog/who-checks-the-checker) y un test que pasa sí. - **Dale la falla en bruto.** Stack trace completo, números de línea, la aserción que falló — no tu paráfrasis. - **Déjalo iterar, pero ponle un tope.** Unos pocos intentos hasta llegar a verde es el punto ideal; un ciclo sin límite solo quema tokens. Dos o tres rondas arreglan casi todo. - **Dile que verifique su propio trabajo.** Pon «corre los tests y confirma que pasan antes de terminar» en las instrucciones permanentes de tu proyecto, para que el agente deje de [cantar victoria antes de comprobar](/blog/agents-cant-finish-the-job). Esa es toda la receta: ejecutar, mostrar el error real, iterar hasta verde, parar. ## En resumen El instinto, cuando un agente escribe código malo, es echar mano de un modelo más grande. Por lo general la solución más barata y efectiva es dejar de hacerlo trabajar a ciegas. Un agente de código sin retroalimentación está adivinando; el mismo agente que puede correr su código y leer el error real está depurando — y depurar es de donde sale el código correcto. Es la misma lección que [la fiabilidad no viene de la inteligencia en bruto](/blog/smarter-but-not-more-reliable): lo que gana no es un cerebro más inteligente, es un ciclo cerrado. Así que antes de actualizar cualquier cosa, hazte la pregunta más simple: ¿puede mi agente ver qué pasa cuando su código se ejecuta? Si no, ese es tu bug, no el del modelo. Dale el error, déjalo iterar hasta que los tests estén en verde y luego hazte a un lado. Es la actualización más barata que jamás harás, y es la que convierte a un agente frustrante en uno útil.