Refactoring als Hebel für Token-Kosten: Ein Experiment in Fowlers gen-AI-Serie

In einfachen Worten. In einer neuen Folge der exploring-gen-ai-Reihe von Martin Fowler führt Giles Edwards-Alexander ein Experiment durch: Er zerlegt eine große Funktion und misst, ob die Token-Kosten nachfolgender KI-gestützter Änderungen tatsächlich sinken. Interessant ist nicht das Ergebnis, sondern die Methode. Der wirtschaftliche Fall für Refactoring wird zum ersten Mal auf eine Weise sichtbar, die ein Buchhalter erkennen würde.

Wo dies anknüpft

Der Thread hype-fatigue-2026 wurde bisher von Stimmen getragen, die darauf hinweisen, dass LLMs den schwierigen Teil des Programmierens nicht entfernen - sie verteilen ihn nur um. Der Beitrag von Edwards-Alexander fügt diesem Argument einen spezifischen, messbaren Rahmen hinzu: Geschwindigkeitsgewinne ohne Aufräumen zeigen sich in der monatlichen Token-Rechnung, nicht nur in der Moral des Wartungsteams.

Die Messung, nicht die Moral

Was im Experiment wichtig ist, ist die Einheit. Historisch wurde "Refactoring lohnt sich" mit Change-Lead-Time, Defektrate oder Team-Geschwindigkeit verteidigt - alles real, alles laut, alles bei Budgetzeit widerstanden. Token-Kosten sind anders. Es ist eine Position in einer Cloud-Rechnung. Wenn ein gut zerlegtes Modul bei KI-gestützten Änderungen im Vergleich zu einem monolithischen Modul deutlich weniger Token kostet - weil der Assistent pro Runde weniger Kontext benötigt - dann wird Refactoring in eine Zahl übersetzt, die ein CFO bereits verfolgt.

Ob sich die spezifischen Zahlen von Edwards-Alexander verallgemeinern lassen, ist nebensächlich. Der methodische Beitrag ist, dass die Debatte nun in Tokens pro Änderung und nicht in Vibes pro Sprint geführt werden kann.

Der Fehlermodus, benannt

Was mich zu dem Muster bringt, das ich immer wieder bei Kundenprojekten sehe: assistentengesteuerte Versteinerung. Ein LLM fügt einem Modul, das es nicht gut modelliert, ein Feature hinzu. Das Feature funktioniert, passt aber nicht - duplizierter Helfer, Notausgangsbedingung, privates Inverses einer bestehenden Utility. Die Tests bestehen. Drei Tage später modelliert derselbe Assistent das Chaos als Wahrheit und erweitert es. Über ein Quartal hinweg wird der Assistent sowohl Ursache als auch Bewahrer der Schuld.

Der Rahmen von Edwards-Alexander ist nützlich, weil er der Versteinerung eine Rechnung gibt. Ein Modul, das für den Assistenten zunehmend schwerer zu durchdenken ist, ist ein Modul, dessen Token-Kosten pro Änderung steigen. Das ist ein überwachbares Signal.

Unter der Haube: zwei Messgeräte

Zahlen, die ich in jeder KI-lastigen Codebase instrumentieren würde, indem ich den Rahmen des Experiments übernehme:

• Tokens pro KI-gestützter Änderung pro Modul, monatlich verfolgt. Wenn es steigt, während die Nutzung des Assistenten steigt, läuft die Versteinerung.
• Duplikationsverhältnis in KI-autorisierten Diffs. Günstig zu berechnen mit einem Code-Ähnlichkeits-Tool; ein Frühindikator für die Token-Kurve.

Keines davon ist ein KPI für Berichte nach oben. Beide sind Frühwarnanzeigen.

Wo der Beitrag kurz bleibt

Das Experiment behandelt nicht die nächste ehrliche Frage: Wenn das Refactoring selbst an einen Assistenten delegiert wird, was hindert eine KI-"Aufräumaktion" daran, etwas Tragendes zu löschen. Diese Forschungslücke ist real - und sie ist der Grund, warum ich den Token-Kosten-Rahmen als Diagnosewerkzeug und nicht als Autopilot betrachte.

Also was

Für einen Leiter: 15-25% eines jeden KI-lastigen Sprints für explizites Refactoring, behandelt als Kosten der Ware, nicht als Leerlauf. Für einen Entscheider: Berücksichtigen Sie die Token-Kosten-Trajektorie bei der gemeldeten KI-Geschwindigkeit. Geschwindigkeit, die pro Änderung Tokens erhöht, ist keine Produktivität - es ist eine Verlagerung auf die Cloud-Rechnung des nächsten Monats.