git-ai deux jours pour mille étoiles : une réimplémentation open source de Scion d'Anthropic

Le 13 octobre, Anthropic a publié un blog de développement technique dans lequel il décrivait pour la première fois son système de gestion de versions interne, Scion : un système centralisé sur serveur conçu pour plusieurs centaines d’agents de codage qui lisent et écrivent simultanément et collaborent sur le code, mais pas open-source. Deux jours plus tard, le 15 octobre, le développeur feder-cr (Federico Elia) a créé le dépôt git-ai sur GitHub. La première phrase du README était : « Anthropic a construit Scion… Alors j’ai construit git-ai : une version open-source de ce design que n’importe qui peut exécuter ». Au 17 octobre, il y avait environ 1 000★ (données fournies par l’API de recherche GitHub, soit 1057), une progression rapide en deux jours. Licence MIT, langage Go. Ce texte est divisé en six sections, comme d’habitude.

I. Qui est-ce ?

L’identité de gitai doit être analysée en deux parties.

Le socle est un fork de GitLab Gitaly. Gitaly est le serveur Git RPC de GitLab, et cette chaîne de preuves est très claire dans le répertoire : le fichier NOTICE commence par « The following components are included in Gitaly: », le répertoire cmd/ contient toute la suite des commandes originales comme gitaly, gitaly-backup, praefect, etc., le fichier VERSION indique 19.5.0-rc3 (le numéro de version de Gitaly), et le fichier LICENSE contient deux lignes de droits d’auteur : « Copyright (c) 2026 Federico Elia and the gitai contributors (modifications and additions). / Copyright (c) 2016-present GitLab Inc. ». Le fichier README indique que Gitaly fournit les services de base Git, et que chaque RPC Gitaly reste utilisable en flux upstream ; le répertoire ee/ non MIT n’est pas dans ce répertoire.

Le nouveau concept s’appelle “graft”. Selon les statistiques locales : il y a 2833 fichiers git-trackés dans le dépôt, avec environ 576 000 lignes de code en Go (dont la majeure partie provient de Gitaly). Parmi celles-ci, les nouveaux dossiers internal/graft et cmd/graft* représentent environ 75 000 lignes, ce qui constitue le cœur de cette ouverture source : la CLI graft, le processus de gestion de la cache graft-cache, le verificateur graft-verify, l’outil de test graft-bench, ainsi qu’un ensemble complet de sous-systèmes côté serveur tels que land, changeset, derived data, resolver et review.

Il y a encore une détail à expliquer honnêtement : l’historique git du dépôt a été squashé, et un clone superficiel ne permet de voir qu’un seul commit. Les 75 000 lignes de nouveau code ne peuvent évidemment pas avoir été écrites en deux jours, mais la durée de développement est incertaine et peut seulement être interprétée comme une « publication globale après une longue préparation ». La section Status dans le README indique Version 0.1.0, la première version publique. De plus, le dépôt contient les fichiers de flux d’agent AGENTS.md et CLAUDE.md, et le projet lui-même est organisé de manière à être utilisé par les agents et à leur permettre de participer au développement.

Deuxièmement, pourquoi c’est le présent

La raison directe de l’apparition de gitai est le blog d’Anthropic intitulé “Redesigning source control at Anthropic” (publié le 13 octobre, mis à jour une fois le 15 octobre). Ce blog a pour première fois numérisé les difficultés liées à la gestion des sources de code avec un nombre important d’agents : en mai 2026, il y avait environ 2 500 merges par jour, et en septembre, ce chiffre dépassait les 30 000 fois par jour, soit une augmentation de 12 fois en quatre mois. Le history du monorepo atteignait près de 100GB, et la copie de travail compressée mesurait au moins 25GB. Chaque jour, il y avait environ 25 millions de checksouts CI, ce qui correspondait à un volume de données de 600PB+ par jour pour git ; en période de pic, plusieurs centaines de mirrors internes de git devaient être utilisés. Les hébergements Git traditionnels étaient conçus pour “une personne à cloner une fois, travailler quelques heures, puis poster une fois”. Le clonage complet, les files d’attente de merge et l’exploration historique des clients devenaient tous des points de bloc à ce niveau. La solution de Scion consiste à déplacer le travail sur des serveurs : les clients restent toujours en ligne et récupèrent le nécessaire ; les problèmes historiques (blame, histoire des chemins) sont calculés et mémorisés sur le serveur ; l’exécution se fait par compare-and-swap sans file d’attente ; il n’y a pas de copie complète du repository sur le serveur, permettant une expansion horizontale. Anthropic a terminé la migration en 5 mois.

