8 fatale Annahmen bei der GenAI-Entwicklung – und wie Teams sie vermeiden

Vor dreißig Jahren veröffentlichte Peter Deutsch seine berühmten „Fallacies of Distributed Computing“ – acht grundlegende Annahmen, die Entwickler bei verteilten Systemen treffen und später teuer bezahlen. Heute begehen wir dieselben Fehler bei genAI-basierter Softwareentwicklung. Doch während Netzwerkprobleme früher zu Systemausfällen führten, sind es heute die falschen Annahmen über die Leistungsfähigkeit von KI-Tools.

Byron Cook, Vice President und Distinguished Scientist bei Amazon sowie Gründer der AWS Automated Reasoning Group mit über 300 Wissenschaftlern und 15 Teams, bringt es auf den Punkt: „GenAI rutscht gerade in die Phase der Ernüchterung.“ Was als „Sommer des Vibes-Programmierens“ begann, endet nun in der Realität: KI beschleunigt zwar Teile des Entwicklungsprozesses, doch die Erwartungen an eine 10-fache Steigerung der Produktivität werden enttäuscht.

Die Diskrepanz zwischen Hoffnung und Realität entsteht nicht etwa durch die Unbrauchbarkeit von KI-Tools, sondern durch grundlegende Fehleinschätzungen darüber, wo genau die Produktivitätsgewinne entstehen – und welche systemischen Anpassungen dafür nötig sind. Die Lösung liegt nicht in mehr KI, sondern in der Rückkehr zu bewährten Prinzipen der Softwarearchitektur.

Warum die meisten GenAI-Projekte scheitern

Der häufigste Irrtum: Schnellere Code-Generierung führt automatisch zu schnellerer Softwareentwicklung. Doch während ein einzelnes Modul durch KI zehnmal schneller entsteht, bleiben die umgebenden Systeme unverändert. Die Folge? Die Schnittstellen brechen – genau wie das von-Neumann-Architektur-Modell vorhersagt, wenn CPU- und Speicherleistung nicht synchron skalieren.

Ein weiteres Problem: KI-generierter Code wirkt oft plausibel, ist aber selten korrekt. Er kompiliert, besteht Tests und liest sich flüssig – während er gleichzeitig Eigenschaften verletzt, die niemand explizit geprüft hat. „Plausibel“ ist nicht gleich „richtig“, und genau diese Lücke wird zur Quelle von Produktionsfehlern.

Die acht zentralen Fallacies und ihre Konsequenzen

1. „KI beschleunigt die gesamte Entwicklung“

Wenn ein Team ein Subsystem zehnmal schneller entwickelt, die Schnittstellen und Abhängigkeiten jedoch gleich bleiben, entsteht ein Engpass – nicht an der Codeerstellung, sondern an den Systemgrenzen. Die CPU-Speicher-Lücke ist hier nur ein Beispiel: Ohne parallele Anpassungen aller Komponenten führt mehr Output zu mehr Problemen.

2. „Wenn der Code läuft, ist alles in Ordnung“

KI-Tools optimieren für syntaktische Korrektheit, nicht für semantische Richtigkeit. Ein Programm kann alle Unit-Tests bestehen und trotzdem Sicherheitslücken oder Logikfehler enthalten, die erst im produktiven Betrieb auffallen. Die Gefahr liegt nicht im sichtbaren Code, sondern in den unsichtbaren Annahmen, die der KI zugrunde liegen.

3. „KI kann KI-Code überprüfen“

Der Einsatz einer zweiten KI zur Codeprüfung löst das Problem nicht – im Gegenteil. Beide Systeme teilen dieselben fundamentalen Schwächen: Nichtdeterminismus, fehlende Verifizierbarkeit und mangelnde Transparenz. Statt die Fehleranfälligkeit zu halbieren, wird sie verdoppelt – während die Kernursache bestehen bleibt.

4. „Menschliche Überprüfung bremst die Entwicklung“

Wer menschliche Review-Prozesse einfach entfernt, ohne sie durch automatisierte Alternativen zu ersetzen, schafft keine Effizienz, sondern nur ungebremste Risiken. Die Lösung liegt in einer Arbeitsteilung: Menschen definieren die Spezifikationen, KI überprüft die Einhaltung – und zwar in Echtzeit.

