GitHub hat die Runtime hinter GitHub Copilot CLI, der Copilot-App und dem Copilot SDK neu aufgebaut. Zuvor basierte sie auf TypeScript, Node.js und der V8-Engine. Das Ergebnis sind laut dem auf dem GitHub-Blog veröffentlichten Beitrag mehr als 800.000 produktionsreife Rust-Zeilen, die größtenteils mithilfe von KI-Agenten über 128 Pull Requests erstellt und schrittweise in den Hauptbranch integriert wurden.
Der Autor sagt, die Arbeit sei innerhalb weniger Monate und im Wesentlichen mit Beteiligung eines einzigen Entwicklers abgeschlossen worden, während der übrige Teil des Teams weiterhin Runtime-Funktionen entwickelte und ihren Einsatzbereich erweiterte. GitHub zufolge verbesserte sich die Leistung nach der Umstellung „um Größenordnungen“, wobei der verfügbare Teil des Beitrags keine detaillierten Zahlen zur Messung dieser Verbesserung nennt.
Das Problem betraf nicht nur die Kommandozeilenschnittstelle
Die Copilot-Runtime beschränkt sich nicht auf die Ausführung der CLI. Sie ist eine gemeinsame Schicht, die von mehreren Versionen und Produkten verwendet wird, darunter GitHub Copilot CLI, die Copilot-App und das Copilot SDK sowie VS Code, Visual Studio, Cloud Agent, Copilot Code Review, Copilot Cowork, Copilot Studio und die Anwendungen Excel, Outlook, PowerPoint und Word.
Im früheren Design waren Runtime und CLI weitgehend miteinander verflochten. Als die Produkte programmgesteuerten Zugriff benötigten, wurde das SDK praktisch auf der CLI aufgebaut. Dabei wurde ein separater Node.js-Prozess gestartet, mit dem über JSON-RPC kommuniziert wurde. Dieser Ansatz war schnell und flexibel, verursachte jedoch für jede nutzende Anwendung zusätzliche Betriebskosten.
Das Erstellen eines neuen CopilotClient bedeutete, einen zusätzlichen Prozess zu starten, der Node.js und V8 hostete, aus TypeScript erzeugten JavaScript-Code zu analysieren und den mit der Engine verbundenen Speicher zu tragen. Außerdem konnten Abstürze in Node.js die Sitzung beenden, während die Anwendungen mindestens zwei Prozesse überwachen mussten. Dem Beitrag zufolge beanspruchten die in C#, TypeScript, Python, Rust, Go und Java geschriebenen SDK-Pakete mindestens rund 100 Megabyte des Arbeitsspeichers für die zusätzliche Runtime – selbst dann, wenn sie Node.js für nichts anderes benötigten.
Warum wurde Rust gewählt?
GitHub definierte klare Ziele für die neue Schicht: die Runtime von der TUI zu trennen, Abhängigkeiten und Betriebskosten zu reduzieren, die Einbettung in denselben Prozess zu ermöglichen sowie Skalierbarkeit und Zuverlässigkeit zu verbessern. Außerdem wurde eine C-ABI benötigt, die die Nutzung der Runtime aus den sechs SDK-Versionen über die verschiedenen FFI-Mechanismen hinweg erlaubt.
Dem Beitrag zufolge half Rust dabei, diese Anforderungen zu erfüllen. Hinzu kamen eine Toolchain, die einen moderneren Sicherheitsmodus unterstützt, eine Verringerung der Risiken in der Lieferkette sowie eine stärkere Unterstützung für standardmäßig korrekten Code. Gleichzeitig betont der Beitrag, dass die Erfahrung keine Empfehlung darstellt, jedes große TypeScript-Projekt in Rust umzuwandeln. Die Wahl ergab sich aus konkreten Anforderungen an Startzeit, Speicher, Einbettung und die Vorhersagbarkeit des Ressourcenverbrauchs.
Schrittweiser Ersatz statt umfassender Neuschreibung
GitHub setzte das Projekt nicht über einen langlebigen Branch oder eine einmalige Umstellung am Ende um. Stattdessen wählte das Unternehmen einen Ansatz innerhalb des Hauptbranches, bei dem jede TypeScript-Komponente einzeln durch eine Rust-Komponente ersetzt wurde. Jeder Pull Request fügte eine dünne Bindingschicht hinzu, die Rust aufruft, und entfernte im selben Änderungsschritt die alte Implementierung. Dadurch blieb der Branch auslieferbar, und der neue Code wurde unmittelbar innerhalb des Systems getestet.
- Die reguläre Arbeit der übrigen Entwickler wurde fortgesetzt, ohne das Projekt anzuhalten.
- Jede Änderung wurde kleiner und leichter zu überprüfen als eine umfassende Neuschreibung.
- Die End-to-End-Tests für CLI und SDK wurden bei jedem Schritt ausgeführt.
- Regressionen wurden während der Migration entdeckt und behoben, statt bis zur abschließenden Umstellung aufgeschoben zu werden.
GitHub lehnte es außerdem ab, über längere Zeit zwei parallele Versionen jeder Komponente beizubehalten. Das Repository verzeichnete jede Woche Hunderte Pull Requests, und die Pflege zweier Implementierungen in unterschiedlichen Sprachen sowie zweier Abhängigkeitsmengen hätte die Komplexität erhöht. Der Vergleich zweier Versionen wird bei Komponenten, die veränderlichen Zustand verwalten, zusätzlich erschwert – etwa bei der Sitzungsformatierung, die mit Rückrufen arbeitet und mit großen Teilen des Systems verbunden ist.
Was zeigen die Zahlen?
Die erste Schätzung lag im Mai 2026 bei etwa 130.000 TypeScript-Zeilen, spiegelte jedoch den tatsächlichen Arbeitsumfang nicht wider. Komponenten, die ursprünglich der TUI-Schicht zugerechnet worden waren, wurden später in die Runtime verschoben. Gleichzeitig wurde parallel zur Migration weiterhin neuer TypeScript-Code hinzugefügt. Daher durchliefen tatsächlich rund 430.000 TypeScript-Zeilen den Umstellungsprozess.
Im selben Zeitraum kamen rund 300.000 produktive TypeScript-Zeilen hinzu, während etwa 430.000 entfernt wurden. Gleichzeitig wurden ungefähr 1.200.000 Rust-Zeilen hinzugefügt und etwa 365.000 entfernt. Diese Zahlen zeigen, dass die scheinbare Stabilität des TypeScript-Umfangs im Repository nicht das Ausbleiben von Fortschritten bedeutete, sondern umfangreiche Hinzufügungen, Löschungen und eine Neuverteilung der Zuständigkeiten verdeckte.
Warum ist diese Nachricht wichtig?
Der praktische Wert des Experiments liegt nicht allein in der Verwendung von Rust, sondern in der Art und Weise, wie die Neuschreibung einer grundlegenden Schicht verwaltet wurde, die von zahlreichen Produkten gemeinsam genutzt wird. Der atomare Ersatz jeder Komponente bei gleichzeitig auslieferbarem Branch und kontinuierlicher Testausführung verringert die Risiken einer „großen Umstellung“ und macht Rücksetzungen oder die Eingrenzung von Fehlerursachen eindeutiger.
Der Beitrag belegt andererseits nicht, dass dieser Ansatz für jede Organisation geeignet ist oder dass KI-Agenten allein die Qualität einer Neuschreibung in dieser Größenordnung gewährleisten können. Der verfügbare Teil enthält außerdem keine veröffentlichten Messungen des Ressourcenverbrauchs vor und nach der Umstellung und erläutert nicht detailliert den personellen Aufwand für Überprüfungen, Tests oder die Behebung von Regressionen. Die deutlichste Lehre betrifft daher die schrittweise Softwareentwicklung und die Trennung von Schichten – nicht Rust oder Agenten als allgemeine Lösung für jede Migration.