KI kann aufgeschobene Arbeit wieder wirtschaftlich sinnvoll machen

Ich hätte nicht drei bis fünf Tage dafür reserviert, die Infrastruktur von PeşinTaksit zu vereinfachen. Das kleine Nebenprojekt lief im Hintergrund, und ich widmete ihm wenig Aufmerksamkeit. Solange es funktionierte, wollte ich seine alte Struktur unangetastet lassen.

Trotzdem musste ich vier Container betreiben: MariaDB, Redis, ein Fastify-Backend und ein Nuxt-Frontend. Jede dieser Entscheidungen war für sich genommen nachvollziehbar. Zusammen forderten sie mehr Aufmerksamkeit, als ich dem Projekt geben wollte. Ich wollte aufräumen, aber nicht so sehr, dass ich mehrere Tage dafür aufgewendet hätte.

Als ich die Struktur mit KI vereinfachte, wurde aus vier Containern ein Deployment auf Cloudflare Workers. Zwischen Beginn der Arbeit und der Inbetriebnahme der neuen Struktur lag etwa eine Stunde.

Tatsächlich verging etwa eine Stunde. Drei bis fünf Tage waren meine Schätzung vor Beginn. Ich habe dieselbe Arbeit nicht ohne KI wiederholt; daraus lässt sich kein belastbarer Beschleunigungsfaktor ableiten.

Verändert hat sich etwas anderes: Ich schloss eine Arbeit ab, für die ich sonst keine mehreren Tage eingeplant hätte. PeşinTaksit wurde dadurch nicht plötzlich wichtiger. Die Bereinigung passte nun in die Zeit, die ich dem Projekt zugestehen wollte.

Auch das Aufschieben ist eine Entscheidung

Ein funktionierendes System muss nicht ersetzt werden, nur weil es etwas Neueres gibt. Selbst wenn die Wartung Aufwand verursacht, kann es vernünftig sein, es vorerst unverändert zu lassen. Wenn Kundenarbeit wartet, lässt sich schwer begründen, ein Team mehrere Wochen mit dem Ablösen einer alten Bibliothek zu beschäftigen.

Ein Eintrag, der lange im technischen Backlog liegt, ist deshalb nicht zwingend vergessen. Das Team weiß vielleicht, was zu tun wäre, und erkennt auch den Nutzen. Der Aufwand ist ihm nur zu hoch. Bei PeşinTaksit war das genauso.

Wenn das Schreiben, Umformen und Korrigieren von Code weniger Zeit kostet, verändert sich die Grundlage dieser Entscheidung. Wer die alte Schätzung unverändert lässt und KI nur in neuen Projekten einsetzt, übersieht möglicherweise eine Gelegenheit. Manche Aufgaben, die zuvor nicht lohnend waren, lassen sich heute abschließen.

Warum bei Asana von fünf Jahren die Rede ist

In OpenAIs Fallstudie über Asana heißt es, eine auf fünf Jahre geschätzte Arbeit sei in zwei Kalenderwochen abgeschlossen worden. Dem grob geschätzten Engineering-Aufwand von rund 6 Mio. US-Dollar stehen 12.000 US-Dollar für Modelle und Infrastruktur gegenüber.

Asanas eigene Darstellung beschreibt eine vertrautere Ausgangslage. Das Team arbeitete bereits daran, die alte Testbibliothek Enzyme abzulösen. Für die verbleibende Arbeit waren damals bei diesem Tempo fünf Jahre veranschlagt. Das bedeutet nicht, dass ein Team fünf Jahre ohne Unterbrechung ausschließlich daran gearbeitet hätte.

Die 6 Mio. US-Dollar sind außerdem eine grobe Schätzung der Arbeitskosten bei manueller Umsetzung. Sie umfassen nicht nur den Austausch der Bibliothek, sondern auch weitere Verbesserungen an den Tests und an der Testinfrastruktur. Die 12.000 US-Dollar enthalten keine menschliche Arbeit. Aus der Differenz lässt sich keine Ersparnis ableiten. Auch ist der Bericht, der im Rahmen der Partnerschaft von Asana und OpenAI veröffentlicht wurde, keine kontrollierte Vergleichsstudie.

Ein konkretes Ergebnis bleibt dennoch: Eine Arbeit, die nur langsam vorankam, wurde abgeschlossen. PeşinTaksit und Asana unterscheiden sich offenkundig in ihrer Größenordnung. Beiden Fällen ist gemeinsam, dass Arbeit beendet werden konnte, die sonst im bisherigen Tempo weitergelaufen wäre. Statt die Zeitangabe eines anderen Unternehmens als Versprechen für das eigene Projekt zu lesen, ist es sinnvoller, den eigenen Fall für aufgeschobene Arbeit neu zu kalkulieren.

Den Code muss weiterhin jemand prüfen

Bevor ein Team Zeit für eine Bereinigung einplant, reicht eine Schätzung der Schreibgeschwindigkeit nicht aus. Wie viel Zeit braucht die Prüfung des Ergebnisses? Woran wird sichtbar, dass etwas nicht stimmt? Wer kann beurteilen, welches Verhalten nach der Migration erhalten bleiben muss?

