Was GitHubs Rust-Umbau über KI-Coding lehrt

Viele Teams erleben gerade dasselbe: Mit Claude Code, Cursor oder Copilot entsteht in Tagen, wofür früher Wochen nötig waren. Und trotzdem wird das Projekt nicht einfacher. Mehr Code, mehr Änderungen, mehr Stellen, an denen etwas unbemerkt kaputtgehen kann.

Der Entwickler und Autor Simon Willison hat das kürzlich so zusammengefasst: Je länger er mit Coding-Agenten arbeitet, desto überzeugter ist er, dass sie Softwareentwicklung schwieriger machen. Man kann Erstaunliches mit ihnen bauen, aber ihr Potenzial auszuschöpfen verlangt außergewöhnlich viel Disziplin und Wissen.

Wie diese Disziplin im Großen aussieht, zeigt ein ausführlicher Bericht von GitHub.

Ein Umbau, der ohne Agenten nicht bezahlbar gewesen wäre

GitHub hat die Laufzeitumgebung hinter Copilot CLI, Copilot App und Copilot SDK von TypeScript nach Rust portiert. Das Ergebnis: über 832.000 Zeilen produktiver Rust-Code plus rund 469.000 Zeilen Unit-Tests. Den Großteil des Codes haben KI-Agenten geschrieben, verteilt auf 128 Pull Requests, im Wesentlichen betreut von einem einzigen Entwickler über etwa vierzehneinhalb Wochen. Nach GitHubs eigener Einschätzung hätte ein ganzes Team dafür vorher ein bis zwei Jahre gebraucht.

Das klingt nach dem Versprechen von Vibe Coding in Reinform. Liest man genauer, zeigt sich allerdings: Die Agenten waren schnell, weil der Rahmen streng war.

Erst die Leitplanken, dann der Code

Bevor die eigentliche Portierung begann, legten die ersten beiden Pull Requests nur das Fundament: Projektstruktur, Toolchain, Lint-Regeln, CI, Build-Pipeline und schriftliche Coding-Anweisungen für die Agenten. Danach folgten bewusst kleine Piloten, reine Hilfsfunktionen ohne Seiteneffekte und mit guter Testabdeckung. Erst als dieser Ablauf einmal komplett funktionierte, ging es an größere Teile.

Die Reihenfolge war ebenfalls geplant: von den Rändern nach innen. Zuerst einfache, isolierte Bausteine, zuletzt die Sitzungssteuerung, also der am stärksten verflochtene Teil des Systems.

Kleine Schritte, immer auslieferbar

GitHub hat sich gegen einen großen Umstieg am Stichtag entschieden. Stattdessen ersetzte jeder Pull Request genau eine Komponente: Der alte TypeScript-Code wurde durch einen dünnen Aufruf des neuen Rust-Codes ersetzt und im selben Schritt gelöscht. Damit blieb der Hauptzweig jederzeit auslieferbar, und jede Änderung war klein genug, um sie wirklich zu prüfen.

Dazu kam eine harte Regel: Alle bestehenden End-to-End-Tests liefen bei jedem Schritt gegen den neuen Code. Schlug ein Pflichttest fehl, wurde nicht gemergt. Ausgeliefert wurde schrittweise, im Schnitt 1,3 Releases pro Tag, meist zuerst als Vorabversion. Probleme ließen sich so schnell einer konkreten Änderung zuordnen.

Der Mensch steuert, statt zu tippen

Aufschlussreich ist, wofür der verantwortliche Entwickler seine Zeit verwendet hat. Rund 2.600 Nachrichten hat er selbst geschrieben oder diktiert. Seine Rolle beschreibt er nicht als „Aufgabe vergeben und warten“, sondern als Regelkreis: Ergebnisse prüfen, technische Entscheidungen hinterfragen, Qualitätsschranken durchsetzen und nachhaken, wenn ein Agent einen Zwischenstand für das fertige Ergebnis hielt.

Auch die Planung war nicht trivial. Anfangs wurde der Umfang auf etwa 130.000 Zeilen geschätzt. Tatsächlich liefen rund 430.000 Zeilen durch die Portierung, weil parallel ständig neuer Code hinzukam.

Zwei Details, die Kosten und Risiko betreffen

Erstens die Kosten: 96 Prozent der eingelesenen Tokens kamen aus dem Prompt-Cache, den Anbieter oft mit rund 90 Prozent Rabatt abrechnen. Lange Agenten-Sitzungen sind nur deshalb wirtschaftlich, weil der Kontext stabil bleibt und nicht bei jedem Schritt neu verarbeitet wird.

Zweitens die Sicherheit: GitHub weist ausdrücklich darauf hin, dass die Sitzungsprotokolle der Agenten Prompts, Befehle, Ausgaben und unter Umständen Geheimnisse wie Zugangsschlüssel enthalten können. Sie sind also als sensible Daten zu behandeln.

Was das für Ihr Projekt bedeutet

Sie portieren wahrscheinlich keine 800.000 Zeilen. Die Muster lassen sich aber direkt auf ein mittelständisches Projekt oder ein Startup übertragen:

• Leitplanken vor Tempo. Linting, Tests, CI und schriftliche Regeln für die Agenten gehören an den Anfang, nicht ans Ende.
• Kleine, prüfbare Änderungen. Wer Agenten große Umbauten in einem Rutsch machen lässt, bekommt Diffs, die niemand mehr ernsthaft reviewt.
• Tests als Schranke. Ohne verlässliche Tests merken Sie erst beim Kunden, was eine Änderung kaputt gemacht hat.
• Jemand muss steuern. KI-Code braucht eine Person, die Architektur, Grenzen und Qualität verantwortet. Diese Rolle fällt nicht weg, sie wird wichtiger.
• Protokolle und Schlüssel schützen. Agenten sehen viel. Was sie mitschreiben, gehört nicht in ein öffentliches Repository.

Gerade bei Prototypen aus Lovable, Bolt oder schnellen Claude-Code-Sessions fehlen genau diese Grundlagen oft, weil am Anfang niemand an sie gedacht hat.

Fazit

GitHubs Projekt zeigt, was mit KI-Agenten möglich ist. Es zeigt aber auch, warum Simon Willison recht hat: Die Werkzeuge nehmen einem das Tippen ab, nicht das Denken. Tempo entsteht aus Struktur.

Sie möchten wissen, welche dieser Leitplanken in Ihrem Projekt fehlen und welche zuerst kommen sollten? Vereinbaren Sie ein kostenloses Erstgespräch.