Ein Entwickler lässt eine KI zwei Wochen lang arbeiten, zahlt rund 24.000 Dollar an API-Kosten und bekommt am Ende einen funktionierenden Rust-Port von Microsofts TypeScript-Compiler, mit 181.711 bestandenen Tests. Ein früherer Versuch mit OpenAIs Codex hatte zuvor über 420.000 Dollar verschlungen und nur etwa 84 Prozent Kompatibilität erreicht. Die Geschichte rund um das Projekt ts-rust von Ping-Labs-Gründer Theo Browne zeigt in aller Deutlichkeit, wie weit KI-Agenten bei großen, semantisch komplexen Code-Migrationen inzwischen gekommen sind, und wo die Grenzen liegen.
Browne veröffentlichte das Projekt am 7. und 8. Oktober 2026 auf GitHub und auf X. Der Fall ist deshalb bemerkenswert, weil er nicht irgendeine Nischenbibliothek betrifft, sondern einen der am häufigsten eingesetzten Compiler im gesamten Webentwicklungs-Ökosystem. Jede TypeScript-Anwendung, jedes Next.js-Projekt, jedes Enterprise-Backend mit Node.js hängt am Ende an diesem Werkzeug. Wer zeigen kann, dass eine KI so ein System zuverlässig in eine andere Programmiersprache übertragen kann, verschiebt die Diskussion über automatisierte Softwaremigration ein gutes Stück weiter.
Was ist ts-rust und wer steht dahinter
Ping Labs ist das Unternehmen von Theo Browne, der in der Entwickler-Community vor allem durch seine Plattform Ping.gg und als technischer Creator bekannt ist. Das Repository pingdotgg/ts-rust beschreibt sich selbst als experimentellen Rust-Port des TypeScript-7-Compilers, also von Typchecker, Language Server und API. Wichtig für das Verständnis: ts-rust portiert nicht die alte, in TypeScript selbst geschriebene Compiler-Version. Browne hat die neuere Go-Implementierung von Microsoft als Vorlage genommen und diese in Rust übersetzt, inklusive identischer Kommandozeile und API-Oberfläche.
Sein erklärtes Ziel war ein Stresstest für moderne Coding-Agenten: Kann eine KI eine große, semantisch heikle Systemmigration weitgehend ohne menschliche Code-Autorenschaft durchziehen? Browne machte in seiner Ankündigung klar, dass er den generierten Code selbst nicht gelesen hat. Das ist zugleich die faszinierendste und die riskanteste Aussage der ganzen Geschichte, dazu später mehr im Abschnitt zu Risiken.
Der gescheiterte erste Versuch: 420.000 Dollar für Codex
Bevor der Durchbruch kam, stand ein teurer Fehlschlag. Laut der Projekt-Dokumentation und Brownes eigenen Angaben liefen die Agenten rund fünf Monate an dem Vorhaben, größtenteils mit OpenAIs Codex-Modellen (GPT-5.6 Sol und GPT-6 Astra). Die Rechnung dafür lag bei über 420.000 Dollar an API-Token-Kosten, das Ergebnis blieb bei etwa 84 Prozent Kompatibilität mit dem Original stehen. Für ein Projekt, das am Ende entweder vollständig funktioniert oder in der Praxis nutzlos ist, reicht das nicht.
Ein Compiler mit 84 Prozent Testabdeckung ist kein Compiler, den jemand in einer Produktionsumgebung einsetzt. Jede fehlende Prozentzahl kann bedeuten, dass ein bestimmtes Typmuster, ein Edge Case in der Typinferenz oder ein Sonderfall im Language Server schlicht falsch oder gar nicht funktioniert. Browne zog nach diesem Ergebnis die Reißleine beim Modellwechsel, nicht bei der Idee selbst.
Der Durchbruch: Claude Opus schafft es in zwei Wochen
Der Wechsel zu Anthropics Claude Opus, gesteuert über Claude Code, brachte den entscheidenden Unterschied. Nach Angaben von Browne kostete dieser Durchlauf etwa 24.047 Dollar und war nach rund zwei Wochen abgeschlossen. Eine erste grobe Version, intern als v0 bezeichnet, stand bereits nach etwa zehn Stunden, komplett neu generiert statt auf dem Codex-Code aufgebaut. Am Ende bestand die Rust-Implementierung 181.711 portierte Tests aus der Go-Testsuite von Microsofts nativer TypeScript-Implementierung.
Zur Einordnung dieser Zahl: Es handelt sich um portierte Tests aus Microsofts Go-Testkorpus, nicht zwangsläufig um eine unveränderte Kopie der ursprünglichen Microsoft-Konformitätssuite für TypeScript. Das Repository beschreibt zusätzlich, dass Language Server und API gegen die Go-Version mit einem Oracle-Verfahren verglichen wurden und dass die Implementierung gegen 120 Open-Source-Repositories getestet wurde. Für TanStack Query Core und das Framework Hono soll die Rust-Version dieselben Diagnosemeldungen liefern wie das Go-Original.
Browne selbst fasste den Unterschied zwischen beiden Versuchen auf X knapp zusammen: Rund 400.000 Dollar für Codex-Token ergaben keinen brauchbaren Fortschritt, rund 20.000 Dollar für Opus-Token führten in zwei Wochen zum Ziel. Diese Differenz von grob 396.000 Dollar ist der Kern, warum die Geschichte innerhalb der Entwickler-Community so viel Aufmerksamkeit bekommen hat.
Die Zahlen im Überblick
Die folgende Tabelle fasst die zentralen, öffentlich dokumentierten Kennzahlen beider Versuche zusammen, so wie sie im ts-rust-Repository und in Brownes Ankündigung genannt werden.
| Kennzahl | Versuch 1: Codex (GPT-5.6 Sol / GPT-6 Astra) | Versuch 2: Claude Opus (Claude Code) |
|---|---|---|
| API-Kosten (gemeldet) | über 420.000 Dollar | rund 24.047 Dollar |
| Projektdauer | Teil von rund 5 Monaten Agenten-Arbeit | rund 2 Wochen bis zur finalen Version |
| Erste lauffähige Version | nicht dokumentiert | v0 nach rund 10 Stunden |
| Erreichte Kompatibilität | rund 84 Prozent | 181.711 portierte Tests bestanden |
| Validierung gegen Praxis-Code | nicht dokumentiert | 120 Open-Source-Repositories getestet |
| Zielsprache | Rust | Rust |
| Vorlage für den Port | Microsofts Go-Compiler (TypeScript 7) | Microsofts Go-Compiler (TypeScript 7) |
Auffällig ist, dass die veröffentlichten Kostenangaben API-Rechnungen sind, nicht eine vollständige Projektkostenrechnung. Es fehlen Angaben zu Supervision, Cloud-Rechenzeit, CI-Infrastruktur oder menschlicher Review-Zeit. Die 24.047 Dollar sollten deshalb als gemeldete API-Kosten gelesen werden, nicht als geprüfte Gesamtbilanz eines Software-Projekts.
Warum Microsoft TypeScript überhaupt nach Go portierte
Um die Geschichte einzuordnen, braucht es den Kontext von Microsofts eigenem Native-Port-Projekt, intern als Project Corsa bekannt. Microsoft kündigte die Arbeit bereits im März 2025 an, mit dem Ziel, den TypeScript-Compiler und die Werkzeugkette von TypeScript-in-TypeScript (intern Strada genannt) in eine native Sprache zu übertragen. Die Begründung war Performance: Große Codebasen litten unter langsamen Build-Zeiten und hohem Speicherverbrauch der JavaScript-basierten Implementierung.
Microsoft entschied sich für Go statt für einen kompletten Neuentwurf in Rust, weil Go eine hohe semantische Kompatibilität bei vertretbarem Zeitaufwand ermöglichte. Eine Release-Candidate-Version von TypeScript 7.0 erschien im Juni 2026, die finale Version folgte am 8. Juli 2026. Microsoft testete die neue Implementierung nach eigenen Angaben gegen rund 20.000 Testfälle, von denen etwa 6.000 besonders kritische Pfade abdeckten.
Die gemessenen Geschwindigkeitsgewinne von TypeScript 7
Microsoft veröffentlichte eigene Benchmark-Zahlen für den Wechsel von der alten JavaScript-Implementierung zur neuen, nativen Go-Version. Diese Zahlen beziehen sich ausschließlich auf Microsofts eigenen Compiler-Wechsel, nicht auf ts-rust, dessen Performance gegenüber tsc bislang nicht mit vergleichbaren Benchmarks belegt ist.
| Projekt | Alte Implementierung (Sekunden) | Native Go-Implementierung (Sekunden) | Beschleunigung |
|---|---|---|---|
| VS Code | 77,8 | 7,5 | 10,4x |
| Playwright | 11,1 | 1,1 | 10,1x |
| TypeORM | 17,5 | 1,3 | 13,5x |
| date-fns | 6,5 | 0,7 | 9,5x |
| tRPC | 5,5 | 0,6 | 9,1x |
| rxjs | 1,1 | 0,1 | 11,0x |
Diese Zahlen erklären, warum die Community überhaupt an einem noch schnelleren Rust-Pfad interessiert ist. Wenn ein Wechsel von JavaScript auf Go bereits Build-Zeiten zweistellig beschleunigt, stellt sich zwangsläufig die Frage, was eine systemnahe Sprache wie Rust zusätzlich herausholen könnte. Genau an diesem Punkt setzt Brownes Experiment an, auch wenn er bislang keine eigenen Timing-Messungen veröffentlicht hat.
Wie ts-rust technisch funktioniert
ts-rust versteht sich als direkter Port von Microsofts nativer Implementierung, nicht als unabhängige Neuentwicklung nach Spezifikation. Die Agenten hatten also ein funktionierendes Referenzsystem, einen riesigen automatisierten Testkorpus und ein Verhaltens-Orakel zur Verfügung, gegen das jede Ausgabe verglichen werden konnte. Wer selbst mit der nativen Vorschau von Microsoft arbeiten will, bekommt einen Eindruck vom Referenzsystem über den offiziellen Preview-Build.
npm install @typescript/native-preview
npx tsgo --version
npx tsgo pfad/zum/projekt/tsconfig.jsonDiese drei Zeilen zeigen, wie Microsofts eigener nativer Compiler aktuell installiert und aufgerufen wird. ts-rust versucht, exakt dieselbe Kommandozeilen-Oberfläche, denselben Language Server und dieselbe API nachzubilden, nur eben in Rust statt in Go. Für Entwicklerinnen und Entwickler würde ein erfolgreicher Umstieg im Idealfall bedeuten, dass sich am eigenen Build-Setup nichts ändert außer der zugrunde liegenden Binärdatei.
ts-rust im Vergleich zu Microsofts offiziellem Go-Compiler
Die beiden Projekte stehen in einer Abhängigkeitsbeziehung, nicht in direkter Konkurrenz im klassischen Sinn. Microsofts Go-Implementierung ist die offizielle, vom TypeScript-Team gepflegte Referenz. ts-rust ist ein nachgelagerter, experimenteller Community-Port dieser Referenz in eine andere Sprache.
| Merkmal | Ping Labs ts-rust | Microsoft TypeScript 7 (Go) |
|---|---|---|
| Programmiersprache | Rust | Go |
| Status | Experimentelles Community-Projekt | Offizieller TypeScript-Compiler |
| Herkunft | KI-gestützter Port des Go-Compilers | Von Microsoft selbst entwickelt (Project Corsa) |
| Veröffentlichung | Oktober 2026, experimentell | 8. Juli 2026, finale Version 7.0 |
| Validierung | 181.711 portierte Tests, 120 Repos | rund 20.000 Testfälle laut Microsoft |
| Performance-Nachweis | bislang nicht öffentlich benchmarkt | bis zu 13,5x schneller als Vorgänger |
Der entscheidende Unterschied liegt also nicht in der Kompatibilität, die bei beiden Projekten hoch ausfällt, sondern im Reifegrad und in der Nachvollziehbarkeit. Microsofts Port wurde von einem festen Entwicklerteam mit öffentlicher Roadmap, Release-Candidate-Phase und Langzeit-Supportversprechen gebaut. ts-rust ist, nach Brownes eigener Aussage, Code, den nicht einmal der Projektinitiator selbst gelesen hat.
Was das für die Softwarebranche bedeutet
Der Marktwert dieser Geschichte liegt weniger im konkreten Rust-Compiler als im Beweis, dass sich die Kostenkurve für große Code-Migrationen innerhalb von Monaten drastisch verschieben kann. Ein Modellwechsel, von Codex zu Claude Opus, reduzierte die Kosten für dieselbe Aufgabe um etwa den Faktor 17 und brachte zugleich ein brauchbares statt ein unbrauchbares Ergebnis. Für Unternehmen, die über Migrationsprojekte nachdenken, etwa den Umstieg von einer Altsprache auf eine moderne Sprache oder die Portierung eines internen Frameworks, verändert das die Kalkulation erheblich.
Gleichzeitig zeigt der gescheiterte erste Versuch, dass dieselbe Kalkulation auch katastrophal danebenliegen kann. Wer eine Migration an Agenten delegiert, ohne ein hartes Abbruchkriterium und ein Kostenlimit zu setzen, riskiert eine sechsstellige Rechnung für ein Ergebnis, das am Ende weggeworfen wird. Die 420.000 Dollar für den Codex-Versuch sind in diesem Sinn ein Warnbeispiel, nicht nur eine Fußnote.
Für IDE-Hersteller und Anbieter von Coding-Agenten wie GitHub Copilot, Cursor oder Windsurf ist die Geschichte ebenfalls relevant. Sie liefert einen öffentlichen, nachvollziehbaren Datenpunkt dafür, wie stark sich die Ergebnisqualität zwischen Modellgenerationen und Modellanbietern bei exakt derselben Aufgabe unterscheiden kann. Das dürfte Enterprise-Kunden, die gerade über Modellwahl-Strategien für eigene Agenten-Workflows entscheiden, direkt betreffen.
Bemerkenswert ist zudem, wie schnell sich die Modellwahl in solchen Projekten auszahlt oder eben nicht. Der Unterschied zwischen beiden Versuchen war kein kleiner Qualitätsgewinn, sondern ein Sprung von unbrauchbar zu produktionsnah, bei gleichzeitig deutlich niedrigeren Kosten. Für Einkaufsabteilungen, die Agenten-Lizenzen und API-Budgets verwalten, bedeutet das: Ein einzelner Benchmark-Test an einer repräsentativen Teilaufgabe kann vor einem Großauftrag mehr Aufschluss geben als jede Marketingfolie eines Anbieters.
Historischer Kontext: von COBOL-Migrationen zur KI-Portierung
Große Sprachmigrationen sind kein neues Problem. Banken und Versicherungen kämpfen seit Jahrzehnten mit COBOL-Systemen, deren Migration auf moderne Plattformen traditionell Jahre dauert und spezialisierte Teams erfordert, weil die ursprünglichen Entwickler oft längst in Rente sind. Automatisierte Transpiler für solche Aufgaben gab es schon in den 1990er- und 2000er-Jahren, allerdings mit deutlich schwächeren Ergebnissen und ohne die Fähigkeit, sich an Testergebnissen selbst zu korrigieren.
Der Unterschied bei ts-rust liegt im iterativen Charakter des Prozesses. Ein Agent kann einen Testlauf starten, das Ergebnis auswerten, den Code anpassen und erneut testen, in einer Schleife, die menschliche Teams aus Kostengründen nur begrenzt durchführen würden. Diese Fähigkeit zur selbstständigen Fehlerkorrektur gegen einen großen, automatisierten Testkorpus ist der eigentliche technologische Fortschritt gegenüber klassischen Transpilern, nicht das bloße Übersetzen von Syntax.
Weitere Beispiele für KI-gestützte Großmigrationen 2026
ts-rust ist nicht das einzige Projekt, das 2026 zeigt, wie Coding-Agenten bei umfangreichen, repository-übergreifenden Aufgaben eingesetzt werden. Agenten übernehmen zunehmend nicht mehr nur einzelne Funktionen oder Bugfixes, sondern komplette Übersetzungs- und Kompatibilitätsarbeit über ganze Codebasen hinweg. Das Muster ist dabei immer ähnlich: Es gibt eine Referenzimplementierung, einen großen automatisierten Testkorpus und ein Verhaltens-Orakel, gegen das sich jede generierte Änderung prüfen lässt. Unter diesen Bedingungen arbeiten Agenten offenbar deutlich zuverlässiger als bei offenen, unterspezifizierten Aufgaben ohne Testreferenz.
Das relativiert auch die Erwartungen an die Technologie. Ein Compiler-Port mit vorhandenem Referenzsystem und riesiger Testsuite ist eine denkbar günstige Ausgangslage für einen Agenten. Die gleiche Methode lässt sich nicht automatisch auf Aufgaben übertragen, bei denen es kein funktionierendes Original und keine vergleichbare Testabdeckung gibt, etwa die Neuentwicklung eines Systems nach einer kurzen, textuellen Spezifikation.
Auch der Zeitfaktor verdient einen zweiten Blick. Fünf Monate Agenten-Arbeit klingen zunächst nach einem langen Projekt, doch der Großteil dieser Zeit entfiel auf den gescheiterten Codex-Pfad und auf Experimentieren mit Prompting-Strategien. Der eigentliche produktive Durchbruch brauchte, einmal mit dem passenden Modell gestartet, nur zwei Wochen bis zur finalen Version und gerade einmal zehn Stunden bis zur ersten funktionsfähigen Rohversion. Diese Beschleunigung zwischen Rohversion und ausgereifter Implementierung ist für Projektplaner mindestens so interessant wie die reinen Kostenzahlen.
Risiken, Kritik und offene Fragen
Mehrere Einschränkungen relativieren die beeindruckenden Zahlen rund um ts-rust deutlich. Erstens besteht ein Risiko beim Testportieren selbst: Wenn Tests für die Rust-Version angepasst statt unverändert übernommen wurden, beweist ein bestandener Test nicht automatisch echte Verhaltensgleichheit mit dem Original. Zweitens kopiert ein Abgleich gegen Microsofts Go-Compiler auch dessen eigene Bugs und undokumentiertes Verhalten, was die unabhängige Korrektheit des Sprachverständnisses nicht belegt.
Drittens fehlen bislang belastbare Messwerte zu Geschwindigkeit, Speicherverbrauch, Startzeit oder Latenz des Language Servers im Vergleich zum Go-Original. 181.711 bestandene Tests belegen Kompatibilität in den getesteten Fällen, sie belegen keine höhere Geschwindigkeit. Viertens bleibt die TypeScript-Sprache in ständiger Weiterentwicklung, ein nachgelagerter Port muss dauerhaft mit Microsofts offizieller Implementierung synchron gehalten werden, sonst veraltet er schnell.
Am schwersten wiegt aus Sicherheitssicht der Punkt, den Browne selbst offen eingeräumt hat: Er hat den generierten Code nicht gelesen. Große Mengen maschinell erzeugten Compiler-Codes können subtile Korrektheitsfehler, unsicheren Code oder Wartungsprobleme enthalten, die gewöhnliche Konformitätstests nicht aufdecken. Für ein Projekt, das als experimentelles Lernstück angekündigt wurde, ist das vertretbar. Für einen produktiven Einsatz in sicherheitsrelevanten Build-Pipelines wäre ein ungeprüfter, KI-generierter Compiler ein erhebliches Risiko, insbesondere wenn er Teil einer Software-Lieferkette wird.
Prognosen: wohin sich KI-gestützte Compiler-Arbeit entwickelt
Auf Basis der verfügbaren Fakten lassen sich mehrere Entwicklungen für die kommenden Monate einschätzen, ausdrücklich als Einschätzung und nicht als gesicherte Tatsache gekennzeichnet.
- Unternehmen mit großen Legacy-Codebasen werden Modellwahl-Experimente wie den Wechsel von Codex zu Claude Opus zunehmend systematisch budgetieren, mit klaren Kostenobergrenzen pro Migrationsversuch.
- Weitere Community-Ports von Referenzsystemen mit großer Testabdeckung sind wahrscheinlich, etwa für andere Compiler, Parser oder Laufzeitumgebungen, bei denen ein Orakel-Vergleich möglich ist.
- Produktive Nutzung von ts-rust selbst bleibt kurzfristig unwahrscheinlich, solange keine unabhängige Code-Review und keine Performance-Benchmarks gegen tsgo vorliegen.
- Anbieter von Coding-Agenten dürften verstärkt mit genau solchen öffentlichen Kosten-Erfolgs-Vergleichen werben, um Modellwahl-Entscheidungen von Unternehmen zu beeinflussen.
- Die Diskussion um Code-Review-Pflichten für KI-generierten Infrastruktur-Code dürfte an Fahrt gewinnen, gerade weil Browne öffentlich zugab, den Code nicht gelesen zu haben.
Was das für Entwicklerinnen und Entwickler in Österreich bedeutet
Für Teams in Österreich und der gesamten DACH-Region, die TypeScript produktiv einsetzen, bleibt der direkte Effekt vorerst gering. tsc und das neue native tsgo von Microsoft sind die Werkzeuge, auf die sich Build-Pipelines heute stützen sollten, nicht ein experimenteller Community-Fork. Der eigentliche Wert der Geschichte liegt im Blick auf die eigene Migrationsplanung: Wer über die Portierung eines internen Legacy-Systems nachdenkt, egal in welcher Sprache, sollte aus dem Fall zwei Lehren mitnehmen.
Erstens lohnt sich ein Pilotversuch mit striktem Kostenlimit vor einem Großauftrag, weil sich Modellqualität und Erfolgsquote zwischen Anbietern innerhalb weniger Monate drastisch ändern können. Zweitens ersetzt ein bestandener Testlauf keine menschliche Code-Review, besonders nicht bei Software, die in sicherheitsrelevanten Build- oder Infrastrukturpfaden landet. Wer das ignoriert, baut sich möglicherweise eine neue Form von technischer Schuld auf, nur eben maschinell erzeugt statt historisch gewachsen.
Häufig gestellte Fragen zu ts-rust und dem Rust-Port des TypeScript-Compilers
Was ist ts-rust genau?
ts-rust ist ein experimenteller, von KI-Agenten erstellter Rust-Port von Microsofts nativem TypeScript-7-Compiler. Das Projekt stammt von Ping-Labs-Gründer Theo Browne und wurde im Oktober 2026 veröffentlicht.
Wie viel hat die Entwicklung gekostet?
Der erfolgreiche Durchlauf mit Claude Opus kostete nach Brownes Angaben rund 24.047 Dollar an API-Kosten über etwa zwei Wochen. Ein früherer Versuch mit Codex-Modellen kostete über 420.000 Dollar und erreichte nur rund 84 Prozent Kompatibilität.
Welches KI-Modell wurde für den erfolgreichen Port verwendet?
Der erfolgreiche Durchlauf lief über Claude Opus, gesteuert mit Claude Code. Die genaue Modellversion ist in den verfügbaren Quellen nicht eindeutig spezifiziert.
Ist ts-rust schneller als Microsofts Go-Compiler?
Das ist aktuell nicht belegt. Es liegen keine veröffentlichten Benchmarks vor, die Geschwindigkeit, Speicherverbrauch oder Latenz von ts-rust mit dem offiziellen tsgo-Compiler vergleichen.
Was ist der Unterschied zwischen ts-rust und Microsofts TypeScript 7?
TypeScript 7 ist Microsofts offizieller, nativer Compiler, geschrieben in Go und am 8. Juli 2026 final veröffentlicht. ts-rust ist ein nachgelagerter, experimenteller Community-Port dieses Go-Compilers nach Rust, ohne offiziellen Status.
Kann ich ts-rust schon produktiv einsetzen?
Davon raten die verfügbaren Informationen eher ab. Der Projektinitiator selbst hat angegeben, den generierten Code nicht gelesen zu haben, und es fehlen unabhängige Performance- und Sicherheitsprüfungen.
Was bedeuten die 181.711 bestandenen Tests konkret?
Es handelt sich um portierte Tests aus Microsofts Go-Testkorpus für den nativen TypeScript-Compiler, nicht notwendigerweise um eine unveränderte Kopie der ursprünglichen Microsoft-Konformitätssuite.
Warum hat Microsoft TypeScript überhaupt nach Go portiert?
Microsoft wollte mit dem sogenannten Project Corsa Build-Zeiten und Speicherverbrauch des bisherigen, in TypeScript selbst geschriebenen Compilers drastisch senken. Eigene Benchmarks zeigen Beschleunigungen von etwa 9x bis über 13x je nach Projekt.