Bei der Migration von rund 3.500 Testdateien hat Airbnb diese Fragen in den Ablauf eingebaut. Die Dateien wurden schrittweise geprüft. Die Arbeit ging erst weiter, wenn die Prüfungen erfolgreich waren; fehlerhafte Ergebnisse wurden dem Modell erneut zur Korrektur vorgelegt. Das Team ergänzte relevanten Code und gute Beispiele, und die Dateien, die die Automatisierung nicht abschließen konnte, bearbeiteten Ingenieure selbst.

Airbnb berichtet, die Arbeit in sechs Wochen abgeschlossen zu haben. Das ist der eigene Fallbericht des Unternehmens; die Dauer dieses Durchlaufs sagt nicht voraus, wie lange ein anderes Projekt braucht. Er zeigt jedoch, wie die Arbeit abgeschlossen wurde. Das Modell schrieb Code, aber der Ablauf erkannte Fehler und übergab das Ergebnis zur Korrektur erneut an das Modell.

Das ist besonders wichtig, wenn sich Tests ändern. Beim Vereinfachen eines Tests kann das Modell den Fehler übersehen, den der Test eigentlich erkennen sollte. Der Test bleibt trotzdem erfolgreich. Ein grüner Status auf dem Bildschirm ist nicht dasselbe wie der Nachweis, dass das bisherige Verhalten erhalten geblieben ist. Wer den Prüfaufwand nicht von Anfang an einplant, betrachtet nur den schnellsten Teil der Arbeit.

KI muss nicht jeden Teil schreiben

Uber versuchte, bei seiner JUnit-Migration generative KI in großem Umfang einzusetzen, und der Versuch scheiterte. Für die eigentliche Umformung setzte das Team OpenRewrite ein, das Code anhand festgelegter Regeln verändert. Das Team nutzte KI, um Fehler in Tests und Builds zu untersuchen.

Zuerst schuf das Team die Infrastruktur, mit der alte und neue Tests parallel ausgeführt werden konnten. Während der Migration setzte es Dateien mit fehlschlagenden Tests auf die alte Version zurück. Der Versuch zeigte, dass das Modell nicht alle Aufgaben übernehmen sollte.

Das sollte auch die Vorgehensweise bestimmen, wenn Teams aufgeschobene Arbeit wieder aufnehmen. Kann ein vorhandenes Werkzeug wiederkehrende Änderungen bereits erledigen, sollte es dafür eingesetzt werden. Ebenso kann es sinnvoll sein, die schwierigen Restdateien von Hand zu korrigieren. Es geht nicht darum zu zeigen, wie viel Arbeit sich welchem Werkzeug zuweisen lässt. Es geht darum, die alte Last zu beseitigen.

Klein anfangen, aber etwas abschließen

Für PeşinTaksit war der Zielzustand konkret: Ich musste nicht länger vier getrennte Container betreiben und wechselte zu einer einfacheren Struktur. Für Teams ist es hilfreich, den ersten Schritt auf ein ähnlich greifbares Ergebnis auszurichten. Die alte Abhängigkeit eines Moduls vollständig zu entfernen oder einen überflüssigen Dienst abzuschalten, ist ein sinnvolleres Ziel als eine bestimmte Zahl von Dateien.

Dazu muss nicht das gesamte System auf einmal geändert werden. Beginnen Sie mit einem abgegrenzten Teil und prüfen Sie, wie lange das Schreiben, Prüfen und Korrigieren des Codes tatsächlich dauert. Nur leichte Dateien auszuwählen, führt in die Irre. Eine schwierige Ausnahme neben den typischen Fällen liefert eine realistischere Schätzung der verbleibenden Arbeit.

Manchmal zeigt ein solcher Versuch, dass die Aufgabe weiterhin teuer ist. Wenn niemand vollständig versteht, was das alte System tut, kann schnelle Codeerzeugung diese Lücke nicht schließen. Zuerst muss klar dokumentiert werden, welches Verhalten erwartet wird. Auch dieser Aufwand gehört in die Kostenrechnung; die Arbeit kann dann weiter aufgeschoben bleiben.

Jemand muss auch die Verantwortung für die Bereitstellung im Produktivbetrieb übernehmen. Woran lässt sich nachweisen, dass sie funktioniert? Wer stoppt die Bereitstellung, wenn etwas schiefläuft? Wie kann das Team auf den alten Stand zurückkehren? Werden Daten verschoben, reicht es möglicherweise nicht, die alte Anwendung wieder zu öffnen. Das Team muss auch entscheiden, was mit Datensätzen geschieht, die in der Zwischenzeit eintreffen. Wann das alte System abgeschaltet wird und wer das neue überwacht, sind keine Details, um die man sich erst am Ende kümmert.

Ich habe nicht einfach ein paar freie Tage gewonnen. Ich schloss eine Arbeit ab, die sonst liegen geblieben wäre. Auch Teams haben möglicherweise Einträge im Backlog, die sich unter diesen Bedingungen ebenfalls neu bewerten lassen. Einen davon mit einem kleinen Versuch neu zu schätzen, kann ausreichen, um die Arbeit wieder aufzunehmen.

Weiterführende Literatur

• The Pulse: We need to talk about migrations with AI: Diese Diskussion gab den Anstoß für den Artikel und ordnet Asanas Schätzungen zu Zeit und Kosten in die Priorisierung ein. Die Fälle sind keine vergleichbare Evidenz für Geschwindigkeit; für den begrenzten KI-Einsatz bei Uber sollte der oben verlinkte Primärbericht maßgeblich sein.