El costo oculto de la IA mal usada en desarrollo de software

La ganancia existe, pero no es la que te imaginas

La pregunta útil no es si la inteligencia artificial acelera el desarrollo. Es dónde acelera y cuánto.

El grupo de Productividad en Ingeniería de Software de la Universidad de Stanford, dirigido por Yegor Denisov-Blanch, mide esto sobre más de 100,000 ingenieros en más de 600 empresas. El resultado no es un número único, y ahí está lo interesante:

En lenguajes populares como Python o Java la ganancia va de 10% a 25%. En lenguajes de nicho —COBOL, Haskell, Elixir— va de −5% a 5%. Es decir, en algunos casos la herramienta resta.

Escribir algo nuevo y trivial no tiene nada que ver con mantener el core de un banco. Como explicamos en el artículo sobre desarrollo de software con inteligencia artificial, la diferencia la hace el método. Casi todo el software que sostiene la operación de una empresa grande peruana está en el cuadrante de abajo: heredado, complejo, a veces en tecnologías que ya nadie enseña. Ese es el cuadrante donde la ganancia es de un dígito. Y es el cuadrante que se usa para justificar el presupuesto, apoyándose en cifras que se midieron arriba.

Lo que siente tu equipo no es una medición

Cuando le preguntas a un equipo si la IA lo hizo más rápido, la respuesta casi siempre es que sí. Ese sí no es un dato.

La organización METR corrió en 2025 un ensayo controlado aleatorizado con desarrolladores experimentados trabajando en sus propios repositorios. Los participantes estimaron de antemano que ganarían 24% de tiempo. Al terminar creían haber ganado 20%. La medición dijo que habían tardado 19% más.

Hay que contar lo que pasó después, porque cualquiera que consulte la fuente lo va a encontrar. METR repitió el experimento a fines de 2025 con más muestra —57 desarrolladores, más de 800 tareas— y el resultado se debilitó: 18% más lentos en el grupo original, 4% en los nuevos, y en los dos casos el intervalo de confianza cruza el cero. Abandonaron ese diseño porque dejaron de poder reclutar: entre 30% y 50% de los participantes reconoció que evitaba enviar tareas que no quería resolver sin IA. La propia organización concluye que su estimación quedó como una cota inferior del efecto positivo.

Entonces la magnitud no se sostiene. Lo que sí se sostiene, y es lo que importa acá, es la brecha entre lo que la gente cree que rindió y lo que rindió. Los desarrolladores se equivocaron por más de cuarenta puntos sobre trabajo que acababan de terminar. El grupo de Stanford observa el mismo fenómeno con otra muestra: equipos que percibían 20% de mejora mientras rendían 20% peor en repositorios que ya conocían.

Vale poner encima el estudio más favorable a la IA que existe, porque es el que te va a citar un proveedor. Publicado en Management Science, con tres ensayos de campo y 4,867 desarrolladores, midió 26% más tareas completadas. Dos de sus seis autores trabajan en Microsoft, que vende la herramienta evaluada. Y su propio indicador de calidad se movió en contra: las compilaciones exitosas cayeron 5.53% en el conjunto y 17.40% en Accenture, donde el resultado sí fue significativo. Los autores lo explican por un aumento del código de prueba y error.

El estudio más favorable a la IA mide más entregas y peor calidad. Esa es la conversación real.

Lo primero que se rompe es la estabilidad

El programa DORA de Google Cloud mide rendimiento de entrega de software desde hace más de una década. En su informe de 2024, con cerca de 3,000 profesionales, encontró que por cada 25% de aumento en la adopción de IA dentro de una organización, la estabilidad de la entrega caía 7.2%.

Vale enfatizar en quién publica ese dato. DORA es de Google Cloud, que vende inteligencia artificial. No es un crítico buscando alguna debilidad: es el proveedor midiendo su propio ecosistema y reportando sus hallazgos.

Su informe de 2025, con cerca de 5,000 encuestados, mantiene esa relación negativa y explica el mecanismo: sin pruebas automatizadas sólidas, control de versiones maduro y ciclos de retroalimentación cortos, más volumen de cambios produce inestabilidad. La frase que ordena todo el asunto es esta: la IA no arregla a un equipo, amplifica lo que ya está ahí. Un equipo sólido mejora. Uno que ya venía con problemas los ve crecer.

