Quelle auf.

Quelle auf.

Ich stelle ChatGPT Fragen, bei denen ich selbst nicht weiß, ob meine Ausgangsannahme stimmt. Statt einer schnellen Antwort soll ChatGPT recherchieren, Quellen prüfen und offenlegen, worauf die Antwort beruht.

Warum ich diesmal frage: Nach meinem Artikel über Mensch-KI-Pair-Programming ließ ich Claude den Text lesen. Claude stellte eine unangenehm praktische Gegenfrage: Was, wenn die Rollenverteilung, die Lernen und Verständnis maximiert, unter echtem Zeit- und Kostendruck gar nicht die wirtschaftlich sinnvollste ist? Vielleicht ist schnelles Generieren, Testen, Ausrollen und notfalls Zurückrollen manchmal günstiger – und vielleicht wandern die eingesparten Kosten nur unbemerkt in Review, Betrieb und spätere Wartung. Das klang plausibel. Gerade deshalb wollte ich wissen, ob es stimmt.

Meine Frage: Wie setze ich KI ökonomisch rational beim Programmieren ein – unter Zeitdruck, mit Budget-Limits, in bestehenden Teams und in Legacy-Systemen, die ohnehin nur teilweise verstanden werden?

Hier ist die Antwort von ChatGPT:

KI lohnt sich dort, wo Prüfen und Irren billig bleiben

Die kurze Antwort lautet: Setze KI dort stark ein, wo du ein Ergebnis günstig verlässlich prüfen kannst und ein durchgerutschter Fehler begrenzte Folgen hat. Führe sie enger, wenn belastbare Prüfung teuer ist oder ein Fehler spät sichtbar, weitreichend oder schwer rückgängig zu machen wäre.

Das klingt zunächst wie eine Risikoregel. Es ist aber vor allem eine Kostenregel.

Eine vierstündige Aufgabe, die mit KI in 30 Minuten erledigt ist, kann sich auch dann lohnen, wenn anschließend zwei Stunden Review nötig werden. Zusätzliche Prüfung macht den Einsatz nicht automatisch unwirtschaftlich. Umgekehrt ist ein Patch, der nach 20 Minuten fertig aussieht, kein Gewinn, wenn er drei knappe Maintainer beschäftigt, eine Datenmigration beschädigt oder Monate später nur noch von der Person verstanden wird, die den Prompt geschrieben hat.

Die entscheidende Zahl ist deshalb nicht die eingesparte Tippzeit. Es ist der Nettonutzen im ganzen relevanten Arbeits- und Betriebssystem.

Fünf Minuten schneller können 90 Minuten langsamer sein

Stellen wir uns einen Dienstagmorgen in einem älteren Abrechnungssystem vor. Ein Entwickler soll eine zusätzliche Rabattregel einbauen. Die Stelle im Code ist gefunden. Der Agent liefert nach wenigen Minuten einen plausiblen Patch, ergänzt Tests und erklärt, er habe alle Fälle berücksichtigt.

Der eigentliche Engpass beginnt erst jetzt.

Gilt der Rabatt vor oder nach Steuern? Was passiert bei einer rückwirkenden Stornierung? Darf ein alter Vertrag eine neue Tariflogik sehen? Die Antworten stehen teilweise in Code, teilweise in Daten und teilweise im Kopf einer Kollegin, die heute in einem anderen Projekt steckt. Die Tests zeigen, dass der Patch das tut, was in den Tests steht. Sie zeigen nicht, dass die Tests die richtige Geschäftsregel beschreiben.

Hier hat die KI Codeproduktion beschleunigt. Ob sie die Aufgabe beschleunigt hat, ist noch offen.

Das ist keine bloße Anekdote. Sie zeigt versteckte Evidenzkosten: Der Diff ist schnell erzeugt, aber die Begründung, warum er fachlich stimmt, kann teuer bleiben. Die Forschung misst tatsächlich sehr verschiedene Ausschnitte derselben Arbeit. Dazu drei Beispiele.

In einem kontrollierten Experiment erledigten Entwickler mit Copilot eine klar abgegrenzte JavaScript-Aufgabe 55,8 Prozent schneller. Es ging um einen HTTP-Server mit eindeutiger Erfolgskontrolle. Integration in ein reales System, Teamreview, Betrieb und spätere Wartung lagen außerhalb des Versuchs. Peng et al., The Impact of AI on Developer Productivity, Abstract und Abschnitt Results. [claim-001]

