Cursor como herramienta de depuración: por qué se estanca el ciclo de corrección

Por qué se estanca una sesión de depuración con Cursor

Depurar es un ciclo: observar, formular una hipótesis, cambiar y volver a observar. Un agente que trabaja a partir de tus archivos puede dar tres de esos cuatro pasos. No puede observar. Cada vez que pegas un stack trace o describes lo que viste en pantalla, estás ejecutando a mano el único paso que él no puede dar, y la calidad de todo el ciclo queda limitada por lo bien que describas las cosas.

Por eso la tercera ronda suele ser peor que la primera: el cansancio hace mella, tu descripción se acorta y el agente ya razona sobre el resumen de un resumen.

Las tres descripciones que despistan a un agente

Qué cierra el ciclo

Dale al agente el paso de observación en lugar de darlo tú. Eso significa que algo maneje la aplicación desplegada como lo haría una persona y reporte lo ocurrido como evidencia, no como prosa.

La forma de esa evidencia importa más que su volumen. Qué se intentó, qué hizo realmente la aplicación y en qué punto se separaron ambas cosas. Sobre eso un agente puede actuar directamente. Una captura de pantalla y un stack trace siguen necesitando que alguien los interprete, lo que te devuelve al ciclo del que intentabas salir.

La instalación añade una skill de verificación dentro del propio Cursor, para que sepa crear un caso, ejecutarlo y leer el resultado sin que tengas que explicar el flujo cada vez.

Puedes hacer lo mismo desde el panel de TestSprite. Todo lo demás que hace la CLI está en el repositorio de la CLI.

Una reproducción que puedes entregar vale más que una descripción

El hábito con más impacto es dejar de describir el error y empezar a reproducirlo. Un caso escrito indica qué página abrir, qué hacer y qué debería cumplirse después. Tres líneas así rinden más que tres párrafos de explicación, porque no son ambiguas y porque se pueden volver a ejecutar.

También cambia la conversación con el agente. En lugar de «el desplegable está roto», la entrada pasa a ser una ejecución que llegó al paso cuatro y encontró seleccionada la opción equivocada. Ya no queda nada que interpretar.

Escribe el caso antes del primer intento de corrección, no después del tercero. En ese momento todavía recuerdas exactamente qué hiciste para provocarlo, y ese conocimiento se evapora más rápido de lo que nadie espera.

Un ejemplo práctico de cómo se cierra el ciclo

Piensa en un caso concreto. Un usuario reporta que, al editar un filtro guardado, a veces se revierte. Lo describes, el agente encuentra una condición de carrera entre dos actualizaciones de estado y propone una guarda. La aplicas, lo pruebas una vez, funciona y sigues adelante. Dos días después vuelve el reporte.

Lo que falló no es la corrección. Es que un único intento manual es una muestra de uno frente a un error intermitente, y los errores intermitentes pasan una sola prueba más o menos con la misma frecuencia con la que la fallan. El ciclo que sí converge tiene otra forma: anota la secuencia como un caso, ejecútalo varias veces y lee la tasa. Cuatro fallos de diez es una instrucción completamente distinta para el agente que «está roto», porque descarta toda una clase de causas deterministas y apunta a los tiempos.

Lo segundo que cambia es lo que ocurre después de la corrección. El mismo caso se vuelve a ejecutar, diez veces, y o la tasa baja a cero o no. Ahora tienes evidencia en lugar de una impresión, y el caso se queda en la suite para que el tercer reporte no llegue nunca.

La afirmación de la que conviene desconfiar

«Ya he corregido el problema» es la frase más cara de la depuración asistida por agentes. Sale del mismo razonamiento que produjo el cambio, así que no aporta ninguna información independiente. Una corrección se confirma cuando se observa que el comportamiento es correcto y, por definición, el agente que la escribió no puede ser quien lo confirme.

Esto no es una crítica al modelo. Una persona que escribe un parche y luego lo declara correcto sin ejecutar nada recibiría la misma respuesta en una revisión.

Haz que la comprobación sobreviva a la sesión

El caso que escribiste para reproducir el error vale más después de la corrección que durante ella. Consérvalo y ejecútalo en cada cambio, para que el mismo defecto no pueda volver sin hacer ruido tres semanas después.

• La GitHub App es un webhook que configuras en el panel de TestSprite. Escucha el evento de despliegue que tu pipeline ya genera, así que nada cambia en tu repositorio.

• GitHub Actions coloca el paso dentro de tu propio workflow, configurado desde la terminal.

Qué cambia al meter un paso de verificación en el ciclo

TestSprite aporta la observación que le falta al ciclo. La instalación añade una skill de verificación dentro del propio Cursor, para que el agente pueda crear un caso, ejecutarlo contra tu aplicación desplegada y leer el resultado sin que tengas que transmitir nada.

El efecto práctico en una sesión de depuración es que las rondas dejan de repetirse. El agente ya no razona sobre tu recuerdo de lo que viste: tiene un registro de qué se intentó, qué hizo la aplicación y en qué punto se separaron ambas cosas. La corrección que propone queda confirmada por algo distinto del razonamiento que la produjo, que es la única manera de que «ya lo he corregido» se convierta en información.

La reproducción también sobrevive a la sesión. El caso que encontró el error se queda en la suite y se ejecuta en cada cambio, para que el mismo defecto no pueda volver sin hacer ruido dentro de seis semanas.