En mayo de 2026 DORA modeló el costo: la tasa de fallo de cambios sube de 5% a 6% tras la adopción, con un impacto de caída de servicio estimado en 344,000 dólares. DORA no concluye que haya que frenar la adopción. Concluye que hay que invertir en pruebas automatizadas, integración continua y lotes de cambio pequeños.

El código se ve mejor y es más difícil de mantener

Una salvedad antes de desarrollar este punto. La empresa que publica las mediciones más completas sobre calidad de código es GitClear, que vende herramientas de análisis: tiene interés comercial en que el problema exista. Su análisis es correlacional, sin grupo de control, y nadie ha replicado sus métricas de forma independiente. Con esa reserva, la escala es difícil de ignorar.

Sobre 623 millones de cambios analizados entre 2023 y 2026, GitClear reporta que la refactorización —reescribir código existente para que quede más simple— cayó del 21% de las líneas modificadas en 2022 al 3.8% en 2026. En el mismo período la duplicación de bloques subió 81%, las llamadas a funciones entre archivos bajaron 35% y las actualizaciones de código heredado cayeron 74%.

Traducido a lo que le importa a un directorio: se escribe mucho más código, se reutiliza mucho menos y lo viejo se toca cada vez menos. Un desarrollador hoy tiene alrededor de cinco veces más probabilidad de copiar y pegar que de reordenar lo que ya existe. En 2022 el patrón era el inverso.

Eso tiene nombre y precio conocidos. Se llama deuda técnica, y no aparece en la factura del proyecto: aparece dieciocho meses después, cuando un cambio que debía tomar dos días toma tres semanas porque nadie entiende del todo por qué el sistema hace lo que hace.

La seguridad no se arregla sola con el próximo modelo

Este es el punto donde más gente supone que el tiempo juega a favor. Hay un año entero de datos que dice que no.

Veracode evalúa cada año más de cien modelos de lenguaje sobre tareas de programación donde la seguridad importa. En su edición de 2025, el 45% de las muestras introdujo vulnerabilidades del catálogo OWASP Top 10, la lista de referencia de fallas de seguridad en aplicaciones web. En la edición publicada el 28 de julio de 2026, esa cifra bajó al 44%.

Un punto porcentual en un año, mientras los modelos mejoraban de forma notoria en todo lo demás. El título del informe lo resume: los modelos se vuelven más inteligentes, no más seguros. La corrección sintáctica del código ronda el 100% y la seguridad quedó estancada en 56%.

El desglose de 2026 cierra la puerta al argumento de esperar la próxima versión:

• Da casi igual el tipo de modelo: los especializados en código aprueban 51%, los generalistas 52%, los grandes 53%, y los de razonamiento 56%.
• El mejor modelo evaluado llega a 68% y aun así falla en casi una de cada tres tareas de seguridad.

Hay un frente donde 2026 sí trajo mejora real, y hay que decirlo. Los modelos inventaban nombres de librerías que no existen: un trabajo académico presentado en USENIX Security 2025, sobre 576,000 muestras, encontró tasas de 5.2% en modelos comerciales y 21.7% en modelos abiertos. Una reevaluación de 2026 sobre 199,845 consultas con modelos actuales estrechó ese rango a 4.62% a 6.10%. La dispersión entre modelos se comprimió en un orden de magnitud. El riesgo, sin embargo, no desapareció: el mismo trabajo identificó 53 nombres de paquetes inventados que todavía pueden ser registrados por un atacante. Si alguien registra uno, el proyecto que lo pida termina instalando código ajeno.

A esto se suma un efecto humano medido en Stanford: los desarrolladores con acceso a un asistente escribieron código menos seguro y al mismo tiempo confiaban más en que su código era seguro. El modelo evaluado allí ya quedó obsoleto, así que el número no vale como estado del arte. El patrón de conducta sí: la herramienta baja la sospecha justo donde hace falta sospechar.

El cuello de botella se mudó de escribir a revisar

Si el equipo produce el doble de código, alguien tiene que leerlo.

Faros AI analizó telemetría de 22,000 desarrolladores en más de 4,000 equipos, con datos hasta marzo de 2026. Tras la adopción de asistentes de IA:

• el tiempo de revisión de las solicitudes de cambio subió 441.5% en la mediana
• los errores por desarrollador subieron 54%
• los incidentes por cambio integrado subieron 242.7%
• los cambios integrados sin ninguna revisión subieron 31.3%
• el tiempo entre escribir el código y verlo en producción subió 480.4%

