IA en el ciclo de desarrollo: velocidad real o deuda técnica disfrazada
Casi todos los equipos de ingeniería hoy pueden mostrar la misma cifra: código generado más rápido que nunca gracias a asistentes de IA. Lo que muy pocos equipos pueden mostrar, cuando se les pregunta con honestidad, es cuánto de ese código sigue siendo confiable seis meses después.
Esa es la pregunta incómoda detrás de la adopción masiva de IA en desarrollo de software: ¿la velocidad que estamos ganando hoy es real, o es deuda técnica que todavía no ha llegado la factura?
Los números que sí se están midiendo
Durante los primeros años de adopción de copilotos de código, la conversación fue casi exclusivamente sobre velocidad: cuántas líneas más, cuántas tareas más rápido, cuánto tiempo recuperado. Cualquier demo de producto mostraba lo mismo: un desarrollador que antes tardaba una hora en resolver algo, ahora lo resuelve en minutos. Esa parte de la historia es real y está bien documentada. Los estudios más recientes están empezando a medir la otra mitad de la ecuación, la que rara vez aparece en una demo, y los resultados piden más cautela de la que la euforia inicial sugería.
GitClear, que analiza cientos de millones de líneas de código en repositorios reales, encontró que el código duplicado se multiplicó varias veces desde que las herramientas de IA se volvieron parte del flujo diario de trabajo, mientras que el porcentaje de código que efectivamente se refactoriza cayó de una cuarta parte de los cambios en 2021 a menos del 10% más recientemente. Traducido: se está escribiendo más código, se está reescribiendo menos, y la limpieza que antes ocurría de forma natural en el proceso de desarrollo, cuando un desarrollador se detenía a simplificar algo que él mismo acababa de escribir, ha dejado de pasar con la misma frecuencia.
El propio reporte DORA de Google, uno de los estudios más citados sobre desempeño en ingeniería de software, encontró que por cada 25% adicional de uso de IA en un equipo, la inestabilidad de las entregas aumenta 7.2%. Es una correlación incómoda, porque contradice la intuición de que más automatización debería significar más consistencia. No es un hallazgo aislado: la encuesta State of Code de Sonar, con más de 1,100 desarrolladores, encontró que 88% percibe efectos negativos de la IA sobre la deuda técnica de su organización, aunque 93% también reconoce beneficios reales como mejor documentación. Las dos cosas conviven en la misma organización, y muchas veces en la misma persona: alguien puede sentir que su productividad individual subió, mientras la salud del sistema completo se deteriora sin que nadie lo note todavía.
Y el tema no se limita a mantenibilidad. Pruebas de Veracode sobre generación de código con modelos de lenguaje encontraron vulnerabilidades de seguridad introducidas en un porcentaje considerable de los casos evaluados, con tasas de falla todavía más altas en ciertos lenguajes de programación. La velocidad de generación no viene acompañada, por defecto, de la misma calidad de revisión que un desarrollador aplicaría manualmente, y la seguridad es precisamente el tipo de problema que no se manifiesta en el momento de escribir el código, sino meses después, cuando alguien externo a la organización lo encuentra primero.
Por qué pasa esto: la IA no conoce tu sistema, solo patrones
La raíz del problema no es que los modelos de IA generen código incorrecto la mayoría del tiempo. En muchos casos generan código que funciona, que compila, que pasa una prueba superficial. El problema es que un modelo entrenado en patrones generales no tiene acceso a las abstracciones internas de un proyecto específico, a sus utilidades compartidas, a las decisiones de arquitectura que ese equipo tomó por razones que no están escritas en ningún comentario.
El resultado es un patrón que la industria empezó a nombrar como "vibe coding": aceptar una sugerencia de IA porque funciona, sin verificar si duplica lógica que ya existe en otra parte del sistema, o si rompe una convención que el resto del código sigue de forma consistente. Cada una de esas aceptaciones individuales parece inofensiva. Acumuladas durante meses, son exactamente la definición de deuda técnica: decisiones que aceleran el corto plazo a costa de una factura que alguien más va a tener que pagar después.
Lo que hace esta deuda distinta a la deuda técnica tradicional es que no siempre es una decisión consciente. Cuando un equipo decidía históricamente tomar un atajo, sabía que lo estaba haciendo, lo documentaba en un comentario, lo apuntaba en un backlog de deuda técnica, y en algún momento volvía a corregirlo con conocimiento de causa. La deuda generada por IA se acumula de forma más silenciosa, escondida en sugerencias que se ven razonables línea por línea, pero que carecen del razonamiento arquitectónico necesario para sostenerse con el tiempo. Nadie decidió conscientemente introducir esa duplicación o ese acoplamiento innecesario; simplemente nadie se detuvo a cuestionar una sugerencia que funcionaba.
Esto genera un problema adicional, más difícil de resolver que la deuda tradicional: la deuda técnica clásica se puede priorizar porque alguien sabe dónde está, la anotó, la puede explicar. La deuda generada por IA muchas veces ni siquiera aparece en la conversación del equipo hasta que ya causó un incidente, porque no hay un momento consciente de "esto lo hicimos rápido, hay que revisarlo después" que quede registrado en ningún lado.
Lo que se pierde cuando nadie entiende el código que su equipo produjo
Hay un efecto secundario menos discutido que la duplicación o la inestabilidad de las entregas, y es el que algunos especialistas empiezan a llamar "deuda de comprensión". Cuando una parte creciente del código de un sistema fue generada por un modelo y aceptada sin una revisión profunda, el conocimiento colectivo que el equipo tiene sobre cómo y por qué funciona ese sistema empieza a erosionarse.
Esto no es un problema abstracto. Es el motivo por el que, meses después, un incidente en producción tarda mucho más de lo esperado en resolverse: la persona que lo investiga no encuentra a nadie en el equipo que pueda explicar con seguridad por qué esa parte del sistema se comporta como se comporta, porque nadie la diseñó con esa intención completa en la cabeza, solo la aceptó porque el resultado parecía correcto en el momento.
La velocidad ganada al escribir se convierte en tiempo perdido al depurar, y ese tiempo casi nunca se contabiliza en la misma columna que la productividad que la IA supuestamente generó.
La confianza está bajando, no subiendo
Un dato que contradice la narrativa de adopción sin fricción: la confianza de los propios desarrolladores en el código generado por IA ha ido a la baja, no al alza. Encuestas recientes de Stack Overflow muestran que la desconfianza hacia la precisión de las herramientas de IA aumentó de forma notable en el último año, y una proporción importante de desarrolladores reporta que depurar código generado por IA les toma más tiempo del que tomaría escribirlo ellos mismos desde cero.
Esto no significa que la IA no sirva. Significa que los equipos que más están sacando provecho no son los que confían ciegamente en cada sugerencia, sino los que tratan la salida del modelo como un primer borrador que requiere el mismo nivel de revisión crítica, o más, que el código escrito por un desarrollador junior.
El problema real no es la herramienta, es el proceso alrededor de ella
Aquí está el punto que casi ningún equipo se detiene a analizar: la velocidad ganada con IA no es automáticamente una ganancia neta si el proceso de revisión, prueba y documentación no evolucionó al mismo ritmo que la generación de código.
Un equipo que multiplicó su capacidad de escribir código por tres, pero que mantiene la misma capacidad de revisión, pruebas y control de calidad que tenía antes, no ganó velocidad real. Simplemente movió el cuello de botella más adelante en el proceso, y lo hizo más difícil de ver, porque en el momento de escribir el código todo se siente más rápido.
Esto explica por qué la relación entre uso de IA e inestabilidad de las entregas, documentada por DORA, no es una casualidad estadística. Es la consecuencia lógica de acelerar una parte del ciclo de desarrollo sin rediseñar el resto del proceso para sostener esa nueva velocidad.
Lo que sí funciona: IA en el ciclo completo, no solo en la generación de código
La diferencia entre los equipos que capturan valor real y los que acumulan deuda técnica disfrazada de productividad no está en qué tan buena es la herramienta de generación de código que usan. Está en si la IA participa solo en la parte más visible del ciclo, escribir líneas de código, o si participa también en las partes que antes dependían completamente de tiempo humano: revisión de pull requests con criterio consistente, generación de pruebas que cubren casos reales y no solo el camino feliz, documentación que se mantiene actualizada porque se genera como parte del flujo y no como una tarea aparte que siempre se pospone, y detección temprana de patrones de duplicación o riesgos de seguridad antes de que lleguen a producción.
Cuando la IA participa en todo el ciclo, y no solo en la fase de escritura, la velocidad ganada sí se traduce en una ganancia neta, porque el proceso completo se diseñó pensando en esa nueva capacidad, no se le agregó un acelerador a una sola etapa dejando las demás como cuello de botella.
Esta es, en el fondo, la misma lógica que separa a una empresa que instala herramientas de IA de una que rediseña su operación alrededor de ella: el beneficio real no viene de acelerar un paso aislado, sino de repensar el flujo completo asumiendo que la IA participa en cada etapa, no solo en la más visible. En el ciclo de desarrollo de software esto se traduce en algo muy concreto: la generación de código deja de ser el único lugar donde la IA interviene, y se convierte en una de varias etapas donde participa con un propósito específico y con el mismo nivel de supervisión que cualquier otra.
Cómo se ve esto en la práctica
La forma más clara de evitar que la velocidad se convierta en deuda es tratar cada uno de estos puntos como parte del diseño del flujo de trabajo, no como una responsabilidad adicional que se le pide a la misma persona que ya está escribiendo código más rápido:
Revisión de código asistida, no reemplazada. Un agente que ayuda a detectar duplicación, riesgos de seguridad y desviaciones de la arquitectura del proyecto antes de que un humano revise el pull request, para que la revisión humana se enfoque en las decisiones de fondo, no en encontrar lo que una herramienta ya podía detectar.
Pruebas generadas junto con el código, no después. Cuando la generación de pruebas queda como una tarea separada y posterior, es la primera que se sacrifica cuando hay presión de tiempo. Integrarla al mismo flujo donde se genera el código reduce esa tentación.
Documentación como parte del proceso, no como deuda que se acumula. La documentación que depende de que alguien la escriba "cuando tenga tiempo" casi nunca se mantiene actualizada. Generarla como parte del mismo flujo de trabajo es lo que la mantiene viva.
Visibilidad real sobre deuda técnica acumulada, no solo sobre velocidad de entrega. Los equipos que solo miden cuántas tareas se completan por semana no tienen forma de ver la deuda que se está acumulando hasta que ya es un problema grande. Medir duplicación, cobertura de pruebas y estabilidad de entregas junto con la velocidad da una imagen completa, no solo la mitad favorable.
No se trata de frenar la adopción, se trata de diseñarla bien
Nada de esto es un argumento para dejar de usar IA en desarrollo de software. La misma investigación que documenta los riesgos también documenta beneficios reales: mejor documentación, revisiones de código más rápidas, y equipos que sí logran acelerar de forma sostenida cuando el proceso alrededor de la IA está bien diseñado.
El error no es adoptar IA en el ciclo de desarrollo. El error es adoptarla solo en la parte más visible y vistosa del proceso, generar código más rápido, sin rediseñar el resto del flujo para sostener esa velocidad de forma confiable. Esa es exactamente la diferencia entre ganar velocidad real y acumular deuda técnica que todavía no se ha cobrado.
La pregunta que vale la pena hacerse
No es cuánto más rápido está generando código tu equipo esta semana. Es qué tan seguro estás de que ese código va a seguir siendo fácil de mantener, seguro y libre de duplicación seis meses después, y si tu proceso de revisión, pruebas y documentación evolucionó al mismo ritmo que tu capacidad de generar código, o se quedó exactamente donde estaba antes de que la IA entrara al flujo.
En Mobiik operamos IA a lo largo de todo el ciclo de desarrollo de software, no solo en la generación de código, con revisión, pruebas y documentación integradas al mismo flujo de trabajo para que la velocidad que se gana hoy no se convierta en la deuda técnica de mañana. Si quieres entender qué tan sólido es el proceso detrás de la velocidad de tu equipo, conversemos.
