GitLab baut Quellcodeverwaltung der nächsten Generation für Coding-Agenten auf dem Git-Protokoll

Antwort auf die Last durch Agenten auf Git

GitLab versteht seine Arbeit als Reaktion auf einen aktuellen Engineering-Blogbeitrag von Anthropic. Diesem Beitrag zufolge, wie GitLab ihn wiedergibt, hat agentenbasiertes Coding die Versionsverwaltung von Anthropic über das hinaus belastet, wofür Git ausgelegt wurde: Die Merges in das Monorepo stiegen von rund 2.500 pro Tag im Mai auf mehr als 30.000 pro Tag im September.

Anthropic baute daraufhin ein internes System namens Scion, das von der Annahme ausgeht, dass nahezu alle Clients Agenten sind, die dauerhaft online sind. GitLab verweist darauf, dass Anthropic klarstellt, Scion solle Git nicht ersetzen und sei auch nicht mit Blick auf Git-Kompatibilität entworfen worden. Es adressiere Skalierungsprobleme, die in den nächsten sechs bis zwölf Monaten verbreitet auftreten könnten.

Der Anthropic-Artikel legt nahe, dass Git-Plattformen serverseitig umfangreichere Operationen anbieten können, ohne die Git-Kompatibilität aufzugeben. GitLab sieht genau darin das Problemfeld seiner eigenen Arbeit an der nächsten SCM-Generation. Das Unternehmen zitiert Nick G. aus dem Bereich Source Control bei Anthropic: „Wir sehen Spielraum, das Leistungsspektrum von Git-Servern für diese Workloads zu erweitern, ohne das grundsätzliche Git-Modell zu verlassen.“

So funktioniert die Architektur

Laut GitLab nutzt das neue SCM das Git-Protokoll, auf das sich Entwickler und ihre Werkzeuge bereits verlassen. Das Backend lässt sich über viele Rechenknoten hinweg skalieren. Über seine Schnittstellen können Agenten gezielt die Dateien und die Historie abrufen, die sie für die jeweilige Aufgabe brauchen. Das kann nach Angaben des Unternehmens wiederholte vollständige Klone von Repositories reduzieren.

Das Design trennt Rechenleistung und Repository-Speicher. Ein Objektspeicher hält die Repository-Daten, während zustandslose Rechenknoten Anfragen aus lokalen Caches bedienen. Die Kapazität wächst durch das Hinzufügen von Knoten, und die Komponenten kommunizieren über die Standard-S3-API. Laut GitLab kann das System auf GitLab.com und in selbst betriebenen Umgebungen laufen, auch in Air-Gap-Setups, in denen Repository-Daten die Infrastruktur des Kunden nie verlassen.

Ziel ist es, Engpässe durch intensive Lese- und Schreibzugriffe zu verringern. In frühen internen Tests liefen Workloads nach Angaben von GitLab bis zu 50-mal schneller, benötigten die Hälfte der Tokens und erzeugten bis zu 1.000-mal weniger Netzwerkverkehr. Es handelt sich um eigene Ergebnisse des Unternehmens aus internen Tests.

Roadmap: Kontext, Nachvollziehbarkeit und Richtlinien

Das Backend sei nur ein Teil der Vorbereitung der Quellcodeverwaltung auf Coding-Agenten, sagt GitLab. Teams müssten außerdem wissen, welche Anweisungen eine Änderung geprägt haben, welche Commits und Merge Requests betroffen waren und welche Richtlinien galten. Die Roadmap umfasst:

• Die Anweisungen und Entscheidungen hinter einer Agentensitzung festhalten, während die Arbeit stattfindet.
• Jede Sitzung mit den Commits und Merge Requests verknüpft halten, die sie erzeugt, auch nach einem Squash oder Rebase.
• Reviewern Änderungen zusammen mit dem relevanten Kontext zeigen, damit sie sich auf Arbeit konzentrieren können, die menschliches Urteilsvermögen erfordert.
• Branch-Richtlinien auf Agentenidentitäten anwenden, damit Teams steuern können, welche Agenten bestimmten Code ändern dürfen.

GitLab ordnet diese Arbeit in seine Vision einer kontrollierten Software-Fabrik ein, die es auf seinem Kundenevent Transcend beschrieben hat: ein vernetztes System, das Teams dabei hilft, Software unter ihren eigenen Richtlinien und Standards von der Idee bis in die Produktion zu bringen. Das Unternehmen betont, dass diese Funktionen geplant und noch nicht ausgeliefert sind. Sein Beitrag enthält die üblichen Hinweise zu zukunftsgerichteten Aussagen.

Arbeit am Upstream-Git und wie es weitergeht

Ein Großteil der Git-Arbeit von GitLab geschieht nach eigenen Angaben im Upstream-Projekt, und das Unternehmen sei in den jüngsten Releases der größte Unternehmensbeitragende zu Git gewesen. In Git 2.54 lieferte es eine steckbare Schnittstelle für den Objektspeicher von Git und verlagert seither weitere Teilsysteme der Objektdatenbank von Git hinter diese Schnittstelle. In Git 2.56 wurden Konsistenzprüfungen, Wartungsaufgaben und die Erzeugung von Packfiles hinter die Schnittstelle verschoben, die Arbeit geht weiter.

Das neue SCM soll laut GitLab als eigene schnelle, skalierbare Implementierung dieser Schnittstelle laufen, ergänzt um Schnittstellen für Agenten. Zudem will das Unternehmen dieselbe Abstraktion auf das Upstream-Git ausweiten, um den Umgang von Git mit großen Binärdateien zu verbessern.

Teams, deren Repositories ihr Git-Backend bereits an Grenzen bringen, lädt GitLab ein, Early Access anzufragen und das System mit diesen Repositories zu testen. Das Versprechen des Unternehmens: Agenten-Workloads lassen sich skalieren, ohne das Git-Modell zu verlassen oder von einem Fork abhängig zu sein.