Blog Unlockers.ai

Un projet vibe codé de 10 000 lignes, entièrement refactoré en 1 h 45 avec un seul prompt

Johan Martinsson — Wed, 28 Oct 2026 00:00:00 GMT

Avant et après un prompt de quinze minutes et 1 h 45 de travail autonome de l'agent.

J’ai un projet Java en ligne de commande, vibe codé : 14 fichiers, 9 580 lignes, aucun test, un fichier de 2 065 lignes et environ 870 violations des règles d’analyse statique. Je lui ai donné un prompt écrit en quinze minutes. L’agent a travaillé seul pendant 1 h 45, de 00 h 42 à 02 h 27. Le projet compte maintenant 156 fichiers, le plus gros faisant 379 lignes, 680 tests, 99 % de lignes couvertes, et il passe une commande unique, ./verify, qui enchaîne huit contrôles automatiques.

Avant de lancer l’agent, j’étais certain de deux choses : rien ne serait cassé, et le résultat irait là où je voulais. Cet article explique d’où venait cette certitude.

Le point de départ : 14 fichiers, 9 580 lignes, aucun test

Le projet audite l’activité de dépôts GitLab en s’appuyant sur des données SonarQube. Il fonctionne, mais tout tient dans quelques gros fichiers, dont GitlabActivityAudit qui fait 2 065 lignes, et rien ne vérifie qu’une modification n’abîme pas autre chose. Les outils d’analyse statique relevaient environ 870 violations.

Ce que j’ai demandé : une commande qui doit passer au vert

Le prompt décrit avant tout un état final : la commande ./verify doit passer entièrement au vert. Elle enchaîne Spotless pour le formatage, Checkstyle, Error Prone avec NullAway, PMD, les tests avec un seuil de couverture de 90 % des lignes et 85 % des branches, et un cliquet que je décris plus bas. L’option --full ajoute CPD pour le code dupliqué et PIT, un test de mutation, avec un seuil de 85 %.

Voici le prompt, raccourci pour la lecture (l’original est plus long) :

Couvre le projet avec des tests qui permettent un gros refactoring.

Utilise le test de mutation pour vérifier cette couverture.

Lance ./verify pour faire ressortir toutes les violations.

Corrige-les dans l’ordre que tu juges le plus pertinent.

Installe ./verify en hooks git et valide qu’ils fonctionnent.

Sauvegarde dans QUALITY_LOG.md tout choix douteux que tu dois faire pour passer les vérifications. Fournis des preuves : couverture avant, couverture après, diff éventuel sur les règles, rapport de ./verify.

L’ordre compte : la couverture d’abord, la structure ensuite. Le journal QUALITY_LOG.md permet à l’agent de me signaler ses choix discutables, j’y reviens plus bas. Quant aux preuves demandées en fin de prompt, elles tiennent sur une page et me suffisent pour relire : le diff sur les règles me montre tout de suite si l’agent a desserré un contrôle.

Ce qui est sorti de la nuit

	Avant	Après
Fichiers	14	156 (le plus gros : 379 lignes)
Tests	0	680
Lignes couvertes	0 %	99 % (97 % des branches)
Mutants tués (PIT)	non mesuré	99 % (3 392 sur 3 433)
Violations d’analyse statique	environ 870	0
Code Health (CodeScene)	6,0	9,8

L’agent a aussi relevé une vingtaine de comportements qui ressemblent à des bugs. Je ne voulais pas qu’il les corrige pendant un refactoring. Il les a documentés et épinglés par des tests nommés, le comportement reste inchangé, et je décide plus tard.

Pourquoi j’étais sûr de ne rien casser

Le refactoring ne commence qu’une fois le comportement protégé. Les tests écrits en premier sont des tests de caractérisation : ils lancent l’outil de bout en bout contre de faux serveurs GitLab et SonarQube, et comparent sa sortie à des instantanés (avec la bibliothèque Selfie). Si le refactoring change une ligne de ce que l’outil produit, un instantané casse.