Drei randomisierte Feldexperimente bei Microsoft, Accenture und einem weiteren großen Unternehmen umfassten zusammen 4.867 Entwickler. Gepoolt stieg die Zahl erledigter Tasks mit KI-Codevervollständigung um 26,08 Prozent. Die einzelnen Experimente waren verrauscht; gemessen wurde vor allem erledigte Arbeit, nicht der langfristige Geschäftswert jedes Changes. Cui et al., The Effects of Generative AI on High-Skilled Work, Abstract. [claim-002]

Dann gibt es den scheinbaren Gegenbeweis. METR ließ 16 erfahrene Open-Source-Maintainer 246 reale Aufgaben in großen Repositories bearbeiten, die sie im Durchschnitt seit fünf Jahren kannten. Mit frühen 2025er KI-Werkzeugen brauchten sie im Mittel 19 Prozent länger. Vorher erwarteten sie eine Beschleunigung; hinterher glaubten sie weiterhin, schneller gewesen zu sein. Ein späteres Update deutet auf bessere Effekte neuerer Werkzeuge, erlaubt wegen Selbstselektion und geändertem Studiendesign aber keine verlässliche aktuelle Zahl. Becker et al., Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, Abstract und Abschnitt 3; METR, We are Changing our Developer Productivity Experiment Design, Ergebnis- und Limitationsabschnitte. [claim-003, claim-004]

Diese Zahlen widersprechen sich nicht. Der Labortask hat ein klares Ende und ein billiges Prüfkriterium: Die Tests sagen, ob der Server funktioniert. Die Feldstudien zählen abgeschlossene Arbeit. METR misst die Zeit bis zum nach üblichem Projektprozess fertiggestellten Task in reifen, vertrauten Repositories.

Die Messgrenze entscheidet über das Ergebnis.

Code ist Output. Produktivität ist ein Systemergebnis

Wenn ein Team mit KI doppelt so viele Pull Requests eröffnet, hat es zunächst doppelt so viele Pull Requests. Ob daraus mehr nutzbare Software entsteht, hängt davon ab, was danach knapp ist.

Vielleicht ist Review der Engpass. Vielleicht wartet jede Änderung auf dieselbe Fachperson. Vielleicht laufen Tests 45 Minuten. Vielleicht kann nur das Betriebsteam erkennen, ob eine Änderung fachlich korrekt ist. Mehr Erzeugungskapazität schiebt dann mehr Arbeit in eine bereits volle Warteschlange.

Ein 2025/2026 aktualisierter Preprint über Open-Source-Projekte liefert dafür einen Warnhinweis. Nach der Copilot-Einführung prüften Kernentwickler 6,5 Prozent mehr Code, während ihre eigene Codeproduktion um 19 Prozent sank. Die Nutzung wurde indirekt bestimmt und die Einführung war nicht randomisiert; daraus wird kein Naturgesetz. Aber der beobachtete Mechanismus ist wirtschaftlich wichtig: Der individuelle Gewinn des Autors kann als zusätzliche Arbeit bei knappen Reviewern auftauchen. Xu et al., arXiv:2510.10165, Abstract. [claim-008]

Die gefährlichste Fehlentscheidung ist dann nicht die falsche Zelle in einer späteren Matrix. Es ist die Annahme, mehr Pull Requests bedeuteten mehr Wert, obwohl Review, Tests oder Betrieb bereits der Engpass sind.

Ein neuerer großer Preprint untersuchte 304.362 verifizierte KI-verfasste Commits aus 6.275 GitHub-Repositories. Bei jedem der fünf untersuchten Assistenten führten mehr als 15 Prozent der Commits mindestens einen neuen statisch erkennbaren Befund ein; 22,7 Prozent der verfolgten Befunde bestanden in der letzten untersuchten Version fort. Die große Zahl beeindruckt, braucht aber eine saubere Grenze: Statisch erkannte Code Smells, Bugs und Security-Befunde sind nicht automatisch Produktionsfehler oder bereits bezifferte Wartungskosten. Sie zeigen, dass Folgearbeit bestehen kann – nicht, was sie in jedem Projekt kostet. Liu et al., Debt Behind the AI Boom, Abstract und RQ2-Ergebnisse. [claim-018]

