Lunes por la mañana. Escribes un prompt en Cursor, Claude Code o Copilot. Tres minutos después, un feature aterriza en tu PR — el pull request que tu código envía antes de mergearse a la rama principal del proyecto. El CI pasa en verde. Ticket cerrado. Golpe de dopamina. Ahora eres un desarrollador 10x.

Una semana después, ese feature se rompe a las 3 AM. Abres el archivo. No puedes rastrear el bug. Tú no escribiste ese código. Lo hizo la IA. Y no dejó ni una miga. Necesitas un debugger. Pero ya no todos los debuggers significan lo mismo.

Dos herramientas de debugging entran a una semana

Entre el 14 y el 16 de abril, mientras el resto de la industria seguía construyendo generadores de código más rápidos, dos herramientas finalmente admitieron que el código generado por IA se rompe de forma diferente al código escrito por humanos — y necesita herramientas diferentes para arreglarlo.

El 14 de abril, Cursor 3.1 lanzó tanto un comando CLI /debug como agentes en segundo plano que auto-crean PRs desde issues de GitHub — un release que abarca ambos lados de la división. El 16 de abril, Visual Studio 18.5 presentó un debugger agéntico que genera hipótesis de falla y coloca breakpoints por ti. Mientras tanto, el lado de la generación mantuvo el ritmo: Claude Code lanzó Routines el 14 de abril y OpenAI actualizó Codex el 16 de abril a 3 millones de usuarios semanales con uso de escritorio y más de 90 plugins.

Ratio generación-a-debugging esta semana: 3:2 (contando los agentes en segundo plano de Cursor del lado de generación, su /debug del lado de debugging). Progreso, supongo.

Misma palabra, dos filosofías distintas

El /debug de Cursor y el debugger agéntico de Visual Studio ambos dicen debuggear. Hacen cosas fundamentalmente diferentes.

El /debug de Cursor lee la salida de errores de tu terminal — stack traces, assertions fallidas, gritos del compilador — los correlaciona con tus archivos abiertos y el contexto del proyecto, y genera un parche. Por debajo, es re-prompting con mejor contexto. La IA ingiere el error, adivina qué se rompió y genera código de reemplazo. Si el parche no pega, re-prompteas. Si eso tampoco pega, borras la función y regeneras desde cero. El workflow optimiza para velocidad: error → parche → ship. Tu trabajo es evaluar el output, no entender el camino.

Esta es una decisión de diseño legítima. Esos agentes en segundo plano en el mismo release de Cursor 3.1 — corriendo en sandboxes en la nube, convirtiendo issues de GitHub en PRs sin intervención humana — revelan la filosofía del producto con claridad. El código es desechable, el output importa, la iteración es barata. /debug es consistente con esa visión del mundo. No entiendas el código roto. Reemplázalo con código que funcione. Sigue adelante.

El debugger agéntico de Visual Studio hace la apuesta opuesta. Cuando describes un bug o pegas una excepción, el agente no genera un fix. Genera hipótesis — explicaciones rankeadas de por qué ocurrió la falla. Luego instrumenta tu código: coloca breakpoints condicionales en las ubicaciones que cada hipótesis predice como defectuosas, configura watch expressions en las variables sospechosas y te guía paso a paso por la ruta de ejecución real.

El anuncio de Microsoft describe al agente evaluando "código relevante, cambios recientes y patrones de error comunes" para producir su lista de hipótesis. El debugger luego entra en lo que llaman un ciclo de investigación: llega a un breakpoint, inspecciona el estado, confirma o rechaza una hipótesis, pasa a la siguiente. No estás leyendo código generado por IA. Estás leyendo el comportamiento real de tu runtime, guiado por una IA que reduce el espacio de búsqueda.

La diferencia mecánica clave: el /debug de Cursor opera sobre texto — código fuente como un string a reescribir. El debugger de Visual Studio opera sobre ejecución — estado del runtime como evidencia a examinar. Uno trata el código como un documento. El otro lo trata como una máquina.

Por qué la distinción importa de verdad

Para un null pointer en una función utilitaria, no importa. El /debug de Cursor lo parchea en segundos. El debugger de Visual Studio sería matar una mosca con un cañón.

