Article historique. Décrit l’architecture v1, y compris le classifieur regex pondéré et le modèle déclenché par la CI sur une seule branche. La plupart de ce qui est décrit ici a été volontairement retiré en v2. Voir Supprimer notre classifieur regex et CI en local, le changement pour ce qui l’a remplacé et pourquoi.
Quand un pipeline CI échoue, quelqu’un dans l’équipe doit s’arrêter, lire les logs, comprendre ce qui a cassé, corriger, pousser et attendre que le pipeline passe. Ce cycle se répète plusieurs fois par jour dans la plupart des équipes d’ingénierie.
Les agents IA peuvent automatiser toute cette boucle. Voici comment Stitch s’y prend.
Étape 1 : détecter l’échec
Stitch s’exécute comme un job en aval dans votre pipeline CI. Quand un job en amont échoue, Stitch s’active. Il ne fait pas de polling ni de webhook. Il est déclenché par le système CI lui-même, donc latence nulle et aucune dépendance externe.
Étape 2 : lire et parser les logs
Les logs CI sont désordonnés. Ils contiennent des codes couleur ANSI, des timestamps, des barres de progression et des milliers de lignes. Stitch retire le bruit et extrait les signatures d’erreur pertinentes.
Il regroupe les erreurs par type : échecs de lint, erreurs de type check, échecs de tests, problèmes de dépendances, erreurs de build. Chaque catégorie a une stratégie de diagnostic différente.
Étape 3 : diagnostiquer la cause racine
C’est là que le modèle IA prouve sa valeur. Stitch envoie le contexte d’erreur nettoyé à un modèle de langage avec les fichiers sources pertinents. Le modèle ne voit pas tout le dépôt. Il voit seulement les fichiers référencés dans la trace d’erreur, plus leurs dépendances immédiates.
Ce contexte restreint est intentionnel. Il évite les hallucinations liées au code non pertinent et garde l’utilisation de tokens prévisible.
Étape 4 : générer et valider le correctif
Le modèle produit un patch. Stitch l’applique localement et relance les vérifications qui ont échoué. Si elles passent, le correctif est commité et poussé. Sinon, Stitch rapporte le diagnostic et la tentative de correction pour qu’un humain prenne le relais avec tout le contexte.
Cette étape de validation est critique. Un correctif généré par IA qui n’est pas testé n’est qu’une suggestion. Stitch traite chaque correctif comme une hypothèse à vérifier.
Étape 5 : regrouper et dédupliquer
Quand plusieurs jobs échouent pour la même cause racine, Stitch les regroupe. Si cinq fichiers de tests échouent à cause d’un import manquant, Stitch corrige l’import une fois et rapporte le correctif pour les cinq jobs. Pas de commits en double, pas de travail redondant.
Garde-fous
Stitch opère dans des limites strictes :
- Une seule branche par pipeline. Tous les correctifs d’une exécution donnée vont dans une branche, une merge request.
- Pas de force push. Jamais.
- Accès fichiers restreint. L’agent ne lit que les fichiers référencés dans les traces d’erreur.
- Auto-merge configurable. Désactivé par défaut. Vous relisez la MR avant qu’elle n’atterrisse.
Le résultat
Les équipes qui utilisent Stitch rapportent moins de changements de contexte pour les échecs CI triviaux. Le cycle corrige-pousse-attends pour les problèmes courants comme les erreurs de lint, les imports manquants et les mismatches de types passe de 15 minutes à moins de 2 minutes. Plus important, les développeurs restent concentrés sur le travail qui compte.
Les pipelines CI casseront toujours. La question est de savoir si un humain doit être dans la boucle pour chaque échec.