¿Qué es la depuración de IA?

El 9 de septiembre de 1947, los ingenieros del ordenador Mark II de Harvard encontraron una polilla en uno de sus relés y lo anotaron en su libro de registro ("primer caso real de hallazgo de un bug"), una página que ahora se conserva en el Smithsonian.¹ La informática Grace Hopper, del equipo del Mark II, popularizó la anécdota, aunque el término es anterior a ella: Thomas Edison se quejó de los "bugs" en una carta de 1878, y el Oxford English Dictionary remonta este uso en ingeniería a las décadas de 1870 y 1880.²

Los errores de ingeniería suelen ser de tres tipos.³ Los errores de sintaxis rompen la gramática de un lenguaje de programación (un ejemplo podría ser la falta de un paréntesis) y se detectan antes de que se ejecute el programa. Los errores de tiempo de ejecución se producen cuando un código válido falla a mitad de la ejecución, como dividir por cero. Los errores lógicos son los más traicioneros: el programa se ejecuta sin problemas, pero da una respuesta errónea.

Los desarrolladores pueden contrarrestar esto mediante pruebas automatizadas (pruebas unitarias que comparan cada pequeño fragmento de código con los resultados esperados) y mediante depuradores, que detienen temporalmente un programa en ejecución para poder inspeccionarlo. Un punto de interrupción (una línea marcada en la que se detiene la ejecución) permite al desarrollador revisar el programa y examinar las variables; el pdb integrado en Python es un ejemplo típico. Un fallo total suele generar un seguimiento de la pila, es decir, un informe de las llamadas a funciones que provocaron el error.⁴

Un estudio de la Cambridge Judge Business School de 2013 estimó que los desarrolladores dedican, de media, la mitad de su tiempo de programación a encontrar y corregir errores, lo que supone un coste aproximado de 312 000 millones de dólares al año a nivel mundial.⁵ La promesa de la depuración asistida por IA, por supuesto, es reducir ese coste.

Un LLM es un sistema de machine learning entrenado con grandes cantidades de texto y código para predecir el siguiente "token" (palabra, bit de palabra o símbolo): la misma tecnología de procesamiento del lenguaje natural detrás de chatbots de IA como ChatGPT o Claude. Durante el entrenamiento, "leía" de manera efectiva miles de millones de líneas de código público, además de los mensajes de error, los informes de errores y las correcciones correspondientes. Para cuando un LLM sale al mercado, probablemente ya haya visto millones de bugs y digerido sus resoluciones. 

Los datos de entrenamiento de código abierto documentados incluyen conversaciones de "problemas" y "solicitudes de extracción" en GitHub(registros en los que los desarrolladores denuncian errores y correcciones) que dan a modelos especialmente entrenados acceso a un registro en papel que muestra cómo los codificadores humanos reparan el código roto.

En un flujo de trabajo común de depuración de IA, el desarrollador proporciona al modelo el código relevante y el mensaje de error o el seguimiento de la pila; a continuación, el modelo explica la causa probable y sugiere correcciones candidatas. Los sistemas de investigación como ChatDBG van más allá, conectando los LLM a depuradores estándar como GDB, LLDB y el pdb de Python para que un desarrollador pueda hacer preguntas en lenguaje sencillo ("¿por qué x es nulo?") Mientras el modelo inspecciona el programa en vivo, realiza búsquedas de causa raíz y propone correcciones.6.

Hay algunas limitaciones que los nuevos en la depuración de la IA deben conocer. En primer lugar, el contexto es importante: una práctica relacionada con el prompt engineering. Las instrucciones vagas tienen más probabilidades de producir diagnósticos vagos; un enfoque más útil es proporcionar el error exacto, la prueba fallida y un poco de código sospechoso. Los usuarios también deben tener en cuenta la ventana de contexto de un modelo: la cantidad máxima de texto (medida en "tokens" o fragmentos de unos pocos caracteres cada uno) que un modelo puede considerar a la vez. Los errores reales en bases de código complejas suelen abarcar varios archivos, como muestra la referencia SWE-bench de problemas reales de GitHub, y un modelo que no puede encajar todo el código relevante en su contexto puede tener dificultades para razonar al respecto.

La depuración de la IA normalmente se realiza a través de asistentes de codificación de IA integrados o creados en torno al espacio de trabajo de codificación del desarrollador, normalmente un entorno de desarrollo (o IDE) integrado. GitHub Copilot, por ejemplo, es un asistente de codificación que puede sugerir código dentro de IDE populares; Cursor y Windsurf son espacios de trabajo de codificación orientados a IA que sitúan la asistencia similar más cerca del centro de la experiencia de programación.⁷ Y a medida que el auge de la "ingeniería agéntica" se convierte en la norma, algunos programas se diseñan con la ventana de chat del asistente de codificación destinada a ser el panel principal en el que el usuario humano interactúa con el IDE; esta es una forma de utilizar IBM® Bob, entre otras.