DORA beschreibt dieselbe Systemperspektive aus Befragungsdaten. 2024 war stärkere KI-Nutzung mit besser eingeschätzter individueller Produktivität, Dokumentation und Reviewgeschwindigkeit verbunden, zugleich aber mit schlechterer Delivery-Stabilität und schlechterem Durchsatz. 2025 fasst DORA KI als Verstärker vorhandener organisatorischer Stärken und Schwächen. Das sind Assoziationen, keine saubere Kausalrechnung. Für die Praxis ist die Frage trotzdem brauchbar: Was verstärken wir gerade – Lieferung oder Warteschlange? DORA, 2024 Accelerate State of DevOps Report, AI-Ergebnisse; DORA, State of AI-assisted Software Development 2025, Zusammenfassung. [claim-005, claim-006]

SPACE, ein etablierter Rahmen für Entwicklerproduktivität, warnt schon grundsätzlich davor, Produktivität aus einer einzelnen Aktivitätsmetrik abzuleiten. Zufriedenheit, Leistung und Qualität, Aktivität, Zusammenarbeit sowie Effizienz und Flow sind verschiedene Dimensionen. Mehr Commits oder akzeptierte Vorschläge können nützliche Signale sein. Sie sind allein keine Gewinn-und-Verlust-Rechnung. Forsgren et al., The SPACE of Developer Productivity, Abstract. [claim-016]

Kosten wandern manchmal. Manchmal verschwinden sie tatsächlich

Es wäre nun leicht, aus jedem schnellen KI-Patch eine spätere Rechnung zu machen. Auch das gibt die Evidenz nicht her.

Google setzte ein eng begrenztes ML-System ein, das Buildfehler reparierte. Die Vorschläge wurden gefiltert, vom Entwickler geprüft und liefen weiterhin durch Build, Tests, statische und dynamische Analyse sowie Code Review. In einem elfwöchigen kontrollierten Experiment sanken aktive Coding- und Shepherding-Zeit je Change um ungefähr zwei Prozent. Bei Rollbacks und neu auftretenden Sanitizer-Fehlern fand Google keinen messbaren Unterschied. Google Research, Safely repairing broken builds with ML, Abschnitte The experiment, Productivity improvements und Maintaining safety. [claim-009]

Das ist kein aufregender Agent, der übers Wochenende eine Plattform baut. Es ist ein lokal begrenzter Schritt mit reichlich vorhandenen Signalen und einer bestehenden Kontrollstrecke. Gerade deshalb ist der Fall wertvoll: Er zeigt eine Situation, in der Erzeugung billiger wurde, ohne dass im beobachteten Fenster eine entsprechende Rechnung nach hinten wanderte.

Die faire Schlussfolgerung lautet daher: Kostenverschiebung ist eine zu prüfende Systemwirkung, kein Naturgesetz. Wahrscheinlicher wird sie, wenn Erzeugung wächst, Review, Tests, Architekturwissen und Deploymentkapazität aber gleich bleiben. Unwahrscheinlicher wird sie, wenn die Aufgabe klein, das richtige Verhalten präzise und die Prüfung automatisiert ist.

Rollback ist nicht dasselbe wie Rückkehr

Claudes ursprünglicher Vorschlag lautete ungefähr: generieren, testen, ausrollen, beobachten, notfalls zurückrollen. Dieses Muster kann wirtschaftlich vernünftig sein. Nur ist es keine Eigenschaft des KI-Modells. Es ist eine Eigenschaft der Liefer- und Betriebsarchitektur.

Google SRE beschreibt Canary-Releases als begrenzte, zeitlich beschränkte Exposition. Ein kleiner Teil des Traffics sieht die neue Version; beobachtbare Abweichungen sollen erkannt werden, bevor die gesamte Population betroffen ist. Der erwartete Schaden sinkt mit der Exposition – sofern die Signale den Fehler zeigen und die Rücknahme schnell funktioniert. Google SRE Workbook, Canarying Releases, What Is Canarying? und Minimizing Risk to SLOs and the Error Budget. [claim-010]

Ein Canary erkennt allerdings nur, was gemessen wird. Das ist meine Übertragung des SRE-Mechanismus auf fachliche Korrektheit: Wenn das Monitoring nur Latenz und Fehlerraten sieht, kann eine falsche Rabattberechnung vollkommen unauffällig bleiben.

Aber ein Code-Rollback ist nur die Rückkehr zu einer alten Binärversion. Es holt keine versandte Zahlung zurück. Es stellt falsch transformierte Daten nicht automatisch wieder her. Es macht eine veröffentlichte Information nicht geheim und widerruft keinen externen API-Aufruf.