Pero los bugs generados por IA no suelen ser null pointers. La evidencia se sigue acumulando — los datos de calidad de código de GitClear, múltiples replicaciones académicas — mostrando que el código co-escrito con IA tiene significativamente más errores de lógica y problemas de rendimiento que el código escrito a mano. Los bugs que importan no son problemas de sintaxis. Son desajustes conductuales sutiles: un handler de API que funciona en tests pero hace doble escritura bajo requests concurrentes, un query de base de datos que devuelve resultados correctos en datasets pequeños pero genera JOINs O(n²) a escala, una máquina de estados que maneja el happy path pero corrompe datos silenciosamente en los reintentos.

Estos bugs no se anuncian en la salida del terminal. Se manifiestan como degradación lenta, fallas intermitentes, inconsistencias de datos que aparecen días después. El /debug de Cursor necesita un mensaje de error para trabajar. ¿Qué le das cuando el síntoma es "los ingresos del checkout cayeron 4% el martes y nadie sabe por qué"?

El enfoque basado en hipótesis de Visual Studio maneja esto de manera diferente. Describes el síntoma. El agente propone causas candidatas — quizás la lógica de reintento de pago cobra doble, quizás la verificación de inventario compite con la actualización del carrito, quizás el cálculo de descuento trunca en vez de redondear. Coloca breakpoints en cada ubicación candidata. Reproduces el escenario y observas cómo la ruta de ejecución revela qué hipótesis se sostiene.

¿Más lento? Enormemente. ¿Requiere que uses el cerebro? Desafortunadamente, sí. Pero es la única herramienta lanzada este mes que trata el debugging como investigación y no como otra ronda de generación.

La bifurcación del workflow

Aquí es donde la industria se divide.

Camino A: El modelo de Cursor. El código es barato. Debuggear es regenerar. Cuando algo se rompe, tíralo y promptea de nuevo. /debug hace este ciclo más ajustado. Los agentes en segundo plano lo hacen autónomo. El punto lógico final es código que nadie lee jamás — generado, testeado, deployeado y reemplazado por máquinas en un ciclo continuo. Los desarrolladores se convierten en product managers que describen intención y evalúan output.

Camino B: El modelo de Visual Studio. El código es infraestructura. Debuggear es comprender. Cuando algo se rompe, entiendes por qué antes de arreglarlo, porque la misma falla estructural reaparecerá en la próxima generación si no lo haces. El punto lógico final son desarrolladores que entienden menos código en total pero lo entienden más profundamente — especialistas en comportamiento de sistemas en vez de producción de sintaxis.

Ningún camino es estúpido. Pero son incompatibles en el mismo codebase. Un equipo que debuggea regenerando no construye conocimiento institucional de cómo se comporta realmente su sistema. Un equipo que debuggea investigando gasta tiempo que los equipos de regeneración llaman desperdicio.

Adivina qué enfoque gana

El de Cursor, obviamente. Es más rápido. Requiere menos pensamiento. Encaja con el workflow de vibe-coding que la industria ha abrazado unánimemente. Borrar, re-promptear, hacer ship, repetir. La investigación es problema de alguien más — hasta que producción se prende fuego y ese "alguien más" eres tú a las 3 AM, mirando tres servicios que tres prompts diferentes escribieron, viendo cómo la interacción entre ellos tumba el checkout.

No puedes re-promptear para salir de una falla de sistema distribuido. Necesitas a alguien que haya mapeado las rutas de ejecución. Y si tu cultura de debugging es "reemplazar hasta que quede verde", esa persona no existe en tu equipo.

El enfoque de Visual Studio es más difícil de vender. "Déjame ayudarte a pensar" pierde contra "déjame arreglártelo" en cada demo, cada tweet, cada ciclo de hype. Pero la comprensión se acumula. La regeneración no.

La parte incómoda

La pregunta no es qué debugger es mejor. Es qué filosofía de debugging adopta tu equipo — y si la eligieron deliberadamente o simplemente se dejaron llevar por la herramienta más rápida.

Si tu stack son funciones stateless y servicios de vida corta, el ciclo de regeneración de Cursor puede ser genuinamente suficiente. Reemplaza la lambda rota. Sigue adelante. Nadie necesita entender una función que vive un solo ciclo de release.

Si tu stack tiene estado, tiene transacciones distribuidas, tiene comportamiento que emerge de la interacción entre componentes — alguien tiene que entender el runtime. No el texto fuente. El runtime. El debugger de Visual Studio es la primera herramienta de IA que reconoce que ese trabajo existe.

Lunes por la mañana, escribirás otro prompt. Algo se va a romper. La pregunta no es si vas a debuggear. Es si debuggear significa "generar de nuevo" o "entender por qué". Elige a propósito. El default es regenerar. Y a las 3 AM, los defaults son todo lo que tienes.