Une couverture de 99 % ne prouve pas que ces tests vérifient quelque chose : une ligne exécutée n’est pas une ligne contrôlée. C’est le rôle du test de mutation. PIT modifie le code par petites touches (un > devient >=, un return est supprimé) et vérifie qu’au moins un test échoue. Sur 3 433 mutations, 3 392 ont été détectées. Le filet de sécurité a donc été éprouvé avant le premier refactoring.

C’est la méthode que j’appelle 3P et que j’ai mise dans une skill : Protéger le comportement existant avec des tests rapides et sales, vérifier le filet en cassant volontairement quelque chose de petit, Préparer le terrain par un refactoring qui ne change aucun comportement, puis Produire la fonctionnalité en TDD. Ici, je n’ai utilisé que les deux premières étapes. Mais rien n’empêche de s’en servir pour ajouter une fonctionnalité dans n’importe quel code legacy, de la même façon : la protection d’abord, la nouveauté ensuite.

Pourquoi l’agent allait là où je voulais

L’objectif est évaluable par l’agent lui-même. Il n’a pas besoin de moi pour savoir où il en est : il lance ./verify, lit ce qui échoue, corrige, recommence. Je n’ai décrit aucune structure cible. Le découpage en 156 fichiers, avec des paquets comme matching, sonar, gitlab, csv, console, naming, parallel ou exclusions, vient de l’agent. Ce que j’ai fixé, ce sont les seuils : ceux de Checkstyle et de PMD, la couverture, la mutation.

Chaque itération rapproche de l’état final ou fait échouer un test, et l’agent choisit librement le chemin.

Le cliquet : les problèmes existants restent, aucun nouveau n’entre

Un objectif mesurable a une faille : l’agent peut passer au vert en desserrant la mesure, en baissant un seuil de couverture, en ajoutant un @SuppressWarnings ou en désactivant un test. Le cliquet ferme cette porte. Son nom vient de la clé à cliquet, qui ne tourne que dans un sens. La règle tient en une phrase : les problèmes existants peuvent rester, aucun nouveau n’est admis, et personne ne desserre un contrôle discrètement.

Concrètement, un petit outil compare l’arbre de travail à une référence git. Un seuil minimum ne peut pas baisser, un seuil maximum ne peut pas monter, un contrôle ne peut pas disparaître. Le nombre de marqueurs de suppression (@SuppressWarnings, NOPMD, CHECKSTYLE:OFF, @Disabled) ne peut pas augmenter. Une règle Error Prone passée en désactivée ou en simple avertissement est détectée. Un commit qui porte une ligne Ratchet-Override: transforme l’échec en avertissement : la dérogation reste possible, mais c’est une décision humaine, visible dans l’historique.

Pendant la nuit, le cliquet a refusé trois nouveaux @SuppressWarnings que l’agent avait ajoutés.

Le journal de qualité : l’agent signale ses choix discutables

Un agent qui travaille seul pendant 1 h 45 prend beaucoup de décisions que je ne verrai pas. La section du prompt sur QUALITY_LOG.md lui demande de les consigner quand elles sont discutables : un compromis, un raccourci, un endroit où il n’était pas sûr. Je lis ce journal à la place de 156 fichiers.

Le journal a servi une deuxième fois. J’ai lancé sur le résultat une revue automatisée (CodeScene, un agent « clean coder », un agent « architecte » et une expérience de changement de comportement) et j’ai confronté ses constats au journal. L’écart entre les deux m’a donné de nouvelles règles de design : un fichier ARCHITECTURE.md et des tests ArchUnit qui imposent des couches, l’isolation entre les tranches du code, l’absence de cycle entre paquets, et une seule classe publique, celle de la commande. Ce sont des tests, donc ils tournent dans ./verify comme le reste. Cette deuxième vague mérite son propre billet.

Ce que cette certitude ne couvre pas

Les tests figent le comportement tel que mes faux serveurs le simulent. Sur 3 433 mutants, 41 ont survécu. Et la vingtaine de bugs suspects est toujours là, volontairement. Le cadre garantit que le comportement observé par les tests ne change pas. Il ne garantit pas que le programme est juste.

Ils appliquent la même recette

Je ne suis pas le seul à observer ça. Ces retours publiés suivent la même recette : un objectif que l’agent vérifie lui-même, et des règles qu’il ne peut pas contourner.

