Wir haben kürzlich KI eingesetzt, um jahrelange Entwicklungsarbeit in etwa einem Sprint zu erledigen. Hier erfahren Sie, wie und warum dies unsere Vorstellung davon, was möglich ist, verändert hat.
Bereits 2022 wollten wir die Frontend-Testsuite von Asana von Enzyme, unserer veralteten Testsammlung, auf die React Testing Library (RTL) migrieren. Enzyme hatte die Unterstützung der Community verloren, funktionierte nicht gut mit neueren Versionen von React und förderte Tests, die eng mit Implementierungsdetails verbunden waren, anstatt mit dem, was Nutzer*innen tatsächlich sehen und tun. RTL führte uns zu einem besseren Modell: Testverhalten, nicht interne Abläufe.
Die Migration machte über Jahre hinweg stetige Fortschritte. Mehrere Projekte, an denen mehrere Ingenieure über Jahre hinweg arbeiteten, wurden dafür eingesetzt. Produktteams arbeiteten an den Bereichen, für die sie zuständig waren. All diese Arbeit war wichtig. Aber bei dem Tempo, in dem wir vorankamen, waren wir noch etwa fünf Jahre von der Fertigstellung entfernt.
Also setzten wir uns ein absichtlich unvernünftiges Ziel: Was wäre, wenn wir die gesamte Migration in einer Woche abschließen würden?
Wir waren nah dran. Die Entwicklungszeit betrug etwa eineinhalb Wochen. Enzyme ist jetzt vollständig aus der Codebasis verschwunden.
Der Ansatz war fast peinlich einfach. Wir haben OpenAIs Codex mit Frontier-Modellen mit besonders hoher Argumentation verwendet und bis zu vier Agents gleichzeitig ausgeführt, die jeweils auf ein anderes Verzeichnis gerichtet waren. Wir haben verhindert, dass die Maschine in den Schlafmodus wechselt, die Agenten den ganzen Tag und die ganze Nacht laufen lassen und jeden Morgen und Abend nachgesehen, um den Fortschritt zu überprüfen und Pull Requests zu öffnen.
Hier ist die gesamte Eingabeaufforderung:
/goal Wir möchten das Repository von Enzyme-Tests zu Tests im Stil der React Testing Library migrieren. Befolge die bestehenden Standards und Best Practices in der Codebase. Migriere alle Dateien in/directory, die Enzyme verwenden, damit sie die React Testing Library verwenden. Teste deine Änderungen mit [Testbefehl]. Im Allgemeinen sollten zuerst einfach zu konvertierende Dateien migriert werden.
Fünf Sätze. Das war's.
Wir haben auch ausgefallenere Setups ausprobiert: die Arbeit in verfolgte Tickets aufteilen, den Agenten eine laufende Notizdatei führen lassen, ihn bitten, Unteragenten zu erstellen, um die Arbeit weiter zu parallelisieren, eine viel detailliertere Eingabeaufforderung zu RTL-Konventionen schreiben. Fast alles davon machte die Sache noch schlimmer. Die Einfachheit hat gesiegt.
Dies ist der wichtigste Teil, und es ist die gleiche Idee, über die OpenAI kürzlich in Harness Engineering geschrieben hat: Die Qualität der Ergebnisse eines Agenten hängt stark von der Qualität der Umgebung ab, die Sie ihm zur Verfügung stellen.
In unserer Codebasis steckten bereits jahrelange Erfahrung und guter Geschmack – die ursprüngliche Entscheidung, RTL zu übernehmen, gut gestaltete Testhelfer, klare Konventionen und echte Beispiele, auf die man zurückgreifen konnte. Wir mussten dem Modell nichts davon erklären; es war bereits da und konnte gelesen werden. Wir haben einfach das Ziel vorgegeben und den Agenten laufen lassen.
Die Aufgabe selbst hatte auch die richtige Form, damit dies funktionierte: eine saubere, überprüfbare Definition von „erledigt“ (kein Enzyme mehr) und schnelle Feedback-Schleifen – Typechecking, Linting, Tests, CI –, die Fehler sofort erkennen konnten. Gutes Harness, klar definiertes Problem, minimale Unterstützung erforderlich.
Der Großteil der Reibung war nicht die Schuld des Modells – sondern unsere:
Einige kürzlich verfasste interne Dokumente und Anleitungen für Agenten wiesen immer noch auf Enzyme als bevorzugtes Muster hin und lenkten den Agenten aktiv in die falsche Richtung. Veraltete Dokumentation ist nicht mehr nur ein kleines Ärgernis, sondern irreführendes Schulungsmaterial für jeden Agenten, der sie liest.
Langsame, fehlerhafte Tools (ein Lint-Schritt, der gelegentlich mehr als zehn Minuten dauerte, Unstimmigkeiten zwischen CI- und lokalen Prüfungen) waren der Bereich, in dem wir am meisten eingreifen mussten. Der Support-Mitarbeiter war selten der Engpass – unsere eigene Infrastruktur war es.
Eine der klareren Lehren aus diesem Projekt: KI beseitigt nicht die Notwendigkeit von technischem Geschmack, sondern verstärkt sie. Saubere Beispiele und klare Konventionen in der Codebasis führten zu sauberen, gut geformten Ergebnissen. Auch unpassende Muster wurden kopiert. Das Gleiche galt für unsere Dokumente – veraltete Anleitungen wurden zu einer Belastung, wie es nie der Fall war, als sie nur von Menschen gelesen wurden.
Die ermutigende Kehrseite ist, dass dies auch in die andere Richtung wirkt. Gute Beispiele verbreiten sich. Klare Dokumente leiten die Agenten richtig. Die Investition in das „Geschirr“ – die Dokumentation, die Richtlinien und die Feedback-Schleifen rund um den Code – zahlt sich bei jeder zukünftigen Migration aus, nicht nur bei dieser.
Wir sind optimistisch, was dies für Asana bedeutet, und wissen, dass es auch beunruhigend sein kann – ein Großteil der Identität von Entwicklern hängt mit dem manuellen Schreiben von Code zusammen. Ich hoffe, dass wir dadurch mehr Zeit haben, uns mehr auf das Handwerk zu konzentrieren, nicht weniger, und ehrgeiziger an das Backlog der langwierigen Migrationen, Neuschreibungen und Performance-Probleme heranzugehen, von denen wir stillschweigend angenommen haben, dass sie immer Jahre dauern werden.
Nicht jedes dieser Probleme wird von Jahren auf eine Woche reduziert. Aber einige werden es. Die Frage, die es wert ist, gestellt zu werden, lautet nicht nur: „Nutzen wir hier KI?“ Die Frage lautet: „Haben wir tatsächlich versucht, einen Agenten über ein Wochenende damit zu beauftragen und uns am Montag anzusehen, was er erarbeitet hat?“
Die gesamte Migration nahm ungefähr eineinhalb Wochen Entwicklungszeit in Anspruch, verteilt auf zwei Kalenderwochen.
Die Modellnutzung kostete etwa 11.000 US-Dollar, plus weitere 1.000 US-Dollar für die Infrastruktur
Um diese 12.000 US-Dollar in die richtige Perspektive zu rücken (schnelle Berechnung): Die Arbeit brachte letztendlich Vorteile, die über die ursprüngliche Framework-Migration selbst hinausgingen. Währenddessen haben wir auch die Testabdeckung verbessert, schlechte Tests behoben und die alte Testinfrastruktur bereinigt. Wir schätzen, dass die manuelle Erledigung dieses gesamten Umfangs einen vollen Engineering-Aufwand von etwa 6 Mio. USD bedeutet hätte.
Wir haben dabei einige unerwartete Erfolge erzielt, darunter die Bereinigung eines noch älteren Test-Frameworks aus der Zeit vor Enzyme, von dem wir vergessen hatten, dass es noch in Teilen der Codebase vorhanden war.
Dieser Beitrag ist Teil einer laufenden Zusammenarbeit und Partnerschaft zwischen Asana und OpenAI, in deren Rahmen untersucht wird, wie Codex größere, anspruchsvollere Engineering-Aufgaben übernehmen kann.