Cursor y Microsoft Research evalúan si un agente de IA necesita acceso completo al depurador

A un agente de IA que corrige bugs ya no le basta con leer código y recopilar logs: cuando tiene acceso a un depurador de verdad, actúa más como un desarrollador humano y entiende mucho mejor en qué punto exacto falla el programa.

A finales de 2025, Cursor lanzó Debug Mode, un modo en el que el agente puede recopilar logs directamente del runtime y usarlos como fuente adicional de contexto. Para la depuración práctica es un paso importante: en lugar de adivinar a partir de los stack traces, el modelo ve qué ocurre en el momento de la ejecución, qué valores pasan por las funciones y en qué punto el sistema se comporta de forma distinta a lo esperado.

El enfoque también resultó intuitivo para los desarrolladores: por la reacción de la comunidad, la idea no se percibe como un modo de marketing más, sino como una herramienta realmente útil para el trabajo diario con bugs.

Pero el registro de logs no es la única forma de acercar la IA a la práctica de ingeniería habitual. La siguiente pregunta es aún más directa: si el agente ya vive junto al IDE, ¿por qué no darle las mismas herramientas que usa una persona? Se trata de breakpoints, ejecución paso a paso, inspección del estado del programa y evaluate expression en la línea que haga falta.

Eso es justo lo que probaron los investigadores de Microsoft Research en el framework experimental Debug2Fix. En su planteamiento, un subagente independiente recibió herramientas para interactuar con el depurador y, en tareas de GitBug-Java y SWE-Bench-Live, resolvió los bugs aproximadamente un 20 % mejor que un agente normal sin ese acceso. No es una mejora cosmética: para la corrección automática de código, una diferencia así cambia el valor práctico de la herramienta.

La idea es clara. Los logs casi siempre ayudan a ver los síntomas, pero el depurador permite llegar a la mecánica del fallo. El agente puede hacer algo más que leer que un valor es incorrecto: puede rastrear en qué momento dejó de serlo, qué rama de la condición se ejecutó, qué contienen los objetos ahora mismo y cómo se comporta una expresión al probar una hipótesis in situ. En la práctica, el modelo obtiene no solo observación, sino un experimento controlado. Para depurar estados complejos, condiciones de carrera, valores null inesperados o errores de lógica de negocio, esto puede ser crítico, porque ahí el análisis estático e incluso los logs detallados suelen quedarse cortos.

En este contexto, es lógico que los asistentes de IDE completos empiecen a ir más allá de leer archivos. Si el agente ya está integrado en el entorno de desarrollo, el acceso al depurador no parece algo exótico, sino una extensión natural de sus capacidades. Por eso la última versión del asistente para IntelliJ incorpora Debug Agent, que puede interactuar con el depurador directamente en el IDE.

El escenario es casi humano: el agente ejecuta el programa, se detiene en el punto adecuado, examina el estado, comprueba una hipótesis y solo después propone una corrección. Es una diferencia importante frente al enfoque en el que el modelo se apoya sobre todo en el logging y en señales indirectas del problema.

Lo más interesante de esta historia no es solo la mejora en los benchmarks, sino la pregunta en sí: ¿qué es más útil para el desarrollador de IA del futuro, un buen acceso a los logs de runtime o unas verdaderas «manos» dentro del depurador? Un solo experimento aún no ofrece una respuesta completa, pero ya se ve que el mercado avanza en dos direcciones a la vez. Un camino apuesta por una observación de calidad de la ejecución del programa; el otro, por la intervención activa en el proceso de depuración.

Si el segundo enfoque confirma su ventaja en un mayor número de casos reales, los AI coding assistants dejarán pronto de ser simples autocompletadores inteligentes y se convertirán en compañeros de pleno derecho, capaces no solo de escribir código, sino también de llegar metódicamente a la raíz de un bug.