La IA acelera lo que escribes, no lo que puedes desplegar

De las dos cosas que el informe DORA dijo sobre la IA en 2024, en 2025 observó lo contrario en una y exactamente lo mismo en la otra. La que no se movió es la que cuesta dinero: «AI adoption does continue to have a negative relationship with software delivery stability». Más IA sigue viniendo con menos estabilidad de entrega. Dos informes seguidos, mismo signo.

Conviene decir de entrada de qué va esto y de qué no. No va de si la IA sirve: la usamos a diario y aquí no vamos a fingir lo contrario. Va de dónde acaban las horas que promete. Y la respuesta que sale de los datos disponibles no es «en ningún sitio», que sería el titular cómodo del escéptico. Es bastante más incómoda: acaban aguas abajo, en la parte del proceso que casi nadie presupuesta porque no tiene logotipo ni suscripción mensual.

Dos informes seguidos, un signo que no cambia

La edición de 2024, con unos 3.000 encuestados y el 75,9 % de ellos apoyándose ya en IA para parte de su trabajo, estimaba que un aumento del 25 % en la adopción de IA venía acompañado de una caída del 1,5 % en el rendimiento de entrega y del 7,2 % en la estabilidad de entrega. Esas dos cifras se publicaron el mismo año en que casi todo el sector estaba contando lo contrario.

Un año después, con casi 5.000 profesionales encuestados y más de cien horas de material cualitativo, el primer número se dio la vuelta: «Unlike last year, we observe a positive relationship between AI adoption on both software delivery throughput and product performance». Los equipos entregan más. El 90 % de los encuestados usa IA en el trabajo y más del 80 % dice que le ha subido la productividad. El 30 % declara poca o ninguna confianza en el código que genera —«a slightly lower percentage than last year», matiza el informe—, y la estabilidad siguió donde estaba: en negativo.

Antes de construir nada encima, el matiz honesto: esto es una encuesta, no un experimento. Son correlaciones sobre respuestas de personas que se autoevalúan, con todo lo que eso arrastra. La productividad percibida del 80 % es exactamente el tipo de dato del que hay que desconfiar, y por eso vale la pena mirar el trabajo reciente que, en vez de preguntar, puso un reloj.

El experimento que sí puso un reloj

En julio de 2025, METR publicó un ensayo aleatorizado con 16 desarrolladores experimentados y 246 tareas reales sobre repositorios de código abierto grandes —de media, más de 22.000 estrellas y más de un millón de líneas— en los que esas personas llevaban años contribuyendo. No eran novatos con un proyecto nuevo: era gente en su propia casa. Con IA permitida tardaron un 19 % más.

Lo que hace memorable ese estudio no es el 19 %. Es lo otro: antes de empezar, los participantes pronosticaron que la IA les recortaría un 24 % el tiempo; después de haber hecho las tareas y de haber ido más lentos, seguían estimando una mejora del 20 %. Habían vivido el experimento entero y no lo notaron. Entre lo que marcó el reloj y lo que recordaban no hay un matiz de grado: hay un cambio de signo. Y la decisión de comprar herramientas, contrataciones y licencias se toma siempre con lo segundo.

Y ahora la parte que casi nadie cita cuando usa este estudio como arma arrojadiza, empezando por los que lo usan contra la IA. Los propios autores dicen que no afirman que el resultado valga para la mayoría de desarrolladores ni para otros dominios, y describen su trabajo como «a snapshot of early-2025 AI capabilities in one relevant setting» — una foto fija de lo que hacían los modelos a principios de 2025 en un escenario concreto. Y en febrero de 2026 fueron mucho más lejos: se desmarcaron de su propio número.

Lo que publicaron el 24 de febrero de 2026 es esto: entre el 30 % y el 50 % de los participantes les dijeron que dejaban de enviar tareas porque no querían hacerlas sin IA, con lo que las que sí entraron en el experimento estaban sesgadas en contra de la herramienta; y sobre las estimaciones de su segundo ensayo escriben que «our estimate reported above is a lower-bound on the true productivity effects of AI on these developers». Ese segundo ensayo, arrancado en agosto de 2025 con 57 desarrolladores, 143 repositorios y más de 800 tareas, da −18 % para los participantes originales (intervalo de confianza de −38 % a +9 %) y −4 % para los nuevos (de −15 % a +9 %): dos intervalos que cruzan el cero. METR califica sus propios datos de «an unreliable signal» y añade que, por lo que les cuentan los participantes, es probable que a principios de 2026 la IA les acelere más de lo que midieron en 2025.

