Si alguna vez has visto a un agente intentar corregir un error, lo has visto adivinar. Lee el código, propone una teoría, hace una edición y espera. A veces acierta. Muchas veces obtienes una corrección que parece segura y que, en silencio, oculta el verdadero error.
El Modo Depuración es lo que construimos para eso. En lugar de quedarse ahí razonando sobre el código, el agente va y obtiene evidencia sobre lo que el código hace cuando se ejecuta.
Así es el ciclo:
- El agente propone múltiples hipótesis y comienza a trabajar primero en la más plausible.
- Luego, se añade registro para probar una hipótesis (sin tocar la implementación).
- Un pequeño servidor de depuración recopila la salida en tiempo de ejecución en .cursor/debug.log mientras tu programa se ejecuta.
- Tú reproduces el error, y el agente ahora puede leer los registros y entender lo que sucedió en lugar de tener que adivinar.
- Cursor encuentra la causa raíz en los registros, hace la corrección y elimina el registro que añadió.
Aquí está aplicado a un error real, acelerado a aproximadamente un minuto:
Cómo lo usa el equipo
Algunas cosas interesantes que hemos resuelto internamente con el modo depuración:
- Una condición de carrera que ocurría 1 de cada 20 ejecuciones. Corrompía los metadatos de git en nuestras ejecuciones de mejor-de-N. El Modo Depuración lo localizó en menos de una hora.
- Una fuga de memoria, rastreada en una sola pasada. Resultó ser un mal uso de nuestro framework frontend. La corrección fue una sola línea.
- Un fallo nativo profundo en C++. Un fallo de Electron que la gente normalmente evitaba. Los registros lo hicieron localizable.
- Un parpadeo de SSR que se había abandonado. Un error de renderizado que nadie quería tocar, corregido una vez que el agente pudo ver lo que la página hacía en tiempo de ejecución.
Pruébalo con Shift+Tab (también está en la CLI, mediante /debug).
Estoy seguro de que la gente lo está usando de formas que no he imaginado, ¡así que házmelo saber!
