L'équipe d'ingénierie d'Agoda a consacré beaucoup de temps à promouvoir les outils de codage IA, puis a fait le point. La conclusion est dérangeante :
La productivité individuelle des développeurs a augmenté, mais la vitesse globale de livraison du projet n'a quasiment pas bougé.
Ce n'est pas un problème propre à Agoda. Faros AI a compilé des données provenant de plusieurs entreprises et a fourni des chiffres préoccupants :
Les équipes à forte adoption de l'IA ont vu le nombre de fusions de PR augmenter de 98 % et le nombre de tâches terminées augmenter de 21 %. Mais dans le même temps, le temps de revue des PR a augmenté de 91 %.
Plus de production, mais des revues plus lentes. Les deux effets s'annulent presque mutuellement.
Quel est le véritable goulot d'étranglement
L'équipe d'ingénierie d'Agoda estime que le problème vient du fait que « le codage n'a jamais été le principal goulot d'étranglement dans la livraison de logiciels ».
L'autocomplétion par IA rend l'écriture de code plus rapide. Mais écrire du code n'est qu'une étape de la chaîne – avant viennent l'analyse des besoins, la conception du système, l'alignement de la solution technique ; après viennent la revue de code, les tests, l'intégration et le déploiement.
Accélérer l'étape du milieu par trois ne signifie pas que toute la chaîne sera trois fois plus rapide.
Lorsque l'IA fait exploser la production de code, la capacité à « digérer ce code » devient le nouveau goulot d'étranglement :
- Chaque PR contient plus de code (le code généré par IA n'est souvent pas concis)
- La revue de code doit examiner davantage d'éléments
- Mais le temps des ingénieurs seniors est limité
Le goulot d'étranglement est passé de « écrire du code lentement » à « revoir le code lentement », et le rythme réel de livraison ne s'est pas amélioré.
Le problème plus profond : la spécification
L'ingénieur d'Agoda, Leonardo Stern, va plus loin : il estime que la ressource vraiment rare s'est déplacée vers le haut – ce n'est pas la revue, mais la spécification – la capacité à transformer des besoins métier vagues en spécifications techniques claires et exécutables.
Avant, les ingénieurs passaient beaucoup de temps à écrire du code, la spécification pouvait être vague, car « en écrivant, on clarifie ».
Maintenant, vous donnez un besoin vague à l'IA, et elle génère un code qui « semble utilisable » mais qui va dans la mauvaise direction. Ensuite, vous revenez modifier la spec, l'IA regénère, plusieurs cycles. En apparence, la production de code est élevée, mais en réalité, vous testez des erreurs avec du code, l'efficacité n'est pas bonne.
Les spécifications de besoins à haute fidélité deviennent l'artefact central du génie logiciel. Pas le code lui-même, mais « comment décrire ce que l'on veut ».
La méthode « Boîte Grise » de Stern
Stern a proposé une méthode de travail appelée « Boîte Grise », située entre deux extrêmes :
- Boîte Blanche : Chaque ligne de code générée par IA est revue, vous êtes entièrement responsable des détails d'implémentation
- Boîte Noire : L'IA écrit et va directement en production, vous êtes responsable du résultat mais pas du processus
- Boîte Grise : Intervention à deux points clés – écrire une spec précise et vérifier que le résultat est conforme à la spec
La logique centrale de la Boîte Grise est : vous n'avez pas besoin de comprendre quelle méthode l'IA a utilisée pour résoudre le problème, mais vous devez être capable de dire clairement « ce qui signifie résolu » et de vérifier qu'il est effectivement résolu.
L'essence de cette méthode est de concentrer le temps et l'attention de l'ingénieur sur ce que l'IA fait le moins bien – définir l'intention et vérifier les résultats, plutôt que les détails d'implémentation.
Où va le rôle de l'ingénieur
Dans l'hypothèse traditionnelle du rôle de l'ingénieur logiciel, « écrire du bon code » était la compétence centrale.
Maintenant, cette hypothèse est ébranlée. Lorsque l'IA peut écrire du code de qualité acceptable, d'où vient la rareté de l'ingénieur ?
D'après la pratique d'entreprises comme Agoda, la réponse s'oriente dans cette direction :
- Les personnes capables de transformer des problèmes métier en spécifications techniques précises
- Les personnes capables de concevoir des schémas de vérification efficaces
- Les personnes capables d'évaluer si le code généré par l'IA a réellement résolu le bon problème
Cela ne signifie pas que « la capacité à écrire du code n'est plus importante » – mais que cette capacité est passée d'une ressource rare à un seuil de base, et la véritable différenciation se situe plus en amont.
Selon Stern : L'autorité humaine se déplace de « l'écriture de code » vers « la définition de l'intention ». C'est un déplacement vers un niveau d'abstraction plus élevé, pas une disparition des compétences.
Comment la direction devrait voir cela
Pour les responsables d'ingénierie, l'étude d'Agoda fournit une recommandation directe : Ne mesurez pas la valeur de l'IA par la quantité de code produite.
Nombre de PR, lignes de code, tâches terminées – tous ces indicateurs vont s'améliorer avec les outils d'IA. Mais si les fonctionnalités livrées n'ont pas augmenté, ne sont pas devenues plus rapides et si la qualité ne s'est pas améliorée, ces chiffres ne sont que des chiffres.
Les indicateurs qui valent vraiment la peine d'être suivis sont : le cycle de mise en production des fonctionnalités, le taux de défauts en production, le temps de bout en bout du besoin à la livraison. Ces chiffres vous diront si l'IA aide vraiment l'équipe ou si elle aide seulement l'équipe à « maquiller les données » sur GitHub.
La prochaine fois que quelqu'un vous présentera des chiffres de fusions de PR pour montrer le ROI d'un outil d'IA, vous pourrez demander : Et le temps de revue ?
Source de référence : CocoLoop, AI Coding Assistants Haven't Sped Up Delivery Because Coding Was Never the Bottleneck (InfoQ)