El equipo de ingeniería de Agoda dedicó bastante tiempo a promover herramientas de programación con IA y luego hizo un balance. La conclusión es inquietante:
La productividad individual de los desarrolladores aumentó, pero la velocidad general de entrega del proyecto apenas se movió.
Esto no es un problema exclusivo de Agoda. Faros AI recopiló datos de varias empresas y presentó cifras preocupantes:
Los equipos con alta adopción de IA experimentaron un aumento del 98 % en las fusiones de PR y un aumento del 21 % en las tareas completadas. Pero, al mismo tiempo, el tiempo de revisión de los PR aumentó un 91 %.
Más producción, pero revisiones más lentas. Los dos efectos casi se anulan mutuamente.
Cuál es el verdadero cuello de botella
El equipo de ingeniería de Agoda concluyó que el problema radica en que "codificar nunca fue el principal cuello de botella en la entrega de software".
El autocompletado con IA hace que escribir código sea más rápido. Pero escribir código es solo un paso en la línea de producción – antes vienen el análisis de requisitos, el diseño del sistema, la alineación de la solución técnica; después vienen la revisión de código, las pruebas, la integración y el despliegue.
Acelerar el paso del medio tres veces no significa que toda la línea de producción sea tres veces más rápida.
Cuando la IA hace que la producción de código se dispare, la capacidad de "digerir ese código" se convierte en el nuevo cuello de botella:
- Cada PR contiene más código (el código generado por IA a menudo no es conciso)
- La revisión de código tiene que examinar más cosas
- Pero el tiempo de los ingenieros senior es limitado
El cuello de botella pasó de "escribir código lento" a "revisar código lento", y el ritmo real de entrega no mejoró.
El problema más profundo: Especificación
El ingeniero de Agoda, Leonardo Stern, va más allá: cree que el recurso realmente escaso se ha desplazado hacia arriba – no es la Revisión, sino la Especificación – la capacidad de transformar requisitos de negocio vagos en especificaciones técnicas claras y ejecutables.
Antes, los ingenieros pasaban mucho tiempo escribiendo código, la especificación podía ser vaga, porque "escribiendo se aclara".
Ahora, le das un requisito vago a la IA, y ella genera código que "parece utilizable" pero va en la dirección equivocada. Luego vuelves a ajustar la spec, la IA genera de nuevo, varias rondas. Superficialmente, la producción de código es alta, pero en realidad estás probando errores con código, la eficiencia no es buena.
Las especificaciones de requisitos de alta fidelidad se están convirtiendo en el artefacto central de ingeniería. No el código en sí, sino "cómo describir lo que se quiere".
El método de "Caja Gris" de Stern
Stern propuso un método de trabajo llamado "Caja Gris", situado entre dos extremos:
- Caja Blanca: Cada línea de código generada por IA se revisa, eres totalmente responsable de los detalles de implementación
- Caja Negra: La IA escribe y va directo a producción, eres responsable del resultado pero no del proceso
- Caja Gris: Intervención en dos puntos clave – escribir una spec precisa y verificar si el resultado cumple con la spec
La lógica central de la Caja Gris es: no necesitas entender qué método usó la IA para resolver el problema, pero debes poder decir claramente "qué significa resuelto" y verificar que realmente se resolvió.
La esencia de este método es concentrar el tiempo y la atención del ingeniero en lo que la IA hace peor – definir la intención y verificar los resultados, en lugar de los detalles de implementación.
Hacia dónde se dirige el rol del ingeniero
En la suposición tradicional del rol del ingeniero de software, "escribir buen código" era la competencia central.
Ahora, esa suposición se está tambaleando. Cuando la IA puede escribir código de calidad aceptable, ¿de dónde proviene la escasez del ingeniero?
Por la práctica de empresas como Agoda, la respuesta apunta en esta dirección:
- Personas que pueden transformar problemas de negocio en especificaciones técnicas precisas
- Personas que pueden diseñar esquemas de verificación efectivos
- Personas que pueden evaluar si el código generado por IA realmente resolvió el problema correcto
Esto no significa que "la capacidad de escribir código ya no sea importante" – sino que esa capacidad pasó de ser un recurso escaso a un requisito básico, y la verdadera diferenciación está más arriba en la cadena.
En palabras de Stern: La autoridad humana se está desplazando de "escribir código" a "definir intenciones". Esto es un cambio hacia un nivel más alto de abstracción, no la desaparición de habilidades.
Cómo debería ver esto la gerencia
Para los gerentes de ingeniería, el estudio de Agoda ofrece una recomendación directa: No midas el valor de la IA por la cantidad de código producido.
Número de PR, líneas de código, tareas completadas – todos estos indicadores mejorarán con las herramientas de IA. Pero si las funcionalidades entregadas no aumentaron, no se volvieron más rápidas y la calidad no mejoró, estos números son solo números.
Los indicadores que realmente vale la pena seguir son: ciclo de lanzamiento de funcionalidades, tasa de defectos en producción, tiempo de extremo a extremo desde el requisito hasta la entrega. Estos números te dirán si la IA realmente está ayudando al equipo o solo ayudando al equipo a "maquillar datos" en GitHub.
La próxima vez que alguien presente números de fusiones de PR para mostrar el ROI de una herramienta de IA, puedes preguntar: ¿Y el tiempo de revisión?
Fuente de referencia: CocoLoop, AI Coding Assistants Haven't Sped Up Delivery Because Coding Was Never the Bottleneck (InfoQ)