Herontwerp van source control bij Anthropic

Nu het aantal merges per dag met meer dan tienvoudig is toegenomen, is source control onze grootste bottleneck in de ontwikkeling geworden. Hier delen we hoe we in vijf maanden zijn overgestapt naar een intern versiebeheersysteem.

Bij Anthropic is programmeren niet langer de bottleneck bij het bouwen van systemen of het doen van onderzoek. Claude is in staat om autonoom te itereren op onderzoekscycli, complexe programma's micro-optimaliseren en nieuwe services vanaf de grond op te bouwen met een snelheid en schaal die we nog niet eerder hebben gezien. De bottleneck is nu de volledige ontwikkelaarsinfrastructuur die is gebouwd voor menselijke schaal: source control, builds en CI (Continuous Integration).

In mei 2026 mergede Anthropic gemiddeld ongeveer 2.500 code-wijzigingen per dag; in september waren dat er meer dan 30.000 per dag. We verwachten niet dat deze groei op korte termijn zal afnemen; de latente vraag naar het mergen van code is vrijwel oneindig, en elke bottleneck die we wegnemen, leidt onmiddellijk tot een verdere toename van de hoeveelheid code die we produceren.

Om deze groei te ondersteunen, hebben we Scion gebouwd, een intern versiebeheersysteem, en in vijf maanden onze monorepo volledig gemigreerd van Git. In diezelfde periode hebben we ook een interface voor code reviews gebouwd (genaamd Antique), code search, een uitgebreid source control IAM-systeem en innovatieve manieren om grote hoeveelheden gereviewde code te beheren en te landen. In dit artikel richten we ons specifiek op de bouw van Scion. Het is een interessante casestudy: het vermogen van Claude om code te schrijven was zowel de reden dat we in deze situatie terechtkwamen, als de manier waarop we snel een hoogwaardig, schaalbaar systeem konden bouwen om ermee om te gaan.

De groei van onze monorepo

Voordat we ingaan op wat we hebben gebouwd, moeten we erkennen hoe ongebruikelijk onze werklast is. Anthropic gebruikt Claude voor het schrijven van software veel vaker dan bijna elk ander bedrijf, waardoor we vaak de eersten zijn die merken waar tools die voor menselijke schaal zijn gebouwd, onder spanning komen te staan. Source control is daar slechts één voorbeeld van. Hoewel we niet verwachten dat veel organisaties op zeer korte termijn tegen deze problemen aanlopen, vermoeden we dat het niet lang zal duren voordat anderen die AI-codingtools gebruiken, tegen dezelfde knelpunten aanlopen.

Git is een gedecentraliseerd systeem: elke clone is een complete, zelfstandige repository die diffs kan berekenen, geschiedenis en 'blame' kan lezen, en elke revisie kan uitchecken terwijl hij volledig offline is. Voor de overgrote meerderheid van de repositories is dit het juiste ontwerp, en dat is een groot deel van de reden waarom Git de standaard is geworden.

Naarmate onze monorepo groeit, past hij steeds minder in dat ontwerp. De geschiedenis van onze hoofdbranch alleen al is bijna 100 GB, en een gecomprimeerde working copy is meer dan 25 GB. We voeren ongeveer 25 miljoen code-checkouts per dag uit voor CI, zonder de omgevingen van ontwikkelaars, agent-sandboxes en onderzoekstaken mee te tellen. Als dit naïef zou worden opgehaald, zou dat neerkomen op meer dan 600 PB aan Git-verkeer per dag.

Git biedt tools om met een deel van een repository te werken, zoals shallow clones, sparse checkouts en promisor remotes. Daarnaast zijn er standaard omwegen voor grote monorepo's, zoals interne Git-mirrors en repository-snapshots (seeds) die in blob-storage worden bewaard. We hebben ze allemaal gebruikt — op ons hoogtepunt beheerden we honderden interne Git-mirrors om de belasting op te vangen. Dit kocht ons tijd, maar ze werden moeilijker te beheren naarmate ons merge-tempo toenam. Seeds raakten tussen de refreshes verder verwijderd van de tip van de hoofdbranch, en het kostte steeds meer zorg om operaties die afhankelijk zijn van geschiedenis, zoals diff en blame, werkend te houden op partiële clones.