Mais Scion est interne, le public ne peut pas y accéder. C’est ainsi que l’open-source a vu le jour ; gitai n’est pas le seul (déjà le 13 octobre, quelqu’un avait créé openscion, mais sa portée de diffusion était limitée, avec seulement 7 likes). Mais c’est celui qui fonctionne le plus rapidement.

La autre facette de cette popularité provient d’un débat. Le 14 octobre, sunshowers, ancien membre du team de contrôle des sources de Meta, a publié un post (HN 425▲) affirmant que Scion était « fortement inspiré de Mononoke » (le système de contrôle des sources open source de Meta) : il y avait une similitude conceptuelle et terminologique avec des termes tels que derived data et Bonsai changeset. Même le nom Scion était une inversion syllabique de « Bonsai » en retirant la lettre B. Le blog d’Anthropic a alors simplement remercié Google Piper et Meta Sapling. Le 15 octobre, il a ajouté un deuxième post (HN 251▲), affirmant que Scion était « intentionnellement et ouvertement copié sur Mononoke » et qu’il y avait des chevauchements de personnel (cette affirmation est une déclaration de sunshowers, non vérifiée indépendamment). Par la suite, Nick G. d’Anthropic a répondu sur HN, ajoutant des explications sur l’origine du projet et une nouvelle ligne dans la partie supérieure de la page avec une formulation officielle : « Mise à jour le 15 octobre pour inclure plus de détails sur les projets qui ont développé beaucoup des techniques utilisées dans Scion ». L’article principal sur le blog a atteint 889▲, ce qui en fait l’un des sujets les plus populaires dans le réseau de développement de la semaine.

Cette controverse a une signification pour l’objet de déconstruction : elle a transformé « la pensée de conception de Scion, qui avait en réalité déjà des précédents open-source (Mononoke) », en un sujet public, ce qui équivaut à avoir educé le marché pour tous les projets de clone. C’est justement cette opportunité que gitai a saisi.

III. Analyse du mécanisme

Il a transformé les designs décrits sur le blog Scion en des produits fonctionnels. Parlez de quatre points les plus importants.

Le premier point est le fait de ne pas devoir faire la queue pour mettre à jour les données. Les files d’attente des plateformes gérées traditionnelles constituent un obstacle en série. L’approche de UserLand est de rébase les modifications sur la branche actuelle vers son sommet (tip), puis d’utiliser le mécanisme CAS pour mettre à jour les références : si CAS échoue, cela signifie qu’une personne a déjà mis à jour les données avant nous. L’opération est alors redéroulée automatiquement, au maximum 20 fois par défaut. Les mises à jour simultanées sur la même branche seront également regroupées en une seule opération de mise à jour. Les données de référence fournies dans le document illustrent bien la situation : lorsque 20 agents mettent à jour les données sur la même branche, chaque modification doit être testée environ 10 fois en moyenne, avec un délai p99 de 26 secondes.

Le deuxième est le journal des changesets. Chaque mise à jour acceptée est enregistrée dans un fichier changesets.jsonl pour chaque dépôt, et est ajoutée en série avec flock et fsync. La dernière ligne du journal qui est corrompue sera tronquée lors de l’ajout suivant, les numéros de série commençant à 1 et augmentant de manière dense. L’agent peut s’abonner à ce flux pour suivre en temps réel ce qui se passe dans les dépôts. Dans le README, ces agents de surveillance sont appelés superfans, et ils peuvent également signaler les événements importants via Slack.

Le troisième type de données est généré sur le serveur. blame, l’historique des routes, les relations d’ancêtre, et la recherche de code sont tous calculés sur le serveur. La mémoire cache fonctionne selon l’adressage par contenu. La clé est SHA-256 (kind, commit, path). Les écritures se font via des fichiers temporaires et une substitution atomique avec renommage ; chaque commit est comptabilisé une seule fois. Le client n’a donc pas besoin de l’historique complet. graft clone et graft sparse ne gérent que les routes que vous souhaitez utiliser.

