KI-Entwicklung & Kosten: Was wirklich anfällt

Vier Folgen dieser Reihe haben die Grundsteine gelegt: Folge 1 sortiert die Marktbegriffe Context Engineering, Harness Engineering und Loop Engineering. Folge 2 zeigt, warum AI Code Review als Strukturprinzip nötig wird und wie das Verification-Trilemma aus Human Oversight, Exhaustive Audits und Vibe Accept nur durch strukturelle Antworten aufgelöst werden kann. Folge 3 beschreibt die fünf Failure-Patterns, die wir bei codecentric in Enterprise-Loop-Projekten wiederholt sehen. Folge 4 stellt das codecentric Loop-Modell als Denkrahmen vor; vier Loops (Coding, Validation, Learning, Business), verbunden über Enterprise Context Management. Diese Folge zieht die ökonomische Konsequenz: Was kostet KI-gestützte Entwicklung wirklich und wo tauchen die Rechnungen später auf, wenn niemand sie geplant hat?

Ein einfacher Prompt liefert keine produktionsreife Software. Aber mit den richtigen Loops und sauberem (Enterprise-)Context-Management lässt sich dieser Rahmen schaffen: Bei codecentric generieren wir inzwischen für diverse Kunden hochgradig automatisiert deploybare Inkremente – in ganz unterschiedlichen Ausbaustufen. Wir sehen in der Praxis, dass es technisch funktioniert.

Aber diese Automatisierung hat mehrere Preisschilder, von denen man nicht alle gleich sieht.

Wir nutzen AI at scale quer durch den Software Lifecycle: Agenten transkribieren, dokumentieren, automatisieren Prozesse und schreiben Code. Wir denken Prozesse, Team Rituale und Arbeit neu. Das funktioniert sehr gut, verursacht aber auch eine monatliche Token-Rechnung im deutlich sechsstelligen Bereich. Vor zwei Jahren haben wir in Projekten noch diskutiert, ob sich eine Tool-Lizenz für 30 Euro pro User rechnet. Heute benennen autonome Agenten mit riesigen Kontextfenstern drei Dateien um, schieben einen Commit durch und verbrennen dabei mal eben jeweils zwei Euro, das läppert sich sehr schnell zu großen Summen. Je mehr Loops laufen, desto schneller dreht sich der Token-Zähler.

Die reinen Generierungskosten sind allerdings nur der offensichtliche Faktor. Es schlummern weitere Kosten, die wir still und heimlich auf morgen verschieben.

KI-gestützte Entwicklungsprozesse können in kurzer Zeit große Mengen an Code erzeugen. Sie erzeugen damit aber auch Aufwand und Verpflichtungen im Spezifizieren, Prüfen, Verstehen und Warten von Code. Diese Folgekosten werden aktuell kaum budgetiert. Gleichzeitig eröffnen neue agentische Loops aber auch Chancen, bestehende technische Schulden in Zukunft automatisiert abzubauen.

Warum das Code-Review zum neuen Flaschenhals wird

Die Generierung von Code wird um ein Vielfaches schneller – die menschliche Kognition aber nicht.

In einer aktuellen Sonar-Umfrage unter über 1.100 Entwicklerinnen und Entwicklern gaben 38 Prozent an, dass das Review von KI-generiertem Code aufwendiger ist als bei Code aus dem eigenen Team. Der Grund: Bei maschinellem Code fehlt der gemeinsame Kontext und der Gedankengang hinter der Lösung. Dennoch verifiziert aktuell nicht einmal die Hälfte der Befragten den KI-Output systematisch.

Wie sich diese Lücke in der Praxis anfühlt, zeigt das Beispiel eines großen Finanzdienstleisters: Nach der Einführung von KI-Coding-Tools sprang der Output von 25.000 auf 250.000 Codezeilen pro Monat. Das Ergebnis war kein schnelleres Release, sondern ein blockiertes System mit einem Review-Backlog von über einer Million Zeilen.

Die Generierung hat sich verzehnfacht. Die Zahl der Menschen, die diesen Code lesen, prüfen und verstehen müssen, ist gleich geblieben. Der Aufwand hat sich nicht in Luft aufgelöst – er hat sozusagen die „Kostenstelle" gewechselt.

Welche Folgekosten von KI-Entwicklung sollte man betrachten?

