Relire des PR faites par l'IA, c'est chiant

« J’aimais concevoir du code. Relire des PR faites par l’IA, c’est chiant. »

C’est une développeuse qui m’a dit ça, il y a quelques semaines. Sa passion pour le métier était née de la création d’algorithmes. Elle aimait soigner la façon dont le code était fait et prenait plaisir à façonner cette matière. L’arrivée des agents l’a privée de ce plaisir. À la place, elle relit du code qu’elle n’a pas écrit, et qu’elle n’aurait pas écrit comme ça.

J’accompagnais son équipe et j’essayais de les convaincre d’utiliser davantage l’IA. Ma conviction : bien utilisée, elle permet de produire du code de meilleure qualité, plus facilement.

On n’était pas en phase. Ce qu’ils connaissaient de l’IA, c’étaient des PR générées par des agents sans vrai guidage. Plus on utiliserait l’IA, plus ils devraient avaler de PR médiocres. Avec un tel volume, ils seraient tentés de merger en l’état, parce que corriger soi-même, personne n’en a envie. Le code deviendrait plus verbeux et moins bien conçu, et on finirait par accepter un niveau inférieur à celui d’avant. Alors ils résistaient.

Dans d’autres équipes, j’ai vu la réaction inverse. On génère tout et on subit. « On passe quatre fois plus de temps à relire des PR. C’est chiant, mais bon, qu’est-ce qu’on peut y faire ? » Ils ont accepté. Leurs journées sont faites de diffs, et ils ne vont pas beaucoup plus vite pour autant.

Ces deux équipes ne sont pas des exceptions. Dans les discussions de couloir et à la machine à café, j’entends les mêmes questions revenir. Des développeurs se demandent ce que devient leur métier. Des managers se demandent où est passé le gain de productivité promis.

Moi, je vois une situation qui me dérange : un fonctionnement inefficace, agrémenté d’une souffrance inutile. Inutile, car je pense que rien ne nous oblige à en rester là. On y reste parce qu’on n’a tout simplement pas pensé à en sortir, comme la grenouille dans l’eau qui chauffe doucement et qui ne saute pas hors de la casserole.

Un déséquilibre

Pour écrire du code, on a reçu des outils puissants et faciles à prendre en main. Pour la relecture et la décision de merger, on n’a rien reçu.

Résultat : l’agent écrit une grande partie du code, mais il ne relit rien et ne décide de rien. Dans les équipes que je croise, aucune PR n’est acceptée par un agent. Toute la relecture est restée humaine, alors que le volume à relire a explosé.

Les bots de revue n’y changent pas grand-chose. Ils commentent les PR, mais tant que l’humain relit tout et décide de tout, ils ajoutent surtout des commentaires à lire.

Le nez dans le guidon

Ce déséquilibre a un coût qu’on voit moins. Les meilleurs relecteurs sont souvent les développeurs qui connaissent le mieux le code. Pendant qu’ils enchaînent les diffs, ils ne construisent pas les tests et l’outillage qui permettraient de relire moins.

Et personne ne lève la tête. C’est, à mon avis, la première raison pour laquelle rien ne change. Il y a aussi de vraies difficultés, que j’aborde dans le prochain article.

Prendre du recul

Voici quatre questions avec lesquelles partir pour ouvrir la réflexion.

1. La situation actuelle est-elle le résultat d’une décision, ou d’une absence de décision ?
2. Dans quelle situation les développeurs, et le reste de l’équipe, s’épanouiraient-ils le plus ?
3. Maintenant qu’on a des agents, quelle valeur seul un humain peut-il apporter ? Faites la liste, puis comparez-la à votre agenda.
4. Si la revue, les corrections et la décision de merger devaient être entièrement déléguées aux agents, comment feriez-vous ? Ce qu’il faudrait mettre en place vous manque probablement déjà aujourd’hui.

Le prochain article portera sur ce qui nous empêche de déléguer la revue, et le suivant sur des dispositifs concrets pour le faire sans sacrifier la qualité.