Anthropic : un compilateur C de 100 000 lignes écrit par 16 agents, guidés par des suites de tests existantes. Le vérificateur doit être presque parfait, sinon l’agent résout le mauvais problème.
OpenAI : un million de lignes en cinq mois par trois ingénieurs, bornées par des règles mécaniques.
Rakuten : sept heures d’autonomie sur vLLM, 99,9 % de précision numérique face à la référence.
Stripe (via InfoQ) : plus de 1 300 pull requests par semaine, avec lint et tests déterministes et deux tours d’intégration continue au plus.
Airbnb (via InfoQ) : 3 500 fichiers de tests migrés en six semaines au lieu de 18 mois.
Meta : 49 % des tests générés à partir de mutants n’ajoutent aucune couverture de lignes, d’où l’intérêt du test de mutation.

Quel lot de travail devient raisonnable maintenant ?

Transformer 10 000 lignes sans test en code testé, découpé et contrôlé demandait des semaines d’une équipe, et on ne le faisait pas. Ça a pris quinze minutes de prompt et 1 h 45 d’attente. Les lois physiques du développement logiciel ont changé, et notre idée de ce qui vaut la peine d’être tenté n’a pas suivi.

Dans votre backlog, cherchez les chantiers dont on sait décrire l’état final de façon vérifiable : tous les tests de la nouvelle version au vert, un module couvert à 90 %, plus aucune violation. Les migrations, les montées de version, la couverture d’un module legacy et la mise en conformité d’un code ancien entrent souvent dans cette catégorie. Demain, que pourriez-vous faire de votre backlog avec cette approche ?

Pour aller plus loin

La skill legacy-3p : Protéger, Préparer, Produire.
Dans la même série : Relire des PR faites par l’IA, Pourquoi on ne délègue pas la revue de code et Comment déléguer la revue de code à des agents.

Johan Martinsson

Comment déléguer la revue de code à des agents

Johan Martinsson — Fri, 23 Oct 2026 00:00:00 GMT

Relire chaque ligne ou déléguer à une équipe de reviewers et de correcteurs, et surveiller la qualité du processus.

Imaginez un CTO dont l’équipe de développeurs grossit chaque jour et qui compte relire lui-même chaque ligne de code pour garder le contrôle. Personne ne croirait que ça tiendra encore demain. C’est pourtant ce que font beaucoup d’équipes avec les agents : ils produisent de plus en plus de code, et les humains relisent tout.

Je pense que notre rôle ne peut plus être de relire chaque ligne. Dans le premier article, je décrivais ce déséquilibre. Dans le deuxième, j’ai regardé ce qui nous empêche de déléguer la revue. Celui-ci porte sur la suite : comment s’y prendre concrètement.

Déléguer, c’est donner le contexte

Déléguer la revue est un vrai acte de délégation, comme avec un collègue : il faut donner à l’agent ce dont il a besoin pour réussir.

L’agent part avec une connaissance générale solide. Il a probablement lu dans son entraînement la plupart des livres sur le bon design, l’architecture, la sécurité, la lisibilité et les code smells. Cette connaissance existe, il faut aller la chercher avec les bonnes questions. Ce qu’il ne peut pas deviner, c’est votre projet, votre contexte, les goûts de votre équipe.

Où trouver la matière d’un code reviewer

Trois techniques se complètent :

Les PR du passé. On laisse l’agent parcourir toutes les anciennes PR, leurs commentaires et leurs instructions, et en tirer des règles applicables, avec des exemples. Les humains de l’équipe y ont déjà écrit ce qui compte pour eux.
Vous-même. On s’assoit et on transcrit tout ce qui est important, avec ses priorités. Ce que l’on sait du projet n’est souvent écrit nulle part, et l’agent ne le trouvera pas seul.
Les revues en cours. À chaque revue, on voit ce que l’agent n’a pas vu, ce qu’il lui manque. On le verse dans sa base de connaissances.

Tester automatiquement un reviewer

Tester un prompt, c’est prendre un cas, le faire jouer, et analyser le résultat. Pour un reviewer, le cas existe déjà dans l’historique.