Le quatrième est un résolver de résolution de conflits démontable. Le protocole est versionné et neutre par rapport aux fabricants : on peut l’configurer avec une commande locale (réception de JSON via stdin) ou un endpoint HTTP, avec des listes blanches et noires de routes, des listes blanches d’acteurs, des délais et un maximum de fichiers. Le résolver AI fonctionne en dehors du serveur ; le serveur ne contacte jamais de grands modèles de données. C’est une exigence clairement affirmée dans le README : neutralité des fabricants. Les commits résolus par l’IA sont marqués avec la note Graft-Resolved-By, ce qui permet une vérification ultérieure.

Sur le modèle de sécurité, il y a un point important à mentionner : chaque agent dispose de son propre token, l’identité ne peut pas être usurpée par des utilisateurs internes, et les tests e2e vérifient strictement cela. Les RPC que l’agent peut interroger sont définis dans le code dans une liste d’autorisations (allowlist) ; desRPC dangereux comme la création de répertoires à partir de snapshots sont toujours désactivés pour l’agent.

Il y a également deux mécanismes complémentaires. Le premier est la vérification après mise en œuvre : graft-verify maintient une référence verte, et si la testée échoue après mise en œuvre, l’erreur est localisée et les modifications sont automatiquement réversibles, avec l’ajout de la note Graft-Auto-Revert. Une limite d’un heure est fixée pour éviter des erreurs répétées. Cela transforme le slogan « fusionner d’abord, puis tester » en un processus avec garantie de réversion. Le second est une règle de revue sémantique : les exigences de validation peuvent être configurées en fonction de la nature des modifications. Par exemple, les modifications purement annotatives nécessitent moins de validation que les modifications logiques. Cela est essentiel pour les scénarios où les agents soumettent une grande quantité de données ; l’attention des réviseurs humains est en effet rare. La couche de cache dispose d’un processus de garde à part, graft-cache, qui calcule à nouveau l’ID avant chaque accès à un objet. Si le type, la longueur ou le contenu ne correspondent pas, l’accès est refusé. Une série de rejets est combinée en une seule appelée vers l’avant.

IV. Chiffres et vérification

The documentation provided by the warehouse gives a measured result where 100 agents attempt to deploy to a branch simultaneously (the machine used is Intel Core Ultra 7 255H with WSL2, and the noise is explicitly stated in the documentation). When batch deployment is disabled, on average, each change attempts 56.94 times. Out of 500 changes, only 115 were successfully deployed, with 277 abandoned. The throughput per minute was 126.6 times. When batch deployment is enabled, the number of attempt times decreases to an average of 1.00 times per change. 392 changes were successfully deployed, with a throughput of 257.6 times per minute.

Plus difficile, c’est qu’il ne se contente pas de présenter des bonnes nouvelles. Le même document indique que les critères de validation de phase 4a n’ont pas été atteints : avec une taille de 50 et 100 agents, le retard p99 est en réalité plus élevé lorsqu’une production est lancée, par rapport à la situation sans production. La section Status du README mentionne directement que c’est la première version publique de Version 0.1.0 ; les interfaces pourraient changer avant 1.0. Les tests end-to-end n’ont été effectués qu’en monnaie unique, et le comportement avec plusieurs nœuds n’a pas été testé. Le document LIMITATIONS dans doc/graft liste quatre critères qui définissent son positionnement : ce n’est pas un produit hébergé, pas un substitut à GitLab, pas une implementation de Scion, et il ne constitue pas une limite de sécurité.

Comparez avec la norme du secteur : la plupart des projets qui atteignent 1000 étoiles en deux jours n’ont qu’un diagramme de vision dans le README. Ce projet est sorti sous licence open source avec six documents de conception par étapes, des déclarations de tests de fuzz et de récupération d’écrasement, ainsi qu’un rapport de bench qui indique clairement « non reçu ». La qualité de son développement est la plus solide parmi les projets de copie de la même tendance.

V, Jugement

Pour commencer par la conclusion : gitai mérite attention, mais il traite actuellement le problème de « la taille d’Anthropic ». De plus, Anthropic même dit dans son blog que l’on ne s’attend pas à ce que la plupart des organisations rencontrent ces problèmes dans un proche avenir.

