Asana hat eine jahrelang aufgeschobene Testmigration mit OpenAI Codex in rund zwei Kalenderwochen abgeschlossen. Der Kern: Coding-Agenten übernahmen die breite, wiederholbare Codearbeit, während Menschen Fortschritt, Qualität und Freigabe kontrollierten.
Übersicht:
Was bei Asana passiert ist
Asana entfernte Enzyme, ein veraltetes Testsystem für React-Code, aus seiner Codebasis. Diese technische Altlast blockierte die Modernisierung des Frontend-Stacks, weil alte Tests neue Framework-Versionen, Abhängigkeiten und Umbauten ausbremsen können.
Die Arbeit galt intern als Projekt mit einem Zeithorizont von mindestens fünf Jahren. Mit OpenAI Codex erledigte Asana sie laut OpenAI in etwa anderthalb Wochen aktiver Engineering-Zeit, verteilt über zwei Kalenderwochen.
Asana nutzt KI-Agenten und Automatisierung nicht nur im eigenen Produkt für Arbeitsmanagement, sondern auch in der eigenen Entwicklung. Genau diese Logik übertrug das Engineering-Team auf eine klassische Altlast: viel gleichförmige Arbeit, hoher Review-Bedarf, aber kein einzelner kreativer Durchbruch.
Wie Codex die Migration beschleunigte
Der technische Ablauf war bewusst schlank. Ein kurzer Prompt mit fünf Sätzen reichte, um bis zu vier Coding-Agenten parallel arbeiten zu lassen. Jeder Agent arbeitete in einer eigenen Kopie der Codebasis, wodurch mehrere Lösungswege gleichzeitig entstehen konnten.
Ein Asana-Engineer prüfte den Stand zweimal täglich und kontrollierte jede vorgeschlagene Änderung. Codex ersetzte also nicht die technische Verantwortung, sondern verschob den Schwerpunkt: weniger manuelles Umschreiben, mehr Steuerung, Prüfung und Integration.
-
Parallele Agenten: Mehrere Codex-Instanzen bearbeiteten getrennte Teile der Migration gleichzeitig.
-
Knappe Vorgaben: Ein einfacher Prompt funktionierte besser als eine überladene Arbeitsanweisung.
-
Menschliche Kontrolle: Jede Änderung blieb reviewpflichtig, bevor sie in die Codebasis übernommen wurde.
Ein konkretes Praxisbeispiel: Statt hunderte Enzyme-Tests manuell durchzugehen, kann ein Agent nach Mustern suchen, Testfälle auf eine moderne Teststruktur übertragen und anschließend die betroffenen Tests ausführen. Der Mensch prüft dann, ob das neue Testverhalten fachlich stimmt, ob Randfälle erhalten bleiben und ob die Änderung zur Architektur passt.
Warum die Rechnung auffällt
Die Zahlen zeigen, warum solche Projekte plötzlich neu bewertet werden. Asana bezifferte Modell- und Infrastrukturkosten auf rund 12.000 US-Dollar. Der frühere Personalplan lag nach interner Schätzung bei ungefähr 6 Millionen US-Dollar.
| Vergleichspunkt | Frühere Planung | Umsetzung mit Codex |
|---|---|---|
| Zeitrahmen | Mindestens fünf Jahre | Rund zwei Kalenderwochen |
| Kostenbasis | Geschätzter Personalaufwand | Modell- und Infrastrukturkosten |
| Kostenschätzung | Etwa 6 Millionen US-Dollar | Etwa 12.000 US-Dollar |
| Rolle der Engineers | Großer Anteil manueller Migration | Steuerung, Review und Freigabe |
Die entscheidende Lehre liegt nicht nur in der Kostenersparnis. Der eigentliche Hebel ist, dass Projekte mit schlechtem Verhältnis aus Aufwand und strategischem Nutzen wieder auf die Roadmap kommen können.
Was andere Engineering-Teams daraus lernen können
Codex zeigt hier kein Wunderwerkzeug für beliebige Fünf-Jahres-Projekte. Der Fall passt zu einem bestimmten Muster: große Codebasis, viele ähnliche Änderungen, klare Zieldefinition, ausführbare Tests und erfahrene Engineers im Review.
Eine einfache Entscheidungsregel hilft: Agent zuerst, wenn die Aufgabe wiederholbar, testbar und gut begrenzbar ist. Mensch zuerst, wenn Produktlogik, Sicherheitsarchitektur, Datenmodell oder Nutzererlebnis neu entschieden werden müssen.
Das Mini-Modell dahinter lautet Technologie, Talent, Tempo. Die Technologie erzeugt viele plausible Änderungen schnell. Das Talent der Engineers entscheidet, welche davon tragfähig sind. Das Tempo entsteht erst, wenn Tests, Review-Prozesse und klare Verantwortlichkeiten zusammenpassen.
Für Unternehmen ist der Asana-Fall deshalb vor allem ein Signal zur Neupriorisierung. Alte Migrationen, Framework-Wechsel, Testmodernisierung und Performance-Aufräumarbeiten sollten nicht mehr automatisch als jahrelange Nebenprojekte gelten. Sie werden zu Kandidaten für agentengestützte Umsetzung, sofern die Organisation die Kontrolle nicht an das Modell abgibt.