Opschalen met codeeragents vraagt om goede repositorycoördinatie

Meerdere codeeragents tegelijk laten werken klinkt als een capaciteitsvraagstuk: voeg workers toe en laat ze code schrijven. In een engineeringartikel van 5 november beschrijft GitHub een minder voor de hand liggende grens. Een drukke gedeelde repository kan een coördinatievraagstuk worden, omdat elke push extra werk oplevert voor schrijvers én voor systemen die de nieuwe commit lezen.

GitHub zegt dat de nieuwe opslagarchitectuur is ontworpen voor repositories met duizenden writes per seconde. In interne tests toonde het bedrijf 5.000 gelijktijdige agents en 7.200 pushes per seconde naar één repository aan. Dit zijn resultaten die GitHub zelf rapporteert. De architectuur was volgens het artikel beschikbaar in een beperkte privépreview; een bredere uitrol stond gepland voor het volgende jaar. Voor de meeste engineeringteams is vooral de opzet interessant, niet het recordaantal.

Onveranderlijke data en veranderlijke verwijzingen kosten iets anders

Een Git-push slaat objecten op—commits, trees en blobs—en werkt daarna referenties bij, zoals branches. Git-objecten zijn onveranderlijk en op inhoud gebaseerd. Twee schrijvers kunnen dus verschillende objecten uploaden zonder elkaars data aan te passen. Een branchverwijzing is anders: het is een kleine gedeelde pointer en gelijktijdige updates moeten in een vaste volgorde worden verwerkt.

Het ontwerp van GitHub benut dat verschil. Packdata staat in Azure Blob Storage, referenties en de packmanifeststatus in een aparte gerepliceerde dienst. Wegwerpbare virtuele replica’s verwerken lees- en schrijfverzoeken. Achtergrondcompressie draait op aparte nodes. Opslag, verzoekverwerking en onderhoud kunnen zo onafhankelijk van elkaar schalen.

Die architectuur is afgestemd op de schaal en garanties van GitHub. Een gemiddeld productteam hoeft haar niet over te nemen. Het principe—bepaal welk kleine deel van de status echt coördinatie nodig heeft—is ook bruikbaar voor wachtrijen, gezamenlijk bewerken, workflows en orkestratie van agents.

Meer agents betekenen ook meer lezers

Na een push volgen vaak CI, deploycontroles, geautomatiseerde code-review en andere agents die de nieuwe branch ophalen. Eén write veroorzaakt zo extra leesverkeer. Wie alleen de uitvoertijd van agents meet, mist mogelijk de extra latency en kosten van fetches, herhaalde controles en concurrentie op een gedeelde branch.

Meet daarom de hele cyclus voordat je het aantal gelijktijdige agents verhoogt:

• Hoeveel commits en pushes produceert één taak?
• Hoeveel CI-jobs, fetches en reviewacties volgen op iedere push?
• Om welke branches of bestanden concurreren agents?
• Wanneer is de volledige repository nodig en wanneer volstaan enkele bestanden?
• Hoe lang duurt het van afgerond werk tot een geïntegreerde, beoordeelde wijziging?

Deze cijfers helpen bepalen of de grens bij modelvertraging, repositorycoördinatie, testcapaciteit of menselijke review ligt. Meer agents helpen alleen als de rest van de keten hun output kan verwerken.

Praktische patronen voor een drukke repository

Geef agents geïsoleerde worktrees, branches of tijdelijke clones, zodat ze elkaars werkbestanden niet overschrijven. Houd taken afgebakend en wijs bestanden duidelijk toe. Behandel commits als onveranderlijke resultaten en maak integratie een expliciete stap met conflictcontroles en tests.

Beperk werk dat door iedere push wordt gestart. Bundel gerelateerde wijzigingen waar dat kan, annuleer CI-runs die door nieuwere runs zijn ingehaald en haal niet steeds een grote historie op als een sparse of partial checkout volstaat. Zo beperk je extra verkeer zonder de review te verzwakken.

Maak coördinatie zichtbaar met pushfrequentie, wachttijd voor CI, conflicten, mislukte integraties en de tijd tot menselijke goedkeuring. Een teller met alleen het aantal agents kan meer activiteit laten zien terwijl software juist langzamer wordt opgeleverd.

Op een bruikbare manier opschalen

Het artikel van GitHub laat zien hoe agents het werkpatroon veranderen: meer gelijktijdige schrijvers, vaker updates en veel meer daaropvolgend leesverkeer. Een algemene engineeringaanpak is om onveranderlijke werkresultaten te scheiden van gedeelde veranderlijke status, zo weinig mogelijk status te ordenen en onderhoud los te koppelen van verzoekverwerking.

Begin met metingen in je eigen repositories. Verhoog de gelijktijdigheid geleidelijk, volg de hele integratiecyclus en wijs een duidelijke eigenaar aan voor de uiteindelijke wijziging. Parallel werk is pas echt snel als de repository er betrouwbare software van kan maken.

Bronnen: GitHub Engineering · GitHub