Le faire tourner sur des PR du passé. On choisit d’anciennes PR qui ont été relues en profondeur et on rejoue le reviewer dessus. Retrouve-t-il au minimum ce qui avait été relevé à l’époque ? Ce score se chiffre, c’est ce qu’on appelle une récompense vérifiable, et c’est ce qui rend l’évaluation simple. On regarde aussi ce qu’il trouve en plus et ce qu’il rate, et on juge la pertinence des constats supplémentaires. On peut aller plus loin et laisser un agent adapter le prompt pour se corriger sur ces cas. Ces PR deviennent une base de test pour améliorer le reviewer.

Le faire tourner en parallèle de l’humain. Pendant un temps, l’humain et l’agent relisent les mêmes PR, et on ajoute au reviewer ce qui lui manque.

Continuer les revues manuelles jusqu’à ce qu’elles n’apportent plus rien. C’est une façon de se rassurer qu’on n’a plus grand-chose à dire. La limite : quand le niveau monte, on remarque d’autres détails, et on peut en trouver sans fin.

Plusieurs reviewers spécialisés qui s’accordent, et un correcteur en boucle

Pour une revue plus poussée, j’ai découpé mon reviewer unique en plusieurs reviewers spécialisés, chacun avec son angle (complexité, tests, architecture, sécurité, etc.), coordonnés par un agent principal. Le balayage devient beaucoup plus profond. J’ai également dû l’instruire de regarder au-delà du git diff : le contexte, la méthode, le fichier complet. Il lui faut aussi des instructions assez strictes pour ne pas s’arrêter après quelques trouvailles, mais chercher absolument tout.

Ensuite, j’ai introduit un correcteur qui tourne en boucle avec les reviewers jusqu’à atteindre un niveau de qualité élevé. Les reviewers voient le travail des autres et s’accordent, par l’intermédiaire de l’agent principal, sur ce qu’il faut corriger. Cette mise en boucle pose quelques problèmes d’implémentation, et je ferai probablement un billet sur cette expérience.

Dans ma bibliothèque, tout part de review-all, l’orchestrateur. Il ne relit rien lui-même : il fige le commit, lance en parallèle cinq reviewers (complexité, tests, architecture, sécurité, slop), puis publie leur synthèse sur la PR, avec un commentaire et un statut par reviewer. Tous suivent le même protocole : chaque constat est classé Critical, Major ou Minor, avec son fichier et sa ligne. S’il y a des choses à corriger, les mêmes reviewers valident le plan de correction puis vérifient le résultat, sans refaire de revue complète. Ensuite, le merge se fait automatiquement si la CI passe.

Si vous voulez partir de quelque chose qui fonctionne, vous pouvez vous servir dans l’Unlockers Skills Library, en open source. Pour essayer, demandez à votre propre agent de lire ce jeu de skills et de l’appliquer à l’une de vos PR.

Un score de risque pour décider où un humain doit regarder

Autre technique : faire donner un score de risque à la revue, puis laisser un approbateur décider s’il faut faire appel à un humain. Ce mécanisme de score n’est pas encore publié dans ma bibliothèque.

Reste à savoir comment scorer. Plutôt qu’une note numérique, je conseille trois ou quatre niveaux, par exemple mineur, majeur, critique. C’est plus fiable avec un LLM, et c’est déjà le vocabulaire que les humains utilisent en réunion pour classer les problèmes. Plusieurs scores peuvent s’agréger pour donner une image d’ensemble.

Pour détecter les erreurs du scoring lui-même, un humain relit en plus quelques PR tirées au hasard, trois par exemple.

Une PR sans bug peut être mergée, le design se revoit plus tard

Dans un projet comme le noyau Linux, seuls les mainteneurs qui connaissent le projet peuvent merger. À mon avis, cela répondait à deux besoins : éviter les bugs et les incohérences, et garantir que les détails importants du projet soient connus de celui qui décide.

Ces deux besoins sont aujourd’hui couverts autrement :

La correction fonctionnelle se règle en amont. Sur certains projets, il est devenu facile d’atteindre une couverture de tests quasi totale, protégée par du mutation testing.
La connaissance du projet se fournit aux agents. Un reviewer qui la possède dépasse de très loin ce qu’un humain peut tenir en tête.

