Für das Schreiben von Code eingesetzte KI-Coding-Agenten müssen die Wartungskosten senken
(jamesshore.com)- Langfristige Produktivität wird stärker von den Wartungskosten als von der Geschwindigkeit beim Schreiben neuen Codes bestimmt
- Im Beispielmodell macht die Wartung nach zweieinhalb Jahren mehr als die Hälfte der Gesamtzeit aus
- Wenn KI-Agenten sowohl den Output als auch die Wartungskosten erhöhen, verschwindet ihr Effekt schnell
- Selbst wenn man den Agenten nicht mehr nutzt, bleiben die durch ihn verursachten zusätzlichen Wartungskosten des bereits erzeugten Codes bestehen
- Wenn sich der Output verdoppelt, müssen die Wartungskosten pro Codeeinheit ebenfalls auf die Hälfte sinken
Wartungskosten bestimmen die Produktivität
- Jede Stunde, die für das Schreiben von Code verwendet wird, verursacht danach fortlaufend Wartungszeit für Bugfixes, Aufräumarbeiten und Abhängigkeits-Upgrades
- Betrachtet wird nicht die Arbeit an neuen Features oder Verbesserungen, sondern nur die Wartung, die Jahr für Jahr wiederkehrt, solange der Code existiert
- Die Beispielschätzung geht davon aus, dass pro Monat Codeerstellung im ersten Jahr 10 Tage und danach jedes Jahr 5 Tage Wartungszeit anfallen
- Nach dem Prinzip der Wisdom of the Crowd lässt sich laut Autor eine recht genaue Antwort erhalten, wenn man etwa 50 Entwickler nach den Wartungskosten fragt
- Laut dem auf dieser Annahme basierenden Spreadsheet-Modell wird in der frühen Phase eines neuen Projekts der Großteil der Zeit für Feature-Entwicklung verwendet, doch mit der Zeit wächst der Anteil der Wartung älteren Codes
- In dieser Schätzung überschreitet die für Wartung aufgewendete Zeit nach zweieinhalb Jahren die Hälfte der Gesamtzeit, und nach 10 Jahren wird es fast unmöglich, noch andere Arbeit zu erledigen
- Halbiert man die Wartungsschätzung, gewinnt man bis zum 50%-Punkt 3 Jahre; verdoppelt man sie, fällt die Produktivität in weniger als einem Jahr unter 50%
- Wer ein produktives Team will, sollte sich stärker auf die Wartungskosten als auf die Geschwindigkeit beim Schreiben neuen Codes konzentrieren
Das Modell kann falsch sein, aber die Richtung stimmt
- In Startups in späteren Phasen zeigte sich nach etwa 5 bis 9 Jahren das Problem, dass Teams Arbeit nicht mehr vernünftig abschließen konnten, was dem im Diagramm gezeigten Muster ähnelt
- Dass reale Teams nicht ganz so schlecht aussehen wie im Diagramm, könnte daran liegen, dass ihre Wartungskosten niedriger waren, oder dass sie das Problem auf andere Weise verdeckt haben
- Mögliche Reaktionen sind: nicht jeden Bug beheben, nicht jede Abhängigkeit aktualisieren, bei nachlassender Teamgeschwindigkeit mehr Leute einstellen und immer weiter aufstocken, oder alles verwerfen und neu schreiben
- Über die genauen Zahlen kann man streiten, aber der große Trend sinkender Produktivität über die Zeit wirkt empirisch plausibel
Der Multiplikationseffekt von KI-Coding-Agenten
- Als Beispiel wird angenommen, dass das moderne agentische Coding-Framework Rock Lobster den Code-Output verdoppelt
- Gleichzeitig wird angenommen, dass der Code etwas schwerer verständlich wird, das Team von Pull Requests überrollt wird und der Code vor der Freigabe nicht mehr richtig gelesen wird
- Wenn in einem Monat Code für zwei Monate entsteht und dessen Wartungskosten ebenfalls doppelt so hoch sind, sind die Wartungskosten im nächsten Monat viermal so hoch
- In diesem Extrembeispiel fällt die Produktivität nach dem Einsatz von Rock Lobster bereits nach rund 5 Monaten auf das ursprüngliche Niveau zurück und ist einige Monate später sogar schlechter als ohne den Einsatz
- Damit ist nicht gemeint, dass KI in der Praxis Produktivität oder Wartungskosten tatsächlich verdoppelt; betont wird vielmehr, dass selbst bei derselben Wartbarkeit wie bei von Menschen geschriebenem Code der Produktivitätsgewinn nicht lange anhält
Selbst nach dem Abschalten des Agenten bleiben Wartungskosten bestehen
- Coding-Agenten kosten Geld, und wenn ihr Nutzen kleiner wird als ihre Kosten, könnte man versuchen, zur alten Arbeitsweise zurückzukehren
- Wird der Agent nicht mehr genutzt, verschwindet der Produktivitätsgewinn, aber die zusätzlichen Wartungskosten des mit dem Agenten erzeugten Codes bleiben bestehen, solange der Code existiert
- In diesem Fall kann man an eine geringere Produktivität gebunden sein als ohne den Einsatz des Agenten
Die Mathematik geht nur mit sinkenden Wartungskosten auf
- Damit die Gesamtproduktivität rechnerisch aufgeht, muss ein LLM die Wartungskosten genau im umgekehrten Verhältnis zu seinem Produktivitätsgewinn beim Code-Output senken
- Wenn sich der Output verdoppelt und sich die Wartungskosten dieses Outputs ebenfalls verdoppeln, steigen die gesamten Wartungskosten auf das Vierfache
- Wenn sich der Output verdoppelt, die Wartungskosten pro erzeugtem Output aber gleich bleiben, verdoppeln sich die gesamten Wartungskosten immer noch
- Wenn sich der Output verdoppelt, müssen sich die Wartungskosten halbieren; bei einer Verdreifachung des Outputs müssen sie auf ein Drittel sinken
- Nur wenn diese Bedingung erfüllt ist, lassen sich Geschwindigkeitsvorteile erzielen, ohne langfristige Abhängigkeiten aufzubauen
Aktuelle Sorgen über Coding-Agenten und mögliche andere Hebel
- In Quellen wie Hacker News gibt es viele Signale dafür, dass Coding-Agenten die Wartungskosten erhöhen
- Manche sagen zwar, sie helfen beim Verständnis großer Systeme, doch die dafür nötige starke Senkung der Wartungskosten ist laut Autor nicht zu erkennen – eher das Gegenteil
- Das Modell bildet die Realität zwar nicht perfekt ab, aber die Aussage bleibt gültig: KI muss die Wartungskosten proportional zur höheren Geschwindigkeit beim Schreiben neuen Codes senken
- Wer die Coding-Geschwindigkeit verbessern will, sollte ebenso viel Zeit in die Verbesserung der Wartungskosten investieren
- Es geht nicht um ein Anti-KI-Argument; auch andere Hebel sind möglich, etwa KI, die die Wartungsarbeit selbst produktiver macht, selbst wenn dadurch die Wartbarkeit des Codes nicht steigt
- Wer die Annahmen an die eigene Realität anpassen will, kann das Spreadsheet kopieren und verschiedene Modellvariablen verändern
1 Kommentare
Hacker-News-Kommentare
In dem Dconf'24-Vortrag Software as investment wurde ein grundlegendes Framework vorgeschlagen, das auf kombinierbaren Wertfunktionen für einzelne Software-Bausteine basiert
Dieses Framework selbst muss sich wegen AI nicht unbedingt ändern; man müsste nur das Kostenmodell aktualisieren, je nachdem, wie gut AI bei der Wartung ist
Es heißt zwar, dass AI 1,7-mal mehr Bugs erzeugt, aber vielleicht behebt sie sie auch schneller, daher bin ich mir nicht sicher
Wenn man Software als Investition betrachtet, spricht man statt von „technischer Schuld“ von „Wert“, und Schulden sind dann einfach Assets mit einem Wert kleiner als 0
Wenn Software die frühere Welt mit hohen Margen verlässt, muss man präzise definieren, welche Software wirtschaftlich überhaupt existenzberechtigt ist
In Software gibt es immer Teile, die man besser hätte schreiben können, und genau das ist die Schuld
Eine aufschlussreiche Perspektive, der ich zustimme
Leider landet Wartbarkeit meist im Korb der „nichtfunktionalen Anforderungen“
Aber nichtfunktionale Anforderungen wie Wartbarkeit sollte man als etwas betrachten, das die spätere Lieferung funktionaler Anforderungen erhält und ermöglicht
Man sollte das nicht einfach als Gegensatz zwischen dem framen, was Software tun soll, und wie sie es tun soll
Bei Projekten, in denen kontinuierliche Feature-Erweiterungen und Verbesserungen wichtig sind, ist Wartbarkeit abgesehen von sehr kurzen Zeiträumen faktisch fast eine funktionale Anforderung
Sobald man ihnen einen eigenen Namen gibt, liefert man weniger informierten Leuten einen Vorwand, sie abzugrenzen und niedriger zu priorisieren
Qualität ist wichtig, und wenn man sie nicht aufrechterhält, schlägt sich das sehr schnell und sehr hart in der GuV nieder
Deshalb ist sie genauso wichtig wie jeder andere Faktor
Man kann Kevlin Henneys Begriffe operational characteristics und development characteristics verwenden
Wartbarkeit ist grundlegend eine development characteristic
Es mag Produkt-Roadmaps für 1–2 Jahre geben, aber ehrlich gesagt dienen solche Roadmaps oft eher dem Vertrieb als der Engineering-Planung
Wenn der Umsatz einbricht, wechseln Produkt und Engineering die Richtung, und je früher ein Unternehmen in seiner Entwicklung ist, desto häufiger passiert das
Sobald man den Startup-Modus hinter sich lässt, sollte sich das stabilisieren, aber viele Firmen tun das nicht und wiederholen stattdessen weiter dieses Muster kurzfristiger Planung
Dadurch bleibt Produktstabilität eine niedrige Priorität
Am Ende scheint es vielen Unternehmen entweder an den Ressourcen zu fehlen, gute Software zu bauen, oder es ist ihnen schlicht nicht wichtig
Beim Aufbau unseres Projekts haben wir erlebt: AI ist schnell, aber die Bugs, die AI einbaut, sind seltsam schwer zu finden
Es sind keine offensichtlichen Bugs, sondern eher solche Logiken, bei denen drei Wochen später in Produktion etwas kaputtgeht und man beim Nachverfolgen merkt, dass AI einen subtilen Punkt falsch verstanden hat
Ehrlich gesagt senkt AI die Wartungskosten nicht so sehr, sondern verschiebt sie
Die Schreibzeit sinkt, die Review-Zeit steigt
AI-Code wirkt selbst dann flüssig und selbstsicher, wenn er falsch ist, deshalb ist er schwerer zu reviewen als menschlicher Code
Ob am Ende ein Nettogewinn entsteht, hängt vollständig davon ab, wie gut ein Team Code lesen kann im Vergleich dazu, ihn zu schreiben
Meiner Erfahrung nach senkt AI die Wartungskosten
Allerdings kann der Kontext wichtig sein. Ich arbeite mit mehreren Jahrzehnte alten Projekten, und obwohl es auch viel Neuentwicklung gibt, sind alter Code und alte Projekte plötzlich deutlich leichter handhabbar und leichter zu modernisieren geworden; in mehreren Fällen konnten sie sogar entfernt werden
Abhängigkeiten von alten Libraries und Build-Tools wurden teils aktualisiert, teils einfach entfernt, und Builds sind schneller und für Entwickler einfacher geworden
Das Einrichten und Automatisieren von End-to-End-Tests ist ebenfalls viel einfacher geworden, DevOps hat sich stark verbessert, und auch die Diagnose von Betriebsproblemen ist deutlich besser
Es gibt sehr viele Logs und Informationen sowie integrierte Dashboards und Monitoring, um die wichtigen Dinge einzufangen, aber jetzt können wir für etwa 50 deployte Systemprojekte deutlich mehr Analysen fahren
Die Grundthese des Artikels ist ja, wie viele Stunden Wartung man pro Stunde „wertschöpfender“ Feature-Entwicklung leisten muss
Deshalb sollte man erstens nicht nur die Wartungskosten messen, sondern das Verhältnis betrachten, und zweitens wurde dieser alte Code ja ursprünglich gar nicht mit AI geschrieben
Der Punkt des Autors scheint aber zu sein, dass alles viel schwieriger wird, wenn man den Zugang zu AI-Tools verliert
Es ist, als würde man erst mit schwerem Gerät bequem einen Berg versetzen und dann wieder zu Handwerkzeug zurückmüssen
Mit der Zahl der ausgelieferten Codezeilen steigen auch die Incidents, und diese Incidents werden immer gravierender
Natürlich haben wir viel alten Code verbessert, noch mehr gelöscht, die Modernisierung von Code automatisiert, Probleme besser diagnostiziert und mehr Möglichkeiten zur Mitigation bekommen
Aber all das hat den überwältigenden Umfang des Codes, der ausgeliefert wird, ohne dass ihn irgendjemand wirklich versteht, nicht aufgewogen
Unser Team nutzt AI nicht nur, um Code hinzuzufügen, sondern auch, um aggressiv alten und ausrangierten Code zu entfernen
Fragen wie „Benutzt das überhaupt noch jemand?“ oder „Wie wird das aufgerufen?“ lassen sich leicht beantworten, wenn man dem Agenten Frontend, Backend und die gesamte Codebase gibt und ihn eine Karte des Softwareprojekts erstellen lässt
IDEs leisten das in gewissem Maß innerhalb einer einzelnen Sprache und meist innerhalb eines einzelnen Projekts, aber Grenzen wie RPC oder REST bringen viele IDE-Tools aus dem Tritt
Diese Frage gefällt mir sehr: Wenn man sich eine Codebase wünschen könnte, welche würde man wollen?
Wenn man kurz darüber nachdenkt, wahrscheinlich keine Codebase mit extrem vielen Features
Man würde sich eher eine Codebase wünschen, die ziemlich ähnlich zu der ist, die man jetzt hat, aber leicht zu verstehen und entlang der künftigen geschäftlichen Anforderungen leicht wartbar und erweiterbar ist
Eine „arbeitende“ Codebase, also eine, die gewartet wird, löst reale Probleme, und diese Probleme zu lösen muss immer Vorrang vor Sauberkeit haben
Eine saubere Codebase ist oft eher ein Ausstellungsstück, das man ins Regal stellt und bewundert
Ich möchte zwei Dinge ergänzen
Erstens gibt es bei Software nicht nur technische Wartung, sondern auch User Support, und der wächst mit der Größe der Software ebenfalls
Zweitens bin ich nicht überzeugt, dass Wartungskosten linear steigen
Selbst wenn sie linear steigen, erreicht man irgendwann den Punkt, an dem die gesamte Zeit in Wartung fließt
Das könnte sein, wenn man nicht nur die einzelnen Teile warten muss, sondern auch die Art, wie diese Teile miteinander interagieren
Das stärkste Signal, das ich bisher dafür gesehen habe, ob AI tatsächlich Wartungskosten senkt, ist, ob Entwickler AI-Output als Entwurf behandeln oder als Endergebnis
Wenn man AI-Tools in einer bestehenden Codebase nutzt, etwa um ein unbekanntes Modul zu verstehen, ein gezieltes Refactoring zu erzeugen oder Migrationsskripte zu schreiben, sinkt die Wartungslast tatsächlich
Das liegt daran, dass AI an Code arbeitet, den ich architektonisch bereits verstehe, sodass ich den Output schnell bewerten kann
Das Problem entsteht, wenn AI neuen Code erzeugt, den niemand wirklich tief versteht
Diesen Code muss dann jemand warten, der ihn weder geschrieben noch entworfen hat
Bei Code von anderen Menschen kann man zumindest aus Namen, Struktur und Commit-Historie auf die Absicht schließen
AI-generiertem Code fehlt oft genau diese lesbare Absicht, weil der „Autor“ keine durchgehende Absicht über die gesamte Datei hinweg hat
Der Artikel hat recht damit, dass man nicht nur Geschwindigkeit messen sollte, sondern auch Wartungskosten
In der Praxis müsste man über Monate statt über Tage verfolgen, wie viel Zeit AI-unterstützter Code und von Menschen geschriebener Code zum Verstehen braucht und wie hoch die Änderungsfehlerquote ist
Für Code-Reviews gilt dasselbe
Ich frage mich, ob AI Code-Reviews besser lesbar machen könnte
Bei menschlichen Code-Reviews lernen Entwickler schnell, unnötige visuelle Änderungen zu vermeiden, etwa Code oder Kommentare neu umbrechen, Einrückungen ändern, die das Tool nicht ausblenden kann, Funktionen verschieben oder Zeilen löschen
Man sollte auch unnötige Refactorings vermeiden
Vielleicht könnte man Reviews in Funktionsänderungen und Darstellungsänderungen aufteilen
Dann wird das Review deutlich einfacher
Das Review startet dann bei „Es darf sich nichts ändern“, und Reviewer können Pattern Matching betreiben
Andernfalls müssen Reviewer jede Codezeile neu bewerten, um sicherzustellen, dass sich wirklich nichts geändert hat, und das sauber zu machen ist wirklich schwer
Die Versionsverwaltungssysteme, die ich benutzt habe, erlaubten jeweils unabhängig reviewte Änderungswarteschlangen
Wenn während der Entwicklung ein Refactoring nötig war, konnte man einen Commit hochladen, das Refactoring machen, das Review schicken und dann die laufende Arbeit darauf rebasen und weitermachen
Wenn man solche Änderungen wie „CLEANUP:“ oder „REFACTOR_ONLY:“ kontinuierlich durchfließen lässt, wird die endgültige Änderung viel kleiner als ein riesiges Monster-Change
Reviewer werden diese Mühe zu schätzen wissen
In einer solchen Organisation kann man sogar Metriken spielerisch nutzen, ohne dass es bösartig wird
Der Autor scheint von der Annahme auszugehen, dass Menschen jeden AI-Code gründlich reviewen und ihn auch ohne AI-Hilfe verstehen und warten können müssen
Meiner Erfahrung nach nutzen Menschen AI aber nicht so
Am Anfang schon. Solange man ihr noch nicht vertraut und noch nicht gelernt hat, so zu prompten, dass man die gewünschten Ergebnisse bekommt, nutzt man sie, um die langweiligen Teile zu automatisieren, während die initiale Implementierung oder das Muster vom Menschen kommt und AI die Lücken füllt
Das ist weniger ein radikaler Wandel darin, wie Code geschrieben wird, sondern eher Autocomplete auf Steroiden
Je mehr Menschen mit AI arbeiten, desto weniger Sorgen machen sie sich um den Code, den AI tatsächlich erzeugt
Das heißt nicht, dass das gut ist. Es kann Bugs, Performance-Probleme und Sicherheitslücken erzeugen
Aber so sieht die Realität aus. Hat AI-Code einen Bug erzeugt? Dann sagt man AI, sie soll ihn beheben
Ist AI-Code aufgebläht und schwer lesbar? Wenn es jemanden stört, sagt man AI, sie soll das beheben. Viele stört es nicht
Wenn Menschen komplett aus der Code-Wartung verschwinden, verschwindet auch der Bedarf an wartbarem Code
Ganz bei 100 % sind wir noch nicht, aber wir bewegen uns in diese Richtung
Für viele Unternehmen ist das Risiko akzeptabel, weil „gut genug“ bereits reicht und sich YOLO lohnt
Ich persönlich vertraue AI nicht so weit, dass ich generierten Code gar nicht mehr lese, aber ich lese auch nicht jede einzelne Zeile
Ich schaue mir Tests genauer an als den Code, der getestet wird, achte stärker auf performancekritische Bereiche und gebe die Gesamtstruktur vor
Und wenn es trotzdem nicht meinen Standards entspricht, pflege ich es nicht selbst, sondern sage AI, sie soll es beheben
Wenn Wartung so billig ist, stehen Wartungskosten auf meiner Prioritätenliste gar nicht weit oben
Dieser Artikel hebt gut hervor, dass AI-Agenten oder Assistenztools nicht nur beim anfänglichen Teil „bau mir ein neues Widget“ helfen sollten, sondern bei vielen Teilen der Softwareentwicklung
Der Autor meint, dass jemand, der AI-Agenten oder Assistenztools nur in der Phase des Bauens neuer Widgets nutzt, mit AI zwar mehr Code produziert, dadurch aber auch deutlich mehr Code warten muss
Selbst bei hoher Codequalität entstehen mit der Zeit Wartungskosten
Das vom Autor beschriebene Problem ist allerdings weniger eines, das alle zwangsläufig treffen wird, sondern zu einem erheblichen Teil ein selbst erzeugtes Problem
Die vom Autor genannte Startup-Situation – also „lass uns das irgendwie zum Laufen bringen, um Product-Market-Fit zu prüfen und Kunden zu gewinnen“ – ging schon immer später mit höheren Wartungskosten einher
Denn um zu prüfen, ob es überhaupt ein Geschäft gibt, und es dann schnell zu skalieren, ist es bis zu einem gewissen Grad nachvollziehbar, Qualität zugunsten von Geschwindigkeit zu opfern
Außerdem hatte ich den Eindruck, dass der Autor sich etwas davor drückt zu sagen, wie AI beim Wartungsteil tatsächlich helfen kann
Mit menschlicher Anleitung kann AI beim Beheben alter Abhängigkeiten oder lästiger Bugs sehr nützlich sein
Solche Aufgaben können sich für Softwareingenieure wie lästige Pflichtarbeit anfühlen und gehören genau zu der Art von Arbeit, bei der man sich AI-Unterstützung wünscht