Stitch 2.0 est là : exécutez votre CI en local, réparez les échecs avec l'IA

Stitch 2.0 est sorti. Si vous avez suivi la série, la version courte, c’est : tout ce que vous avez lu dans les retros vient d’atterrir.

Sinon, ce post est le résumé autonome. Ce qu’est Stitch aujourd’hui, ce qui change par rapport à v1, et comment l’essayer dans les trente prochaines secondes.

Ce qu’est Stitch 2.0

Un outil en ligne de commande qui tourne sur votre laptop. Il lit la configuration CI déjà dans votre dépôt, parse les jobs que vous avez définis et lance les jobs de vérification (lint, typecheck, test, build) en local en quelques secondes. Quand un job échoue, Stitch passe l’échec à un agent IA (Claude Code ou Codex) que vous avez déjà installé. L’agent corrige le problème. Stitch relance le job. S’il passe, c’est terminé.

Une seule commande pour installer et lancer :

npx stitch-agent run claude

Pas de clés API. Pas d’image Docker. Pas de nouveaux jobs pipeline. Aucun fichier de configuration requis. La CI que vous avez déjà, sur la machine que vous utilisez déjà, avec l’agent déjà ouvert à l’écran.

Ce qui a changé depuis v1

La liste courte, pour ceux qui ont utilisé Stitch v1 et se demandent ce qui a cassé :

• Langage. v1 était Python, distribué sur PyPI. v2 est TypeScript, distribué sur npm. Le nom du package reste stitch-agent.
• Modèle d’exécution. v1 tournait comme un job CI déclenché par un échec de pipeline. v2 tourne en local depuis votre terminal. Le pipeline reste intact.
• Intégration de l’agent. v1 parlait aux modèles via une API, avec des clés que vous fournissiez. v2 délègue à votre Claude Code ou Codex déjà installé et utilise votre abonnement existant.
• Surface de config. v1 exigeait d’ajouter deux jobs (stitch-monitor, stitch-heal) à votre YAML CI. v2 n’exige aucun changement à votre CI.
• Classification des erreurs. v1 avait un moteur regex de 150 patterns qui triait les erreurs en neuf catégories. v2 n’a rien de tout ça. L’agent gère le diagnostic directement.
• Auto-merge. v1 avait un flag pour ça. v2 fait auto-commit + push uniquement sur des branches propres et seulement si vous passez --auto-commit. Désactivé par défaut.
• TUI interactif. La sortie de v1 était un log CI. v2 a une interface terminal en direct avec un stepper de pipeline, une table de statut des jobs et un panneau driver.
• Mode watch. Nouveau en v2. Re-vérifie les jobs affectés à la sauvegarde de fichier.

Pourquoi une réécriture complète et pas une migration ? Parce que la plupart de ces changements ne sont pas des features, c’est la forme. Une bibliothèque faite pour tourner dans un environnement CI est structurée différemment d’une CLI faite pour tourner à côté de votre éditeur. Essayer de reforger v1 en v2 aurait été plus lent que d’écrire v2 à partir de zéro. On a essayé la voie lente d’abord. Les posts précédents de cette série expliquent comment on est arrivés à cette décision.

À qui ça s’adresse

Le profil qu’on avait en tête en réécrivant :

• Vous travaillez sur un ou plusieurs dépôts avec un pipeline CI.
• La CI casse pour des raisons triviales assez souvent pour que ça vous agace.
• Vous utilisez déjà Claude Code, Codex ou un autre agent IA en CLI au quotidien.
• Vous préféreriez ne pas attendre l’aller-retour d’un pipeline distant pour apprendre que vous avez oublié un point-virgule.

Si c’est vous, Stitch 2.0 est à une seule commande.

La suite

Stitch 2.0 est la première release de la forme local-first. La roadmap à partir d’ici est plus courte et plus simple que celle de v1, et c’est voulu. Ce qu’on veut ajouter ensuite :

• Plus de plateformes CI. GitLab CI et GitHub Actions sont supportés aujourd’hui. CircleCI, Drone et les runners self-hosted arrivent.
• Plus d’agents. Claude Code et Codex sont les drivers actuels. Ajouter d’autres agents en CLI est un petit pattern match.
• Meilleure inférence des jobs. L’heuristique pour classer vérification contre infra est bonne mais pas parfaite. Les cas limites sur les pipelines exotiques demandent plus de travail.
• Partage en équipe. Pas un dashboard, pas un service. Juste un moyen de partager une politique .stitch.yml à l’échelle d’un dépôt sans que chaque développeur la redécouvre.

Ce qu’on n’ajoute volontairement pas mérite aussi d’être nommé. Pas de service hébergé. Pas de compte. Pas de télémétrie. Pas d’entraînement sur votre code. Si ça change, ce sera un produit séparé avec un nom séparé.

Essayez

npx stitch-agent run claude

Si vous avez dix minutes et un pipeline qui échoue, c’est suffisant. Le dépôt est sur github.com/x24labs/stitch-agent. Les issues sont ouvertes. Les contributions sont bienvenues.

Merci d’avoir suivi la série. La réponse honnête à “pourquoi il a fallu une réécriture” est que la bonne forme ne nous était pas accessible tant qu’on n’avait pas vu la mauvaise forme expédiée. v2 est la version qu’on voulait construire depuis le début. Il fallait juste construire v1 pour le savoir.