La première version de Stitch faisait ce qu’elle promettait. Vous ajoutiez deux jobs à votre config CI, stitch-monitor et stitch-heal, pointant sur une image Docker publique, et la prochaine fois qu’une règle de lint ou qu’un test cassait, une merge request apparaissait avec un patch. Pour le sous-ensemble d’échecs qu’il gérait bien, l’expérience était presque magique.
On l’a expédié. On l’a utilisé sur nos propres dépôts. Et en quelques mois, on a compilé une liste honnête de ce qu’il avait raté. Ce post, c’est cette liste.
Il vivait au mauvais endroit
Stitch v1 était un citoyen de votre système CI. Il s’exécutait comme un job en aval, activé sur un échec amont, et faisait tout son travail dans l’environnement du pipeline. Ça a l’air propre. Mais ça avait des conséquences qu’on a sous-estimées.
Chaque correctif imposait un aller-retour complet dans le pipeline. Votre CI tournait, échouait, Stitch tournait, commitait, poussait, votre CI retournait. Même sur un runner rapide, la boucle de retour durait des minutes, parfois des dizaines de minutes. Pour le genre d’erreur que Stitch était censé gérer, un import manquant, un désaccord de formatter, une annotation de type que le test runner n’aimait pas, le correctif lui-même prenait une seconde et la vérification prenait une éternité. L’humain attendait toujours la machine, juste dans une autre pièce.
Il supposait que l’agent vivait ailleurs
v1 parlait à un modèle de langage via une API. On a livré une intégration OpenRouter, un GitHubAdapter, une classe StitchAgent. Le discours d’onboarding était “apportez votre propre clé API”. Ça paraissait petit. En pratique, chaque équipe qui voulait essayer Stitch devait créer un compte chez un fournisseur, générer une clé, la stocker dans des secrets CI et budgétiser des tokens.
Pendant ce temps, de plus en plus de développeurs avaient déjà Claude Code ou Codex sur leur laptop, déjà authentifié, déjà payé via leur abonnement perso ou équipe. Stitch v1 ne savait pas leur parler. Il demandait aux utilisateurs de payer deux fois.
Il a sur-ingénié les parties qu’il pouvait voir
v1 embarquait un classifieur regex. Un moteur pondéré qui lisait les logs CI, les passait à travers cent cinquante patterns et triait les erreurs en neuf catégories : lint, formatage, types, build, config CI, test, types complexes, logique, inconnu. Chaque catégorie avait un score de confiance. Chaque catégorie avait une stratégie de correction.
C’était satisfaisant à construire. C’était aussi surtout du théâtre. L’agent à l’autre bout de l’API était capable de lire un log brut et de comprendre ce qui avait cassé. Notre classifieur, au mieux, servait à garder le prompt court. Au pire, c’était une couche de traduction qui introduisait ses propres bugs. Quand l’agent s’est amélioré, on a gardé le classifieur. On l’avait déjà construit.
Il poussait avant de savoir
L’auto-merge était un flag. Désactivé par défaut, mais mis en avant. Un correctif atterrit, la relance passe, la merge request peut se fermer toute seule. En pratique, ce flag est un piège. Une CI qui passe prouve que la suite de tests est contente, pas que le patch était le bon. On a vu des cas où l’agent faisait taire un test qui échouait en changeant l’assertion, obtenait du vert, et l’équipe perdait complètement le signal. La réponse de v1 était “relisez chaque MR”. La réponse de v2 devait être différente.
Il passait mal à l’échelle pour les petits cas
v1 supposait que l’équipe avait une plateforme CI quelque part qui pouvait héberger son image Docker, avait le budget pour du calcul en plus à chaque échec, et avait quelqu’un d’habilité à ajouter des jobs à la config pipeline. Pour une startup de trois ingénieurs, ça faisait trois obstacles avant le premier correctif. Pour un développeur solo sur un side project, c’était un mur.
Les cas d’échec où Stitch était le meilleur, les petits nettoyages de cinq minutes, étaient exactement ceux où les petites équipes avaient le plus besoin d’aide. Et c’étaient exactement les équipes que v1 n’atteignait pas.
Ce qu’on a gardé
Pas tout. Mais beaucoup.
L’idée de base, que les agents IA peuvent lire des logs d’échec, comprendre le problème et produire un patch ciblé, était juste. L’insistance sur la validation, qu’un patch qui ne repasse pas proprement n’est pas un correctif, était juste. L’idée d’escalader après un nombre borné de tentatives était juste. Ces points sont passés en v2 sans changer.
La forme autour d’eux, non. Le prochain post de cette série raconte où on l’a emmenée.