Un pivot produit démarre rarement par une slide. Ça démarre généralement par une plainte qui ne passe pas.
Pour Stitch, la plainte, c’était la latence. Même quand v1 marchait parfaitement, le cycle de retour restait un aller-retour de pipeline. On l’a habillé, on l’a documenté, on a fait la paix avec. Les utilisateurs, non. Les gens qui ont essayé Stitch et l’ont aimé continuaient à nous renvoyer la même question : pourquoi j’attends ma CI pour trouver un import manquant alors que je pouvais lancer le même linter en une seconde sur ma machine ?
La réponse qu’on se donnait était “parce que l’agent a besoin de l’environnement CI”. La réponse honnête, une fois écrite, était “parce qu’on a décidé que l’agent devait vivre là-bas”. Ce n’est pas la même chose.
L’observation
Les développeurs font déjà tourner des agents IA en local. Claude Code vit dans le terminal. Codex aussi. Les deux sont authentifiés, les deux sont configurés, les deux ont déjà accès au dépôt que le développeur édite actuellement.
Rien de tout ça n’est dans l’environnement CI. Pour l’y mettre, il faut en reconstruire un sous-ensemble, mal. Clés API, registres d’images, dépendances en cache, secrets montés. Tout ça pour approximer, sur un runner, une chose que le développeur a déjà devant lui.
Le changement, quand on l’a enfin dit à voix haute, était d’une simplicité embarrassante. Arrêter de bâtir l’agent dans le pipeline. Faire tourner le pipeline en local, à côté de l’agent que le développeur possède déjà. Les laisser parler directement.
Ce que ça débloque
Une fois qu’on dit “Stitch tourne en local”, beaucoup de problèmes de v1 cessent d’en être.
La latence s’effondre. Les jobs tournent sur la même machine que l’éditeur. Un job de lint qui attendait quatre-vingt-dix secondes un runner en file tourne en une demi-seconde. Le correctif qui prenait trois cycles de pipeline à vérifier prend trois exécutions locales. Un retour en secondes, pas en minutes.
Les clés API disparaissent. L’agent est déjà authentifié via l’abonnement Claude Code ou Codex du développeur. Stitch n’a pas besoin de sa propre clé, n’en stocke pas, n’en demande pas. L’onboarding, c’est npx stitch-agent run claude et c’est tout.
Votre config CI existante, c’est la config. Il n’y a rien à ajouter à .gitlab-ci.yml ou .github/workflows/*.yml. Stitch lit le fichier que vous avez déjà écrit et lance les mêmes jobs sur votre machine. Le pipeline que vous gardez dans votre dépôt reste la source de vérité.
Les jobs d’infrastructure restent distants. Déploiements, publications, pushes d’images, rien de tout ça ne doit tourner sur un laptop. v2 les détecte par nom de job et les saute. Vous gagnez l’exécution locale pour les jobs de vérification, votre CI garde les jobs d’infra. Rien de dupliqué, rien de cassé.
La confidentialité arrête d’être une slide de vente. L’exécution locale veut dire que vos logs, votre source, vos correctifs ne quittent jamais la machine, sauf si vous configurez un canal de notification qui les envoie ailleurs. Il n’y a pas de backend Stitch qui puisse fuiter quoi que ce soit parce qu’il n’y a pas de backend Stitch.
Ce que ça contraint
Le local-first n’est pas gratuit. Ça veut dire que Stitch tourne là où vos outils tournent. Si votre CI exige une image Docker spécifique pour compiler un binaire, votre machine locale doit pouvoir faire la même chose, sinon le job ne peut pas être vérifié en local. En pratique, ça va pour les toolchains de langages classiques et c’est pénible pour les environnements de build exotiques.
Ça veut aussi dire que Stitch est un outil par développeur, pas un service d’équipe. Pas de dashboard partagé, pas de métriques à l’échelle de l’orga, pas de plan de contrôle central. C’est un compromis assumé. Le compromis, c’est “votre CI, votre machine, votre agent, votre rythme”. Si ce que vous voulez c’est un service managé de correction au merge, Stitch n’est pas la bonne forme pour vous.
La seconde intuition
L’intuition plus discrète qui est sortie de ce pivot portait sur le public de Stitch.
v1 supposait toujours une équipe avec un budget pipeline. v2 marche aussi bien pour un développeur solo sur un projet du week-end. Le code s’en fiche. La même commande npx, la même expérience d’agent-dans-un-terminal, la même absence de config. On avait optimisé pour le client qu’on aurait voulu avoir au lieu du développeur qu’on voyait sans cesse essayer Stitch et rebondir.
Le local-first a rendu le produit accessible à quiconque avait déjà un dépôt et un agent. Ce qui, de plus en plus, est tout le monde.
Le prochain post est plus petit et plus technique : un classifieur qu’on a passé trois mois à construire et qu’on a supprimé en un après-midi.