Anfang 2025 gewann die von KI-Forscher Andrej Karpathy eingeführte Idee des „Vibe Coding“ schnell an Aufmerksamkeit in der Tech- und Geschäftslandschaft. Die Prämisse war einfach und ansprechend. Die Interaktion in natürlicher Sprache mit großen Sprachmodellen (LLMs) könnte den Bedarf an tiefgreifendem Programmier-Know-how erheblich reduzieren. Anstatt detaillierter Spezifikationen könnten sich Teams auf konversationelle Prompts, kreativen Fluss und schnelle Iteration verlassen.

Für frühe Experimente und Proof-of-Concept-Arbeiten erwies sich dieser Ansatz als effektiv. Doch als Unternehmen begannen, dieselben Methoden auf Produktionssysteme mit echten Nutzern, regulatorischen Risiken und langfristigen Betriebskosten anzuwenden, wurde eine strukturelle Grenze offensichtlich.

Im großen Maßstab wird Software nicht danach beurteilt, wie schnell sie generiert wird. Sie wird danach beurteilt, wie vorhersehbar sie sich unter Druck verhält.

Für Gründer, CEOs und CTOs, die für echte Produkte verantwortlich sind, lautet die Frage nicht mehr: „Kann KI Code schreiben?“ Sie lautet: „Kann KI-gesteuerter Entwicklung die Systemverantwortung, Sicherheit und langfristige Weiterentwicklung anvertraut werden?“

Die Evaluationslücke: Wenn Prototypen keine Aussagekraft mehr haben

Eines der am meisten unterschätzten Risiken in der KI-gestützten Entwicklung ist die Evaluationslücke. Sie beschreibt die Diskrepanz zwischen Benchmark-Erfolg und realer Performance.

Große Sprachmodelle erreichen eine Genauigkeit von 84-89 % bei synthetischen Benchmarks wie HumanEval. Diese Ergebnisse prägen oft den anfänglichen Optimismus und die Zustimmung der Führungsebene. Wenn dieselben Modelle jedoch bei realen Implementierungsaufgaben auf Klassenebene, die Unternehmenssoftware ähneln, evaluiert werden, sinken die Erfolgsquoten auf 25-34 %. Dies ist kein geringfügiger Rückgang. Es spiegelt eine strukturelle Einschränkung wider.

Warum diese Lücke existiert

1. Unternehmenssysteme sind keine Ansammlungen isolierter Funktionen.

Sie sind Netzwerke voneinander abhängiger Komponenten. Gemeinsame Datenmodelle, dateiübergreifende Logik, implizite Verträge und sich entwickelnde Anforderungen interagieren alle miteinander. Synthetische Benchmarks spiegeln dieses Umfeld selten wider.

2. Die Syntax ist nicht mehr die Beschränkung.

LLMs zeigen nahezu null Syntaxfehlerquoten (0,00 %). Die ungelöste Herausforderung ist die semantische Korrektheit. Code muss Bedeutung und Verhalten über ein gesamtes System hinweg bewahren.

3. Fehler verändern im Produktivbetrieb ihren Charakter.

In Benchmarks treten Fehler tendenziell als einfache Logikfehler wie AssertionError auf. In realen Systemen verschieben sich die Fehler hin zu strukturellen Ausfällen. AttributeError und TypeError dominieren dann und legen Lücken im Architekturverständnis offen, anstatt mangelnde Programmierkenntnisse. Für Führungsteams sind frühe Demos daher ein schwaches Signal für die Produktionsreife.

Verschiebung der Fehlerverteilung

Das Produktivitätsparadoxon in ausgereiften Codebasen

KI-Tools werden oft mit der Erwartung dramatischer Effizienzsteigerungen eingeführt. Kontrollierte Studien an erfahrenen Entwicklern, die in ausgereiften Systemen arbeiten, zeigen jedoch ein anderes Muster.

Eine randomisierte kontrollierte Studie ergab, dass der Einsatz modernster KI-Tools bei komplexen, etablierten Codebasen die Zeit für die Aufgabenerledigung um 19 % erhöhte. Die Verlangsamung ist nicht auf die Tippgeschwindigkeit oder Tooling-Reibung zurückzuführen. Sie resultiert aus der Instabilität der Entscheidungsfindung. Wenn Entwickler sich ohne ein stabiles Architekturmodell auf KI verlassen, wird das Debugging probabilistisch. Korrekturen werden generiert, getestet, rückgängig gemacht und ersetzt. Konvergenz ist nicht garantiert.

Dies führt zu dem, was Praktiker informell als eine „Katastrophenkette“ bezeichnen. Jede versuchte Korrektur führt zu neuen Inkonsistenzen, da dem System ein einziges, maßgebliches Verständnis dafür fehlt, wie Komponenten interagieren sollten.

Erkenntnisse aus der wissenschaftlichen und parallelen Datenverarbeitung