Une PR qui passe ces deux filtres n’a probablement pas de bug, donc elle peut être mergée. Ce qu’un regard humain apporte encore, c’est le design : l’architecture, les mauvais patterns, un code qui devient sloppy. Le benchmark SlopCodeBench fait étendre leur propre code à 15 agents, itération après itération : l’érosion structurelle augmente dans 77 % des trajectoires, et leur code est 2,3 fois plus verbeux que celui de 473 dépôts open source. Il n’est pas forcément représentatif, car ces agents n’y disposent d’aucun harnais de qualité. Dans tous les cas, la PR n’est pas toujours le bon endroit pour le traiter. Corriger une dérive détectée peut transformer un petit incrément de fonctionnalité en refactoring global de la base de code.

Cette revue de design peut donc se faire en décalé, sur plusieurs PR, en regardant les évolutions récentes. J’ai un agent qui fait ce genre de revue à plus long terme : il relève les mauvaises odeurs, les problèmes apparus dernièrement et les refactorings opportunistes à faire au vu du travail réalisé.

Un ami a tenté l’expérience : la revue ne bloque plus le merge. Les développeurs ont dû se demander comment obtenir la qualité autrement, ce qui a fait appel à leur créativité.

Mon avis : le rôle des humains reste important, mais il ne se joue plus principalement dans une PR.

Le coût du refactoring est devenu très faible

Il y a aussi une raison économique. Avant, laisser entrer un code peu propre coûtait cher : sans tests complets, on ne pouvait pas le refactorer en sécurité, donc il fallait le bloquer à l’entrée. Avec les tests en place, changer une implémentation ne coûte presque rien.

L’autre jour, j’ai pris une base de code de 9 580 lignes, entièrement vibe-codée et sans aucun test. En un seul prompt et 1 h 45 de travail autonome de l’agent, je l’ai fait couvrir par des tests, découper en modules et nettoyer de tous les mauvais patterns que les outils automatiques détectent (le détail). S’accrocher par réflexe aux anciennes règles de revue n’a plus de justification.

Pour aller plus loin

Unlockers Skills Library : mes agents et skills de revue, avec leur protocole commun.

Johan Martinsson

Pourquoi on ne délègue pas la revue de code à l'IA

Johan Martinsson — Fri, 16 Oct 2026 00:00:00 GMT

Confier la revue à un agent et ne plus regarder la route : la faille critique arrive quand même.

« Une revue de code faite par l'IA, ce n'est pas fiable. Du coup, je la fais à la main. »

Ce raisonnement tient en deux phrases et il paraît solide. Dans le billet précédent, j’ai décrit ce qu’il produit : des agents qui écrivent beaucoup de code, des humains qui relisent tout, et beaucoup de monde qui le vit mal. Cette fois, je cherche ce qui nous empêche d’en déléguer ne serait-ce qu’une partie. Je vois cinq freins.

1. La peur de l’erreur qu’on ne verra pas

La peur n° 1 : tout est au vert, l'agent approuve, et l'erreur grave passe sans bruit.

Ce qui fait peur, ce sont les erreurs graves que l’agent pourrait laisser passer : une faille de sécurité, un bug grave, qui traverse la revue sans bruit et qu’on découvre des semaines plus tard en production. Quand la PR est relue par mes collègues, je connais leurs forces et leurs angles morts. Avec un agent, je ne sais pas quand je m’en rendrai compte, ni combien ça me coûtera à ce moment-là.

Pour beaucoup, cette peur a une origine précise. On a essayé une fois, l’agent a raté quelque chose d’évident, et on n’a pas recommencé. Une erreur a suffi. Et on se dit que la prochaine, on ne la verra peut-être pas.

2. On confond déléguer et réussir à 100 %

La revue manuelle plafonne ; une revue automatisée part plus bas mais continue de progresser. Croquis illustratif, pas des mesures.

Si l’agent valide tout, il faut qu’il ait raison tout le temps. Comme il n’y arrivera pas, on ne commence pas. Ce raisonnement saute une étape : déléguer partiellement ne demande pas d’atteindre 100 %. On peut laisser l’agent faire la revue, corrections comprises, et repasser derrière lui jusqu’à avoir assez confiance. On peut aussi essayer plusieurs variantes de revue sur des PR déjà relues, et ne garder que celles qui tiennent la route. J’y reviens dans le prochain billet.

