Faros : dans les équipes qui utilisent des agents IA, le temps médian de revue de code a bondi de 441%

La télémétrie de Faros sur 22 000 développeurs montre que, dans les équipes à forte adoption de l'IA, le temps médian de revue de code a augmenté de 441%, et que les pull requests sans aucune revue sont mergées 31% plus souvent. Le temps économisé grâce aux agents, les humains le consacrent eux-mêmes à de nouvelles tâches et à la vérification du code d'autrui. En septembre, un auteur de Habr a écrit à des connaissances qui avaient commencé à travailler avec des agents IA quelques mois plus tôt, pour leur demander comment ça se passait.

Il s'attendait à des récits d'accélération, et il en a eu : l'un n'analyse plus les logs à la main, un autre a commencé à prendre des tâches en frontend, en backend et en DevOps. Mais la plupart parlaient d'autre chose : le volume de revue a fortement augmenté, une quantité d'informations bien plus grande leur passe sous les yeux, et le soir venu, il ne leur reste plus d'énergie pour leur propre projet. D'où la question : s'agit-il d'un creux temporaire ou d'une nouvelle norme ?

Le temps économisé, les développeurs le dépensent eux-mêmes

Les chercheurs de Berkeley Haas ont observé pendant huit mois une entreprise technologique américaine d'environ 200 personnes (les résultats ont été publiés par la HBR). Avec l'IA générative, les salariés travaillent plus vite, prennent des tâches plus larges et finissent plus tard, alors que personne ne l'exige. Les prompts partent pendant la pause déjeuner, pendant les appels et pendant le chargement d'un fichier. La hausse précoce de productivité laisse peu à peu place à une baisse de qualité et à un turnover.

Les données de Faros concordent avec cette observation : les gens n'arrivent tout simplement plus à vérifier le flux de modifications. L'étude du BCG précise la cause de la fatigue. Quand l'IA prend en charge la routine, le burn-out diminue. Quand le travail se transforme en surveillance permanente d'un agent, la fatigue décisionnelle et l'envie de démissionner augmentent. On écrit moins de code, mais on passe plus de temps à poser les tâches, à vérifier et à décider, et la plupart des développeurs n'ont pas été formés à cette compétence.

D'abord, ça empire : courbe d'apprentissage et sensations trompeuses

L'étude la plus citée sur le ralentissement est celle de METR, publiée en juillet (un laboratoire qui mesure l'effet réel de l'IA sur le travail). 16 développeurs open source expérimentés ont résolu des tâches dans leurs propres dépôts, et avec l'IA, cela leur a pris 19% de temps en plus. Avant l'expérience, ils s'attendaient à une accélération de 24%, et après, ils estimaient malgré tout avoir gagné 20%. Les participants n'avaient utilisé Cursor que quelques dizaines d'heures, et les auteurs écrivent explicitement qu'on ne peut pas exclure un effet d'apprentissage au-delà de 50+ heures.

Une nouvelle mesure six mois plus tard a donné, pour les dix participants revenus, une accélération d'environ 18%. L'intervalle de confiance inclut toutefois zéro, et les auteurs eux-mêmes jugent le signal peu fiable : beaucoup ont refusé de travailler sans IA, et l'échantillon s'est biaisé. Dans l'enquête de METR, les participants évaluent le gain environ deux fois plus haut, et d'après les mesures précédentes, ils surestiment l'effet de 40 points de pourcentage en moyenne.

Conclusion de l'auteur : sans compétence ni projet préparé, l'IA peut effectivement ralentir, et les sensations mentent. Celui qui abandonne au fond du creux conclut que « l'IA ne marche pas ». Celui qui le traverse conclut : « je ne peux déjà plus m'en passer ». Le milieu est dangereux : on voit dans son fil dix agents qui ont vidé le backlog en une nuit, on installe un framework de plus et cinq MCP, on lance des agents en parallèle et on entre dans un état d'anxiété permanente.

La confiance, c'est la vérifiabilité : l'ordre d'adoption

L'enquête Stack Overflow 2026 montre où se situe la limite : 6% des développeurs font confiance à l'IA pour les décisions importantes, mais près de la moitié lui font confiance s'ils peuvent vérifier le résultat. Sans vérification automatique rapide, il ne reste que deux extrêmes épuisants : lire chaque ligne, ou croire sur parole le « c'est fait » et démêler les conséquences une semaine plus tard. La position raisonnable est celle d'un tech lead : contrôler « le tronc et les branches » (l'architecture, la facturation, le modèle de données, les tests critiques) et ne pas toucher à chaque feuille.

Dans un sondage sur le canal Telegram de l'auteur, seuls 2 répondants sur 32 ont cité le choix de l'outil comme principal problème, contre 19 pour la structuration des connaissances. Voici l'ordre auquel il est arrivé :

• les bases de l'ingénierie, sans lesquelles on ne distingue pas une modification qui fonctionne d'une modification vraisemblable ;
• la définition de la tâche avec des critères d'acceptation avant d'écrire le code ;
• la feedback loop : types, linter, tests, navigateur, logs, pour que l'agent se vérifie lui-même ;
• les extensions (skills, MCP, plugins) seulement après cela ;
• les connaissances sur le projet, un plan pour les grosses tâches et une revue par rapport aux exigences ;
• les agents parallèles, tout à la fin.

Une étape sautée coûte plus cher par la suite. L'erreur typique consiste à plonger directement dans le Spec-Driven Development, les orchestrateurs et cinq agents. Les novices obtiennent des specs 3–5 fois plus volumineuses que le code, que personne ne lit, des limites d'usage brûlées et l'impression de travailler avec une boîte noire. Installer des extensions à l'aveugle constitue en outre un risque pour la chaîne d'approvisionnement : en février 2026, Koi Security a trouvé 341 skills malveillants sur 2 857 dans la marketplace ClawHub.

La manière d'apprendre compte aussi. Dans l'expérience d'Anthropic, les juniors qui apprenaient une nouvelle bibliothèque avec l'IA ont obtenu 50% au test, contre 67% sans IA. Mais ceux qui posaient à l'agent des questions conceptuelles et démêlaient eux-mêmes les erreurs ont obtenu 65% et plus.

Bilan de l'auteur : le creux sera franchi, mais le volume de travail de vérification ne disparaîtra pas, c'est la nouvelle norme. On peut alléger la charge en confiant les vérifications de routine aux outils et à un second agent au contexte vierge, en ne gardant pour soi que le critique et en n'ouvrant pas plus d'agents qu'on ne peut en vérifier. L'auteur présentera son exposé sur ce sujet lors de la conférence en ligne AI Dev Live, le 12 novembre.