Beim Umbau einer Testsuite von Enzyme zu React Testing Library erledigt ein KI-Modell in Minuten, wofür Entwickler früher Wochen brauchten. Asana, Airbnb und Uber haben das bereits dokumentiert. Wie diese Migrationen technisch ablaufen, welche Ergebnisse realistisch sind und was von den genannten Einsparungen übrig bleibt, zeigt der Blick auf die drei Fälle.
Fünf Jahre Arbeit in zwei Wochen: Die OpenAI-Fallstudie
OpenAI veröffentlichte eine Fallstudie. Asana, ein Anbieter von Projektmanagement-Software, habe mithilfe von OpenAI Codex ein veraltetes Testsystem in zwei Wochen entfernt. Die Kosten: rund 12.000 Dollar für Modell- und Infrastrukturaufwand. Der vorherige Plan sah vor, dass vier Ingenieure fünf Jahre an dieser Aufgabe arbeiten, geschätzt auf rund sechs Millionen Dollar. So soll Asana fast sechs Millionen Dollar eingespart haben.
Bei genauer Prüfung der Rechnung fallen Ungereimtheiten auf. Vier Ingenieure, fünf Jahre, bei einem angesetzten Jahresgehalt von rund 300.000 Dollar je Kopf — so kommen die sechs Millionen zustande. Gergely Orosz, der die Rechnung im Pragmatic Engineer nachgerechnet hat, hält sie für aufgeblasen. Interessanter als die Zahl ist ohnehin die Frage, wie eine solche Migration technisch abläuft.
Warum Enzyme und React Testing Library so unterschiedlich ticken
Die Migration von Enzyme zu React Testing Library ist kein einfaches Suchen und Ersetzen. Beide Frameworks verfolgen grundlegend verschiedene Ansätze beim Testen von React-Komponenten. Enzyme arbeitet auf der Komponenteninstanz; du kannst direkt auf Methoden und Zustände der Komponente zugreifen. Die React Testing Library rendert die Komponente und arbeitet auf dem Document Object Model, also der Struktur, die später im Browser ankommt. Das klingt nach einem Detail, hat aber erhebliche Auswirkungen auf den Testcode.
Ein einfaches Beispiel macht das deutlich: Ein Test, der prüft, ob ein Button einen Zähler erhöht, sieht in Enzyme völlig anders aus als in React Testing Library. Beim Vergleich der beiden Dateien haben sie nur die Imports gemeinsam. Der Rest unterscheidet sich in Syntax, Aufbau und Denkweise. Enzyme-Tests sind in der Regel näher an der Implementierung, während React-Testing-Library-Tests das Verhalten aus Nutzersicht prüfen. Deshalb müssen Entwickler nicht nur Code umschreiben, sondern auch ihre Teststrategie überdenken.
Diese konzeptionelle Differenz erklärt, warum eine manuelle Migration so lange dauert. Ein Tool, das nur die Syntax anpasst, scheitert hier schnell. Die Übersetzungsregeln müssen den Kontext verstehen: Wie ist der Test aufgebaut, was will er prüfen, wie drückt man das im neuen Framework aus? LLMs können über reine Textersetzung hinausgehen und semantische Äquivalenz herstellen.
Airbnb zeigt, wie LLM-Migration in der Praxis abläuft
Airbnb berichtete 2025 über eine Migrationsinitiative. Das Unternehmen migrierte mit Unterstützung von Large Language Models 3500 Komponententestdateien von Enzyme zu React Testing Library. Die manuelle Schätzung lag bei 1,5 Ingenieurjahren, tatsächlich brauchte das Team nur sechs Wochen. Entscheidend war ein mehrstufiger Prozess, den Airbnb für jede Datei durchlief.
Zunächst baute das Team Schleifen, die fehlgeschlagene Migrationen immer wieder neu anstießen. Nach der Optimierung dieser Schleifen schafften sie 75 Prozent der Dateien in vier Stunden. Die restlichen 25 Prozent waren komplexer; dafür bauten sie eine ausgefeiltere Refactoring-Pipeline. Am Ende waren 97 Prozent aller Tests migriert. Dieser Lauf dauerte mehrere Tage. Die verbleibenden 3 Prozent stellten Ingenieure in einer Woche fertig.
Das Datum ist relevant: Die Migration fand im März 2025 statt, damals war Claude 3.7 Sonnet das leistungsfähigste Codemodell. Die inzwischen verfügbaren Modelle wie GPT-5.6 Sol oder Claude Fable 5 sind deutlich besser. Deshalb ist es plausibel, dass Asana ein Jahr später nur zwei Wochen für eine ähnlich umfangreiche Migration brauchte. Die Struktur der Aufgabe ist gleich geblieben: Migrationen auslösen, validieren, Fehlversuche erneut anstoßen. Diese Verifikationsschleifen machen den Unterschied.
Im Gespräch mit Asana: Was die sechs Millionen Dollar wirklich bedeuten
Orosz sprach mit Dan Ubilla, der die Developer-Productivity-Gruppe bei Asana leitet, um die Zahlen einzuordnen. Ubilla ergänzte Details, die in der OpenAI-Fallstudie fehlen. Die Migration begann 2024, das Team hatte mehr als 4000 Enzyme-Dateien zu bearbeiten. Beim ersten Versuch mit LLMs migrierten sie etwa 25 Prozent der Dateien, vor allem die mit dem höchsten Nutzen. Der Rest war nicht dringend und wurde aufgeschoben.
Die oft genannten fünf Jahre sind also nicht als Vollzeitprojekt zu verstehen. Es war die geschätzte Dauer für eine Migration mit niedriger Priorität, die nebenher laufen sollte. Asana priorisierte nach Stufen wie kritisch, wichtig und opportunistisch. Enzyme war eine von vielen opportunistischen Aufgaben, die ohnehin hinten anstand. Mit dem LLM-Projekt wollte das Team zeigen, dass sich langwierige Migrationen stark verkürzen lassen, und nutzte genau diese ungeliebte Aufgabe als Testfall.
Und die sechs Millionen Dollar? Auch dazu hat Ubilla eine klare Antwort. Die Schätzung entstand auf klassische Art: Man schätzt, wie lange ein Ingenieur manuell für eine einzelne Datei braucht, multipliziert das mit der Anzahl der offenen Dateien und addiert den Aufwand für das Entfernen von Rahmenbedingungen wie Monitoring oder statische Analysen. Mit dem Stundensatz eines typischen Ingenieurs ergibt das die sechs Millionen. Diese Rechnung ignoriert den Lerneffekt bei vielen Wiederholungen und geht von null KI-Unterstützung aus. Orosz hält die Zahl deshalb für eine Überschätzung, aber sie dient als grober Anhaltspunkt, wie viel Arbeit in einem solchen Projekt steckt.
Uber, Bun und die neue Lust auf lästige Aufgaben
Asanas Erfolg steht nicht allein. Einige Monate zuvor berichtete Uber über eine massive JUnit-Migration mit KI: 600.000 Unit-Tests mit insgesamt 15 Millionen Zeilen Code von JUnit 4 auf JUnit 5. Zwei Ingenieure schafften das in vier Monaten; dabei wurden 1,25 Millionen Zeilen Code geändert. Ohne KI-Tools wäre das Vorhaben praktisch undurchführbar gewesen, weil es Jahre gedauert und alle Entwickler blockiert hätte.
Bei der Laufzeit Bun wurden 530.000 Zeilen von Zig zu Rust in zwei Wochen umgewandelt. Die API-Kosten dafür betrugen 165.000 Dollar. Diese Beispiele zeigen ein Muster: KI-gestützte Code-Migration funktioniert nicht ohne menschliche Planung, reduziert den Aufwand aber um Größenordnungen. Allen erfolgreichen Migrationen gemeinsam ist ein klar definierter Prozess mit Verifikationsschleifen und erfahrenen Ingenieuren.
Für dich als Entwickler bedeutet das vor allem Entlastung. Migrationsprojekte schoben bisher alle auf, weil sie monoton und zeitraubend sind. Mit KI-Assistenten schrumpft der langweilige Teil, der anspruchsvolle bleibt: Du musst verstehen, was der Code tut, und sicherstellen, dass die neuen Tests dasselbe Verhalten abdecken. Die Technik übernimmt das stupide Umschreiben, du steuerst die Richtung. Langwierige Migrationen werden damit zu einem planbaren Projekt, das in Wochen statt Jahren abgeschlossen werden kann. Die Fallstudien zeigen, dass die Werkzeuge funktionieren. Und du kannst endlich technische Schulden abbauen, die lange liegen geblieben sind.
Quelle: blog.pragmaticengineer.com
