Tout outil proche du CI lancé ces dix-huit derniers mois arrive avec le même pitch : connectez votre repo, donnez-nous votre pipeline, laissez notre agent corriger les échecs. La forme de la demande est identique, même quand les produits ne le sont pas. Gitar veut votre repo dans son cloud. Nx Cloud veut que vous réorganisiez votre graphe de build dans son monorepo. Dagger veut que vous réécriviez votre YAML dans son SDK. Chacun a une raison défendable. Aucune de ces raisons n’enlève la taxe de migration à votre équipe.
Stitch a été construit autour d’une autre observation. Le développeur a déjà le pipeline, possède déjà la machine et, de plus en plus, a déjà un agent IA authentifié dans son terminal. Le travail n’est pas d’introduire un nouveau plan de contrôle. Le travail est de connecter les trois choses qui existent déjà.
Ce post traite des parties de la comparaison qui ne tiennent pas dans une matrice de fonctionnalités.
Le marché se divise en trois
Quand on regarde vraiment les produits, la catégorie AI-CI n’est pas un seul marché. Il y en a trois.
- Plateformes de refactor cloud comme Gitar. Vous poussez le code dans leur environnement, leur agent fait des changements à grande échelle, vous récupérez le résultat. Optimisées pour la modernisation ponctuelle à grande échelle.
- SaaS de graphe de build comme Nx Cloud. Vous restructurez le repo en workspace, poussez le graphe vers leur cache, recevez exécution distribuée et caching distant. Optimisées pour les gros monorepos avec des builds coûteux.
- Moteurs de pipeline programmables comme Dagger. Vous remplacez le YAML par du code, faites tourner le pipeline dans leur moteur en conteneurs et obtenez reproductibilité et portabilité. Optimisés pour les équipes dont le YAML CI est devenu impossible à maintenir.
Stitch n’est rien de tout cela. C’est une quatrième catégorie : une boucle de vérification local-first qui lit votre config CI existante et la fait tourner sur votre machine avec l’agent IA que vous utilisez déjà.
Matrice de capacités
| Capacité | Stitch | Gitar | Nx Cloud | Dagger + IA |
|---|---|---|---|---|
| Utilise votre config CI existante | Oui | Non | Non | Non |
| Exécute les jobs en local | Oui | Cloud uniquement | Cloud + local | Conteneurs |
| Agent IA enfichable | N’importe quel CLI | Built-in seul | Built-in seul | Built-in seul |
| Nécessite une nouvelle infra | Aucune | Compte SaaS | Workspace Nx | SDK Dagger |
| Intégration native Claude Code | Livre une skill | Non | Non | Non |
| Tarif | Gratuit, MIT | Plans payants | OSS gratuit + Cloud payant | Moteur OSS gratuit + Cloud payant |
La matrice sous-estime ce qui se passe vraiment. La partie intéressante est ce que chaque ligne implique pour une équipe d’ingénierie trois mois plus tard.
Ce que “utilise votre config CI existante” veut vraiment dire
Si un outil lit .github/workflows/*.yml ou .gitlab-ci.yml directement, votre CI reste la source de vérité. Le pipeline que vous envoyez en prod est le pipeline que la boucle de vérification exécute. La divergence est impossible par construction.
Si un outil exige de traduire votre pipeline dans un nouveau format (SDK Dagger, graphe de projet Nx, YAML SaaS du fournisseur), vous gérez maintenant deux pipelines. Un que vous poussez en CI. Un que l’outil local comprend. Chaque changement sur l’un doit être miroité sur l’autre. Dans la pratique, le miroir vieillit. Dans la pratique, l’outil local diverge lentement de la prod. Dans la pratique, “passe en local” cesse de signifier “passe en CI”.
La migration n’est pas le coût. La maintenance continue de deux configs est le coût. Stitch l’évite en refusant de posséder la config.
L’exécution locale n’est pas qu’une histoire de latence
Les outils cloud-only vendent l’échelle. La lecture honnête est qu’ils vendent l’échelle parce que le cloud est le seul mode qu’ils proposent. Il n’y a pas de CLI local que vous pouvez faire tourner sur un laptop sans aller-retour réseau. Cela a trois conséquences que personne ne met sur une page de vente.
- Votre code quitte la machine. Chaque itération envoie des diffs vers un backend SaaS. Pour des environnements régulés, c’est un examen de conformité.
- Vous payez à la minute de calcul. Un workflow de feedback rapide sur un runner lent devient cher vite.
- Vous héritez de leur disponibilité. Quand le SaaS a un incident, votre boucle de vérification s’arrête.
Local-first inverse les trois. Les jobs Stitch tournent sur la machine où vit l’éditeur. Rien ne sort sauf si vous configurez un canal de notification qui l’envoie. Il n’y a pas de backend Stitch susceptible de tomber.
”Agent IA enfichable” est la seule réponse honnête
Gitar, Nx Cloud et les fonctions IA boulonnées à Dagger Cloud livrent tous un seul agent propriétaire. Le choix appartient au fournisseur, le coût est la facture du fournisseur, la cadence de mise à jour du modèle est la roadmap du fournisseur.
Stitch n’a pas d’agent. Il invoque l’agent que vous utilisez déjà : Claude Code, Codex, n’importe quoi de compatible CLI. Les credentials sont les vôtres. Le choix de modèle est le vôtre. Quand Anthropic livre un Claude plus rapide ou OpenAI un Codex moins cher, vous l’adoptez le jour même, sans release Stitch nécessaire.
Cela compte parce que le marché des agents IA bouge plus vite que n’importe quel fournisseur de CI. Verrouiller l’agent dans l’outil de CI est un pari : que le fournisseur de CI suivra le rythme des modèles de frontière. Jusqu’ici, aucun ne le fait.
Le coût d’infrastructure est la vraie question de prix
La ligne tarif cache le chiffre le plus important. “Gratuit, MIT” pour Stitch signifie que la seule dépense est votre abonnement à l’agent IA déjà en place. Une ligne SaaS à partir de 20 dollars par utilisateur par mois, ou un plan Nx Cloud, ou un plan Dagger Cloud, sont des factures par siège qui grandissent avec l’équipe, en plus de l’abonnement à l’agent IA.
Pour une équipe de cinq personnes utilisant déjà Claude Code, Stitch ajoute zéro. Les outils concurrents ajoutent une ligne annuelle à quatre chiffres avant que la boucle de vérification ne tourne une seule fois.
Là où Stitch perd
Les comparaisons honnêtes ont besoin de cette section.
- Si vous voulez un service géré de fix-on-merge avec des dashboards à l’échelle de l’organisation, Stitch n’a pas cette forme. Il tourne par développeur.
- Si votre CI exige des images de build exotiques qui ne tournent pas sur un laptop, l’exécution locale ne vérifiera pas ces jobs. Stitch les détecte et les saute ; vous gardez le CI pour le reste.
- Si votre problème est “moderniser ce code Java 8 vers Java 21”, une plateforme de refactor comme Gitar est faite pour cela. Pas Stitch.
- Si votre problème est “notre YAML est illisible”, le remplacer par du code Dagger peut être la bonne décision. Stitch ne résoudra pas cela.
La matrice n’est pas “Stitch gagne partout”. La matrice est “Stitch gagne là où le problème est la vérification pré-push avec une boucle de fix IA sur le pipeline que vous avez déjà”.
Le pari
Le pari sous Stitch est que la machine du développeur est le bon endroit pour la boucle de vérification, et que l’agent IA déjà présent du développeur est le bon endroit pour les corrections. Tous les autres outils de la catégorie font le pari inverse : le bon endroit est le cloud du fournisseur, avec l’agent du fournisseur, au prix du fournisseur.
Si le pari est juste, les outils local-first gagnent en latence, coût, confidentialité et liberté d’agent. Si le pari est faux, les outils cloud gagnent en échelle et contrôle central. Nous pensons que le pari est juste parce que les agents sont déjà sur la machine du développeur. La partie difficile n’est plus “où faire tourner l’IA ?”. La partie difficile est “arrêter de la forcer ailleurs”.