La producción también creció: 34% más tareas por desarrollador. El problema no es que no se produzca. Es lo que llega a revisión: el código a menudo no está listo, y quien revisa termina haciendo el trabajo que debió hacerse antes.

Las reservas de siempre: Faros vende analítica de ingeniería y su estudio es observacional. Aun así describe algo que cualquier gerente de tecnología reconoce: la capacidad de revisar no creció al ritmo de la capacidad de producir. Y la revisión es el control que impide que todo lo anterior llegue a producción.

Por qué esto golpea distinto en el Perú

Acá tenemos, por primera vez, medición local. PwC Perú y la UTEC publicaron el 9 de agosto de 2026 un estudio sobre adopción de inteligencia artificial en empresas peruanas: el 79% de los ejecutivos aumentó su presupuesto de IA y el 64% la usa a diario. Entre las empresas de más de mil empleados, el 58% incrementó su inversión.

Y el dato que importa para esta conversación: solo el 10% tiene modelos de gobernanza de inteligencia artificial integrados.

Esa es la tesis de DORA medida en el Perú. Si la IA amplifica lo que ya está ahí, y nueve de cada diez empresas están adoptándola sin gobierno, lo que se amplifica es la ausencia de controles. Debemos tener claro qué es ese estudio: una encuesta a ejecutivos, sin tamaño de muestra publicado, que mide inversión declarada y no adopción verificada.

Del lado de la oferta, PROMPERÚ describe un sector compuesto principalmente por micro, pequeñas y medianas empresas, con la escasez de perfiles especializados como obstáculo declarado. Un comprador de empresa grande está contratando, en buena parte de los casos, a proveedores sin capacidad estructural para sostener pruebas automatizadas, revisión de seguridad y control de versiones maduro. Que son exactamente los controles que DORA señala como condición para que la IA no genere inestabilidad.

Queda una ausencia que debemos nombrar: no existe medición pública de cómo se usa la IA en desarrollo de software en el Perú. Ninguna. Esa brecha es parte del problema: se adopta sin instrumentos para saber si funciona.

Qué puedes exigirle a tu proveedor

Nada de lo anterior es un argumento contra usar inteligencia artificial. Nosotros la usamos todos los días, y tenemos un marco de trabajo propio, AI-Forge, precisamente porque la diferencia no está en la herramienta sino en el método con que se aplica. Lo que la evidencia dice es que sin controles la IA acelera el deterioro con la misma eficiencia con que acelera la entrega.

Si estás evaluando a un proveedor que dice construir con inteligencia artificial, hay preguntas que se responden con evidencia o no se responden:

• Cómo mide la velocidad. Si la respuesta es que el equipo siente que va más rápido, no hay medición. Pide el dato de entrega antes y después.
• Qué ganancia espera en tu tipo de código. No es lo mismo un sistema nuevo que uno heredado. Un proveedor que ofrece el mismo porcentaje para los dos no midió ninguno.
• Qué pasa con la estabilidad. Con qué frecuencia falla un cambio en producción y cuánto tarda en recuperarse. Esa cifra debería existir antes de que aparezca la IA en la conversación.
• Quién revisa y con qué capacidad. Si el volumen de código sube, la revisión tiene que crecer con él. Pregunta cuántos ojos humanos pasan por un cambio antes de producción, y qué porcentaje pasa sin revisar.
• Cómo se controlan las dependencias. Qué mecanismo valida que cada librería que entra al proyecto existe, es la correcta y está mantenida.
• Qué pruebas de seguridad corre y sobre qué código. No sirve auditar solo lo que escribió una persona.
• Cómo mantiene lo ya construido. Si el proveedor solo sabe hablar de lo nuevo, el costo del sistema completo va a caer sobre ti.

Ninguna necesita un especialista. Son preguntas de gobierno y las siete caben en una reunión.

Conclusión

El costo de la IA mal usada rara vez aparece donde se firma el contrato. Aparece después: el código que nadie quiere tocar, el cambio que costaba dos días y ahora cuesta tres semanas, la vulnerabilidad que pasó porque el código se veía prolijo, el equipo que revisa cuatro veces más volumen con la misma gente.

La evidencia no dice que la IA empeore el software. Dice que amplifica el método que ya tenías. Si era sólido, acelera. Si no lo era, acelera el deterioro y lo vuelve más difícil de detectar, porque el resultado se ve mejor que antes.

Por eso la conversación útil con un proveedor no es cuánta inteligencia artificial usa. Es qué controles tiene puestos para que usarla no salga caro después.