Notes · Article
Relisez le plan, pas la pull request
Overmind ne relit plus ses propres pull requests. Presque tout le code que l’entreprise met en production n’est plus lu par aucun humain, auteur compris. La revue n’a pas disparu pour autant. Elle s’est déplacée vers un plan d’environ une page et demie, dont on débat avant qu’un agent écrive la moindre ligne, et dans les trois semaines qui ont suivi le changement, l’équipe a fermé trois fois plus d’issues, tandis que le lead time tombait de 3,2 jours à 1,3.
La conférence, c’est Pull Requests Are Dead, Long Live Peer Review, de Dylan Ratcliffe, fondateur et CEO d’Overmind, donnée à AGNTCon + MCPCon North America 2026. Overmind utilise l’IA pour simuler les changements sur de grosses infrastructures back-end. Dans ma note sur l’usine logicielle, la partie lente de ma propre installation, c’est ma file de revue. Cette conférence, c’est la réponse d’une équipe à ce problème.
La revue remplissait quatre rôles
Comme la plupart des équipes, Overmind comptait sur la revue de code pour bien plus que les bugs. Elle attrapait les bugs, elle couvrait la conformité SOC 2 et ISO 27001, elle formait les ingénieurs juniors, et elle construisait une vision partagée de la façon dont le système fonctionne vraiment.
Ce qui faisait marcher tout ça, c’est qu’un humain tenait à chaque ligne. Commentez la pull request d’une personne, et il en sort quelque chose de bon dans tous les cas. Si vous avez raison, elle apprend et le produit s’améliore. Si elle conteste, c’est qu’il existe une contrainte que vous ignoriez, et maintenant vous la connaissez.
Commentez la pull request d’un bot qui traite lui-même les commentaires de revue, et vous obtenez le même acquiescement empressé, que vous ayez entièrement raison ou entièrement tort. C’est sa première leçon : l’IA n’est pas votre pair, donc la revue par les pairs ne s’applique pas à son travail.
- 1Attraper les bugs
- 2Conformité SOC 2 et ISO 27001
- 3Former les ingénieurs juniors
- 4Une vision partagée du fonctionnement du système
L’auteur est une personne
Votre commentaire de revue
Si vous aviez raisonElle apprend, et le produit s’améliore
Si elle avait raisonVous découvrez une contrainte que vous ignoriez
vs
L’auteur est un bot
Votre commentaire de revue
Si vous aviez raisonAcquiesce et applique
Si vous aviez tortAcquiesce et applique
Leçon 1L’IA n’est pas votre pair, donc la revue par les pairs ne s’applique pas à son travail.
Deux personnes ont livré plus que toute l’entreprise
En début d’année, Overmind comptait environ 80 % d’ingénieurs. Le produit, c’était Dylan et un product manager. Ils trouvaient l’idée, faisaient la recherche et posaient le cadrage, c’est-à-dire l’architecture de haut niveau. Venaient ensuite une réunion de passation, une série de questions, puis les ingénieurs planifiaient et construisaient avec l’IA.
Le hic : une fois que Dylan avait tout fait jusqu’au cadrage, confier directement le travail à un agent allait plus vite que le confier à une personne. Il vit à San Francisco, une bonne partie de ses ingénieurs sont en Europe, et l’agent ne dort jamais.
Une semaine, le product manager et lui ont donc produit plus que toutes les autres personnes de l’entreprise réunies, sur chaque indicateur qu’ils suivaient : lignes de code, pull requests, tickets fermés et story points. Ça ne fait que six personnes, mais ce sont deux personnes qui abattent le travail de six ingénieurs à plein temps. « Aucun de nous deux n’est ingénieur », a-t-il dit.
Il reconnaît ouvertement avoir sérieusement envisagé de licencier la moitié des ingénieurs pour les remplacer par des product managers. Il ne l’a pas fait. À la place, il a fait venir tout le monde en France pendant une semaine pour remettre le process à plat.
Dylan et le product managerqui confient le travail directement aux agents
Les six autrestout le reste de l’entreprise
Devant sur chaque indicateurlignes de codepull requeststickets fermésstory points
EnvisagéLicencier la moitié des ingénieurs, embaucher des product managers
FaitFaire venir tout le monde en France une semaine
Dylan« Aucun de nous deux n’est ingénieur. »
Le travail s’est déplacé vers la gauche
Voici la slide que j’ai retenue de la conférence, redessinée. Avant, le produit avait l’idée, la recherche et le cadrage, et l’ingénierie avait le plan, la construction et la livraison. Désormais, le produit garde l’idée, l’ingénierie prend la recherche, le cadrage et le plan, et un agent construit et livre.
AvantMaintenant
IdéeProduitProduit
RechercheProduitIngénierie
CadrageProduitIngénierie
PlanIngénierieIngénierie
ConstructionIngénierieAgent
LivraisonIngénierieAgent
une personne sur le travail←le travail s’est déplacé à gauche
Leçon 2Si votre métier consiste à transformer des specs détaillées en code de qualité, vous n’avez plus de métier. C’est vrai depuis janvier et Opus 4.5, dit-il.
Sa deuxième leçon est sortie de cette semaine-là : si vous pensez que votre métier consiste à transformer des specs détaillées en code de qualité, vous n’avez plus de métier. Selon lui, c’est vrai depuis janvier et Opus 4.5.
Une page, 24 heures, aucune question
Déplacer les ingénieurs vers la gauche s’est accompagné d’une règle. Le produit remet un document d’une page. L’ingénieur qui le reçoit montre une démo sous 24 heures, et n’a le droit de poser aucune question pendant ce temps.
Un document d’une page est plein de trous, et c’est tout l’intérêt. Est-ce que ça doit marcher sur mobile ? Allez vérifier si les gens utilisent ce genre d’app sur mobile. Obligés de lever l’ambiguïté eux-mêmes, les ingénieurs avaient le plus souvent raison.
Personne ne peut absorber toute cette nouvelle ambiguïté et continuer à tenir à chaque ligne de code, cela dit. Le détail ligne par ligne est donc passé aux agents.
1Une page
Venue du produit, pleine de trous exprès
224 heures
Aucune question autorisée
3Une démo
Chaque trou comblé selon le jugement de l’ingénieur
RésultatLaissés seuls face à l’ambiguïté, les ingénieurs avaient le plus souvent raison.
Toutes les boucles d’agents ne se valent pas
Quand l’équipe a étudié comment les gens construisent des « usines logicielles » et des « usines lumières éteintes » agentiques, la plupart faisaient tourner ce qu’il appelle une boucle do-while. L’agent prend un ticket, décide de l’approche, fait les compromis, écrit le code et les tests, enregistre parfois une vidéo de démo, et ouvre une pull request tout à la fin. Ensuite, un humain doit reconstituer chaque décision à partir du code.
L’idée que l’IA lui prenne son travail l’inquiète un peu. Ce qui l’inquiète davantage, c’est que l’IA lui prenne la partie intéressante et qu’on le paie pour valider des décisions prises sans lui.
L’équipe a donc construit une boucle until. Des agents explorent la base de code, par exemple pour vérifier s’il existe déjà une pratique pour ce genre de changement. Des humains décident de l’approche, font les compromis et écrivent un plan d’implémentation, qu’un pair relit. Puis un agent écrit le code et un second agent le compare au plan. Le moindre écart renvoie le code, et la boucle tourne jusqu’à ce que code et plan correspondent.
La plupart des usines d’agents
do-while
- AgentPrend un ticket
- AgentDécide de l’approche et des compromis
- AgentÉcrit le code et les tests, parfois une vidéo de démo
- AgentOuvre une pull request
- HumainRelit : reconstitue chaque décision à partir du code
vs
Ce que fait tourner Overmind
until
- AgentExplore la base de code
- HumainDécide de l’approche et des compromis
- HumainÉcrit le plan
- HumainRelit : un pair lit le plan
- Se répète jusqu’à ce que le code corresponde au plan
- AgentÉcrit le code
- AgentCompare le code au plan
- ProdLivre, sans qu’aucun humain lise le code
Une fois que la boucle ressemble à ça, la place de la revue par les pairs saute aux yeux : avant que la boucle démarre.
Relisez le plan, puis arrêtez de lire
Les plans ont droit à une vraie revue, parce que les gens y tiennent de nouveau. Quand quelqu’un commente aujourd’hui une pull request de Dylan, sa réaction honnête, c’est : « Je n’ai même pas lu ce code. Si ça se trouve, vous êtes le premier à l’avoir lu. » Quand quelqu’un commente son plan, il argumente, parce qu’il en a écrit chaque ligne et sait pourquoi chacune est là.
Il traite un plan approuvé comme un changement pré-approuvé. La plupart des dispositifs de conformité connaissent déjà l’idée : un changement bien défini peut être approuvé à l’avance, tant que vous faites exactement ça. La boucle ne peut pas se terminer tant que le code ne correspond pas à un plan approuvé, donc le code part en production sans seconde revue humaine.
Deux contrôles gardent le système honnête :
- Des humains vérifient par sondage un petit pourcentage des comparaisons entre plan et code, pour s’assurer que l’agent de revue ne se trompe pas.
- Si l’agent de code trouve une meilleure idée, ou une vraie raison de ne pas suivre le plan, il consigne un écart, et un humain en prend acte.
Overmind était en plein audit au moment de la conférence. Dylan est convaincu que le process est conforme, et il le saura à la fin de l’audit.
L’outillage n’a aucune interface utilisateur. Les plans s’écrivent dans Claude Code ou dans n’importe quel harnais (harness), et envoyer un plan, le récupérer ou laisser une revue, ce sont tous des appels MCP.
Humains
Plan approuvé
- Environ une page et demie
- Les compromis et leurs raisons
- Un changement pré-approuvé
Agents
La boucle until
- L’un écrit le code
- L’autre le compare au plan
- Pas de sortie tant qu’ils diffèrent
Pas de seconde revue
Production
- Du code qu’aucun humain n’a lu
- Conforme à un plan approuvé
SondageDes humains vérifient un petit pourcentage des comparaisons entre plan et code
Un écartL’agent consigne pourquoi il a quitté le plan, et un humain en prend acte
Sans UILes plans s’écrivent dans Claude Code ou dans n’importe quel harnais. Les envoyer, les récupérer et les relire, ce sont des appels MCP.
Trois semaines plus tard
L’équipe a changé de process en une semaine, puis a comparé les trois semaines suivantes aux trois précédentes. Le nombre d’issues terminées a triplé, celui des commits aussi. Le lead time, entre le moment où un ticket est pris et celui où il tourne en production, est tombé de 3,2 jours à 1,3.
Ce sont les chiffres d’une petite équipe, trois semaines contre trois semaines, mesurés par l’entreprise elle-même. Et Overmind vend désormais un produit construit sur exactement cette idée : prenez la conférence comme un argument solide, venant de quelqu’un qui a un intérêt dans l’affaire.
3×issues terminées
3×commits
1,3 jourde lead time, contre 3,2
Le goulot d’étranglement, c’était l’attention
L’équipe n’a jamais passé 90 % de ses journées en revue de code, donc le facteur 3 ne vient pas du temps de revue économisé. Sa réponse : l’attention. Les pull requests obligeaient à jongler avec trop de balles à la fois et à changer de contexte en permanence.
L’ancienne chronologie d’un changement : environ 3 heures à écrire le code, 15 minutes à ouvrir la pull request, une journée et demie à attendre un relecteur débordé, puis une heure d’allers-retours. Vous ne pouvez rien en oublier, parce que vous êtes le seul à comprendre le code. Le temps qu’un commentaire revienne, il avait écrit 15 000 lignes de plus et ne se souvenait plus de ce qu’il essayait de faire, au point qu’abandonner le changement pouvait être plus simple que de s’y replonger. Environ quatre heures et demie de travail ont vécu dans sa tête pendant une quarantaine d’heures.
Un plan s’écrit plus vite, et se relit beaucoup plus vite, que 3 000 lignes de Go. Une fois approuvé, vous le retenez comme la description du fonctionnement du système. Le code n’existe pas encore, mais il existera dans trois heures environ, parce qu’il n’y a pas d’autre sortie de la boucle. Ça coûte deux heures d’attention, à peu près.
Pull requestenviron 4,5 h de travail, environ 40 h dans la tête
Plandeux heures environ dans la tête
0 h10 h20 h30 h40 h
- dans la tête
- votre temps de travail effectif
- attente, toujours dans la tête
- boucle d’agent, sortie de la tête
Une recette se refuse plus facilement qu’un plat
Debout dans la cuisine, au moment de décider quoi préparer, c’est facile de dire « Je n’ai pas envie de salade. » Une fois la salade faite, vous ne pouvez plus. Demander à quelqu’un de refaire un plat demande une énergie à la Gordon Ramsay, et c’est exactement ça, rejeter une pull request. C’est dur émotionnellement, et c’est pourquoi c’étaient en général les ingénieurs les plus seniors qui s’en chargeaient.
Les plans ont changé ça. Overmind a désormais 2,8 fois plus de chances de rejeter un plan qu’elle n’en a jamais eu de rejeter une pull request, et les rejets viennent de toute l’équipe, produit compris. C’est aussi bien moins cher : un plan rejeté ajoute environ 40 minutes de lead time, alors que le moindre commentaire sur une pull request ajoutait 16 heures.
Sa grande crainte au départ, c’était de voir des agents écrire les plans et d’autres agents les relire, sans personne pour rien lire. Il dit que les chiffres montrent que ce n’est pas arrivé. Les plans sont assez courts pour que les gens les lisent, et ils y tiennent.
Ça ouvre aussi une porte aux juniors. Un junior qui ne comprend pas un plan peut en discuter avec son agent jusqu’à ce qu’il le comprenne, et rejeter ce qui n’a toujours pas de sens. Le product manager de Dylan relit les plans d’ingénierie exactement comme ça, et quand il conteste, il a raison environ 80 % du temps.
Dylan voit une victoire dans les 8 % de plans abandonnés. Le quoi semblait bon, le comment a montré que ça n’en valait pas la peine, et personne n’a eu à le construire juste parce que c’était déjà dans le sprint.
Avant la cuisson
Une recette
« Pas envie de salade », c’est facile à dire
Le plan : tout le monde en rejette désormais
vs
Une fois cuisiné
Un plat
Le renvoyer demande une énergie à la Gordon Ramsay
La pull request : les seniors s’en chargeaient
2,8×plus de chances de rejeter un plan qu’une pull request
80 %des objections du product manager étaient justes
8 %des plans abandonnés avant toute ligne de code
Le comment compte toujours
Il a conclu en contredisant une phrase de Paul Graham : « Quand n’importe qui peut fabriquer n’importe quoi, ce qui fait la différence, c’est ce que vous choisissez de fabriquer. » Pour Dylan, ce qui fait la différence, c’est toujours la façon dont vous le fabriquez.
Deux ordinateurs portables peuvent avoir exactement la même fiche technique et être des produits complètement différents. La différence, ce sont des centaines de décisions sur le comment, prises en cours de route, et ce sont elles qui décident si un produit est performant, s’il tient la charge et s’il reste facile à déboguer. Son conseil : ne restez pas en bas d’une boucle où l’agent prend ces décisions à votre place, et refusez les outils qui vous y mettent.
Ce qui change, c’est le niveau auquel vous y répondez. Vous ne vous souciez plus de l’organisation des fichiers ni du nom des fonctions. Vous décidez toujours de la façon dont les données circulent, dont l’authentification fonctionne et dont le système gère les pannes.
Un produitMême fiche techniqueUn autre produit
Vous décidez toujours, dans le planle flux des donnéesle fonctionnement de l’authentificationla gestion des pannes
Les agents décident, dans le codel’organisation des fichiersle nommage des fonctions
DylanNe restez pas en bas de la boucle, et refusez les outils qui vous y mettent.
Essayez
Overmind a publié son outil interne sous le nom d’until, « des tickets adossés à git, pour les humains et les agents ». Vous écrivez le plan, quelqu’un le valide, chaque section du plan devient une tâche que vos agents prennent en charge, et un agent de revue compare le code au plan, si bien que tout ce qui manque ou dépasse vous revient sous forme de décision. Pour l’instant, c’est sur liste d’attente uniquement, et le site cite Claude Code, Cursor, Codex, Pi, Factory Droid, Amp et OpenCode.
L’argument existe aussi sous forme de manifeste, AI Is Not Your Peer, signé Dylan Ratcliffe, James Lane et David Schmitt. Sa phrase clé : « L’artefact qui mérite une revue, c’est le plan que nous avons écrit avant que l’agent écrive quoi que ce soit. »
01Vous écrivez le plan
Chaque fonctionnalité commence par un plan, et le plan vous appartient
02Quelqu’un le valide
Aucun agent ne démarre tant qu’une personne n’a pas dit oui
03Les agents prennent les tâches
Chaque section du plan devient une tâche nommée
04Vérifier l’écart
Tout ce qui manque ou dépasse vous revient sous forme de décision
Harnais citésClaude CodeCursorCodexPiFactory DroidAmpOpenCode
Liste d’attenteDes tickets adossés à git, pour les humains et les agents.
Pour aller plus loin :
- Pull Requests Are Dead, Long Live Peer Review, la conférence, 25 minutes
- AI Is Not Your Peer, le manifeste
- until, l’outil de revue de plan, sur liste d’attente
- L’usine logicielle agentique, c’est celle de 2022 avec une seule case changée, là où la revue est devenue mon goulot d’étranglement
- Ce qui casse quand un agent IA gère un vrai commerce, une autre conférence d’AGNTCon + MCPCon
Regardez la conférence, puis essayez de relire votre prochaine tâche d’agent sous forme de plan, avant que le moindre code existe. Dites-moi si votre lead time bouge.
Texte brut: review-the-plan-not-the-pull-request.md · Flux Atom · Toutes les notes