Als we een stap terug doen, merkten we dat we, net als de meeste bedrijven, Git gebruikten als een gecentraliseerd systeem met één gezaghebbende kopie, maar dat bijna al onze clients agents en jobs waren die per definitie online zijn. De eigenschappen die Git uitstekend maken voor gedistribueerd, offline werk, ondermijnden actief ons vermogen om te schalen naarmate de repo groeide. Daarom stelden we onszelf de vraag: als we source control vanaf het begin zouden ontwerpen met het feit dat agents altijd online zijn in het achterhoofd, hoe zou dat er dan uitzien?

Principes voor source control op agentschaal

Bij agent-gestuurd programmeren evolueren veel gangbare aannames over hoe software wordt ontwikkeld. We hebben deze veranderingen omarmd bij het bouwen van Scion, wat ons in staat stelde een fundamenteel andere benadering dan Git te hanteren op basis van verschillende kernprincipes. Er is reeds voorkennis voor source control van enorme monorepo's, met name Google’s Piper en Meta’s Sapling, waardoor we Scion konden bouwen met hun lessen in het achterhoofd. Onze principes zijn:

• Clients zijn altijd online. Git gaat ervan uit dat clients offline werken en een volledige kopie van de repository nodig hebben. Aangezien bijna al onze clients agents en jobs zijn, hebben we de client en protocollen van Scion ontworpen rond een server die altijd bereikbaar is, waarbij clients data ophalen wanneer ze die nodig hebben.
• Client-server asymmetrie. In Git is elke client in staat om een volwaardige server te zijn. In Scion beantwoordt de server vragen over bestandshistorie en blame, maakt hij commits aan, voert hij merges en rebases uit, enzovoort. De client onderhoudt een beperkte lokale object-cache, plaatst de bestanden van de working copy op disk, monitort wijzigingen in het bestandssysteem en biedt gebruikers een ergonomische manier om met de server te werken. De client kan zelf zeer weinig berekenen, maar in ruil daarvoor is er veel minder lokale data nodig.
• Een uitgebreide source control service kan vele nieuwe toepassingen aandrijven. Bij Git moet een CI-job of tool die een vraag over de repository wil stellen (bijvoorbeeld wie een regel als laatste heeft gewijzigd of hoe twee commits aan elkaar gerelateerd zijn), een lokale kopie van de repo bijhouden of hopen dat vendor-specifieke API's het antwoord geven. Bij Scion zijn alle source control-queries die de client gebruikt ook via API beschikbaar. In veel gevallen hebben jobs dus helemaal geen lokale repository nodig. Veel interne tools, zoals onze geautomatiseerde bisect- en revert-pipelines, zouden op schaal niet praktisch zijn zonder deze goedkope, programmatische toegang tot source control.
• Alles moet horizontaal schaalbaar zijn. Op ons hoogtepunt draaiden we honderden Git-mirrors, wat de capaciteit zwaar belastte en niet langer schaalde zodra de repo de disk- of geheugenlimieten van de mirrors oversteeg. In Scion zijn de data van de repository gedistribueerd en is elk component onafhankelijk schaalbaar; er is nergens een volledig gematerialiseerde kopie van de repo, zelfs niet op de server. Er is geen equivalent van packfiles (de gecomprimeerde bundles van objecten in Git), waardoor repository-onderhoud niet nodig is.
• Commits moeten goedkoop, incrementeel en lock-vrij zijn. In Git commit je lokaal en push je vervolgens om je werk te delen. In Scion gebeurt elke commit, rebase of merge op de server, dus er is niets te pushen, maar elke operatie moet snel zijn. De kosten voor het maken van een commit en het bijwerken van de downstream-datastructuren moeten schalen met de grootte van de wijziging, niet met de totale grootte van de repo, anders kan de server het niet bijbenen. De ontwikkelingscyclus in Scion ontmoedigt refs (pointers naar commits, zoals branches en tags), behalve voor de hoofd-ref of release-branches, omdat globale status waar elke server het over eens moet zijn, een dreigend schaalprobleem is.
• De working copy is optioneel en inherent 'sparse'. Omdat onze monorepo zo groot is en we dagelijks tientallen miljoenen keren code uitchecken voor CI, wilden we checkouts zoveel mogelijk vermijden. Met Scion kan een CI-job die bijvoorbeeld het verschil (diff) nodig heeft tussen een commit en zijn merge-basis, dit direct aan de server vragen. Hetzelfde geldt voor schrijfacties: veel write-workloads kunnen de checkout overslaan en volledig via API functioneren. Het protocol van Scion is gecentreerd rond sparse checkouts (die alleen de mappen bevatten waar de client om vraagt) en gevirtualiseerde checkouts (die bestanden on-demand materialiseren), zodat wanneer een job bestanden op disk nodig heeft, de client alleen betaalt voor wat hij daadwerkelijk leest.

