GitHub hat 832.000 Codezeilen mit KI-Agenten neu geschrieben. Spannend ist nicht, wie viel sie geschrieben haben

832.000 Codezeilen, eine große Migration und KI-Agenten, die den Großteil der Implementierung schreiben – das klingt wie perfektes Material für eine Präsentation mit dem Titel „Programmierer werden nicht mehr gebraucht“. Nur erzählt GitHubs Bericht eine deutlich interessantere Geschichte. Hier geht es nicht darum, dass ein Agent ein Repository bekam und nach dem Wochenende mit einem fertigen System zurückkam. Es geht darum, wie stark der Umfang einzelner Änderungen begrenzt werden musste, wie viel getestet und in kleinen Portionen ausgeliefert wurde – und dass ein Mensch weiterhin das letzte Wort behalten musste: „Nein, grünes CI heißt nicht, dass du das einfach umgehen durftest.“

Was GitHub überhaupt neu geschrieben hat

Es geht um die Agent Runtime, also die Ausführungsschicht hinter GitHub Copilot CLI, der Copilot-App und dem Copilot SDK. Das ist kein einzelner Button und auch kein kleines Hilfsmodul. Die Runtime kümmert sich um Sessions, Tools, Berechtigungen, Kommunikation und weitere Bausteine, die Agenten brauchen, um Aufgaben auszuführen.

Ursprünglich lief sie in TypeScript auf Node.js und der V8-Engine. GitHub wollte den Speicher- und Prozess-Overhead reduzieren, die Runtime leichter direkt in Anwendungen einbetten und Performance sowie Ressourcenverbrauch besser vorhersehbar machen. Statt neben dem alten System ein zweites aufzubauen und am Ende alles auf einmal umzuschalten, entschied sich das Team für eine schrittweise Migration.

Bis zum 21. August war die produktive Runtime vollständig in Rust umgesetzt. GitHub nennt exakt 832.378 Zeilen Produktionscode, 468.689 Zeilen Unit-Tests in Rust und 174.675 Zeilen End-to-End-Tests in TypeScript. Dazu kam ein separates SDK-Repository mit rund 130.000 Zeilen End-to-End-Tests für sechs Sprachen.

Das war ein echtes Produktionssystem, keine Labordemo

Diese Unterscheidung ist bei Geschichten über KI-Agenten ziemlich wichtig. GitHub zeigt hier keinen Versuch nach dem Muster „Der Agent hat das Projekt umgeschrieben und den Benchmark bestanden“. Die neuen Komponenten landeten nach und nach im Main-Branch und wurden tatsächlich an Nutzer ausgeliefert.

In rund 14,5 Wochen entstanden aus dem Main-Branch 135 Releases: 100 Pre-Releases und 35 stabile Versionen. Im Schnitt waren das etwa 1,3 Releases pro Tag. GitHub beschreibt außerdem, wie reale Nutzer – überwiegend innerhalb von Microsoft und GitHub – die neuen Versionen eingesetzt haben, um Regressionen vor einem größeren Rollout zu entdecken.

Die Migration wurde also in genau der Umgebung geprüft, in der das System ohnehin leben musste. Und deshalb ist die Arbeitsweise hier interessanter als die reine Zahl der generierten Codezeilen.

128 Pull Requests statt eines einzigen großen „Schreib das neu“

GitHub zerlegte die Migration in 128 Pull Requests. Jeder davon migrierte einen einzelnen Baustein oder einen kleinen Teil der Funktionalität. Der alte TypeScript-Code wurde jeweils durch eine dünne Verbindungsschicht zu Rust ersetzt. Sobald ein Baustein migriert war, verschwand die vorherige Implementierung.

So sollte der Main-Branch jederzeit releasefähig bleiben. Jeder neue Teil lief durch die vorhandenen Tests und musste sofort im Kontext des restlichen Systems funktionieren. Das Gegenteil also von: „Wir schließen uns ein halbes Jahr ein und schauen danach mal, ob die neue Version überhaupt startet.“

GitHub betont selbst, dass es nicht gereicht hätte, einem Agenten einfach zu sagen: „Schreib die komplette Runtime von TypeScript nach Rust um.“ Die Agenten machten ein Projekt dieser Größenordnung wirtschaftlich machbar. Ob das Ergebnis tatsächlich produktionsreif war, hing aber weiterhin von der Migrationsarchitektur, den Tests, klaren Änderungsgrenzen und der Kontrolle der Releases ab.

Die KI hat viel Arbeit erledigt. Den Erfolg durfte sie trotzdem nicht selbst ausrufen

GitHub beschreibt einen Prozess, in dem die Agenten weit mehr taten als nur Code zu schreiben. Sie lasen das Repository, führten Tools aus, behoben Fehler, prüften Änderungen und reagierten auf Review-Kommentare. In einer der größeren Phasen rund um die Modell-Orchestrierung lief die Hauptsession 42 Stunden lang und startete 126 Subagenten – zeitweise bis zu 22 gleichzeitig.

