KI portiert TypeScript-Compiler von Go nach Rust

Der vielleicht erstaunlichste Satz über diesen Compiler steht nicht in einer technischen Dokumentation, sondern gleich zu Beginn der öffentlichen Projektbeschreibung: Sein Initiator habe keine einzige Zeile des erzeugten Codes gelesen.

Und doch soll das Programm funktionieren. Mehr noch: Der experimentelle TypeScript-Compiler „tsc-rs“ besteht nach Angaben des Projekts alle 181.711 übernommenen Tests seines Vorbilds, liefert bei ausgewählten Anwendungen dieselben Diagnosen und arbeitet in eigenen Messungen schneller als Microsofts offizielle Fassung. Geschrieben wurde er weitgehend mithilfe von KI.

Auf den ersten Blick wirkt diese Geschichte aus der Welt der KI-gestützten Softwareentwicklung kaum glaubhaft. Dahinter steht jedoch ein öffentlich einsehbares Softwareprojekt mit knapp 6.000 Commits, Quellcode, Testwerkzeugen, Entwicklungsprotokollen und einer am 7. Oktober 2026 veröffentlichten Version 0.1.0. Installieren lässt sie sich wie ein gewöhnliches Entwicklerwerkzeug. Allerdings ist das Repository unübersehbar als „experimentell“ gekennzeichnet. Dieser Hinweis steht dort nicht zum Schmuck. Er ist entscheidend für die Einordnung des Projekts. Recherchequelle: GitHub – ts-rust→

Ein Übersetzer für den Übersetzer

TypeScript erweitert JavaScript um ein Typsystem. Der Compiler prüft beispielsweise, ob eine Funktion tatsächlich die Art von Daten erhält, für die sie vorgesehen ist. Er meldet Fehler, bereitet Quellcode für die Ausführung vor und versorgt Entwicklungsumgebungen mit Informationen für Navigation, automatische Ergänzungen und Umbauten.

Solche Programme gehören zur grundlegenden Infrastruktur der Softwarewelt. Meist bleiben sie unsichtbar, doch ihre Fehler können weit reichen. In einer gewöhnlichen Anwendung betrifft ein Defekt womöglich nur eine einzelne Funktion. Im Compiler hingegen kann er sich durch Tausende Projekte ziehen und Entwicklern glaubhaft versichern, ihr Code sei korrekt, obwohl er es nicht ist.

Microsoft hatte den ursprünglich in TypeScript geschriebenen Compiler bereits selbst in Go neu entwickelt. Daraus entstand TypeScript 7. Der native Compiler verarbeitet große Projekte parallel und soll Builds, Prüfungen und die Arbeit im Editor erheblich beschleunigen. Microsoft berichtet unter anderem, die Prüfung des TypeScript-Codes von Slack sei von ungefähr siebeneinhalb Minuten auf rund 75 Sekunden gesunken. Mehr als ein Jahr hatte das Unternehmen an dieser Umstellung gearbeitet. Recherchequelle: Microsoft TypeScript Blog→

An diesem Punkt setzt das neue Projekt an. Statt die Regeln von TypeScript neu zu erfinden, überträgt es Microsofts Go-Implementierung nach Rust. Der Compiler entsteht also nicht aus dem Nichts, sondern als möglichst genaue Übersetzung eines vorhandenen, hochkomplexen Systems.

Auch der Vergleichsmaßstab ist klar festgelegt: tsc-rs orientiert sich an einer bestimmten TypeScript-Revision vom 29. September 2026. Die Ausgaben der Rust-Fassung sollen möglichst bytegenau den Ergebnissen des dazugehörigen Go-Compilers entsprechen. Dieser eingefrorene Referenzpunkt ist wichtig, denn TypeScript entwickelt sich ständig weiter. Ohne eine feste Version ließe sich kaum feststellen, ob eine Abweichung auf den Rust-Port oder auf eine zwischenzeitliche Änderung des Originals zurückgeht. Recherchequelle: GitHub – Upstream Provenance→

Erst schrieb die KI schnell. Dann fiel der Prototyp durch die Prüfung

Der Weg zum heutigen Stand verlief keineswegs geradlinig. Erste Versuche mit OpenAI-Modellen brachten innerhalb weniger Tage einen umfangreichen Prototyp hervor. Er wirkte offenbar eindrucksvoll, hielt einer späteren Prüfung aber nicht stand: 70 Tests schlugen fehl, und bei vergleichbaren Aufgaben lief der Compiler 2,6- bis 3,4-mal langsamer als die Go-Version.

