Raiffeisenbank dio agentes de IA a 500 ingenieros, pero la velocidad no aumentó. Por qué

Raiffeisenbank ha presentado los resultados de la segunda parte de su experimento de adopción de IA en una organización de ingeniería de 500 especialistas: la aceleración local de roles concretos mediante agentes de programación no modificó las métricas clave Lead Time, Throughput y Defect Rate.

Por qué los copilotos no aceleraron al equipo

Dar agentes de programación a los ingenieros no cambia, por sí solo, la velocidad del sistema. Es la conclusión de la primera parte del experimento, que Raiffeisenbank compartió en su blog de Habr. Según los autores, se puede aumentar el MAU LLM (la audiencia mensual del modelo de lenguaje), luego el MAU API (el número de llamadas a través de la API), repartir agentes de programación entre las personas y aun así no ver cambios en tres métricas de ingeniería: Lead Time (tiempo desde la idea hasta el resultado), Throughput (capacidad del proceso de desarrollo) y Defect Rate (proporción de defectos en el código publicado).

Estas tres métricas son un indicador estándar de la salud de un proceso de ingeniería, y los autores del blog consideran que su estabilidad tras la adopción masiva de IA es el principal resultado de la primera parte del experimento.

• El experimento abarca la organización de ingeniería de Raiffeisenbank, con 500 especialistas
• Métricas que no cambiaron tras adoptar IA: Lead Time, Throughput, Defect Rate
• La aceleración local choca con los requisitos, la revisión, las pruebas, las aprobaciones, los equipos vecinos y los expertos de negocio
• El siguiente paso de la compañía es pasar a Agentic Engineering

Dónde se pierde realmente la velocidad

Acelerar a una persona o a un rol no acelera el sistema entero, explican los autores del blog de Raiffeisenbank: la tarea sigue pasando por todas las demás etapas del proceso. Un empleado puede empezar a hacer su parte más rápido, pero el resultado sigue esperando turno para revisión, pruebas, aprobación o la decisión de un equipo vecino. Los autores lo describen como un problema de optimización local: acelerar un eslabón de la cadena no cambia el rendimiento global si el cuello de botella está en otro punto del proceso, como los revisores, los testers o las áreas que aprueban.

«Una persona o un rol pueden empezar a hacer su parte más rápido, pero la tarea sigue esperando requisitos, revisión, pruebas, aprobaciones, equipos vecinos o un experto de negocio», dice el blog de

Raiffeisenbank en Habr.

Qué viene: Agentic Engineering

Raiffeisenbank no se quedó en repartir herramientas a ingenieros individuales y decidió ir más lejos, hacia lo que la compañía llama Agentic Engineering. En la industria, este término suele describir el paso de asistentes de IA puntuales para un solo desarrollador a agentes integrados en el proceso a nivel de equipos y etapas, y no solo en el puesto de trabajo de una persona. Qué entiende exactamente Raiffeisenbank por este concepto y cómo resolverá el problema de las aprobaciones y las colas entre roles, lo promete explicar en la continuación de su serie de artículos en Habr. El material se presenta expresamente como la segunda parte de la historia de la adopción de IA en 500 ingenieros.

Qué significa

El caso de Raiffeisenbank muestra que repartir herramientas de IA a los ingenieros de forma individual no acelera el desarrollo si los cuellos de botella persisten en las uniones entre roles y equipos. El efecto real aparece solo cuando la aceleración alcanza al proceso completo y no al trabajo de una sola persona.