La integración de herramientas de programación asistida por IA, lo que en el sector se conoce como vibe coding, no se ha traducido en lanzamientos más rápidos. Un nuevo estudio revela que el 79% de los líderes de ingeniería produce código más rápido, pero los ciclos de publicación siguen igual. El cuello de botella está en la depuración, que consume el 42% de la semana laboral, y en la frustración que genera el código de IA casi correcto que no termina de funcionar.
La promesa inicial parecía sencilla: si la IA escribe código más deprisa, los equipos entregan funciones antes. Sin embargo, como os contaremos a continuación, la realidad que describen los responsables de ingeniería consultados es otra. La revisión y la caza de errores sutiles absorben ya más horas que la propia escritura, y ese desplazamiento explica por qué los ciclos de lanzamiento no se han acortado pese a la generación de código asistida por IA.
Qué dice el estudio sobre el tiempo perdido depurando
Undo, compañía especializada en herramientas de depuración, encargó a la firma de investigación Coleman Parkes una encuesta realizada entre julio y agosto de 2026 a 300 responsables sénior de ingeniería en Estados Unidos y Reino Unido. Todos ellos trabajan en empresas con más de 250 millones de dólares de facturación, principalmente en finanzas, redes y diseño de chips, sectores donde una caída de servicio sale cara.
El hallazgo principal es tajante: el 79% de estos líderes asegura que su equipo produce código mucho más rápido gracias a la IA, pero los ciclos de lanzamiento no se han acelerado un ápice. La explicación aparece en otra cifra que conviene que tengáis presente: la depuración ocupa ahora el 42% de la semana laboral de sus equipos. Este porcentaje engloba toda la revisión de errores, no solo los que introduce la inteligencia artificial, lo que indica que el cuello de botella se ha trasladado de la escritura a la corrección.
Cómo se reparte el tiempo un equipo de desarrollo
Para entender por qué los lanzamientos no ganan velocidad hay que mirar cómo se reparten esas 40 horas semanales. Producir código ocupa 9,8 horas, un 25% de la jornada. Depurar durante el desarrollo suma otras 9,7 horas (24%), una cifra que iguala casi por completo al tiempo de escritura. A eso se añaden 7,2 horas (18%) dedicadas a resolver incidencias que detectan los propios clientes ya en producción. El resto de tareas lleva 13,3 horas, un 33% de la semana. Sumadas, estas cuatro partidas cubren la semana completa de 40 horas: la depuración, en sus dos variantes, ya no es una tarea residual sino la que más horas absorbe tras sumarlas.
Fijaos en esta cuenta, que es sencilla: si la IA redujera a la mitad esas 9,8 horas de producción, el ahorro rondaría las cinco horas semanales. Pero si el código que genera añade otras cinco horas de depuración, el beneficio desaparece. El equipo no gana tiempo, solo lo cambia: de escribir a investigar qué ha fallado. Es la paradoja que atraviesa todo el informe: la velocidad que se gana escribiendo se pierde revisando.
El código de IA casi correcto es más caro que el que falla
La Encuesta para Desarrolladores de Stack Overflow de 2025, con más de 49.000 respuestas, señala cuál es la mayor fuente de frustración: el 66% de los programadores se queja de recibir soluciones de IA que están casi bien, pero no del todo. Un 45% añade que depurar ese código generado por IA le lleva más tiempo que depurar el propio. Son cifras que colocan esta frustración por encima de cualquier otro problema reportado en la encuesta.
El código que falla sin más es el caso fácil: arroja un error en la primera ejecución, se lee la traza y se corrige. El problema aparece con el código casi correcto, el que compila, pasa la prueba obvia y se ve limpio en la revisión, para luego romperse ante el dato que nadie probó: una lista vacía, un año bisiesto, un usuario en otra zona horaria. Greg Law, fundador de Undo, lo resume así: «cuando el código está claramente roto, la causa suele ser fácil de encontrar». Si alguna vez os habéis topado con un fallo que solo aparece en producción y nunca en vuestras pruebas, reconoceréis el patrón.
El 81% de los programadores sufrió una incidencia por la IA
Las consecuencias de integrar código que nadie termina de entender son tangibles. Los líderes encuestados calculan que el 35% del código generado por IA llega a producción antes de que su equipo lo comprenda del todo. En los últimos seis meses, el 81% sufrió al menos una incidencia o caída de servicio vinculada al uso de herramientas de programación con IA.
Más llamativo es el último dato: el 93% reconoce que una alucinación de la IA le llevó, al menos una vez, a perseguir la causa raíz equivocada, en ocasiones con la propia herramienta señalando la pista falsa. La cifra resulta inquietante porque invierte el proceso habitual: en vez de que un fallo señale dónde mirar, la IA puede apuntar hacia el lugar equivocado y alargar la investigación. Son estimaciones de los propios directivos, no mediciones de laboratorio, pero apuntan al riesgo de depender de un código que no se ha revisado a fondo. Si trabajáis con agentes de IA en vuestro día a día, esta cifra explica por qué conviene revisar con lupa cualquier diagnóstico que os ofrezcan.
La encuesta de Stack Overflow de 2026, publicada el 6 de octubre, confirma el giro desde el otro lado. Entre los desarrolladores que usan IA en su día a día, el 69,3% la emplea para generar código en un área que ya domina. Justo detrás, el 63,8% la usa para depurar, resolver problemas o refactorizar, y el 58,1% para escribir pruebas.
El autocompletado, la función que vendió estas herramientas al principio, ni siquiera aparece entre las opciones principales: en la edición de 2025, solo el 13,8% decía limitarse a Copilot o al modo autocompletar. La IA se ha convertido en una segunda mirada sobre el código más que en un teclado más veloz. La confianza, sin embargo, no ha seguido el mismo ritmo: solo el 48% confía en lo que genera cuando puede comprobarlo con facilidad, y apenas el 6,6% lo haría para una decisión de trabajo importante. Si vosotros mismos usáis estas herramientas a diario, probablemente reconozcáis esa misma distancia entre lo útil que resulta la IA y lo poco que os fiáis de ella sin revisar antes el resultado.
Qué puede cambiar en Claude Code, Cursor y otras IA
Antes de dar estas cifras por buenas, conviene que las miréis con cierta distancia. Undo vende herramientas de depuración, así que tiene un interés directo en que ese trabajo parezca costoso. El propio informe cierra con un argumento comercial: el 82% de los encuestados cree que los agentes de codificación serían mucho más útiles si contaran con contexto de tiempo de ejecución, que es justo lo que ofrece Undo. Ese sesgo explica, en parte, que el estudio insista tanto en la necesidad de depurar con más contexto.
La muestra, además, es reducida y muy específica: 300 líderes de grandes compañías de Estados Unidos y Reino Unido, de los cuales el 93% trabaja con C o C++ en sistemas de misión crítica. El 42% del tiempo dedicado a la depuración incluye todos los errores, no solo los que introduce la IA, porque el informe no desglosa esa diferencia. Si vuestro trabajo diario transcurre en una aplicación web pequeña o en un equipo que programa en Python o JavaScript, es razonable pensar que os enfrentáis a un escenario distinto al que describe este informe, centrado en software crítico de gran escala.
El estudio no incluye datos de España, así que conviene que no extrapoléis directamente estas cifras a vuestro propio equipo si trabajáis aquí. La tendencia de fondo, eso sí, trasciende geografías: producir código más rápido no sirve de mucho si la depuración sigue absorbiendo buena parte de la semana. El valor en la ingeniería de software se desplaza de escribir líneas a entenderlas, probarlas y encontrar dónde fallan.