Así que no: el 19 % no demuestra que la IA te frene, y quien lo esté usando este año como prueba de eso está citando un número del que sus autores ya se han distanciado. Lo que queda en pie es más aburrido y más útil: no sabes si te frena o te acelera hasta que lo mides, tu impresión no sirve como medida, y ni siquiera un equipo que se dedica a medir esto consigue un intervalo que no cruce el cero. Si ellos no pueden afirmarlo con 800 tareas cronometradas, la sensación de tu equipo en la reunión del lunes tampoco.

Adónde se fue el tiempo: a revisar

DORA lo resume en una frase que explica los dos resultados a la vez: «time saved in creation is frequently re-allocated to auditing and verification». El tiempo que te ahorras escribiendo se reasigna a comprobar. Y en las entrevistas cualitativas aparecen las frases que uno oye en cualquier equipo un martes por la tarde: «I spend more time babysitting the AI and reviewing what it is trying to do», y esta otra, que es la que de verdad importa para lo que viene después: «Reviewing [another's] code is so much harder than writing it. AI tools are increasing the rate at which people can churn out code that needs to be reviewed».

Esto último es una opinión nuestra y la marcamos como tal: revisar código de un compañero es caro, pero revisar código de un modelo es peor, porque al compañero le puedes preguntar por qué lo hizo así y la respuesta cambia lo que buscas. Al modelo le preguntas y te da una explicación igual de fluida tanto si acertó como si no. Se revisa sin la pista que más ahorra tiempo.

La frase del informe que explica la factura

Traducido y sin adornos: la IA acelera, y esa aceleración destapa las debilidades que ya tenías más abajo. Sin sistemas de control sólidos —pruebas automáticas serias, prácticas maduras de control de versiones, realimentación rápida—, más volumen de cambio se convierte en inestabilidad. Fíjate en el verbo: expose. No dice que la IA cree la grieta. Dice que sube el caudal hasta que la grieta se ve.

Es exactamente la misma idea con la que llevamos años explicando la resiliencia de infraestructura, y por eso este informe nos suena tan familiar: el fallo es inevitable, la avería es una decisión de diseño. Un cambio que rompe algo va a ocurrir, escríbalo quien lo escriba. Que ese cambio tumbe el servicio, o que se quede parado en un entorno de pruebas un miércoles a las once, no lo decide la herramienta con la que se escribió. Lo decide lo que tienes montado debajo. El resumen del propio informe lo dice sin anestesia: «AI doesn't fix a team; it amplifies what's already there».

Lo que el informe de 2026 pone en dinero

El 11 de mayo de 2026 el mismo equipo publicó un informe de retorno de la inversión. Aquí hay que ser muy preciso con lo que es cada cosa, porque es un modelo, no una medición: para una organización de ingeniería de 500 personas, modela un retorno de unos 11,6 millones de dólares el primer año frente a 8,4 millones de inversión —un 39 % de retorno y unos ocho meses hasta recuperarla—. Nosotros no hemos auditado ese modelo y no lo presentamos como un hecho: lo citamos por lo que tiene dentro.

Dentro hay dos cosas que interesan más que el total. La primera es una partida negativa, y conviene leerla con cuidado porque es un supuesto del modelo y no un hallazgo: en el ejemplo de la calculadora se supone que la tasa de fallo del cambio pasa del 5 % al 6 % tras adoptar IA, y ese punto porcentual se contabiliza como 344.000 dólares de coste, con el razonamiento de que más código moviéndose más rápido «can overwhelm existing deployment pipelines and manual review gates». Un punto. La segunda es la conclusión, que se lee como un aviso: «The greatest returns on AI investment come not from the tools themselves but from a strategic focus on the underlying organizational system: the quality of the internal platform, the clarity of workflows, and the alignment of teams».

Si tu empresa tiene doce personas en desarrollo, esos millones no te dicen nada: no se dividen por cuarenta y salen tus números. Lo que sí se traslada es el orden de las causas. Que el mayor retorno no esté en la herramienta sino en la plataforma que tienes debajo es una afirmación incómoda para quien acaba de firmar licencias para todo el equipo y no ha tocado su proceso de despliegue desde hace tres años. Es la misma conclusión a la que llegamos en julio por otro camino, cuando Gartner calculó cuántos proyectos de agentes se cancelarían antes de acabar 2027 — allí la causa era el coste y la falta de línea base; aquí son datos y fuentes distintos y el resultado apunta al mismo sitio.

Las cuatro cosas que tienen que aguantar más caudal

No es una lista de buenas intenciones: cada punto lleva su medida, porque si no se mide vuelves al problema del principio —creerte más rápido sin serlo—.

Ninguna de las cuatro es nueva ni lleva IA dentro. Son las mismas que pedíamos antes de que existiera el problema, y esa es justamente la cuestión: lo que ha cambiado no es la lista, es la prisa. Lo mismo pasa con el calendario de la plataforma — quien opera Kubernetes ya sabe que la versión caduca sola, mires o no mires—; el volumen de cambio no espera a que termines de montar lo que le falta debajo.

Cuándo esto no va contigo

Toca declarar el conflicto de interés: nosotros vendemos plataforma, CI/CD y guardia. Cuando alguien como nosotros te dice «necesitas más plataforma», mira quién cobra la factura. Así que la parte honesta: si tu equipo son tres personas, despliegas una vez al mes y la última restauración de copia que probaste funcionó, no toques nada. Montar tuberías para un caudal que no tienes es otra forma de gastar mal, y encima una que se paga en complejidad todos los meses. La plataforma se dimensiona por el caudal de cambio real, no por el que te gustaría tener el año que viene.

Lo que sí conviene mirar con lupa es lo que se coló por la puerta lateral. Los pilotos de IA que alguien montó «para probar» y acabaron con cosas reales encima tienen su propia factura, y ya escribimos sobre lo que pasa cuando nadie los apaga: un piloto en producción sin dueño, sin ventana de actualización y sin inventario no es un experimento, es un servicio que nadie ha aceptado mantener.

La pregunta que sirve en un comité

La pregunta habitual es «¿cuánto nos ahorra la IA?», y ya hemos visto que se contesta con una percepción que en el primer experimento con reloj se equivocó en el signo. La que sirve es otra: ¿cuántos cambios más al mes puede absorber lo que tenemos montado sin que suba la tasa de fallo? Tiene la ventaja de que solo se puede contestar con números que ya existen o que no existen. Y si la respuesta es «no lo sabemos, porque no medimos la tasa de fallo», ahí está el primer trabajo del trimestre. No lleva IA, no da para una nota de prensa y es el que decide si el resto sirve de algo.

Fuentes (verificadas el 27-09-2026): las citas «Unlike last year, we observe a positive relationship…», «AI adoption does continue to have a negative relationship with software delivery stability», «AI accelerates software development, but that acceleration can expose weaknesses downstream…» y «AI doesn't fix a team; it amplifies what's already there», junto con los datos de casi 5.000 encuestados, el 90 % de uso, el 80 % de productividad percibida y el 30 % de poca o ninguna confianza — anuncio del informe DORA 2025 en el blog de Google Cloud. Las frases sobre reasignación del tiempo a verificación, las dos citas de ingenieros y «Working in small batches is a critical countermeasure…» — DORA, «Balancing AI tensions». Las estimaciones de 2024 (−1,5 % de rendimiento y −7,2 % de estabilidad por cada 25 % más de adopción, con 75,9 % de uso sobre unos 3.000 encuestados) las tomamos del análisis del informe de 2024 publicado por RedMonk, no del PDF original. El ensayo aleatorizado, el 19 %, las 16 personas, las 246 tareas, el 24 % pronosticado, el 20 % estimado después y la advertencia de los autores («a snapshot of early-2025 AI capabilities in one relevant setting») — METR, 10-07-2025, con el artículo en arXiv:2507.09089. El segundo ensayo (57 desarrolladores, 143 repositorios y más de 800 tareas, arrancado en agosto de 2025), los −18 % y −4 % con sus intervalos de confianza, el sesgo declarado del 30-50 % de participantes que dejaban de enviar tareas, «our estimate reported above is a lower-bound on the true productivity effects of AI on these developers», «an unreliable signal» y la expectativa de mayor aceleración en 2026 — nota de METR del 24-02-2026. Las cifras del informe de retorno del 11-05-2026 (11,6 M$, 8,4 M$, 39 %, ocho meses, el salto del 5 % al 6 % y los 344.000 $) y la cita «The greatest returns on AI investment…» las tomamos de la reseña de InfoQ, que habla de «the assumed change failure rate» — por eso aquí se presenta como supuesto de la calculadora y no como medición; la página del informe está publicada, pero no hemos abierto el PDF y lo decimos. Lo que es nuestro y no de las fuentes: la lectura de que el cuello de botella se desplaza a la entrega, la comparación entre revisar código de un compañero y de un modelo, las cuatro comprobaciones con su medida y la pregunta final. Los informes de DORA son encuestas con autoevaluación, no experimentos controlados, y así los citamos. Foto de portada: «LOOM office seating», Wikimedia Commons (CC0).