La recherche DORA sur la performance des équipes de livraison logicielle va dans ce sens. Dans le rapport Accelerate State of DevOps 2019, les organisations qui imposaient un processus d’approbation formel et lourd avaient 2,6 fois plus de chances d’être parmi les moins performantes. Le rapport ne dit pas pourquoi. Mon interprétation : un contrôle manuel plafonne, alors qu’un contrôle automatisé s’améliore à chaque règle qu’on lui ajoute. C’est pareil pour la revue : commencer à déléguer, même mal, c’est se donner quelque chose à améliorer.

3. On n’a jamais explicité comment on relit

Expliciter sa revue : passer de l'intuition à des règles écrites, qu'un agent peut exécuter.

Quand on relit une PR, on le fait à l’intuition. Si on se demande ce qui compte vraiment pour nous et ce qu’on regarde en premier, la réponse ne vient pas tout de suite. Et d’une PR à l’autre, on ne relit pas tout à fait de la même façon. C’est souple : on relit une PR critique autrement qu’un renommage. Mais c’est aussi irrégulier, et une machine qui suit des règles écrites ne l’est pas.

Il y a au moins un indice que ça aide. Dans un papier présenté à un atelier de l’ICML 2026, un petit modèle relecteur inspecte une base de code Python contenant 11 backdoors insérées. Sans contrainte ni outil, il en retrouve 54,5 %. Avec des contraintes imposées par l’outillage sur le code et un petit outil de documentation, il monte à 90,9 %. C’est un petit jeu de données synthétique, mais le résultat est net : le relecteur trouve mieux quand on lui dit quoi vérifier.

4. Les LLM sont en dents de scie

L'intelligence en dents de scie : l'agent excelle sur les détails et passe à côté de l'essentiel.

Les LLM sont excellents sur certaines tâches et complètement à côté sur d’autres, et on ne sait pas encore sentir à l’avance lequel des deux on va avoir. Andrej Karpathy appelle ça la jagged intelligence, à partir de modèles qui résolvent des problèmes difficiles mais se trompent pour savoir si 9,11 est plus grand que 9,9 (son message d’origine). Une étude de Harvard, Wharton et BCG parlait déjà de « frontière technologique en dents de scie », et Ethan Mollick l’a vulgarisée dans Centaurs and Cyborgs on the Jagged Frontier.

Imaginez confier la revue à un collègue qui, un jour sur deux, fait un travail remarquable et, l’autre jour, passe complètement à côté. Vous ne lui confieriez pas grand-chose.

5. Déléguer à un agent passe par l’écrit

Avec un collègue, on peut dire « fais-le avec moi quelques fois, et ensuite tu sauras ». Il observe, il comprend ce qui nous importe, et on lâche prise progressivement. Avec un agent, cette transmission par l’observation n’existe pas : ce qu’on n’a pas écrit, il ne le sait pas.

On peut contourner en partie. On fait parcourir à un agent tout le contenu du projet ainsi que les commentaires laissés sur les PR passées, et on lui demande d’en tirer un modèle de ce qui nous importe en revue. Ce n’est pas parfait, mais l’agent récupère une partie de ce qu’un collègue apprendrait en nous regardant faire.

Et maintenant ?

Ces cinq freins sont réels, mais le simple fait de les expliciter permet de les traiter, et l’agent fait alors assez facilement mieux qu’un humain.

Dans le prochain billet, je vous raconte comment nous faisons aujourd’hui, et ce que j’ai enfin le temps de faire à la place.

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

Johan Martinsson — Fri, 25 Sep 2026 00:00:00 GMT

« 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.

La situation actuelle est-elle le résultat d’une décision, ou d’une absence de décision ?
Dans quelle situation les développeurs, et le reste de l’équipe, s’épanouiraient-ils le plus ?
Maintenant qu’on a des agents, quelle valeur seul un humain peut-il apporter ? Faites la liste, puis comparez-la à votre agenda.
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é.