Darum müssen vor dem schnellen Ausrollen sieben Dinge hinreichend wahr sein:

  1. Die Änderung ist klein und möglichst entkoppelt.
  2. Tests prüfen die Eigenschaften, auf die es tatsächlich ankommt.
  3. Produktion liefert schnelle fachliche, nicht nur technische Signale.
  4. Der betroffene Kreis ist begrenzt.
  5. Die Wirkungen sind wirklich rücknehmbar oder reparierbar.
  6. Zuständigkeit und Recovery-Ablauf sind vorbereitet.
  7. Der erwartete Verlust passt zum Risikobudget.

Error Budgets machen diesen letzten Punkt explizit. Zuverlässigkeit wird nicht maximiert, sondern gegen Featurewert und Opportunitätskosten abgewogen. Hundert Prozent Zuverlässigkeit kann unbezahlbar sein. Null Vorab-Prüfung kann es ebenfalls sein. Google SRE Book, Embracing Risk, Managing Risk und Risk Tolerance of Services. [claim-011]

Spät gefundene Fehler können teurer werden – nur nicht immer um denselben Faktor

Das externe Research-Review erinnerte an eine alte Softwareökonomie-Grafik: Je später ein Fehler entdeckt wird, desto teurer kann seine Korrektur werden. Eine NASA-Auswertung stellte Boehms Zahlen mehreren späteren Schätzungen gegenüber. Die Faktoren streuen stark, aber die Richtung ist konsistent: Ein Requirementsfehler, der erst in Test oder Betrieb auffällt, zieht mehr Änderung, Abstimmung und Revalidierung nach sich. NASA, Error Cost Escalation Through the Project Life Cycle, Software Cost Factors, Abbildung 1 und Tabelle 1. [claim-019]

Die bekannte Versuchung ist, daraus später kostet immer zehnmal so viel zu machen. Das wäre nicht belastbar. Die Daten stammen überwiegend aus älteren, stärker phasengetrennten Projekten. Kleine Batches, automatisierte Tests und Continuous Delivery verändern die Kurve. Ein CSS-Fehler, der nach fünf Minuten im Canary auffällt, ist nicht automatisch teurer als eine Stunde zusätzliche Analyse vorab.

Der Mechanismus bleibt trotzdem relevant. Je mehr bereits auf einer falschen Annahme aufbaut, desto mehr muss später entwirrt werden. Bei öffentlichen Schnittstellen, Datenverträgen, Berechtigungsmodellen und Architekturpfaden kann ein wenig Verständnis vor der Generierung billiger sein als sehr schnelle Korrektur danach.

Legacy ist keine Kostenklasse

Ein altes System kann gut getestet, beobachtbar und durch erfahrene Betreiber beherrscht sein. Ein neues System kann gekoppelt, ungetestet und irreversibel sein. Legacy allein sagt wenig über das wirtschaftlich sinnvolle Maß der Delegation.

Für die konkrete Änderung sind andere Fragen wichtiger:

METRs Maintainer-Befund zeigt, dass KI in einem großen Bestandssystem trotz jahrelangen Wissens der Entwickler bremsen kann. Ein kleines Experiment mit 32 Personen zeigt zugleich, dass ein auf den bearbeiteten Code kontextualisiertes LLM-Interface bei Codeverständnisaufgaben stärker helfen konnte als Websuche. Google Research, Using an LLM to Help With Code Understanding, Abstract. [claim-014]

Legacy erhöht also zwei Dinge gleichzeitig: den möglichen Wert schneller Erklärung und Suche – und das Risiko eines Patches, der lokal passend aussieht, aber eine unsichtbare Regel verletzt.

Die KI sollte knappes Fachwissen deshalb nicht imitieren, sondern hebeln. Fachkundige benennen Invarianten, verdächtige Schnittstellen, fachliche Orakel und den Rückweg. Der Agent kann suchen, Varianten bilden, Testskelett und reversible Ausführung übernehmen. Das spart nicht zwingend Wissen. Es setzt es dort ein, wo es die Rechnung verändert.

Zwei Fragen sind nützlicher als ein Punktesystem

Aus den Quellen ergibt sich kein etablierter Score, der aus Teamgröße, Legacy-Anteil und Testabdeckung eine erlaubte Menge KI-Code berechnet. Die folgende Zweiteilung ist deshalb meine eigene Synthese.

Erste Frage: Was kostet verlässliche Evidenz für diese Änderung?

Billig ist sie bei einer kleinen, gut beschriebenen Änderung mit schnellen relevanten Tests und klarer fachlicher Abnahme. Teuer ist sie bei impliziten Anforderungen, schwachen Testorakeln, großem Kontext, seltenen Zuständen und Abhängigkeit von wenigen Fachkundigen.