Wir teilen das Ganze auf in 3 Blöcke:

Kostenblock	Aufwand / Kosten
1. Verifikationsaufwand (Verification Tax)	Jeder Output braucht Strukturen, die ihn zuverlässig prüfbar machen: Test-Infrastruktur, Lizenzen, Verification Token, Personenzeit im Review
2. Verständnisschuld (Comprehension Debt)	Reviewer verstehen, was der Code tut – aber nicht mehr, warum er so gebaut wurde. Kaum messbar. Signale: Langsameres Onboarding, zähere Bug-Analyse
3. Technische Schulden	Code ohne echtes Verständnis für den Unternehmenskontext ist schwerer zu erweitern. Schnelle Workarounds kosten später: Wartungs-Backlog, Refactoring-Kosten, sinkende Feature-Velocity nach 6 Monaten

1. Verifikationsaufwand (Verification Tax)

Wer KI-generierten Code in Produktion absichern will, braucht Tests, die unabhängig vom generierten Code entstehen, und ausgereifte Review-Gates für kritische Stellen, die die Anforderungen und Compliance der Organisation verstehen. Diesen Aufwand könnte man Verification Tax nennen – eine Steuer, die auf jeden generierten Beitrag anfällt.

KI ist sehr gut darin, Code plausibel aussehen zu lassen und Tests grün zu machen. Einfache, oberflächliche Tests sind für kritische Systeme nicht ausreichend.

Wenn wir nicht prüfen, prüft die Produktion. Das können teure Tests werden …

Wer den KI-Anteil am Code erhöht, braucht ein stärkeres Sicherheitsnetz. Plant man dieses Budget für Test-Infrastruktur nicht vorab ein, bezahlt man die Rechnung später in Form von ungeplanter Bugfix-Zeit.

2. Verständnisschuld (Comprehension Debt)

Wenn ein agentischer Loop in fünf Minuten 200 Zeilen Code produziert, sieht der Mensch im Review oft nur noch das Was, kann das Resultat in der Geschwindigkeit aber nicht mehr semantisch durchdringen. Er sieht nicht mehr, warum eine Lösung gewählt wurde oder ob subtile Edge Cases im Datenmodell übersehen wurden.

Addy Osmani beschreibt das als Comprehension Debt (Verständnisschuld): die wachsende Lücke zwischen der Codebasis und dem Anteil, den im Team noch jemand tiefgehend versteht. Eine Microsoft-Research-Studie (Lee et al., CHI 2025) mit 319 Wissensarbeiter*innen und 936 KI-Anwendungsfällen zeigt die Verschiebung empirisch: kognitiver Aufwand wandert von der Aufgaben-Ausführung zur Aufgaben-Überwachung, von der Problemlösung zur Response-Integration, von der Informations-Beschaffung zur Verifikation. Wer der KI stärker vertraut, denkt weniger kritisch mit, wer sich selbst stärker vertraut, denkt mehr mit.