A menudo, los asistentes de codificación son independientes del modelo; GitHub Copilot, por ejemplo, puede utilizar modelos de proveedores como OpenAI, Anthropic y Google; xAI también ha descrito su modelo "Grok Code Fast 1" como diseñado para flujos de trabajo de agentes de programación y disponible a través de herramientas como Copilot, Cursor y Windsurf.^{8 9} Por su parte, IBM Bob utiliza diversos modelos y redirige automáticamente las consultas al modelo más adecuado en función de la complejidad y el coste; los materiales del lanzamiento de 2026 hacen referencia a "una combinación de modelos de vanguardia, entre los que se incluyen Anthropic Claude, los modelos de código abierto Mistral e IBM Granite, junto con modelos especializados y ajustados con precisión para el razonamiento de código, la seguridad y la predicción de la siguiente edición".

Algunos agentes de depuración de IA son generalistas; otros son especialistas. En el extremo más generalista del espectro, al agente de codificación Copilot de GitHub, presentado en 2025, se le puede asignar una incidencia de GitHub, trabajar en segundo plano mediante GitHub Actions y enviar los cambios propuestos como una solicitud de incorporación de cambios (un conjunto de modificaciones de código para que las revise un desarrollador humano).¹⁰ Con su combinación de modelos, IBM Bob también se inclina por el generalismo. En el lado especializado está Copilot Autofix, que se dirige específicamente a las vulnerabilidades de seguridad. Para ello, combina CodeQL, el motor de escaneo de código de GitHub, con explicaciones generadas por IA y correcciones sugeridas. El ahorro de tiempo puede ser impresionante; GitHub informa de un tiempo medio de corrección de 28 minutos frente a 1,5 horas manualmente.¹¹

Aunque son impresionantes, los resultados en la vanguardia de la IA generativa son desiguales. Un reciente estudio de IBM realizado entre 2000 CEO reveló que solo el 25 % de las iniciativas de IA habían generado el rendimiento esperado de la inversión en los últimos años.

Los resultados mixtos también se aplican a la depuración de IA. En un estudio de DebugBench de 2024, los investigadores descubrieron que los modelos de código cerrado aún no estaban a la altura del rendimiento humano en general y que los errores lógicos eran mucho más difíciles de reparar que los errores de sintaxis y referencia.¹²

Sin embargo, herramientas mejores y más especializadas están mejorando las perspectivas. ChatDBG, por ejemplo, conecta un LLM a un depurador en vivo, lo que le da visibilidad de lo que estaba haciendo exactamente el programa cuando falló (en lugar de solo el texto del código sospechoso). En una evaluación, una sola consulta a ChatDBG proporcionó una corrección práctica para programas en Python en el 67 % de los casos; cuando solo se permitió una pregunta de seguimiento, la tasa aumentó hasta el 85 %.¹³

Para complicar el panorama, las metas con las que se evalúan los modelos cambian constantemente. SWE-bench Pro, un sucesor más exigente del famoso SWE-bench¹⁴, fue diseñado para ser más realista y resistente a la contaminación; en una evaluación reciente, los mejores modelos de frontera se mantuvieron por debajo del 25 %, con GPT-5 en el 23,3 %.¹⁵  

El comportamiento de los desarrolladores puede estar cambiando más rápido de lo que se puede medir científicamente. El ensayo aleatorio de METR realizado a principios de 2025 reveló que los desarrolladores experimentados de código abierto tardaban un 19 % más al utilizar herramientas de IA, pero METR se apresuró a calificar esos resultados de obsoletos; una continuación del estudio realizada en 2026 encontró algunas pruebas de una mayor productividad, aunque señaló que esta aceleración era difícil de medir con precisión.¹⁶ La explicación de METR sobre esa dificultad es reveladora: "Hemos observado un aumento significativo en el número de desarrolladores que deciden no participar en el estudio porque no desean trabajar sin IA, lo que probablemente sesga a la baja nuestra estimación de la aceleración que proporciona la IA". 

Está claro que el desarrollo (y la depuración) asistidos por la IA no van a ningún lado. Pero por ahora, las herramientas de depuración de la IA probablemente se entiendan mejor como asistentes potentes, no como pilotos automáticos fiables. Son capaces de explicar las trazas de pila, detectar errores sintácticos y elaborar rápidamente borradores de parches. Pero los casos más difíciles (errores lógicos, bases de código complejas y código sensible a la seguridad) siguen exigiendo pruebas, puntos de interrupción y un humano cualificado que revise la corrección antes de que se fusione con una base de código.