Hoe Scion werkt

Datastructuren

In Scion is de eenheid van werk een "changeset", een vermelding in een write-ahead log. Een changeset bevat het meeste van wat je zou verwachten van een commit in Git. Maar waar een Git-commit een pointer naar de tree opslaat, slaat een changeset een lijst op van de bestanden die zijn gewijzigd ten opzichte van de eerste parent[^1], samen met content-addressed pointers naar de gecomprimeerde bestandsinhoud in blob-storage. Changesets worden server-side aangemaakt en zijn direct overal beschikbaar.

Deze structuur stelt ons in staat om changesets met een zeer hoge doorvoer te accepteren, omdat er geen packfiles geaccepteerd hoeven te worden, geen locking of cross-server coördinatie nodig is, en er geen refs verplaatst hoeven te worden. Scion ondersteunt technisch gezien refs, maar aangezien noch het aanmaken noch het ophalen van commits deze vereist, is het verplaatsen van een ref een compare-and-swap op een enkele Spanner-rij die apart van het aanmaken van changesets gebeurt.

Een changeset registreert alleen wat er is gewijzigd, dus op zichzelf kan hij geen vragen snel beantwoorden zoals wie een regel als laatste heeft bewerkt of welke commits een bestand hebben beïnvloed. Om deze te beantwoorden, bouwt Scion aanvullende datastructuren vanuit de changesets, waaronder specifieke structuren voor file blame en pad-historie, en skip-lists voor de commit-graph. We noemen alles wat niet direct deel uitmaakt van de changeset "afgeleide data" (derived data), en we berekenen dit allemaal via één generiek mechanisme. Elk type afgeleide data is recursief gedefinieerd, zodat de waarde voor een changeset wordt berekend op basis van de waarden van de parents van die changeset.

Dit mechanisme heeft drie voordelen:

1. We kunnen gemakkelijk een nieuw type afgeleide data toevoegen wanneer een nieuwe datastructuur een operatie sneller zou maken.
2. Voor elk type kunnen we kiezen of we het direct (eager) berekenen of het werk uitstellen, zodat we het materialiseren van data die we niet nodig hebben vermijden.
3. Omdat de client nooit de interne werking van deze datastructuren ziet, kunnen we ze optimaliseren zonder de client te wijzigen.

Het schalen van Scion

Een kleine vloot Scion-servers biedt source control API's voor elke operatie die een client nodig heeft, zoals het ophalen van changesets, het berekenen van diffs, het vinden van merge-bases en het ophalen van blobs. Alle source control-data is content-addressed, wat betekent dat een stuk data nooit verandert zodra het is opgeslagen, en elke server het kan cachen zonder overleg met andere servers. Hierdoor zijn de servers horizontaal schaalbaar en is er weinig coördinatie nodig. Ze zijn in feite grote caches die ook afgeleide data on-the-fly kunnen berekenen en de resultaten terugschrijven naar Spanner.

De vele consumenten van Scion hoeven geen eigen lokale repositories meer te onderhouden. Het ophalen en onderhouden van de repository was voorheen een aanzienlijke onderhoudslast voor CI-jobs of tools. In het begin van de migratie beantwoordde Scion alleen deze "metadata"-queries. Het ophalen van bestandsinhoud en het materialiseren van working copies zijn veel data-intensievere operaties en vereisten een eigen ontwerp.