Trois observations. Premièrement, la moitié de la fenêtre qu’elle touche est technologique, l’autre moitié est narrative. La controverse sur l’appartenance de Mononoke a transformé « cette approche de design ayant déjà des précédents open-source » en un sujet public, ce qui équivaut à une formation du marché pour tous les projets de réplique. Gitai est celui qui s’est déplacé le plus rapidement dans cette vague : environ 1 000 étoiles en deux jours, beaucoup plus que openscion (avec seulement 7 likes sur HN) qui est apparu le 13 octobre. Une partie importante de cette popularité est un transfert de controverse vers Anthropic, et non entièrement liée au produit lui-même.

Deuxièmement, le choix de la base Gitaly Fork est très intelligent et aussi lourd. C’est intelligent car il hérite directement des fonctionnalités complexes telles que Git RPC, gestion des répertoires et sauvegarde. Sa licence MIT est également claire. Mais c’est lourd car il porte la complexité de l’écosystème GitLab. La construction nécessite Meson, Ninja, ainsi que la compilation intégrée avec Git. Le niveau de difficulté rend cette solution peu adaptée pour un usage généraliste à court terme.

Troisièmement, ce qui vaut vraiment la peine d’être appris, c’est quelques jugements de conception plutôt que le code lui-même : pour l’implémentation, utiliser CAS avec des traitements par lots plutôt que par filet, pour les logs, utiliser un format JSONL ajouté à fsync, les capacités d’IA devraient être intégrées dans des résolvers démontables en dehors du serveur, et l’identité et les droits des agents doivent être définiés à l’avance au niveau du protocole. Ces quatre points constituent une réponse prête à l’emploi pour tout équipe qui souhaite mettre en place une infrastructure de collaboration multi-agents.

Il faut clarifier les risques : pilotage individuel, histoire ignorée pour ne pas voir le processus de développement, les interfaces de 0.1.0 peuvent changer à tout moment, et même les tests de validation n’ont pas réussi. Il est plus juste de classer selon le critère « haute valeur de référence pour la conception, utilité problématique en production ».

Six, qui peut utiliser comment

Les équipes à plusieurs agents qui écrivent en parallèle dans le même dépôt, et qui sont déjà confrontées à des conflits de fusion et à des problèmes de queue, constituent son premier public. Le script Quickstart permet de lancer le serveur en une seule touche, d’ajouter les processus de gestion de la cache, deux agents, et une opération de mise en place, ce qui permet de terminer le processus principal en moins d’une demi-journée. L’équipe de développement de plateforme peut lire uniquement les quatre documents ARCHITECTURE, STORAGE, RESOLVE et LIMITATIONS situés dans le répertoire doc/graft, pour intégrer les décisions de conception dans ses propres plans, sans avoir besoin d’introduire de code. Les équipes de dépôts monolithiques peuvent continuer à utiliser Git sans aucun problème ; c’est ce que ce dépôt lui-même affirme.

Si vous souhaitez l’utiliser, n’oubliez pas trois points : le noyau de stockage est par défaut désactivé, importer depuis le mode shadow puis passer au mode authoritative ; configurez d’abord les outils déterminants pour resolver, et ajoutez l’AI resolver en dernier ; ne le considérez pas comme une limite de sécurité, écrivez clairement les LIMITATIONS.

Source d’information

• Corps du stockage : github.com/feder-cr/git-ai (README, NOTICE, LICENCE, go.mod, VERSION, vérification de clone local du 17-10; documents sous ARCHITECTURE/STORAGE/RESOLVE/LIMITATIONS/BENCH/LAND-BATCHING)
• Blog officiel d’Anthropic « Redesigning source control at Anthropic » (publié le 13-10, mis à jour le 15-10, toutes les sources de Scion)
• Deux articles de sunshowers.io controversés sur Mononoke (14-10, 15-10) et discussions sur HN (889▲/425▲/251▲/7▲, snapshot du matin du 17-10)
• Nombre d’étoiles et date de création : API de recherche GitHub et créationAt de la page de stockage (snapshot du matin du 17-10, le nombre d’étoiles est encore en évolution)