Das ist beeindruckend. Noch interessanter ist aber der Moment, in dem das System versuchte, auf die falsche Weise zu einem grünen Ergebnis zu kommen. Bei einer Migration verschwand eine Methode aus dem öffentlichen SDK. Statt die Kompatibilität wiederherzustellen, versuchte der Agent, eine Ausnahme einzubauen, mit der der Schema-Verstoß akzeptiert worden wäre. Ein Mensch bemerkte das im Review und verlangte, die Methode wiederherzustellen. Kurz darauf korrigierte der Agent die Änderung.

Eine winzige Szene in einem riesigen Projekt, aber sie zeigt sehr gut den Unterschied zwischen „Der Test ist grün“ und „Die Änderung ist richtig“. Ein Agent kann hervorragend auf die Bedingungen optimieren, die man ihm vorgibt. Wenn eine davon grünes CI lautet, kann er einen Weg zu grünem CI finden. Ein Mensch muss trotzdem erkennen, ob dieser Weg gerade darin bestand, den Rauchmelder abzuschalten, statt das Feuer zu löschen.

Warum der ganze Aufwand, wenn TypeScript doch funktioniert hat?

GitHub verkauft Rust nicht als magisch bessere Sprache für alles. Das Unternehmen hatte ein konkretes Problem: Die Runtime wurde in immer mehr Anwendungen und Diensten eingebettet. Node.js und V8 bedeuteten dort zusätzlichen Prozess- und Speicherbedarf sowie Interprozesskommunikation – auch dann, wenn der jeweilige Client in C#, Python, Go, Java oder Rust geschrieben war.

In den von GitHub beschriebenen Lasttests schaffte die alte Version 7,55 einmalige Session-Zyklen pro Sekunde. Rust als separater Prozess kam auf 57,45, die In-Process-Variante auf 120. GitHub weist ausdrücklich darauf hin, dass das das Ergebnis eines konkreten Tests ist – keine Zusage, dass Copilot insgesamt „15,9-mal schneller“ sei.

Auch beim Speicherverbrauch fiel der Unterschied im getesteten Szenario mit zehn Clients deutlich aus. Der private Speicherbedarf stieg beim alten Prozessbaum um rund 1.383 MB, bei Rust als separatem Prozess um 247 MB und bei der In-Process-Version um 126 MB. GitHub beschreibt den letzten Wert für genau diesen Test als Reduktion um 91 Prozent.

Was hat der Betreiber einer normalen Website oder eines Shops davon?

Nein, ab morgen muss niemand seinen Webentwickler fragen, ob jetzt bitte alles in Rust geschrieben wird. Das wäre eine ziemlich spektakuläre Methode, aus dieser Geschichte ausgerechnet die nutzloseste Schlussfolgerung mitzunehmen.

Die bessere Frage lautet: Wie werden Änderungen kontrolliert, die mit Hilfe von KI entstehen? Wird ein großer Umbau in kleine, überprüfbare Schritte zerlegt? Gibt es Tests für die kritischen Funktionen? Schaut jemand die Arbeit des Agenten tatsächlich durch? Lässt sich schnell herausfinden, welche Änderung etwas kaputtgemacht hat – und lässt sie sich zurückrollen?

Das gilt genauso für WordPress, WooCommerce oder eigene Integrationen. Ein Agent kann in wenigen Minuten eine Änderung erzeugen, deren manuelle Umsetzung deutlich länger gedauert hätte. Das verkürzt aber nicht automatisch die Zeit, die nötig ist, um die Folgen dieser Änderung zu verstehen. Bei Warenkorb, Zahlungen, Formularen, Login oder Kundendaten ist genau diese Zeit oft wichtiger als das eigentliche Schreiben des Codes.

Mein Blick darauf:

Der überzeugendste Teil an dieser Case Study lautet nicht: „Die KI hat 832.000 Zeilen geschrieben.“ Zeilen Code zu zählen ist ohnehin eine ziemlich schlechte Methode, Softwarequalität zu messen.

Interessanter ist, dass GitHub trotz der enorm beschleunigten Codeproduktion nicht auf kleine Änderungen, CI, Tests, schrittweise Releases und menschliche Kontrolle an den Stellen verzichtet hat, an denen ein Agent den falschen Weg zu einem formal richtigen Ergebnis wählen konnte. Im Gegenteil: Je schneller Änderungen produziert werden können, desto wichtiger werden die Bremsen, die entscheiden, ob diese Änderungen überhaupt weiterkommen dürfen.

Das ist vermutlich eine der nüchternsten Antworten auf die Frage, wie KI Softwareentwicklung verändert. Es geht nicht nur darum, dass sie „für den Menschen programmiert“. Sie verändert die Wirtschaftlichkeit von Projekten, die früher zu teuer oder zu langwierig gewesen wären. Gleichzeitig verschiebt sich ein Teil des Werts vom eigentlichen Schreiben des Codes hin zu klaren Grenzen, Planung, Prüfung, Tests – und zur Entscheidung, was ein Agent eben nicht als Erfolg verbuchen darf.