Kaum eine Entwicklung hat die Softwarebranche in den vergangenen zwei Jahren so verändert wie der produktive Einsatz von KI. Codeerzeugung ist schneller, günstiger und breiter verfügbar geworden. Seltener diskutiert wird die andere Seite dieser Rechnung: Geschwindigkeit bei der Erstellung sagt wenig über die Kosten im Betrieb. Für Unternehmen, die Software über Jahre pflegen, weiterentwickeln und gegenüber Kunden wie Aufsichtsbehörden verantworten müssen, entscheidet sich der Wert von KI nicht am Tag der Auslieferung, sondern bei der übernächsten Änderung.
Der Fachbegriff für die Differenz zwischen beidem lautet technische Schulden. Gemeint ist der Mehraufwand, der entsteht, wenn bei der Entwicklung eine schnellere gegenüber einer tragfähigeren Lösung bevorzugt wird, und der anschließend, wie ein Zins auf jede weitere Änderung an dieser Stelle anfällt. Nach Untersuchungen von McKinsey entsprechen technische Schulden im Schnitt rund 40 Prozent dessen, was in der IT-Bilanz eines Unternehmens steht. Sie sind damit kein Randposten der Entwicklungsarbeit, sondern eine ihrer größten Kostenpositionen.
Warum KI-gestützte Entwicklung den Schuldenstand beschleunigt
Drei Effekte greifen dabei ineinander. Keiner davon spricht gegen den Einsatz von KI. Gemeinsam beschreiben sie jedoch, warum die Wirkung ohne methodischen Rahmen ins Gegenteil kippen kann.
Erzeugung und Prüfung entkoppeln sich
Solange Entwicklerinnen und Entwickler jede Zeile selbst schrieben, war das Verständnis der Codebasis ein Nebenprodukt ihrer Entstehung. Diese Kopplung löst sich auf, sobald ein wesentlicher Teil der Implementierung maschinell erfolgt. Die Software funktioniert, aber die Begründung ihrer Struktur existiert nur im Kontext des Modells und nicht mehr im Team. In unseren Projekten wird das selten unmittelbar sichtbar, sondern typischerweise beim ersten größeren Änderungsvorhaben, wenn niemand mehr belastbar erklären kann, warum eine Komponente so und nicht anders geschnitten wurde.
Plausibilität ersetzt Korrektheit
Sprachmodelle signalisieren keine Unsicherheit. Sie formulieren auch dann konsistent weiter, wenn die zugrunde liegende Information fehlt. Besonders deutlich zeigt sich das bei eingebundenen Fremdkomponenten: In einer auf der USENIX Security 2025 vorgestellten Untersuchung existierten 19,7 Prozent der von Code-Modellen empfohlenen Programmbibliotheken überhaupt nicht. Der praktisch relevante Punkt ist dabei weniger die Fehlerquote als die Unauffälligkeit des Fehlers. Ein Ergebnis, das nicht als fehlerhaft erkennbar ist, durchläuft Review-Prozesse, die auf menschliche Fehlermuster ausgelegt sind.
Im Bestand sinkt die Zuverlässigkeit erheblich
Bei Neuentwicklungen ohne Altlasten sind die Ergebnisse KI-gestützter Entwicklung belastbar. In Brownfield-Szenarien, also in gewachsenen Systemen mit historisch entstandener Geschäftslogik, fällt die Trefferquote dagegen deutlich ab: Benchmarks, die langlaufende Aufgaben in realen Unternehmenscodebasen prüfen, weisen gegenüber Standardtests einen Einbruch um mehr als die Hälfte aus. Die Ursache ist keine technische. In jahrzehntealten Systemen stecken Randbedingungen, Ausnahmen und fachliche Entscheidungen, die nie dokumentiert wurden. Ein Modell ohne Architekturkontext verletzt sie und beschleunigt damit genau den Zustand, den es beheben sollte.
Wo technische Schulden entstehen und was sich durch KI-gestützte Entwicklung verschiebt:
| Ebene | Klassisches Entstehungsmuster | Verschiebung durch KI-gestützte Entwicklung |
| Implementierung | Bewusste Abkürzungen unter Termindruck, deren Bereinigung verschoben wird | Hohe Ausgabemengen, die die Kapazität für Sichtprüfung strukturell übersteigen |
| Architektur | Regeln existieren als Konvention und leben im Wissen einzelner Personen | Beiträge ohne Architekturkontext verletzen Grenzen, die nirgends automatisiert erzwungen werden |
| Abhängigkeiten | Veraltete Bibliotheken, verzögerte Aktualisierungszyklen | Vorschläge, die nicht existieren oder aus fremden Ökosystemen stammen |
| Fachwissen | Dokumentation veraltet, Verantwortlichkeiten wechseln | Die fachliche Absicht wurde nie in einer Spezifikation festgehalten |
| Nachweisführung | Prüfschritte laufen manuell und in unterschiedlicher Tiefe | Änderungsvolumen und Prüfkapazität entkoppeln sich messbar |
Der Wendepunkt liegt in der Spezifikation
Dass sich derselbe Werkzeugkasten auch in die Gegenrichtung einsetzen lässt, zeigt ein vielbeachtetes Beispiel aus der Finanzbranche. Morgan Stanley entwickelte mit DevGen.AI ein internes Werkzeug für eine Ausgangslage, die in Banken, Versicherungen und Industrie gleichermaßen auftritt: geschäftskritische Kernsysteme in Sprachen wie COBOL und PL/I, für die kaum noch Personal verfügbar ist. Seit Januar 2025 hat das Werkzeug nach Unternehmensangaben rund neun Millionen Zeilen Bestandscode verarbeitet und etwa 280.000 Entwicklerstunden eingespart.
Aufschlussreicher als der Umfang ist die gewählte Methodik. Das Werkzeug überführt Altcode nicht unmittelbar in eine moderne Zielsprache, sondern zunächst in fachliche Spezifikationen in natürlicher Sprache. Die Neuimplementierung übernehmen anschließend die Entwicklungsteams. KI wird hier also nicht zur Steigerung der Ausgabemenge eingesetzt, sondern zur Rekonstruktion verlorenen Fachwissens.
Vier Stellhebel, die über die Richtung entscheiden
Die belastbarsten Zahlen zur Gegenrichtung stammen ebenfalls von McKinsey. Nach Auswertung eigener Modernisierungsvorhaben verkürzt der Einsatz von Künstlicher Intelligenz die Projektlaufzeiten um 40 bis 50 Prozent und senkt die aus technischen Schulden resultierenden Kosten um rund 40 Prozent, bei zugleich verbesserter Ergebnisqualität. Der Unterschied zwischen diesem Ergebnis und einem beschleunigten Schuldenaufbau liegt nicht im eingesetzten Modell, sondern im methodischen Rahmen. In unseren Beratungsprojekten sind es regelmäßig dieselben vier Elemente, an denen sich die Richtung entscheidet:
- Spezifikation vor Implementierung. Eine maschinenlesbare Beschreibung der fachlichen Anforderung schafft den Prüfmaßstab, gegen den sich ein Ergebnis überhaupt bewerten lässt. Fehlt sie, kann lediglich festgestellt werden, ob Code ausführbar ist, nicht ob er die Anforderung erfüllt. Unter dem Begriff Spec-Driven Development hat dieses Vorgehen inzwischen einen eigenen methodischen Rahmen erhalten.
- Validierung außerhalb des erzeugenden Systems. Prüfszenarien, die dieselbe Instanz erstellt hat, die auch implementiert, bestätigen sich selbst. Erst strikt getrennte Holdout-Szenarien, die für das Modell nicht einsehbar bleiben, machen ein positives Testergebnis aussagekräftig. Ohne sie lässt sich der Mensch nicht aus dem Review-Loop nehmen, ohne Kontrolle zu verlieren.
- Maschinell erzwungene Architekturgrenzen. Architekturregeln, die ausschließlich im Code-Review leben, erodieren unter Lieferdruck zuverlässig. Als automatisierte Prüfung im Build hinterlegt, lässt ein Verstoß den Durchlauf sofort scheitern, statt über Monate unbemerkt zu wachsen. Das verlagert Architekturarbeit von der Ermahnung in den Prozess.
- Durchgängige Rückverfolgbarkeit. Wenn jede Änderung auf die zugrunde liegende Anforderung zurückgeführt werden kann, übersteht das fachliche Wissen den Personalwechsel. Zugleich ist dies die Grundlage jeder späteren Nachweisführung gegenüber internen Revisionen und externen Prüfern.
Regulatorik: verschobene Fristen, unveränderte Anforderungen
Der regulatorische Rahmen hat sich im Sommer 2026 bewegt, allerdings nicht in der Sache. Mit dem Digitalen Omnibus, den der Rat der EU am 29. Juni 2026 final angenommen hat, gelten die Pflichten für eigenständige Hochrisiko-Systeme nach Anhang III der KI-Verordnung nicht mehr ab August 2026, sondern erst ab Dezember 2027. Verschoben wurde ausschließlich der Geltungsbeginn. Die materiellen Anforderungen an Risikomanagement, Daten-Governance, technische Dokumentation, menschliche Aufsicht und automatische Protokollierung blieben unverändert.
Unabhängig davon läuft eine zweite Frist weiter: Ab dem 9. Dezember 2026 klassifiziert die novellierte EU-Produkthaftungsrichtlinie Software erstmals ausdrücklich als haftungspflichtiges Produkt. Welche Konsequenzen sich daraus für den Entwicklungsprozess ergeben, haben wir im Beitrag zu den fünf Reifegraden der KI-Softwareentwicklung ausgeführt.
Für die Frage technischer Schulden ist dabei vor allem eine Konsequenz relevant. Rückverfolgbarkeit lässt sich nur unter erheblichem Aufwand nachrüsten. Wer sie erst herstellt, wenn eine Frist näher rückt, muss sie in einen Bestand einziehen, den er zu diesem Zeitpunkt nicht mehr überblickt. Das ist die teuerste denkbare Form der Rückzahlung, und in unserer Erfahrung derjenige Posten, der Modernisierungsbudgets am zuverlässigsten sprengt.
Vom Einzelprojekt zur institutionellen Lieferfähigkeit
Die vier genannten Stellhebel lassen sich in einem einzelnen Vorhaben einführen. Ihre volle Wirkung entfalten sie erst, wenn sie nicht länger von der Disziplin einzelner Teams abhängen, sondern strukturell im Lieferweg verankert sind. Genau diesen Übergang beschreibt das Betriebsmodell der Software Factory: spezialisierte KI-Agenten innerhalb eines verbindlichen Governance-Rahmens, in dem Reviews, Tests und Audits bei jeder Änderung automatisiert mitlaufen und der Mensch an definierten Freigabestufen in der Verantwortung bleibt.
Der wirtschaftliche Hebel dahinter liegt weniger im eingesparten Aufwand als in der freigesetzten Kapazität. Nach der Bitkom-Studie zum Arbeitsmarkt für IT-Fachkräfte sind in Deutschland rund 109.000 IT-Stellen unbesetzt. Unter dieser Bedingung ist jede Senior-Stunde, die in die Rekonstruktion unverstandenen Codes fließt, doppelt teuer. Besonders ausgeprägt gilt das dort, wo Software unter regulatorischen Bedingungen entsteht: in der Versicherungswirtschaft, bei Banken, in der Logistik sowie im Umfeld von Life Science und Medizintechnik.
Ausblick: Von der Erzeugungsfrage zur Bestandsfrage
Die Diskussion der vergangenen zwei Jahre drehte sich weitgehend um Erzeugung: welche Modelle den besseren Code schreiben, welche Werkzeuge sich durchsetzen, wie hoch der Produktivitätsgewinn ausfällt. Diese Phase neigt sich dem Ende zu. Da inzwischen nahezu alle größeren Entwicklungsorganisationen KI produktiv einsetzen, verschiebt sich die Bewertung auf die Bestandsfrage: Was ist in den vergangenen Monaten entstanden, wer versteht es, und zu welchen Bedingungen lässt es sich weiterentwickeln?
Technische Schulden verschwinden nicht dadurch, dass Code schneller entsteht. Sie verschwinden dadurch, dass jede Änderung erklärbar bleibt. Beide Richtungen stehen offen: KI kann den Schuldenstand ebenso beschleunigt aufbauen wie abtragen. Welche der beiden eintritt, entscheidet nicht das Modell, sondern der methodische Rahmen, in den es eingebettet ist.
Vereinbaren Sie ein Beratungsgespräch zur Software Factory. Wir besprechen Ihre Ausgangslage, den Umgang mit bestehenden Altlasten und konkrete nächste Schritte.
Häufig gestellte Fragen (FAQs)
Was sind technische Schulden in der Softwareentwicklung?
Technische Schulden bezeichnen den Mehraufwand, der entsteht, wenn bei der Entwicklung eine schnellere gegenüber einer tragfähigeren Lösung bevorzugt wird, und der anschließend auf jede weitere Änderung an dieser Stelle anfällt. Der Begriff stammt aus der Kreditmetapher: Nicht die Aufnahme ist problematisch, sondern der Zins. Nach Untersuchungen von McKinsey entsprechen technische Schulden im Schnitt rund 40 Prozent dessen, was in der IT-Bilanz eines Unternehmens steht.
Erzeugt KI-gestützte Entwicklung mehr technische Schulden?
Nicht zwangsläufig, aber schneller und unauffälliger. Sobald ein erheblicher Teil der Implementierung maschinell erfolgt, entkoppeln sich Erzeugung und Prüfung. Hinzu kommt, dass fehlerhafte Ergebnisse plausibel wirken und dadurch Review-Prozesse passieren, die auf menschliche Fehlermuster ausgelegt sind. Ohne unabhängige Validierung entstehen so Verbindlichkeiten, die niemand bewusst eingegangen ist.
Wie lassen sich technische Schulden bei KI-gestützter Entwicklung begrenzen?
Über vier Elemente: eine maschinenlesbare Spezifikation vor der Implementierung, Holdout-Validierungsszenarien außerhalb des erzeugenden Systems, maschinell erzwungene Architekturgrenzen im Build sowie durchgängige Rückverfolgbarkeit jeder Änderung bis zur zugrunde liegenden Anforderung. McKinsey beziffert die Wirkung eines solchen Vorgehens auf 40 bis 50 Prozent kürzere Modernisierungszeiträume und rund 40 Prozent geringere Kosten aus technischen Schulden.
Was bedeutet die Verschiebung der EU-AI-Act-Fristen für laufende Vorhaben?
Die Pflichten für eigenständige Hochrisiko-Systeme nach Anhang III gelten seit dem Digitalen Omnibus nicht mehr ab August 2026, sondern erst ab Dezember 2027. Verschoben wurde ausschließlich der Geltungsbeginn, nicht der Umfang der Anforderungen. Für die Praxis bedeutet das mehr Umsetzungszeit bei unveränderter Zielsetzung, insbesondere hinsichtlich Protokollierung und Nachvollziehbarkeit.
Kurz-Glossar
- Technische Schulden: Mehraufwand, der entsteht, wenn bei der Entwicklung eine schnellere gegenüber einer tragfähigeren Lösung bevorzugt wird, und der auf jede weitere Änderung an dieser Stelle anfällt.
- Brownfield: Arbeit in gewachsenen Bestandssystemen mit historisch entstandener Geschäftslogik, im Gegensatz zur Neuentwicklung ohne Altlasten (Greenfield).
- Holdout-Szenario: Validierungstest, der strikt vom produktiven Code getrennt ist und für die KI nicht einsehbar bleibt, damit sie nicht auf ihre eigenen Tests hin optimiert.
- Architekturgrenze: Verbindliche Regel darüber, welche Systembestandteile aufeinander zugreifen dürfen. Als automatisierte Prüfung im Build hinterlegt, lässt ein Verstoß den Durchlauf scheitern.
- Rückverfolgbarkeit: Durchgängige Zuordnung jeder Codeänderung zu der Anforderung, aus der sie hervorgegangen ist. Grundlage für Wartbarkeit und regulatorische Nachweisführung.
- Spec-Driven Development (SDD): Entwicklungsansatz, bei dem die maschinenlesbare Spezifikation den Code ersetzt. Die KI implementiert, ein Validierungssystem prüft.
Quellenverzeichnis
¹ McKinsey (2023): Breaking technical debt’s vicious cycle to modernize your business – technische Schulden als rund 40 Prozent der IT-Bilanz; zusätzlich 10 bis 20 Prozent Projektaufschlag zur Adressierung bestehender Altlasten. Verfügbar unter: mckinsey.com/capabilities/tech-and-ai/our-insights/breaking-technical-debts-vicious-cycle-to-modernize-your-business
² Spracklen et al. (2025): We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs. USENIX Security 2025 – 19,7 Prozent halluzinierte Programmbibliotheken über 576.000 Codebeispiele aus 16 Modellen. Verfügbar unter: arxiv.org/abs/2406.10279
³ Scale AI / Deng et al. (2025): SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks? – Leistungseinbruch bei langlaufenden Aufgaben in realen Unternehmenscodebasen gegenüber Standard-Benchmarks. Verfügbar unter: scale.com/blog/swe-bench-pro
⁴ Wall Street Journal (2025): How Morgan Stanley Tackled One of Coding’s Toughest Problems – DevGen.AI, rund neun Millionen Zeilen Bestandscode und etwa 280.000 eingesparte Entwicklerstunden seit Januar 2025. 04.06.2025.
⁵ McKinsey (QuantumBlack) (2024): AI for IT modernization: Faster, cheaper, better – 40 bis 50 Prozent kürzere Modernisierungszeiträume, rund 40 Prozent geringere Kosten aus technischen Schulden. 02.12.2024. Verfügbar unter: mckinsey.com/capabilities/quantumblack/our-insights/ai-for-it-modernization-faster-cheaper-and-better
⁶ Verordnung (EU) 2024/1689 (KI-Verordnung) in der durch den Digitalen Omnibus geänderten Fassung – finale Annahme durch den Rat der EU am 29.06.2026: Hochrisiko-Pflichten nach Anhang III ab 02.12.2027 statt 02.08.2026, nach Anhang I ab 02.08.2028. Verfügbar unter: eur-lex.europa.eu/eli/reg/2024/1689/oj
⁷ Richtlinie (EU) 2024/2853 (EU-Produkthaftungsrichtlinie) – Software und KI-Systeme werden ausdrücklich als haftungspflichtige Produkte klassifiziert; anzuwenden ab 09.12.2026. Verfügbar unter: eur-lex.europa.eu/eli/dir/2024/2853/oj
⁸ Bitkom (2026): Der Arbeitsmarkt für IT-Fachkräfte, Studienbericht 2025 – rund 109.000 unbesetzte IT-Stellen in Deutschland. Repräsentative Befragung von 855 Unternehmen. Verfügbar unter: bitkom.org/Bitkom/Publikationen/Der-Arbeitsmarkt-fuer-IT-Fachkraefte