5. „Bessere Kontextdaten verhindern Halluzinationen“

Retrieval-Augmented Generation (RAG) verbessert zwar die Eingabedaten, löst aber nicht das Kernproblem: die Überprüfung der Ausgabedaten. Selbst mit perfekten Fakten kann KI Code generieren, der bestehende Constraints verletzt. Kontext und Verifikation sind komplementär – keines der beiden ersetzt das andere.

6. „Jede Zeile KI-Code ist ein Wert“

Mehr generierter Code bedeutet nicht mehr Wert, sondern mehr Wartungsaufwand. Jede Zeile muss getestet, gesichert, dokumentiert und verstanden werden. Der Fortschritt liegt nicht in der Code-Menge, sondern in der Fähigkeit, mit minimalem Code maximale Funktionalität zu erreichen.

7. „Spezifikationen sind ein neues Dokument“

Spezifikationen existieren bereits in jedem Codebase – in Form von Typsystemen, API-Verträgen oder Datenbank-Schemata. David Parnas argumentierte bereits 1972 für die systematische Dokumentation dieser Constraints. Die eigentliche Innovation liegt nicht in der Erstellung, sondern in der maschinellen Durchsetzung.

8. „Mehr KI-Agenten steigern die Produktivität“

Die Einführung zusätzlicher KI-Agenten ohne klare Protokolle führt nicht zu mehr Effizienz, sondern zu mehr Inkonsistenz. Das Problem gleicht der Herausforderung verteilter Systeme: Ohne definierte Schnittstellen und Koordinationsmechanismen entsteht Chaos, kein Fortschritt.

Die gemeinsame Wurzel aller Fallacies

Alle acht Annahmen basieren auf einem fundamentalen Irrtum: die Annahme, dass die Generierung von Code der schwierigste Teil der Softwareentwicklung sei. Doch genau das Gegenteil ist der Fall. Die eigentlichen Herausforderungen liegen in der Verifikation, Wartung, Koordination und der langfristigen Konsistenz des Systems. KI hat den einfachen Teil beschleunigt – die harten Teile bleiben unverändert.

Die Lösung für alle Fallacies folgt einem architektonischen Grundsatz: Spezifikationen müssen als erste Klasse behandelt werden. Sie dienen als Koordinationsprotokolle für Agenten, als mechanische Verifikationsgrundlage und als langfristige Dokumentation des Systemdesigns. Teams, die diese Prinzipien frühzeitig umsetzen, werden die „Trough of Disillusionment“ schneller durchschreiten als ihre Konkurrenten.

Praktische Schritte für Entwicklerteams

Die Implementierung dieser Lösungen erfordert keine revolutionären neuen Tools, sondern die Rückkehr zu bewährten Prinzipien:

• Identifiziere die existierenden Spezifikationen in deinem Codebase – Typsysteme, API-Verträge, Datenbank-Schemata.
• Ersetze manuelle Review-Prozesse durch automatisierte Verifikation gegen diese Spezifikationen.
• Nutze bestehende Open-Source-Tools wie Stave (ein Cloud-Sicherheits-Analyse-Tool mit über 2.600 Sicherheitsinvarianten) oder iam-explain (ein CLI-Tool zur Überprüfung von IAM-Richtlinien).
• Dokumentiere die Entscheidungsgründe hinter jedem Spezifikations-Constraint – nicht als Kommentar im Code, sondern als explizite Design-Dokumentation.

Die GenAI-Ära hat gezeigt, dass Technologie allein keine Softwareprobleme löst. Die Lösung liegt in der Kombination aus moderner KI-Unterstützung und klassischer Softwarearchitektur. Teams, die diesen Balanceakt meistern, werden nicht nur effizienter entwickeln – sie werden auch zuverlässigere und wartbarere Systeme schaffen. Die Frage ist nicht, ob KI die Softwareentwicklung revolutioniert, sondern wie gut Teams die neuen Werkzeuge in bestehende bewährte Praktiken integrieren können.