Zweite Frage: Was kostet ein Fehler, der diese Evidenz passiert?

Billig ist er bei begrenzter Exposition, schneller Entdeckung, echtem Rückweg und tolerierbarem Schaden. Teuer ist er bei Datenmutation, externer Wirkung, großer Reichweite, langer Entdeckungslatenz und schwieriger Recovery.

Evidenzkosten Fehlerfolgen Wirtschaftlich plausible Nutzung
niedrig niedrig Stark delegieren; klein ändern, automatisch prüfen, gestuft ausrollen
niedrig hoch Viel erzeugen lassen; die billige starke Verifikation bleibt zwingend
hoch niedrig Exploration zulassen; Perfektion begrenzen, Rückweg sichern
hoch hoch Delegation enger führen; Änderung verkleinern oder zuerst Kontext, Tests und Recovery verbessern

Das ist kein Freigabeautomat. Eintrittswahrscheinlichkeit, Häufigkeit und Exposition bleiben Teil der erwarteten Fehlerkosten. Und beide Achsen lassen sich verändern. Ein guter Contract-Test senkt Evidenzkosten. Ein Feature Flag begrenzt Exposition. Eine rückwärtskompatible Migration macht Recovery billiger. Ein kleinerer Change senkt oft beides.

Der wirtschaftlich größte Hebel liegt deshalb häufig nicht darin, über 40 oder 60 Prozent KI-Anteil zu streiten. Er liegt darin, das System prüfbarer und seine Änderungen kleiner zu machen.

Was ich am Dienstagmorgen tatsächlich messen würde

Unter Zeit- und Budgetdruck braucht es keine perfekte Vollkostenrechnung. Es braucht eine Baseline und wenige Messpunkte, die nicht am ersten Commit enden.

Für wiederkehrende Aufgabentypen würde ich mindestens erfassen:

Direkte Tokenkosten gehören damit sichtbar in die Rechnung. Nicht weil sie zwangsläufig größer als Personalkosten werden, sondern weil agentische Schleifen aus Lesen, Planen, Ausführen, Prüfen und erneutem Prompten variabel sind. Ein pauschaler Sitzpreis kann diese Variable verdecken. Sinnvoll ist nicht Tokens pro Entwickler, sondern Kosten pro akzeptiertem Ergebnis.

Auch die einfache Nutzenformel bleibt nur eine Denkstütze:

Nettonutzen der KI = Wert früherer Lieferung + tatsächlich eingesparte Arbeit − Werkzeug- und Nutzungskosten − zusätzliche Verifikation − erwartete Folge-, Recovery- und Wissenskosten.

Die Formel ist keine Buchhaltung. Sie macht nur sichtbar, an welchen Stellen Kosten und Erträge verschwinden oder doppelt gezählt werden können.

Dabei darf der Wert früherer Lieferung nicht noch einmal als eingesparte Arbeitszeit verbucht werden. Und ein möglicher Fehler kostet nicht automatisch seinen maximalen Schaden. Erwartete Kosten hängen davon ab, ob der Fehler die Kontrollen passiert, wen er betrifft, wann er auffällt und was bis zur Wiederherstellung geschieht.

Die Antwort wird kleiner

Claude hatte mit dem Kern seines Einwands recht. Die Rollenverteilung, die maximales Verständnis erzeugt, ist nicht automatisch die wirtschaftlich beste. Manchmal ist es vollkommen rational, eine vierstündige Aufgabe in 30 Minuten generieren zu lassen, zwei Stunden zu prüfen und das begrenzte Restrisiko zu tragen.

Aber generate, test, deploy, observe, rollback ist kein kostenloses Betriebsmodell, das zusammen mit dem Coding Agent geliefert wird. Es funktioniert nur, wenn Tests, Signale, Exposition und Recovery diese Verben tatsächlich wahr machen.

Für den Dienstagmorgen bleibt deshalb keine große KI-Strategie, sondern eine kleinere Frage vor jedem Change:

Wie teuer ist es, hier verlässlich genug zu wissen, dass die Änderung stimmt – und was kostet uns der Fehler, den wir trotzdem übersehen?

Wenn beide Antworten klein sind, darf die KI viel schreiben. Wenn eine groß wird, muss nicht zwangsläufig der Mensch wieder jede Zeile tippen. Dann muss das Team zuerst die Änderung kleiner, die Evidenz billiger oder den Rückweg echter machen.