La IA acelera el desarrollo de código. ¿Acelera la entrega?

Pedimos a los equipos que aceleren, pero buena parte del plazo se decide en sitios donde ellos no tienen capacidad de actuación. La relación entre IA y entrega de software obliga a mirar también las revisiones, las dependencias y las decisiones que quedan pendientes.

Un equipo terminó un cambio un lunes. Llegó a producción once días después.

El trabajo en sí llevó unas cuatro horas. El resto fue esperar. Primero una aprobación que fue pasando de mano en mano porque nadie tenía claro a quién le tocaba, y que volvió con unos criterios que el equipo no conocía. Hubo que revisar el cambio, rehacer una parte y empezar otra conversación. Mientras tanto, la fecha de entrega seguía en el calendario y en alguna reunión alguien pedía al equipo un último esfuerzo.

Es un caso que te sonará porque ocurre en muchas corporaciones, aunque las cifras son ilustrativas. Pero si trabajas en una organización con una regulación fuerte, probablemente lo reconozcas sin que te lo explique.

Mi tesis es ésta: muchos retrasos que atribuimos a los equipos son decisiones de dirección que nadie ha tomado. Una responsabilidad sin dueño, un criterio que nadie ha publicado, una dependencia entre áreas que sigue ahí porque nadie tiene el encargo de resolverla. El equipo puede esforzarse todo lo que quiera, que esa parte del plazo no depende de él.

Acelerar el código no acorta el plazo

Coge un papel y hagamos una cuenta sencilla. Un cambio tarda diez días en llegar a producción y programarlo son dos de esos diez. El resto es revisión, pruebas, aprobaciones, coordinación y espera. Si el equipo programa el doble de rápido, ahorra un día. El cambio llega en nueve días, no en cinco.

Nada de esto es nuevo. Es la teoría de restricciones de Goldratt: mejorar lo que no es el cuello de botella apenas mueve el resultado. Y es también la razón por la que en el mundo Lean se habla de eficiencia de flujo, es decir, de qué parte del tiempo total el trabajo está siendo trabajado y qué parte está esperando. En muchas organizaciones esa proporción es difícil de asimilar cuando alguien se atreve a calcularla. Lo que quiero añadir a esa conversación es una pregunta más: de cada espera, ¿quién es el dueño?

La IA tiene que pasar la misma prueba

Casi todas las compañías han puesto asistentes de código en manos de sus equipos, y la expectativa en los comités es fácil de vislumbrar: si escribir código cuesta menos, entregaremos antes. La cuenta hecha en la hoja de papel ya dice que no tiene por qué ser así, y los datos disponibles piden prudencia.

En 2025, METR hizo un ensayo con dieciséis desarrolladores veteranos que trabajaban en repositorios de código abierto que ellos conocían. Con IA tardaron un 19 % más en completar las tareas, aunque ellos creían haber ido más rápido [4]. Eran herramientas de principios de 2025 y un contexto muy concreto, así que conviene no generalizar. El informe DORA de ese año es más matizado: ya ve una relación positiva entre adoptar IA y el rendimiento de la entrega, pero la adopción sigue asociada a más inestabilidad. Sus autores lo resumen diciendo que la IA acelera el desarrollo y que esa aceleración deja al descubierto debilidades que están más adelante en el recorrido [5].

Mi lectura es que la velocidad que se ve en una demo no dice nada del recorrido completo. Si una herramienta o un agente reduce el tiempo de una tarea, lo que me interesa es qué pasa después. Quizá haya más código que revisar, quizá cambie la evidencia que hace falta para aceptar el resultado, quizá aparezca una supervisión que antes no era necesaria. Hay que medirlo antes de darlo por bueno.

Quién es dueño de la espera

Volvamos a la aprobación del principio. Lo que parecía lentitud era otra cosa: unos criterios que no estaban claros y una responsabilidad mal definida. El equipo perseguía respuestas inmediatas, y quien revisaba recibía peticiones incompletas. Los dos acababan perdiendo tiempo en reconstruir lo que tendría que haber estado claro desde el principio.

No hace falta quitar ningún control para arreglarlo. Áreas como seguridad, arquitectura y gobierno tienen responsabilidades dentro de las organizaciones. Lo que sí se puede hacer es acordar qué evidencia necesita cada tipo de cambio, publicar los criterios y dar a alguien el encargo explícito de resolver las excepciones. Si una validación va a condicionar el diseño, mejor plantearla antes de construir.

Otro caso que podría llegar a ocurrir. Una funcionalidad llega a validación y aparece una excepción de negocio que nadie había concretado. Resolverla obliga a cambiar el comportamiento, rehacer pruebas y tocar una dependencia con otro equipo. El problema empezó antes de escribir una línea de código: había una duda importante y se siguió adelante sin resolverla. Cuando por fin se aclara, ya hay trabajo construido sobre otra interpretación.

