Le problème
Nous sommes une petite équipe. Cinq personnes qui construisent une plateforme d’IA. À tout moment, nous avons 14 dépôts actifs. Cela signifie beaucoup de PR et pas assez d’humains pour bien les relire.
Les revues prenaient trop de temps. Des éléments importants passaient à la trappe. Nous livrions du code plus vite que nous ne pouvions le vérifier.
Nous avons donc construit notre propre bot de revue de code. Au départ, c’était un projet secondaire pour résoudre un point de douleur interne. Aujourd’hui, c’est un produit. Surmado Code Review. 15 $ par mois pour 100 PR.
Voici comment nous l’avons réellement construit. Ce qui a été vibe-codé, ce qui ne l’a pas été, et le framework que nous recommanderions à quiconque prototypant un pipeline d’IA.
Phase 1 : Démarrage en vibe coding
La première version était un agent de résumé. Rien de plus. On ouvre un PR, on obtient un résumé en langage naturel des changements. Tout a été vibe-codé. Rapide, pragmatique, avec Claude qui faisait l’essentiel du travail.
Puis nous avons commencé à nous demander : peut-il aussi détecter des bugs ?
C’est là que ça devient intéressant.
Phase 2 : Le forward-backward pass
C’est la partie que nous pensons vraiment utile de partager. Un framework applicable à n’importe quel pipeline d’IA, pas seulement à la revue de code.
Nous avons repris un concept de l’apprentissage automatique : le forward-backward pass. Mais au lieu d’entraîner les poids d’un modèle, nous avons traité tout le pipeline comme si c’était un LLM.
Voici comment cela fonctionne.
Forward pass. Vous définissez un ensemble d’entrées contrôlées. Dans notre cas, des PR avec des bugs que nous avons volontairement introduits. Vous les faites passer dans le pipeline et vous observez ce qui est détecté et ce qui ne l’est pas.
Backward pass. Vous analysez les ratés. Vous ajustez les prompts, la structure, la logique de revue. Puis vous relancez. Le bug est-il détecté cette fois ? Y a-t-il plus de faux positifs ?
Répétez. Chaque cycle est rapide et peu coûteux. Vous ne ré-entraînez pas un modèle. Vous itérez sur le code, les prompts et l’architecture avec un signal immédiat sur ce qui a fonctionné.
L’idée clé : vous transformez Claude Code en utilisateur synthétique. Vous lui donnez une entrée attendue et une sortie attendue. Vous le laissez générer d’autres cas de test et évaluer les résultats par rapport à votre pipeline. C’est votre test harness.
Les test harness sont faciles à vibe-coder. Si vous avez une API que vous pouvez appeler, vous pouvez en monter un en une après-midi. Quelque chose de déployé, conteneurisé, ou même qui tourne en local. Vous définissez les types de bugs que vous voulez que votre pipeline détecte, vous générez des cas de test, vous les exécutez et vous itérez.
C’était notre v1 et v2. Nous avions 10 théories différentes sur la façon de structurer la logique de revue. Au lieu de les débattre, nous faisions passer les 10 dans le harness et nous laissions les résultats trancher.
Phase 3 : Là où le vibe coding atteint ses limites
Au fil de toutes ces expérimentations, nous avons trouvé le vrai levier : l’ancrage par des standards.
L’agent de revue s’est considérablement amélioré dès qu’il a eu un document de standards bien rédigé comme référence. Les conventions de code réelles de l’équipe, nos décisions d’architecture.
Si vous faites du vibe coding, vous avez probablement déjà un CLAUDE.md ou un .cursorrules. C’est un contrat d’écriture. Il dit à l’agent ce qu’il doit produire. Mais la plupart des équipes n’ont pas de contrat de revue. Il n’y a pas de fichier équivalent qui dise à qui que ce soit, humain ou machine, ce qui est acceptable à merger. C’est de cette asymétrie que naît la dérive.
Nous avons écrit un STANDARDS.md pour chaque dépôt. Une fois ce fichier en place, l’agent avait enfin quelque chose de concret contre quoi comparer. Pas des bonnes pratiques génériques. Nos opinions concrètes sur la façon dont nous construisons.
Mais voilà. Le document de standards lui-même ne pouvait pas être vibe-codé. Sa mise en forme, son intégration au pipeline, sa langue et sa structure. Tout cela demandait un jugement humain soigneux. Nous avons écrit, testé la façon dont l’agent l’interprétait, et retravaillé. Cette boucle a été conduite par des humains.
La mise en produit a été entièrement faite à la main. Chaque partie.
Authentification et paiements. Câblés délibérément. Nous tenons à protéger l’argent des clients.
États d’erreur et remboursements. Conçus à la main. Quand quelque chose se passe mal, nous devons savoir exactement ce qui se produit et pourquoi.
Confidentialité. Non négociable. Le code des clients traverse notre pipeline. Cela exige une architecture délibérée, pas du code généré.
Intégration avec Scout. Scout est notre analyste de recherche par IA. Le câblage entre Surmado Code Review et Scout a été soigné, testé, intentionnel.
Nous avons aussi passé beaucoup de temps sur le poids des modèles dans le pipeline. Être délibéré sur quel modèle prend en charge quoi, équilibrer coût et qualité. Ce genre de décision ne se délègue pas au vibe coding. Elle demande de comprendre ses marges, les attentes des clients et les modes de défaillance de chaque palier de modèle.
Rien de tout cela n’a été confié à la machine.
Phase 4 : Revue humaine et finition
Après que le prototype vibe-codé et la boucle de test agentique nous ont donné une base solide, le reste a été beaucoup de travail humain de revue. Lire les sorties. Les comparer à ce qu’un ingénieur senior signalerait vraiment. Affiner le document de standards. Tuer les faux positifs.
Nous l’avons utilisé sur nos 14 dépôts internes. Au moment où nous avons sorti la v7, il avait traité des milliers de PR réels sur du code qui nous importait.
Résultat : temps jusqu’au merge divisé par trois sur ces dépôts. Les PR ne stagnaient plus. Les ingénieurs seniors ne chassaient plus les cinq mêmes choses dans chaque revue. Les juniors ne devinaient plus les conventions. Les PR générés par des agents ne dérivaient plus vers des formes que personne dans l’équipe n’aurait écrites.
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.
Le framework (à reprendre)
Si vous construisez un pipeline d’IA, de revue de code ou autre, voici le schéma.
1. Vibe-codez votre prototype. Faites tourner le flux de base. Ne surpensez pas l’architecture. Laissez l’IA monter l’échafaudage.
2. Construisez un test harness agentique. Définissez vos entrées et sorties attendues. Laissez Claude Code jouer le rôle d’un utilisateur synthétique. C’est le forward-backward pass. Il est rapide à monter si vous avez une API à appeler, et il vous permet de tester 10 idées dans le temps qu’il vous faudrait pour en évaluer une manuellement.
3. Laissez les données désigner les gagnants. Ne débattez pas de quelle approche est meilleure. Faites-les toutes passer dans le harness. Le signal est immédiat.
4. Trouvez le mécanisme d’ancrage. Pour nous, c’était un document de standards. Pour vous, cela pourrait être un guide de style, une grille, un ensemble de règles ou un dataset de référence. La chose qui rend votre pipeline cohérent et opiné. C’est votre véritable différenciateur, et cela demande presque certainement un artisanat humain.
5. Construisez à la main ce qui protège vos clients. Auth, paiements, confidentialité, états d’erreur. Ce n’est pas le terrain du vibe coding. C’est ce qui gagne la confiance. Faites-le délibérément.
Le constat honnête
Le vibe coding est un framework phénoménal pour le prototypage et l’expérimentation. La boucle de test agentique, le motif forward-backward, nous a permis d’aller plus vite en début de développement que nous n’aurions jamais pu autrement. Nous sommes passés de « et si on construisait un bot de revue de code » à un prototype fonctionnel attrapant des bugs réels en quelques jours.
Mais les choses qui rendent un produit digne de confiance ont exigé des humains prenant des décisions délibérées avec un contexte complet. L’ancrage par les standards. Le choix des modèles. Les flux de paiement. L’architecture de confidentialité.
Vibe-codez vos couches de prototypage et d’expérimentation. Façonnez à la main ce qui protège vos clients. C’est la ligne. Nous pensons que c’est la bonne.
Essayez-le sur vos propres dépôts
Surmado Code Review. 15 $/mois pour 100 PR. Construit par une équipe de cinq personnes. Utilisé en interne sur 14 dépôts.
Voir comment fonctionne Surmado Code Review ou lancer une revue sur votre prochain PR.
Lectures associées :