Der Fehlschlag legt ein Grundproblem KI-generierter Software offen. Schierer Umfang kann Fortschritt vortäuschen. Tausende Dateien, Funktionen und Commits ergeben noch kein belastbares Programm, wenn der Maßstab für Korrektheit erst nachträglich festgelegt wird. Das Projekt zog daraus eine nüchterne Konsequenz: weniger neue Funktionen, enger gefasste Ziele, härtere Prüfungen.

In den dokumentierten Protokollen summiert sich der Verbrauch der drei frühen Entwicklungsphasen auf rund 216 Millionen neu verarbeitete Token. Zählt man wiederverwendeten Kontext hinzu, erscheinen in den Rohprotokollen sogar mehr als acht Milliarden Token. Diese größere Zahl erfasst allerdings überwiegend Informationen, die dem Modell wiederholt vorgelegt wurden; sie steht nicht für entsprechend viel neue Rechenarbeit. Eine nützliche Fußnote in einer Branche, die gern mit möglichst großen Zahlen glänzt. Recherchequelle: GitHub – Projektgeschichte→

Später nahm der Initiator mit Claude Opus 5.5 einen neuen Anlauf. Nach seiner Darstellung begann das Modell noch einmal von vorn, brachte innerhalb von zehn Stunden eine erste funktionierende Fassung hervor und arbeitete anschließend etwa zwei Wochen weiter. Die ausgewiesenen API-Kosten für diesen Durchlauf betrugen rund 24.047 Dollar. Frühere Versuche mit OpenAI-Modellen hätten, zu regulären API-Preisen gerechnet, mehr als 400.000 Dollar gekostet und seien bei ungefähr 84 Prozent Kompatibilität stecken geblieben.

Eine unabhängige Vergleichsstudie sind diese Werte nicht. Damit sich die gleichzeitig arbeitenden KI-Prozesse nicht gegenseitig behindern, legen die Arbeitsregeln genau fest, wer auf welche Dateien zugreifen und Änderungen vornehmen darf und zu welchem Zeitpunkt die einzelnen Arbeitsergebnisse zusammengeführt werden. Als dokumentierter Erfahrungsbericht bleiben sie dennoch bemerkenswert. Sie legen nahe, dass nicht allein die Modellstärke ausschlaggebend war, sondern auch die Qualität der Prüfmechanismen, der festgelegte Referenzstand und die Organisation der Arbeit.

Kontrollschleifen machen den Port belastbar

Das Projekt folgt nicht der romantischen Vorstellung, jemand tippe in ein einzelnes Chatfenster: „Schreibe einen Compiler“. Seine Entwicklungsregeln erinnern eher an den Betriebsplan einer ungewöhnlich strengen Softwarefabrik.

Für zentrale Änderungen sind getrennte Rollen vorgesehen: ein Implementierer, ein unabhängiger Prüfer und ein Regressionstester. Wer den Code erzeugt, darf nicht zugleich das abschließende Urteil über ihn fällen. Ein Stoppsignal blockiert die weitere Arbeit an Funktionen, bis die beanstandete Abweichung untersucht oder behoben wurde. Zudem muss jede akzeptierte Revision eine Reihe geschützter Tests, Vergleiche mit dem Go-Original und Prüfungen realer Projekte durchlaufen.

Zeitweise arbeiteten mehr als tausend KI-Unterprozesse an klar abgegrenzten Aufgaben. Die Protokolle verzeichnen Zehntausende Werkzeugaufrufe, manche Unterprozesse nutzten Kontexte von fast einer Million Token. Um Konflikte bei der gleichzeitigen Arbeit mehrerer KI-Systeme zu vermeiden, legen die Anweisungen genau fest, welcher Prozess für die Bearbeitung welcher Dateien zuständig ist und zu welchem Zeitpunkt die einzelnen Ergebnisse zusammengeführt werden. Recherchequelle: GitHub – Arbeitsregeln→

Mit solchen Verfahren verändert sich das Bild der automatisierten Softwareentwicklung. Der Mensch schreibt nicht mehr unbedingt jede Funktion selbst. Stattdessen baut er Leitplanken, legt Referenzwerte fest, entwirft Prüfungen und entscheidet, wann ein Resultat als belastbar gelten darf. Die reine Tippgeschwindigkeit verliert an Bedeutung. Wichtiger wird die Fähigkeit, der Maschine einen so engen Korridor vorzugeben, dass sie keine nur scheinbar elegante Abkürzung nehmen kann.

181.711 bestandene Tests sind viel – aber kein Freibrief

