Un ingénieur Google s’est inscrit à Surmado Code Review la semaine dernière. Le produit fonctionne avec Scout, notre analyste de recherche IA. Il a écrit un fichier STANDARDS.md pour son projet, ouvert sa première pull request, puis lancé Scout dessus.
Scout a signalé une faille architecturale critique qui aurait cassé la production.
Il n’a pas mergé. Il nous a écrit pour décrire son flux de travail :
« Je prends les retours de Surmado, je les copie dans Gemini. Gemini se flagelle, puis me donne un nouveau prompt à utiliser avec Gemini Code Assist dans mon IDE. Gemini Code Assist apporte les modifications. Je mets à jour la branche et Surmado relit automatiquement la nouvelle version. Et lorsque j’ai épuisé la boucle, c’est seulement à ce moment-là que je tague mes collaborateurs pour la relecture. »
Relisez. Il y a une boucle qui mérite d’être nommée.
La boucle
- Gemini Code Assist écrit le code dans son IDE.
- Surmado le relit par rapport à son
STANDARDS.md. - Il colle la relecture de Surmado dans le chat Gemini.
- Gemini lit le verdict de Surmado et réécrit le prompt pour lui-même.
- Code Assist régénère le code avec le nouveau prompt.
- Il pousse la nouvelle branche. Surmado relit automatiquement.
- Lorsqu’il épuise la boucle, il tague ses collaborateurs humains.
C’est la dernière étape qui nous fascine. La boucle ne remplace pas la relecture humaine. Elle fait en sorte que la relecture humaine n’intervienne que lorsqu’elle est réellement nécessaire. Au moment où un humain regarde la PR, l’évident est déjà corrigé. Les défauts d’architecture, les violations de standards, ce qu’un lecteur attentif attraperait un mardi après-midi fatigué. Disparu. Le relecteur humain se retrouve avec ce qui requiert vraiment un humain : les arbitrages de conception, l’intention, le jugement.
C’est cette version de l’IA dans la boucle dev qui fonctionne réellement. Pas « l’IA remplace les humains ». L’IA gère la partie convergente. Les humains gèrent la partie décisionnelle.
Ce qu’a dit Gemini
L’ingénieur a collé la relecture de Surmado dans Gemini deux fois pendant la session. Les deux fois, Gemini a immédiatement abondé dans le sens de Surmado.
La première réponse :
« Surmado vient d’attraper une faille architecturale critique qui aurait cassé votre site de production, et il l’a signalée en citant directement le fichier
STANDARDS.mdque nous avons écrit il y a 20 minutes. Vous ne devriez absolument pas merger cette PR pour le moment. Voici exactement ce qui s’est passé et pourquoi Surmado a entièrement raison. »
La seconde :
« Surmado a attrapé un trou dans notre exécution, et franchement, j’ai laissé tomber sur le prompt que je vous ai donné pour Code Assist. »
C’est cette seconde citation qui nous fascine. Gemini n’a pas blâmé le modèle. Gemini a blâmé le prompt. Les instructions que Gemini avait données à Code Assist n’incluaient pas les conventions de l’équipe, parce que Gemini ne savait pas quelles étaient les conventions de l’équipe.
Surmado le savait, parce que l’ingénieur les avait écrites vingt minutes plus tôt. STANDARDS.md est le pont entre ce que valorise l’équipe et ce sur quoi le modèle peut agir.
Pourquoi c’est ça, le produit
La plupart des outils de relecture de code IA vérifient les bonnes pratiques génériques. Indentez votre code. Ne masquez pas les variables. Évitez les nombres magiques.
C’est le minimum syndical. Tous les linters le font. La raison pour laquelle les équipes mergent encore du mauvais code, c’est que les bugs qui font mal en production ne sont pas génériques. Ils sont spécifiques à la façon dont l’équipe construit. C’est ce qui se trouve dans votre wiki, vos documents de conception, les conventions qui vivent dans la tête de trois ingénieurs seniors.
STANDARDS.md, c’est là que vous le mettez. Scout le lit. Chaque PR est relue par rapport à ce fichier. Chaque relance lit le nouveau diff et la relecture précédente, donc Scout peut dire si les problèmes antérieurs ont été corrigés.
La boucle de l’ingénieur fonctionne parce que chaque pièce fait ce pour quoi elle est bonne. Gemini écrit du code. Surmado le vérifie par rapport aux règles de l’équipe. Gemini se corrige lorsqu’on lui fournit un retour extérieur. Les humains relisent ce qui reste. L’intégrité vient de la boucle, pas d’un modèle isolé.
Ce que ça donne vraiment
Voici comment il a décrit ses tentatives précédentes de projets web :
« Je m’enthousiasmais devant les lignes de code générées, puis j’attendais, plein d’impatience, que ma création prenne vie, pour être finalement vraiment déçu quand elle finissait inévitablement par casser. »
Quiconque a tenté de vibe-coder un vrai projet connaît cette courbe. L’enthousiasme. L’impatience joyeuse. Le crash.
Puis ceci :
« Pas ce soir. J’ai poussé des PR qui ont accompli exactement ce que je m’étais fixé. »
Voilà la différence. Pas « l’IA a écrit du code ». Pas « l’IA a relu du code ». Une boucle qui converge vers un logiciel qui fonctionne, avec un point de contrôle humain à la fin lorsqu’il en faut un.
Le cadre que nous aimons
La plupart des outils IA se positionnent contre les humains. « Plus rapide qu’un relecteur humain. » « Attrape ce que les humains manquent. »
Surmado se positionne entre les IA. Pas plus rapide que Gemini. Pas plus malin que Claude. Le modèle qui a écrit le code ne sait pas ce que valorise l’équipe. Le modèle qui l’a relu, lui, le sait, parce que quelqu’un l’a écrit noir sur blanc.
Voilà à quoi ressemble un produit d’orchestration. Le LLM n’est pas le produit. La façon dont le LLM est branché aux règles réelles de votre équipe, voilà le produit.
L’ingénieur l’a résumé dans son dernier message : « Très impressionné. Et tellement parfaitement intégré au flux de travail. »
C’est ce que nous construisons.
Deux clics. Et ça fonctionne. 15 $ par mois pour 100 PR. Nous ne regardons jamais votre code. Les laboratoires de pointe que nous utilisons non plus.