De scn client van Scion wijkt op verschillende belangrijke punten af van de fetch-protocollen van Git. De onderhandeling van Scion vertelt de server niet wat de client al heeft; in plaats daarvan werkt het uitsluitend op basis van de trees en blobs die de client wil hebben. Vanaf een root-tree controleert de client zijn lokale store op ontbrekende trees en vraagt deze recursief op, waarna het proces wordt herhaald voor blobs. Elke aanvraag is voor een specifiek object dat nooit verandert, dus elke cache kan deze beantwoorden. Dit proces is efficiënt en hervatbaar, omdat er geen sprake is van één enkele multi-gigabyte packfile-respons. Sparse en zelfs gevirtualiseerde checkouts hebben geen speciale ondersteuning nodig, omdat de client simpelweg niet vraagt naar trees die hij niet wil.

In de vloot communiceert de client via een socket met een daemon, scion-daemon, die objecten opslaat voor de gehele node. De meeste nodes hebben toegang nodig tot de monorepo, en jobs op dezelfde node hergebruiken grotendeels dezelfde objecten. Elke daemon start vanuit een periodiek verversde snapshot en communiceert vervolgens alleen met de tree- en blob-cache-servers in zijn regio, genaamd scion-cache. Deze cache-servers streamen objecten direct uit het geheugen, in het disk-formaat dat de daemon zal consumeren. Wanneer een cache een object mist, vraagt hij dit aan de gezaghebbende scion-servers, die indien nodig lezen uit Spanner of cloud-storage.

De scion-daemon, scion-cache en scion-server reageren allemaal op identieke RPC's voor dit protocol, waardoor de client de cache-topologie niet hoeft te kennen. We handhaven echter strikt de tiering om failure-domeinen te isoleren en te voorkomen dat een storing in een regionale scion-cache de upstream scion-servers overbelast en het hele systeem platlegt.

Elke laag van dit systeem behoudt een cache-hitrate van meer dan 99% en vereist geen langdurige status, waardoor het gemakkelijk op te schalen is. Onze Scion-infrastructuur is nu 200x kleiner dan onze vorige Git-mirroring-infrastructuur qua CPU- en geheugenvereisten. CI- en research-jobs checken code twee ordes van grootte sneller uit (seconden in plaats van minuten), wat een aanzienlijke hoeveelheid capaciteit in de vloot vrijmaakt; CI alleen al leverde een winst van 25% in CPU-capaciteit op.

Lessen getrokken bij het bouwen van Scion

We begonnen met het bouwen van Scion rond dezelfde tijd dat Claude Mythos Preview en Claude Tag intern beschikbaar kwamen. Beide releases versterkten tegelijkertijd de behoefte aan Scion en versnelden aanzienlijk hoe snel we het konden bouwen.

Een opvallend voorbeeld: eerder in het jaar hadden we de eerste versie van de Git-naar-Scion-ingestionpipeline grotendeels handmatig geschreven als prototype. We dachten dat het goed was — tot we toegang kregen tot een vroege interne snapshot van Claude Mythos Preview. We vroegen het model om het geheel te herschrijven en, zonder verdere instructies, produceerde het een versie die 20x minder geheugen verbruikte en 4x sneller was, terwijl alle impliciete invarianten rond de volgorde van ingestion en datastructuren behouden bleven.

Wat we hebben geleerd bij het bouwen en exploiteren van Scion, biedt interessante lessen voor softwareontwikkeling op agentschaal:

• Snelle ontwikkeling met een klein team wordt gebruikelijker. Een team van zeven mensen bouwde zowel Scion als Antique (onze tool voor code review) en een half dozijn gerelateerde systemen, en migreerde hier volledig na in vijf maanden. Dit gebeurde terwijl het volume aan dagelijks gemergde code met 10x toenam. Voorheen zou het ontwikkelen en implementeren van een dergelijk systeem jaren hebben geduurd met veel meer engineers.
• Engineers zijn niet minder waardevol, maar hun werk verandert. Alle engineers die aan dit systeem hebben gewerkt, zouden Claude nu beoordelen als beter in het schrijven van code dan zijzelf. Maar onze engineers leverden nog steeds het onmisbare begrip van de high-level inter-systeemcomponenten en de design-trade-offs. Vaak was de rol van de engineers om "nee" te zeggen tegen Claude. Agents schenden soms kernbeperkingen van het systeem om een patroon te volgen dat nooit toegestaan had mogen worden. Ook was er soms sprake van over-engineering in reactie op hypothetische zorgen; menselijke engineers moesten Claude sturen om dit te voorkomen. De teamleden reviewen nog steeds elke change request, maar ze kijken nu naar de intentie van de wijziging in plaats van elke regel code te lezen.
• Optimalisatie en kwaliteit konden aanzienlijk worden verbeterd. Dankzij het vermogen van Claude om enorme hoeveelheden code veel sneller te schrijven dan wijzelf, is Scion een van de best geteste codebases waar we ooit aan hebben gewerkt. Zelfs binnen onze krappe tijdlijn konden we hermetische simulaties bouwen van elke niet-triviale infrastructuur- en source control-interactie, naast fuzzing en geavanceerde rate-limiting.
• Grondslag voor nieuwe vormen van monorepo-beveiliging. We hebben Scion ontworpen met veiligheid en compliance in het achterhoofd. Het ondersteunt uitgebreide toegangscontrole op repositories en de mogelijkheid om permissies toe te passen op individuele mappen. De review-tooling kan complexe semantische beperkingen voor goedkeuringen uitdrukken, waardoor menselijke reviewers zich kunnen concentreren op de meest consequente wijzigingen.
• Een nieuw niveau van operationele uitmuntendheid is mogelijk. We gebruiken Claude Tag intensief om componenten te monitoren. We hebben Slack-kanalen aangemaakt waar Claude de taak heeft om obsessief gefocust te zijn op de gezondheid van één enkel component (we noemen deze Claudes "superfans"). Ze hebben toegang tot telemetry en logs en treden op als een ervaren engineer die continu grafieken ververst en zoekt naar afwijkingen.

We denken nu volledig na over onze aannames. Een traditionele merge queue is bijvoorbeeld niet logisch op agentschaal. Wat betekent CI nog als honderden of duizenden wijzigingen kunnen mergen terwijl tests draaien? We hebben geïnvesteerd in geautomatiseerde testen na de merge en vóór de deployment. Dit betekent dat concurrerende wijzigingen kunnen conflicteren, maar Claude kan deze conflicten meestal sneller oplossen dan mensen ze kunnen identificeren.

Bijdragen aan het bredere ecosysteem

We zien Scion als slechts één onderdeel van het antwoord op de schaalproblemen die steeds capabelere AI-agents veroorzaken. We delen deze details als voorbeeld van hoe teams soortgelijke uitdagingen kunnen aanpakken.

Scion is absoluut geen geschikte vervanger voor Git voor algemeen gebruik. De concepten die we hier beschrijven zijn alleen zinvol voor werkelijk enorme monorepo's met tienduizenden engineers of zwermen agents. Daarnaast is Anthropic uniek in de zin dat ons budget voor interne token-consumptie veel hoger is dan wat elk ander bedrijf realistisch gezien zou willen uitgeven.

Het is praktisch gezien moeilijk om Scion in een vorm aan te bieden die breed nuttig is voor andere organisaties, omdat het sterk afwijkt van Git en eigen tooling voor review, search en CI vereist. We verwachten echter dat deze klasse van problemen de komende zes tot twaalf maanden gebruikelijker wordt. We denken dat de meest impactvolle bijdrage is om ons denkproces te delen, zodat andere ontwikkelaars de succesvolle delen van Scion kunnen toepassen op Git zonder het algemene model te verlaten. Een Git-server hoeft namelijk niet op dezelfde manier te werken als een Git-client.

Ten slotte willen we erkennen dat de Git-community bijna twee decennia heeft besteed aan het schalen van het platform voor miljoenen ontwikkelaars. Onze bijdrage is veel smaller: het delen van ons vroege inzicht in hoe agent-gestuurde softwareontwikkeling interageert met deze systemen, zodat we kunnen samenwerken met GitHub, GitLab en de OSS-community om te voorzien in de veranderende behoeften van ontwikkelaars.

***

Erkenningen Geschreven door Nick G. en het source control team: S.G., R.K., Dan C., Garrett H., Ben L., Colin M., Joe P. We zijn dankbaar aan Vilas J. en Sergiu D. voor hun ondersteuning en aan Amir O. voor vroege bijdragen aan Antique.

[^1]: Het opslaan van gewijzigde bestanden ten opzichte van de eerste parent van een merge is een stilistische keuze; in de praktijk hebben we gemerkt dat mensen bij trunk-based development in een monorepo alleen geïnteresseerd zijn in historie of blame voor commits op de hoofdlijn.