Wie Cursor die Grenzen von Git in großem Maßstab umgangen hat

Cursor, der KI-Code-Editor, musste ein echtes Skalierbarkeitsproblem mit Git lösen, um auf sehr großen Codebasen korrekt zu funktionieren. So haben sie es gemacht – und warum das für jeden Senior-Dev interessant ist.

Der konkrete Fall

Stellen Sie sich einen Codebase mit mehreren Millionen Zeilen vor – die Art von Code, die man in großen Tech-Konzernen, ausgereiften Open-Source-Projekten oder schnell gewachsenen Startup-Monorepos findet. Git beginnt zu kämpfen: git status dauert Sekunden, alltägliche Operationen werden frustrierend. Jetzt fügen Sie ein KI-Tool (Cursor) hinzu, das den Zustand des Repos in Echtzeit verstehen muss, um seine Vorschläge zu kontextualisieren. Das Problem wird kritisch.

Genau das ist Cursor passiert – und The Register erklärt, wie sie die Skalierungsgrenzen von Git umgangen haben.

Das grundlegende Problem: Git ist nicht für KI ausgelegt

Git wurde 2005 von Linus Torvalds entwickelt, um den Linux-Kernel zu verwalten – eine große, aber mit einem menschlichen Nutzungsmodell: Entwickler, die commiten, verzweigen und mergen. Git war nicht dafür gedacht, dass ein KI-Tool den Zustand des Repos dutzende oder hunderte Male pro Minute liest, um seine Echtzeit-Vorschläge zu speisen.

Die Engpässe sind bekannt:

• Git-Index: Die Datei .git/index wird bei jeder Status-Operation vollständig neu gelesen, selbst wenn nur eine einzige Datei geändert wurde.
• Objektspeicher: Das Abrufen von Objekten per Hash ist nicht für massenhafte und wiederholte Lesevorgänge optimiert.
• Dateisystem-Hooks: Auf Windows und macOS fügen Dateisystem-Watcher zusätzliche Latenz hinzu.

Was Cursor getan hat: S3 als Single Source of Truth, NVMe lokal für die Latenz

Die von The Register enthüllte Architektur von Cursor basiert auf einem zweistufigen Ansatz: S3 (Cloud-Objektspeicher) als Single Source of Truth für das Repository und lokale Repos auf NVMe (hochperformante SSDs) für latenzempfindliche Vorgänge.

Konkret bedeutet das: Statt dass die KI direkt auf dem lokalen Git-Repo mit seinen Skalierungsgrenzen arbeitet, hält Cursor eine kanonische Kopie in S3 vor und nutzt lokale NVMe-Caches für Operationen, die eine schnelle Antwort erfordern. Die Synchronisation zwischen den beiden Ebenen ist so optimiert, dass vollständige Lesevorgänge des Git-Index minimiert werden.

Das ist die Art von Problem, das erfahrene Entwickler gut kennen: Standardabstraktionen funktionieren bis zu einem bestimmten Punkt, dann muss man auf eine tiefere Ebene gehen – hier bedeutet das, das Speichermodell komplett neu zu denken, statt die git-Aufrufe nur marginal zu optimieren.

Warum das jeden betrifft

Die Lösung von Cursor hat Auswirkungen, die über ihr Tool hinausgehen:

• Monorepos: Jedes Team, das an einem Monorepo mit signifikanter Größe arbeitet, kennt diese Probleme. Die S3- + lokale NVMe-Architektur ist übertragbar.
• Git LFS: Löst das Problem großer Binärdateien, nicht die Skalierung des Index. Das ist ein offenes Problem, das Cursor anders umgangen hat.
• KI-Tools für Codebasen: Alle Tools für statische Analyse, KI-gestützte Code-Reviews oder Code-Generierung werden in großen Codebasen auf dieses Problem stoßen.