Bei der Bewertung wissenschaftlicher Programmieraufgaben bewältigten KI-Systeme einfache Integrationen adäquat. Sie scheiterten bei der Implementierung eines parallelen 1D-Wärmegleichungslösers. Und diese Fehler waren nicht oberflächlich. Die meisten Implementierungen brachen aufgrund von Laufzeitfehlern oder fehlerhafter Logik zusammen. Die Ursache war ein unzureichendes Verständnis der parallelen Ausführungsmodelle und Koordinationsbeschränkungen.

Für Organisationen, die hochlastige, verteilte oder regulierte Systeme betreiben, ist diese Einschränkung wesentlich.

Sicherheit und Compliance sind strukturell, nicht optional

Das Sicherheitsrisiko steigt stark an, wenn die Entwicklung Geschwindigkeit über Systemverantwortung priorisiert.

Die Forschung zeigt, dass  LLMs mit einer um 10 % höheren Wahrscheinlichkeit anfälligen Code generieren als menschliche Entwickler, wobei etwa 40 % des KI-generierten Codes Sicherheitslücken aufweist.

Wiederkehrende Risikomuster

Kritische Schwachstellenklassen
Häufige Probleme sind Out-of-Bounds Writes (CWE-787), Directory Traversal (CWE-22) und Integer Overflows (CWE-190).

Unsichere Datenpraktiken
Die Speicherung von Passwörtern im Klartext und hartkodierte Geheimnisse treten häufig in KI-generierten Implementierungen auf.

Kontextfreie destruktive Aktionen
In einem dokumentierten Fall hat ein KI-Programmieragent während eines Testlaufs eine Produktionsdatenbank gelöscht, da ihm das kontextuelle Verständnis fehlte, das erforderlich ist, um die Konsequenz eines destruktiven Befehls zu bewerten.

Das Kernproblem ist nicht, dass KI Fehler macht. Es ist vielmehr, dass stimmungsbasierte Arbeitsabläufe die Kontrollen umgehen, die dazu dienen, diese Fehler zu erkennen. Architekturprüfungen, QA-Prozesse, Sicherheitsaudits und Compliance-Checks werden oft übersprungen oder verzögert.

Für Systeme, die in regulierten oder sensiblen Bereichen betrieben werden, stellt dies ein existenzielles Risiko dar.

Wo professionelle Ingenieurskunst den Unterschied macht

Mit fortschreitender KI-Adoption zeichnet sich eine klare Aufgabenteilung ab. Einige Teams nutzen KI für Exploration und schnelles Prototyping. Andere behalten die menschliche Verantwortung für Architektur, Korrektheit und das langfristige Systemverhalten.

Professionelles Engineering führt Eigenschaften ein, die unbegrenzte Automatisierung nicht garantieren kann. Systeme müssen über Dienste hinweg zusammensetzbar bleiben, unter Produktionslast vorhersehbar sein und unter realen Bedingungen testbar sein.

Die Rolle und Grenzen von RAG

Fortgeschrittene Teams nutzen zunehmend Retrieval-Augmented Generation (RAG) um Kontextverlust zu mindern. Durch das Einbringen relevanter Projektartefakte in den Generierungsprozess bietet RAG strukturelle Orientierung statt blinder Generierung.

Studien zeigen 4-7%ige Verbesserungen der Korrektheit wenn RAG angewendet wird. Es reduziert auch semantische Fehler, indem es die Generierung in bestehenden Mustern und architektonischen Entscheidungen verankert. Tools wie RepoRift und CodeRAG nutzen selektives Retrieval und Abhängigkeitsmodellierung, um diesen Prozess zu unterstützen.

RAG ersetzt jedoch nicht die Notwendigkeit eines technischen Urteilsvermögens. Ohne fachkundige Aufsicht kann es neue Probleme verursachen, wie das Kopieren ungültiger Abhängigkeiten oder die Verstärkung veralteter Annahmen. KI bleibt ein Verstärker, kein Eigentümer.

Fazit: KI multipliziert Disziplin oder deren Fehlen

KI ersetzt nicht die technische Reife. Sie legt sie offen. In Organisationen mit schwacher Architekturdisziplin beschleunigt KI die Anhäufung technischer Schulden. In Organisationen mit starker technischer Verantwortung wird sie zu einem Multiplikator.

Vibe Coding ist effektiv für schnelle Erkundung und frühe Validierung. Es verkürzt Feedbackschleifen und senkt die Kosten für Experimente.

Doch Systeme, die skalieren, Audits bestehen, tief integriert werden und sich über Jahre hinweg entwickeln müssen, erfordern etwas grundlegend anderes. Sie erfordern deterministisches Verhalten unter realen Betriebsbedingungen.

Der Wettbewerbsvorteil wird nicht den Teams gehören, die kurzfristig am schnellsten sind. Er wird jenen gehören, die KI-Beschleunigung mit professioneller Softwareentwicklung verbinden und so den Schwung in Systeme umwandeln, denen in der Produktion vertraut werden kann, anstatt sie nur in Demos zu bewundern.