Exécutez cinq instances de Claude Code sur le même ticket. Vous obtenez cinq implémentations fonctionnelles. Elles passent toutes les tests. Elles résolvent toutes le problème. Aucune ne ressemble au code que votre équipe aurait écrit il y a six mois.
C’est la nouvelle base. L’espace des implémentations valides a explosé, et il ne va pas se réduire de lui-même.
L’IA n’a pas rendu le code review obsolète. Elle en a fait le goulot d’étranglement.
Pendant dix ans, la génération était la contrainte et la revue était le nettoyage. L’après-midi d’un ingénieur senior, c’était 30 % d’écriture, 70 % de revue. Le goulot d’étranglement, c’était la vitesse de réflexion humaine.
Ce ratio s’est inversé. La génération est devenue quasi gratuite. Un développeur solo avec Claude Code ou Cursor peut produire en une semaine plus de code qu’une équipe de cinq personnes en un an.
Le goulot s’est déplacé. Désormais, la question est : laquelle de ces cinq implémentations fonctionnelles appartient vraiment à notre base de code ?
Cette question n’a pas de réponse modèle. Elle a une réponse d’équipe. Le goût accumulé de l’équipe est la seule chose qui distingue « du code qui fonctionne » de « du code qui a sa place ici ». La façon de nommer. La structure des modules. Ce que vous refusez d’importer. Quand vous sortez tôt. Comment vous écrivez les tests.
Sans cela, chaque PR devient un pile ou face entre cinq options raisonnables.
Votre goût est votre moat. Formalisez-le.
C’est là que la plupart des équipes bloquent. Le goût existe. Il vit dans la tête de trois ingénieurs. Il sort dans les commentaires de PR, dans les threads Slack, dans le regard désapprobateur qu’un senior jette à un junior un mardi après-midi. Il est réel, et c’est ce qui distingue une base de code qui accumule de la valeur d’une base qui dérive vers le chaos.
Mais il n’est pas encodé d’une manière lisible par une machine. Donc les agents ne peuvent pas le suivre. Les nouvelles personnes non plus. Même les seniors ne l’appliquent pas de façon cohérente, parce qu’ils sont fatigués, d’astreinte ou en réunion quand le PR arrive.
La plupart des équipes ont déjà un CLAUDE.md ou des .cursorrules. Ce sont des instructions sur la façon dont les agents doivent écrire du code dans votre repo. Remarquez l’asymétrie. Il y a un contrat d’écriture et il n’y a pas de contrat de revue. CLAUDE.md dit à l’agent quoi produire. Il n’y a pas de fichier équivalent qui dise à qui que ce soit, humain ou machine, ce qui est acceptable à merger.
Ce fichier, c’est STANDARDS.md. Du Markdown simple, dans le repo, versionné avec le code. Les décisions accumulées de l’équipe, rendues explicites. Pas des bonnes pratiques génériques. Vos opinions concrètes sur la façon dont vous construisez.
Rien de tout cela n’est une idée neuve. Kleppmann, dans Designing Data-Intensive Applications, soutient que les systèmes accumulent de la valeur quand leurs contrats sont explicites et vérifiables par machine. Un schéma, pas une intuition. STANDARDS.md applique cette même discipline un niveau au-dessus. Le contrat n’est plus entre services. Il est entre le PR d’un ingénieur et le goût accumulé de l’équipe.
Une fois que ce fichier existe, trois choses deviennent possibles.
Les agents génèrent du code en respectant ces standards. Votre goût contraint l’espace des possibles avant même que le code soit écrit.
Chaque PR est automatiquement revu par rapport à eux, que l’auteur soit humain ou agent. Pas de dérive, pas d’exceptions, pas de « on le rattrapera au prochain sprint ».
Les nouvelles personnes lisent un seul document et absorbent la vision de l’équipe en une après-midi.
Le fichier de standards n’est pas de la documentation. C’est la fonction de réduction. Elle prend l’explosion des implémentations valides et la projette sur votre implémentation.
Nous avons accéléré notre équipe par trois en faisant revoir chaque PR par l’IA selon nos standards.
Nous avons rencontré exactement ce mur en interne il y a trois mois. Nous avons construit Surmado Code Review d’abord pour nous-mêmes. Outil interne, v7. Exécuté sur 14 dépôts à chaque commit.
Nos standards vivent dans un STANDARDS.md par repo. Scout le lit, lit le diff, et dit au relecteur humain ce qui est bon, ce qui doit être amélioré, où regarder et quelles hypothèses le PR fait.
Le x3 concerne le temps jusqu’au merge sur nos 14 repos. Nos PR ne stagnent pas. Ils avancent.
Ce gain ne vient pas du fait que le bot fasse la revue. Il vient du fait que le bot réduit le bruit pour que les humains se concentrent sur ce qui compte. L’ingénieur senior cesse d’attraper les cinq mêmes choses dans chaque PR. Le junior cesse de deviner les conventions. Les PR générés par des agents cessent de dériver vers des formes que personne dans l’équipe n’aurait écrites.
Si vous n’avez pas encore de STANDARDS.md, Scout l’écrit avec vous. Deux clics pour installer. Scout vous interroge sur votre stack, vos conventions, votre posture de tests et les choix architecturaux que vous avez déjà faits.
Là où vous avez des opinions, Scout les écrit. Là où vous n’en avez pas encore, Scout propose des défauts que vous pouvez accepter, modifier ou remplacer. Si vous êtes un vibe coder qui n’a jamais eu à articuler ses standards, Scout structure la réflexion et fait émerger les questions que vous n’aviez pas pensé à poser.
Les opinions restent les vôtres. L’ossature est la même que celle que nous utilisons en interne pour nos STANDARDS.md. Le genre de discipline de standards qu’une équipe plus grande met des semaines à construire, vous l’avez en route cet après-midi.
Mon équipe de développement m’a forcé à le sortir. Ils en avaient marre de dire à des amis fondateurs que non, ils ne pouvaient pas l’avoir, que c’était interne. Alors nous en avons fait un produit.
À propos de votre code
Nous ne le stockons pas. Nous ne nous entraînons pas dessus. Nous ne lisons pas l’ensemble de votre dépôt.
Scout fonctionne sur des modèles de frontière d’Anthropic et d’OpenAI. Chaque revue de PR envoie uniquement le diff à leurs APIs, dans le cadre des accords API standard. Pas de rétention. Pas d’entraînement. Rien sur votre code ne persiste dans nos systèmes après la revue.
Lisez la politique de confidentialité et les conditions complètes. Tout est documenté.
À quoi cela sert vraiment
Le pitch que font la plupart des outils d’IA est : le modèle remplace l’humain. Ce cadre est faux sur le fond, et il est particulièrement faux maintenant.
La génération par IA accélère les équipes, mais elle accélère aussi la dérive des bases de code. L’accélérateur et l’entropie viennent du même endroit. Les équipes qui prennent de l’avance sont celles qui ont trouvé comment élever le jugement humain pour suivre la vitesse de la machine, pas celles qui l’ont remplacé.
Surmado Code Review n’est pas un relecteur autonome. C’est un amplificateur du goût de votre équipe. Vos standards, appliqués à chaque PR, chaque push, chaque exécution d’agent. Les humains continuent à faire le travail humain : décider quels sont les standards, prendre les décisions architecturales, transmettre à l’équipe, connaître le métier. Le bot fait la partie qui épuisait vos seniors : détecter les écarts par rapport à des décisions que vous avez déjà prises.
L’avenir de l’IA dans le code, ce n’est pas des agents qui remplacent les ingénieurs. C’est le goût des ingénieurs, encodé une fois, appliqué partout, à la vitesse de la machine. Les équipes qui comprennent cela en premier vont paraître méconnaissables aux équipes qui ne l’auront pas compris. Pas parce que leurs développeurs sont plus intelligents. Parce que leur goût s’applique à chaque ligne de code, y compris celles qu’ils n’ont pas écrites.
Comme tout ce que nous construisons chez Surmado, cela centre l’humain et renforce l’agent. Votre goût, amplifié.
Essayez-le sur votre prochain PR
Surmado Code Review. Deux clics pour installer. 15 $/mois pour 100 PR. Pas de tarification par utilisateur. Zéro rétention de vos diffs. Conçu pour les développeurs solo et les petites équipes qui avancent vite. Pas pour l’entreprise.
Installer Surmado Code Review ou lire comment nous l’avons construit.
Lectures associées :