En pocas palabras: Un agente IA de programación como Codex (OpenAI) no acierta de una: itera. Cuando Dan Luu le pidió bisectar commits para un bug de UI, primero tiró un commit imposible y varios errados; recién con feedback humano llegó al correcto.
Cuando un agente IA debuggea código, no te da la respuesta correcta de una: itera. El caso más claro lo contó Dan Luu, cuando le pidió a Codex bisectar commits para encontrar un bug de UI y el modelo primero le tiró un commit imposible, después uno o dos equivocados y recién con feedback llegó a uno plausible. Los agentes IA para programación funcionan así: prueban, se equivocan y se corrigen, pero necesitan un humano validando.
Un agente IA para programación es un modelo de lenguaje conectado a herramientas de desarrollo (terminal, tests, navegador, control de versiones) que recibe una tarea de código, intenta resolverla en varios pasos, ejecuta lo que escribe y ajusta según el resultado. Codex, de OpenAI, es uno de estos sistemas: no solo sugiere código, lo corre y produce evidencia. La clave es el ciclo, no la respuesta única.
En 30 segundos
- El agente itera, no acierta de una: en el caso de Dan Luu, Codex dio un commit fuera del rango de fechas (imposible) antes de acercarse al correcto.
- El loop agentico es el corazón: tarea, intento, validación, feedback, reintento. Sin ese ciclo cerrado, el agente solo alucina con confianza.
- Sí automatiza testing: Codex escribió tests en Playwright, los ejecutó contra el commit antes y después, y generó videos de la ejecución.
- La validación humana no es opcional: el developer detectó cada error del modelo y le pidió que probara sus hipótesis.
- Brillan en exploración exhaustiva (bisectar cientos de commits), pierden en bugs simples donde mirás el código y lo ves en 30 segundos.
¿Cómo se comportan los agentes IA cuando debuggean código?
Ponele que tenés un bug de interacción en la UI, de esos que no tienen test y ni siquiera estás seguro de cómo escribir uno. Eso le pasó a Dan Luu, que viene usando IA de forma intensiva desde fines de 2025. En lugar de romperse la cabeza a mano, le pidió a Codex que bisectara entre dos fechas para encontrar el commit que rompió todo.
La primera respuesta fue un desastre. Según el relato de Dan Luu en su blog, Codex le dijo que el commit culpable estaba después del rango de fechas que él mismo había definido. Eso es imposible por construcción. Es como pedirte que busques una carta en un mazo y que te contesten que está en otro mazo.
Le avisó que estaba mal. El agente respondió con otro commit, también claramente incorrecto. Otro aviso, otro intento. Recién ahí Codex ofreció un commit que al menos parecía razonable. ¿El patrón es preocupante o esperable? Las dos cosas. El modelo no tiene un mecanismo interno que le diga “esto que estoy afirmando es lógicamente imposible”, pero sí sabe reaccionar al feedback y reencauzarse. Ese ida y vuelta es lo que hace útil al agente, siempre que vos estés del otro lado marcando la cancha.
¿Qué son los loops agenticos en desarrollo?
Un loop agentico es un ciclo: el agente recibe una tarea, intenta resolverla, valida el resultado con alguna herramienta (un test, una compilación, un screenshot), y si falla usa ese resultado como nuevo contexto para reintentar. No es magia. Es prueba y error automatizado con memoria de corto plazo.
Ojo con confundir “agentico” con “autónomo”. Un sistema autónomo tomaría decisiones sin consultarte. Lo que muestra el caso de Codex es otra cosa: el agente avanza solo dentro de cada intento, pero la corrección de rumbo la mete el humano. Cuando Dan Luu le dijo “esto está mal”, ahí se cerró el loop. Sin ese input, el modelo se quedaba defendiendo su primer commit imposible con total soltura. Esto se conecta con lo que analizamos en cómo funcionan los modelos de razonamiento.
El tema es que el loop puede correr muchas veces sin que vos toques nada, y ahí está la potencia y el riesgo. Subís la tarea, el agente prueba una hipótesis, escribe un test, lo corre, lee el fallo, ajusta el test, vuelve a correr, arma un video, y todo eso pasa mientras vos tomás un café, hasta que volvés y tenés que decidir si lo que armó tiene sentido o es una construcción convincente pero falsa.
¿Cómo automatizan los agentes IA el testing y la bisección de commits?
Acá viene lo bueno. Cuando Dan Luu le pidió a Codex que probara o refutara su hipótesis del commit culpable, el agente no se quedó en palabras. Escribió código de test en Playwright, lo ejecutó contra el estado del repo antes y después del commit sospechoso, y afirmó haber confirmado que ese era el commit que rompía la funcionalidad.
Después Dan Luu subió la apuesta: pidió un video con el stack completo de desarrollo en un navegador normal, punta a punta. El agente dijo que no tenía permisos para eso (sí, en serio), pero ofreció una alternativa: grabar la ejecución del repro antes y después del commit en Playwright, con el código de test correspondiente. Y el video era convincente. Mostraba la feature funcionando bien antes del commit y fallando después.
Eso es lo interesante de la bisección automatizada: el agente no solo señala un commit, genera la evidencia visual y ejecutable de por qué ese commit es el culpable. Para un repo con cientos de commits entre dos fechas, hacer eso a mano es tedioso. El agente lo paraleliza con paciencia infinita. La contra es que “convincente” y “correcto” no son sinónimos, y esa distinción es todo el trabajo que te queda a vos.
¿Qué errores y alucinaciones cometen los agentes IA en debugging?
La alucinación estrella del caso Dan Luu fue el commit “fuera del rango”. No es un error menor de precisión, es una imposibilidad lógica que el modelo presentó con la misma confianza que una respuesta correcta. Ese es el problema de fondo: los agentes no calibran bien su propia certeza.
¿Por qué pasa? Un modelo de lenguaje genera la continuación más probable dado el contexto, no la verdad verificada. Si el patrón estadístico dice “acá va un hash de commit”, te devuelve uno, aunque no cierre con la restricción que vos pusiste. La confianza del texto no refleja confianza en el hecho. En capacidades de Claude para agentes profundizamos sobre esto.
Lo que salvó la situación fue la validación multimodal dentro del loop. El agente se corrigió porque hubo feedback y porque terminó anclando su hipótesis a algo ejecutable (el test y el video), no a pura prosa. Cuando el modelo pasa de “yo creo que es este commit” a “corrí este test y grabé esto”, el margen de alucinación se achica. No desaparece, pero se achica. Si Codex hubiera falsificado silenciosamente el test para que diera lo que él afirmaba, ahí sí estabas en problemas, y por eso el ojo humano sigue siendo el último filtro.
¿Cuándo debuggear manualmente es más rápido que con agentes?
No todo bug justifica largar un agente. Depende de la complejidad y de cuánto contexto ambiguo haya. Esta comparativa es cualitativa, basada en el tipo de tarea, no en un benchmark de laboratorio.
| Criterio | Debugging manual | Debugging con agente IA |
|---|---|---|
| Bug simple (typo, off-by-one) | Segundos a minutos, lo ves a ojo | Overkill, tarda más en armar el loop |
| Bisect de cientos de commits | Horas, tedioso y propenso a error humano | Fuerte: paraleliza y no se aburre |
| Bug de UI sin test previo | Difícil escribir el repro a mano | Puede generar test en Playwright y video |
| Precisión de la primera respuesta | Alta si conocés el código | Baja, requiere varias iteraciones y feedback |
| Iteraciones necesarias | Pocas, pero cada una cuesta atención tuya | Muchas, pero corren sin tu intervención |
| Necesita validación humana | Vos sos la validación | Sí, siempre, sobre todo la hipótesis inicial |
La curva de utilidad es clara: cuanto más exhaustiva y mecánica es la tarea, más gana el agente. Cuanto más depende de intuición y conocimiento del sistema, más rápido sos vos.
¿Pueden los agentes IA escribir y validar código de pruebas automáticamente?
Escribir tests, sí. Los agentes generan código de prueba sin problema. La pregunta real es si esos tests prueban lo que decís que prueban. Escribir un test no alcanza. Lo que le da valor al test es la ejecución y la evidencia.
En el caso Codex, la secuencia completa fue: generar el test en Playwright, ejecutarlo contra dos estados del repo, producir un video, y auto-evaluar la hipótesis contra ese resultado. Esa cadena es lo que separa a un agente útil de un generador de texto que “dice” que probó algo.
- Generación: el agente escribe el caso de prueba a partir de la descripción del bug.
- Ejecución: corre el test en un entorno real (Playwright, en este caso), no lo simula en su cabeza.
- Evidencia: produce un artefacto verificable, como el video de antes y después del commit.
- Auto-evaluación: compara el resultado con su hipótesis y decide si se sostiene.
Eso sí: la auto-evaluación del agente es sugerencia, no veredicto. Un test puede pasar por el motivo equivocado. Vos tenés que mirar si el test refleja el comportamiento real que te importa. Complementá con por qué GPT impulsa la automatización.
¿Cómo integrar agentes IA para programación en tu flujo de debugging?
La regla práctica que sale del caso Dan Luu es simple: usá el agente para el trabajo pesado y reservá para vos la decisión. Invocá un agente cuando el problema es exhaustivo (bisectar muchos commits, reproducir un bug esquivo, generar tests de regresión) y no cuando ya sabés dónde está el error.
- Definí bien las restricciones: si le pasás un rango de fechas para bisectar, esperá que a veces las viole y verificá que respete los límites.
- No confíes en la primera respuesta: pedile siempre que pruebe o refute su hipótesis con evidencia ejecutable.
- Dá feedback específico: “está mal” funciona, pero “ese commit está fuera del rango que definí” reencauza más rápido.
- Corré la validación en un entorno controlado: probá en staging o en un servidor de prueba antes de tocar producción. Si necesitás cloud o VPS para levantar ese entorno, en Argentina lo resolvés con donweb.com.
- Revisá la lógica, no el tono: un video convincente no valida nada por sí solo. Mirá qué prueba realmente.
Errores comunes al usar agentes IA en debugging
Aceptar la primera respuesta como buena. El agente te tira un commit con seguridad total y vos lo tomás por válido. Corrección: pedile evidencia ejecutable antes de creerle una sola línea.
Confundir “convincente” con “correcto”. Un video de Playwright que muestra el bug antes y después parece definitivo. Pero el test que lo generó puede estar mal armado. Corrección: leé el código del test, no solo mires el resultado.
Usar el agente para bugs triviales. Largar un loop agentico para un typo es perder tiempo. Corrección: reservá los agentes para tareas exhaustivas o exploratorias donde tu atención rinde poco.
No dar feedback correctivo específico. Si solo repetís “no, probá de nuevo”, el agente da tumbos. Corrección: señalá exactamente qué está mal y por qué, así el modelo tiene contexto para reencauzarse.
Qué está confirmado y qué no
- Confirmado: Codex generó tests en Playwright, los ejecutó y produjo videos de la ejecución antes y después del commit, según el relato publicado por Dan Luu.
- Confirmado: el agente dio al menos una respuesta lógicamente imposible (commit fuera del rango de fechas) antes de corregirse con feedback humano.
- Confirmado: el agente afirmó no tener permisos para grabar el stack completo end-to-end en un navegador normal.
- No confirmado: si el commit “plausible” al que llegó Codex era efectivamente el culpable real. El relato muestra el proceso, no un veredicto final independiente.
- No confirmado: la versión exacta del modelo usado. Dan Luu menciona GPT “quizás 5.0 o 5.1” sin precisar.
Preguntas Frecuentes
¿Qué es un loop agentico en programación?
Un loop agentico es un ciclo en el que el agente IA recibe una tarea, la intenta resolver, valida el resultado con una herramienta (test, compilación, screenshot) y usa ese resultado para reintentar si falló. Repite hasta lograr un resultado aceptable o hasta que el humano corrige el rumbo. Te puede servir nuestra cobertura de cómo ChatGPT acelera el desarrollo.
¿Puede la IA automatizar el debugging por completo?
No por completo. Los agentes automatizan la parte mecánica (bisectar commits, generar y correr tests, producir evidencia), pero cometen alucinaciones con alta confianza. El caso de Dan Luu muestra que la validación humana es la que detecta las respuestas imposibles y guía la corrección.
¿Qué es Codex?
Codex es el agente de programación de OpenAI que conecta un modelo de lenguaje con herramientas de desarrollo: terminal, ejecución de tests, navegador automatizado y control de versiones. No solo sugiere código, lo corre y genera artefactos verificables como videos de ejecución.
¿Los agentes IA pueden escribir tests confiables?
Escriben tests que corren, sí, pero la confiabilidad depende de la validación. Un test puede pasar por el motivo equivocado o probar algo distinto de lo que necesitás. Siempre revisá el código del test, no solo el resultado que reporta el agente.
¿Cuándo conviene debuggear a mano en vez de con un agente?
Conviene a mano cuando el bug es simple y lo ves de un vistazo, o cuando ya conocés bien el código y ubicás el error rápido. El agente gana en tareas exhaustivas y mecánicas, como bisectar cientos de commits o reproducir un bug esquivo sin test previo.
Conclusión
El caso que contó Dan Luu resume bien dónde estamos con los agentes IA para programación en 2026: hacen cosas que a un humano lo harían quedar pésimo (afirmar un commit fuera del rango de fechas), y aun así son útiles porque el loop agentico los deja corregirse con feedback y anclar sus hipótesis a evidencia ejecutable.
Lo que cambió no es que el agente “resuelva” el bug solo. Es que hace el trabajo tedioso (generar tests, correrlos, grabar videos, bisectar) mientras vos ponés el criterio. Si lo usás para exploración exhaustiva y validás cada hipótesis en vez de creerle el primer video convincente, ganás tiempo real. Si le delegás el juicio final, tarde o temprano publicás un bug que el agente te juró que no existía.