Aquí probaría una conversación temprana entre producto, desarrollo y pruebas, centrada solo en los supuestos que más pueden descolocar el resultado. Unos cuantos ejemplos de aceptación y una persona a la que poder preguntar rinden más que otro documento sin destinatario claro. Y hay que vigilar el coste, porque si llenamos la agenda de reuniones habremos cambiado un problema por otro.

Cómo medirlo sin engañarnos

Hay tres marcos que ayudan a interpretar situaciones como estas: DORA, SPACE y la investigación sobre Developer Experience.

DORA mide el rendimiento de la entrega y cómo evoluciona. Su guía actual usa cinco métricas, y el change lead time cuenta desde que el cambio se registra en el control de versiones hasta que llega a producción [1]. Eso recoge la espera por aprobación de mi primer caso, siempre que ocurra después de ese momento, pero no lo que pasó antes.

SPACE recuerda que la productividad tiene varias dimensiones y no se deduce de una única métrica ni del volumen de actividad: satisfacción y bienestar, rendimiento, actividad, comunicación y colaboración, eficiencia y flujo [2]. Terminar más tareas no basta para saber si estamos haciendo mejor software.

Noda, Storey, Forsgren y Greiler proponen estudiar la experiencia de desarrollo a través de los ciclos de feedback, la carga cognitiva y el estado de flujo, y combinar lo que cuentan las personas con los datos de los sistemas [3]. Los registros dicen cuándo pasó algo. Las personas dicen qué significó para su trabajo.

Ninguna de las tres da un diagnóstico automático ni garantiza que una intervención concreta funcione. Sirven para formular mejores hipótesis. Y tampoco basta con que suba la satisfacción para concluir que ha mejorado la entrega.

Queda un tema más. Una hora menos de espera no equivale a una hora de trabajo recuperada, porque quizá el equipo ha avanzado en otra tarea. Disponer de capacidad tampoco es lo mismo que haber ahorrado. El beneficio suele estar en entregar antes, rehacer menos o poder comprometer una fecha con más confianza, y eso es lo que entiende un comité de dirección cuando se le pide justificar una inversión.

Qué haría el lunes por la mañana

Elegiría una dificultad que se repita en un servicio y reconstruiría varios cambios recientes con quienes los desarrollaron y con quienes intervinieron en ese paso. Dónde se pararon, qué faltaba, qué permitió seguir. Es el primer paso del método que estoy documentando como Engineering Friction Map, y a menudo revela que lo que parecía falta de capacidad era una responsabilidad poco clara.

Después, un pequeño cambio. En la aprobación del primer caso serían criterios accesibles y un responsable para una categoría de peticiones. Antes de empezar dejaría por escrito qué debería mejorar, qué control no se toca y cuándo vamos a mirar los resultados.

Compararía peticiones parecidas, teniendo en cuenta su complejidad y el volumen de trabajo. Si una cola baja y la siguiente crece, lo único que habremos hecho es mover la espera de un sitio a otro, y habrá que mirar más adelante en el proceso. Si la intervención cuesta más esfuerzo del que evita, se ajusta o se abandona.

Una decisión que le toca a dirección

Pedir resultados implica fijarse en lo que los equipos pueden decidir y en lo que depende de otros. Cuando una dificultad se repite y nadie puede resolverla desde su puesto, deja de ser un asunto del equipo. Es una decisión pendiente de dirección, y ninguna herramienta, tampoco la IA, va a tomarla por nosotros.

Si exigimos fechas, deberíamos dedicar el mismo empeño a revisar las condiciones que las hacen posibles.

De eso quiero hablar en Engineering Experience: escuchar cómo se trabaja de verdad, contrastarlo con datos y asumir las decisiones que nos corresponden. Esta es la primera entrega y habrá más.

Te dejo una pregunta para vuestra próxima entrega: ¿qué podría retrasarla que el equipo no controla, y quién tiene capacidad para cambiarlo?

Referencias

[1] DORA. DORA’s software delivery performance metrics. Guía actualizada el 5 de enero de 2026 (comprobar la fecha antes de publicar).

[2] Forsgren, N.; Storey, M.-A.; Maddila, C.; Zimmermann, T.; Houck, B.; Butler, J. (2021). The SPACE of Developer Productivity: There’s More to It Than You Think. ACM Queue, 19(1).

[3] Noda, A.; Storey, M.-A.; Forsgren, N.; Greiler, M. (2023). DevEx: What Actually Drives Productivity. ACM Queue, marzo-abril de 2023 (sustituir el enlace por el de ACM Queue).

[4] METR (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Julio de 2025.

[5] DORA / Google Cloud (2025). Announcing the 2025 DORA Report: State of AI-assisted Software Development. 23 de septiembre de 2025.