Dem aktuellen Stand des Repositorys zufolge bestehen sämtliche 181.711 aus dem Go-Projekt übertragenen Tests. Bei TanStack Query und Hono sollen die Diagnosen mit denen des Originals übereinstimmen. Zusätzlich wurden die Kommandozeilenausgaben anhand von 120 Open-Source-Projekten verglichen.

Beachtlich wirken auch die gemessenen Geschwindigkeiten. Bei einer Messung auf einem Mac mit M4-Pro-Chip benötigte tsc-rs für die vollständige Prüfung des VS-Code-Quellcodes 4,20 Sekunden. TypeScript 7 kam auf 6,84 Sekunden, die ältere JavaScript-Fassung auf 54,56 Sekunden. Im geometrischen Mittel über sechs ausgewählte Anwendungen war der Rust-Port 1,61-mal schneller als der Go-Compiler.

Doch nicht jeden Geschwindigkeitsvergleich entschied der Rust-Port für sich. „Bun check“ war in fünf der sechs Anwendungen schneller, meldete bei Sentry und tRPC jedoch Fehler, die von den anderen Prüfern nicht ausgegeben wurden. Geschwindigkeit ist bei einem Compiler eben nur dann ein Vorteil, wenn er dabei dieselbe Wahrheit erzählt.

Zur Einordnung gehört außerdem, dass das Projektteam die Benchmarks selbst durchgeführt hat. Eine breite unabhängige Begutachtung steht noch aus. Bestandene Tests belegen, dass bekannte, darin erfasste Fälle korrekt behandelt werden. Sie können jedoch weder garantieren, dass es keine unbekannten Fehler gibt, noch dass die Architektur langfristig wartbar bleibt oder sich jede künftige Änderung von TypeScript zuverlässig übernehmen lässt.

In der Praxis zeigen sich die Grenzen vor allem bei der Plattformunterstützung und bei mehreren Funktionen. Fertige Pakete gibt es zunächst nur für Linux-Systeme mit x64-Architektur und für Macs mit ARM-Prozessoren. Windows wird noch nicht unterstützt. Bei bestimmten Monorepos, Projektabhängigkeiten und langen Editor-Sitzungen nennt das Projekt ebenfalls bekannte Probleme. Schnellkorrekturen, Refaktorierungen und weitere Komfortfunktionen des integrierten Sprachdienstes sind noch nicht vollständig übertragen. Die erste stabile Paketversion ist deshalb eher eine Einladung zum Prüfen als eine Aufforderung zum sorglosen Umstieg vom etablierten Compiler. Recherchequelle: GitHub – Release tsc-rs 0.1.0→

Der Rust-Port ist damit weder bloß eine technische Kuriosität noch bereits ein neuer Industriestandard. Er steht vielmehr für einen Moment des Übergangs: KI ergänzt nicht mehr nur einzelne Funktionen, sondern arbeitet bereits an tragender Softwareinfrastruktur.

Am auffälligsten sind dabei nicht die Millionen Codezeilen, sondern die Maschine aus Regeln, Gegenprüfungen und Vergleichsläufen, die um den Code herum gebaut werden musste. Je schneller KI Code erzeugt, desto wertvoller wird der langsame, misstrauische Blick auf das Ergebnis. Das gilt selbst dann, wenn zunehmend auch Maschinen diese Prüfung übernehmen.

Weiterführende Informationen

Quellenhinweis: Einzelne Fakten, Einschätzungen und Prognosen dieses Beitrags stützen sich auf Veröffentlichungen der nachfolgend genannten Unternehmen und Institutionen. Die Links dienen zugleich der weiterführenden Information.

Martin Cid Magazine – TypeScript 7.0 ist 10-mal schneller — Vue, Svelte und Angular müssen warten
Der Artikel erläutert den nativen Go-Port und den Rückgang der Slack-Typprüfung von 7,5 Minuten auf 75 Sekunden.
https://de.martincid.com/technologie-2/typescript-7-go-compiler-10x-faster/

Sebastian Krötzsch – Wie Anthropic mit Claude Code große Code-Migrationen meistert
Die technische Vertiefung beschreibt getrennte KI-Rollen für Implementierung, Prüfung und Korrektur sowie mechanische Vergleichs- und Regressionstests.
https://sebask.de/wie-anthropic-mit-claude-code-grosse-code-migrationen-meistert/

Golem.de – Github migriert mit KI 800.000 Codezeilen nach Rust
Das Fallbeispiel vertieft Leistungsgewinne und Compiler-Feedback, betont aber zugleich die Grenzen von Kompilierung und Tests ohne menschliche Kontrolle.
https://www.golem.de/news/von-typescript-und-node-js-github-migriert-mit-ki-800-000-codezeilen-nach-rust-2609-213310.html