Dabei gibt es einen Unterschied zu klassischen technischen Schulden. Technische Schulden haben einen Ticket-Owner. Verständnisschuld hat keinen Owner. Sie meldet sich erst bei einer Erweiterung unter Zeitdruck oder bei einem Incident in der Produktion („Ich sehe, was der Code macht – aber ich habe keine Ahnung mehr, warum").

Fehlen erfahrene Entwickler und Entwicklerinnen, kippen Bewertungen schnell in Richtung „Vibe Accept" – man winkt einfach durch, was gut aussieht. (Folge 2 zum AI Code Review hat die psychologischen Mechanismen dahinter, Normalization of Deviance und Ikea-Effekt, detailliert beschrieben.) Zu jedem Feature gehört auch mehr Kontext, der maschinenlesbar dokumentiert werden muss. Gespräche zwischen POs und Entwicklende, kann man zum Beispiel transkribieren, um alle kleinen Details nachvollziehbar zu machen.

3. Technische Schulden durch KI

KI im Coding-Loop erzeugt syntaktisch korrekten Code, kennt aber ohne das richtige Context Management weder die langfristige Zielarchitektur des Unternehmens noch die Roadmap für das nächste Quartal. Ohne KI entstehen technische Schulden, weil man beim Coden Abkürzungen nimmt. Man entscheidet teilweise bewusst: „Der richtige Weg ist aktuell zu aufwändig / teuer, wir nehmen eine Abkürzung". Mit KI werden Abkürzungen immer weniger notwendig, Schulden entstehen eher dadurch, dass man vorher nicht genug spezifiziert hat, wo man über einen längeren Zeitraum hin will.

Was in den ersten Sprints wie eine dramatische Beschleunigung aussieht, verwandelt sich ein paar Quartale später in ein System, das sich gegen Änderungen sträubt. Codezeilen ohne klare Architektur erzeugen ein Netz aus impliziten Abhängigkeiten, bis das Neuschreiben von Komponenten plötzlich billiger wird als ihr Refactoring.

Das muss nicht unbedingt schlecht sein, es eröffnet neue Denkweisen über das Thema. Wir kennen das Prinzip aus dem Betrieb, wo es langfristig günstiger ist, Systeme abzureißen und neu zu provisionieren anstatt diese so lange zu „hegen und zu pflegen" bis ein unwartbarer Zustand entsteht.

Warum diese Folgekosten Feature sind, nicht Bug

Die drei Blöcke oben sind nicht als Warnschild zu lesen, sondern als Rahmen. Wer KI-Entwicklung ernsthaft betreibt, kann den Verifikationsaufwand, die Verständnisschuld und die technischen Schulden nicht auf null drücken, sie sind der Preis dafür, dass Generierung schneller wird als Kognition. Wer sie niedrig hält, hat entweder zu wenig generiert (die KI-Beschleunigung wirkt nicht) oder zu wenig geprüft und verstanden (die Rechnung kommt später).

Der seriöse Weg ist nicht „Folgekosten minimieren", sondern „Folgekosten sichtbar machen, budgetieren, steuern". Testing-Aufwand haben wir in den letzten 20 Jahren auch nicht wegoptimiert, wir haben ihn als Disziplin etabliert. Folgekosten von KI-Code sind der gleiche Schritt, nur für die KI-Ära.

LLM FinOps: Wie man Token-Kosten im Griff behält

Kommen wir wieder zurück zu den offensichtlichen Kosten auf der Rechnung. Wer AI at scale nutzt, braucht in der Regel eine Infrastruktur, in der per Token abgerechnet wird. Subscription-Modelle sind häufig zu klein dimensioniert oder aus Compliance-Gründen nicht nutzbar. Eigene Hardware ist schwer zu betreiben und man bekommt dafür „nur" die verfügbaren Open-Source-Modelle (welche aber je nach Task inzwischen auch sehr leistungsfähig sind).

Anwender von KI brauchen einen Blick darauf, welche Kosten sie bei der Nutzung von KI verursachen. Nur so können sie wirtschaftlich mit den verfügbaren Tools umgehen. Dies erfordert FinOps-Praktiken, die man in den Teams etablieren muss.

Der kaufmännische Blick im Team-Ritual

Entwicklerinnen und Entwickler brauchen ein Gefühl für das Preisschild ihrer Werkzeuge. Ein Review-Agent, der trivialen Code mit dem teuersten Modell analysiert, verbrennt unsichtbar Budget.

Einfache Fragen in Team-Ritualen wirken bei jedem Sprint, natürlich kann man Metriken auch automatisiert in der Build Pipeline messen und zurück aufs Ticket tracken:

• Was haben wir heute generiert?
• Was hat es an Token gekostet?
• Wie hätten wir dasselbe Ergebnis günstiger erreichen können?

Zusätzlich kann sich lohnen, in folgende Bereiche zu investieren:

• Fehlender Unternehmenskontext: Ein Agent ohne Domänenwissen erfindet eigene Realitäten. Wir haben dazu eine Methode entwickelt, die sich „konsumierbare Domäne" nennt und Unternehmenswissen maschinenlesbar macht.
• Klarere Spezifikation: Was vorab nicht exakt definiert wurde, lässt sich hinterher nicht automatisiert verifizieren.
• Senior-Zeit im Review: Verständnisschuld kann nur abbauen, wer das Gesamtsystem im Kopf hat.
• Das richtige Modell für den richtigen Job: Kleine lokale Modelle oder ein zentrales LLM Gateway, das verschiedene Modelle über verschiedene Anbieter bereitstellt.

Schließlich etablieren sich immer mehr Best Practices, wie man KI effizienter nutzen kann. Um die Spezifikation zu verbessern und Review-Aufwand zu verringern, haben Kollegen beispielsweise eine Methodik entwickelt, die etablierte Best-Practices der letzten Jahrzehnte in die KI-Welt überführt: EXACT Coding (von Marco Emrich und Ferdinand Ade).

Der Kern setzt vor der Generierung an: Beispiele vor Code. Ein gut gewähltes Beispiel ist die billigste und präziseste Form der Spezifikation. Ein fehlschlagender Test definiert den nächsten Schritt im Loop exakter als jedes Ticket.

Durch den Grundsatz „Mensch als Korrektiv an klar definierten Checkpoints" wird knappe Senior-Zeit als gezielte architektonische Leitplanke eingesetzt. Das macht Folgekosten steuerbarer.

FAQ: Häufige Fragen zu KI-Kosten & Software Development

Warum steigen unsere Entwicklungskosten, obwohl unsere Teams mit KI nachweislich schneller Code generieren?

Weil KI-Coding-Tools den Aufwand nicht eliminieren, sondern vom Schreiben in nachgelagerte Phasen verschieben. Während die reine Generierungszeit sinkt, wachsen die Aufwände für Code Reviews, automatisierte Test-Infrastruktur, das Verstehen fremder Logik (Verständnisschuld) und das spätere Refactoring.

Was ist der Unterschied zwischen klassischen technischen Schulden und der Verständnisschuld (Comprehension Debt)?

Klassische technische Schulden entstehen meist bewusst (z. B. durch bewusste Shortcuts für ein schnelles Release) und lassen sich als konkrete Refactoring-Tickets im Backlog managen. Verständnisschuld ist unbewusst und hat keinen Ticket-Owner: Sie beschreibt die wachsende Lücke zwischen der Menge an Code im System und dem Anteil, den das Team semantisch wirklich durchdringt. Sie meldet sich nicht im Linter, sondern erst als Zeitverlust bei komplexen Erweiterungen oder kritischen Bug-Analysen in Produktion.

Ab wann wird der reine Token-Verbrauch in der KI-Entwicklung zum betriebswirtschaftlichen Problem?

Agenten, die in Schleifen planen, Kontext lesen, Dateien ändern und Tests ausführen, verbrauchen ein Vielfaches an Token pro Aufgabe. LLM FinOps wird notwendig, um stark ansteigende API-Kosten zu managen. Nicht jede kleine Aufgabe ist ein Task für den teuersten Agenten. Manche Aufgaben macht weiterhin günstiger der Mensch.

Wie verhindern wir, dass Entwicklerinnen und Entwickler im Review unter Zeitdruck verifizieren und „Vibe Accept" betreiben?

Durch eine Verschiebung der Qualitätssicherung vor den eigentlichen Generierungs-Loop. Statt Entwicklende am Ende tausende Zeilen Black-Box-Code lesen zu lassen, müssen Anforderungen vorab durch klare Beispiele und automatisierte, isolierte Akzeptanzkriterien (wie beim EXACT Coding) spezifiziert werden. Der generierte Code wird erst dann für das menschliche Review freigegeben, wenn deterministische Tests die funktionale und architektonische Integrität bereits bewiesen haben.

Und in Folge 6 …

In der vorletzten Folge dieser Reihe weiten wir den Blick nochmal: Wie sich Verifikation und Loop-Denken über den Coding-Loop hinaus ausweiten. Shift Left, Shift Right — und warum das Loop-Modell für viel mehr gilt als nur Softwareentwicklung.

Weiterführende Lektüre

• Addy Osmani: Comprehension Debt – der Ursprungstext zur Verständnisschuld (O'Reilly Radar)
• Melanie Volk: Die menschliche Seite der KI-Transformation – dieselbe Verschiebung aus psychologischer Sicht
• Microsoft Research: The Impact of Generative AI on Critical Thinking – empirisch zur Verschiebung von Informationsbeschaffung zu Verifikation
• Ethan Mollick: The Cybernetic Teammate – zur Frage, wann sich Delegation überhaupt rechnet
• Wes McKinney: Adversarial Agents und Roborev – Open-Source-Werkzeug für kontinuierliches Review per Git Hook
• EXACT Coding von Marco Emrich und Ferdinand Ade – das Training und das Buch