Die Ära des ‚vorherigen Vibe Coders‘ beginnt

💡 Zusammenfassung: zentrale Punkte

• Die Geschwindigkeitsillusion: Das Produktivitätsgefühl beim Programmieren mit KI – die „Vibe Velocity“ – ist weit entfernt von der Geschwindigkeit, sicheren, leistungsfähigen und nachhaltig wartbaren Code in Produktion zu bringen („Net Throughput“).
• Subventionierte Schlampigkeit: KI kann die anfänglichen Kosten der Codeerzeugung (CAPEX) senken und zugleich Wartungs- und Betriebskosten (OPEX) aufschieben, wenn Teams ungetestete oder schlecht strukturierte Software akzeptieren.
• Das Ende von DRY: Arbeitet KI mit unvollständigem Projektkontext, kann sie doppelte Inline-Logik im Frontend und das Umgehen von Architekturregeln im Backend fördern.
• Der Markt für Zitronen: Da interne Codequalität von außen unsichtbar ist, füllt sich der Markt mit billigem KI-generiertem „Zitronen“-Code und sauberer Engineering-Arbeit entsteht ein wirtschaftlicher Nachteil.
• Die Krise des „vorherigen Vibe Coders“: Systeme, die heute mit KI billig gebaut werden, können später einen Sumpf aus Technikschulden erzeugen, der teure Sanierung und Refactoring durch Seniors verlangt.

Seit einem Jahr herrscht in der Softwarewelt ein eigentümlicher Rausch. Behauptungen wie „Mit KI haben wir Entwicklerkosten um 90 Prozent gesenkt“ oder „Ich habe in zehn Minuten eine SaaS-Anwendung von Grund auf gebaut“ sind überall. In Vorstandsetagen laufen Präsentationen über KI-Agenten, die ganze Engineering-Teams ersetzen sollen. Hinter dieser Begeisterung liegt jedoch eine Realität, über die kaum jemand offen sprechen will.

Die Lücke zwischen dem raschen Produzieren von Code an der Tastatur – jenem flüchtigen Pseudo-Produktivitätsgefühl, das wir „Vibe Velocity“ nennen – und dem tatsächlichen Bereitstellen eines sicheren, leistungsfähigen und nachhaltig wartbaren Produkts in Produktion („Net Throughput“) wird täglich größer.

Diese Entwicklung führt die Branche an den Rand einer sehr vertrauten Krise, diesmal mit einem anderen Verursacher: dem Problem des „vorherigen Vibe Coders“.

Wie KI Schlampigkeit subventioniert

KI kann Codeerzeugung billiger machen, ohne die Kosten für Sorgfalt, Tests oder Architektur zu beseitigen. Sie kann diese Kosten lediglich leichter aufschieben.

Ökonomisch ausgedrückt: KI kann die unmittelbaren Kosten der Codeerzeugung (CAPEX) vorübergehend gegen null drücken, während sie die langfristigen Kosten von Wartung und Betrieb (OPEX) unsichtbar auflaufen und später anfallen lässt.

Tests schreiben, Sicherheitslücken prüfen, Randfälle durchdenken und Architektur erhalten kosten mentale Arbeit und Zeit. KI beseitigt diese unmittelbare Reibung, indem sie in Sekunden Code liefert, der „so aussieht, als funktioniere er“.

„KI kann doch auch Tests schreiben“ ist kein ausreichender Einwand. Ohne menschliche Prüfung des fehlschlagenden Verhaltens kann ein Modell für ein grünes Dashboard optimieren, indem es den Test ändert statt die Ursache zu beheben. Alles kann grün sein, obwohl der Test so geschwächt wurde, dass er den Fehler akzeptiert.

Entscheidend ist: Es sieht so aus, als funktioniere es. Entwicklerinnen und Entwickler können zum nächsten Feature weitergehen, ohne den strukturellen Verfall hinter dem Code zu bemerken. Diese unsichtbaren OPEX erscheinen später als langsamere Änderungen, schwierigere Diagnose und teurerer Betrieb.

Der stille Tod von DRY und das Bibliothekschaos

Das Risiko ist keine allgemeine Eigenschaft jedes Modells oder Arbeitsablaufs. Es entsteht, wenn KI mit unvollständigem Projektkontext arbeitet und ein Team eine lokal plausible Antwort akzeptiert, ohne sie an der Architektur des Systems zu prüfen.

Ein Forschungs-Preprint von 2025, der auf intern entwickelten MVPs und jüngeren Branchenberichten beruht, beschreibt dies als Zielkonflikt zwischen Fluss und Schulden: Reibungslose Codeerzeugung kann mit Architekturinkonsistenzen, Sicherheitslücken und höherem Wartungsaufwand einhergehen. Sein Umfang beweist nicht, dass jedes KI-unterstützte Projekt so scheitert, liefert der Sorge jedoch einen konkreteren Mechanismus. Zum Flow-Debt-Preprint von 2025.

Das deutlichste Opfer dieser lokalen Verzerrung ist eine Grundregel der Software: DRY (Don’t Repeat Yourself).

Chaos und aufgeblähte Bundles im Frontend

Wenn Sie KI bitten, eine neue Seite in einem Frontend-Projekt zu gestalten, entsteht immer wieder dieses Muster:

1. Seite A: Bibliothek X wird hinzugefügt und eine fertige Komponente importiert.
2. Seite B: KI vergisst Bibliothek X und schreibt Hunderte Zeilen Inline-Code von Grund auf für dieselbe Funktion.
3. Seite C: Sie erfindet eine weitere Inline-Funktion mit ganz anderer Logik für dieselbe Aufgabe.

Das Projekt wird mit unnötigen Abhängigkeiten und doppeltem Inline-Code aufgebläht. Das vergrößert direkt das Bundle im Browser der Nutzer und schadet Ladezeit sowie Core Web Vitals (LCP, INP). Bei einem Fehler müssen Sie ihn dann an zehn Stellen suchen und beheben. Verlassen Sie sich nicht darauf, dass eigene Agentenregeln und Systemprompts dies verhindern: Es passiert weiterhin. In der realen Welt lösen wir Fehler leider nicht mit „Sie haben recht, tut mir leid“.

Architektur im Backend umgehen

Dieselbe Disziplinlosigkeit befällt das Backend. Stellen Sie sich eine saubere Route → Handler → Service → Repository-Architektur vor, ähnlich CQRS. Bittet man KI um einen neuen API-Endpunkt, kann sie die Schichten einzeln zu setzen vermeiden und für die schnellste Antwort eine rohe SQL-Abfrage oder einen Datenbankzugriff direkt in die Route schreiben.

Das funktioniert am ersten Tag. Caching-Schichten im Service werden jedoch umgangen, Validierungsregeln übersprungen und Testbarkeit zerstört. Die eine Hälfte des Projekts hält Architektur ein, die andere wird zu Spaghetti-Code mit direkten Datenbankabfragen.

Die Unsichtbarkeit von Clean Code

Gute Engineering-Qualität ist wie Negativraum: Sie wird durch das Fehlen von Problemen bestimmt, nicht durch ihre Anwesenheit.

Niemand bewertet die zusätzliche Zeit für sicheren Code, bis die Datenbank kompromittiert und Nutzerdaten geleakt sind. Oder bis eine von KI geschriebene, nicht optimierte Hintergrundschleife fünf Prozent Akkukapazität pro Stunde verbraucht, während optimierter Code nur ein Prozent benötigt. Der Nutzer bemerkt es nicht unmittelbar, doch die Lebensdauer des Geräts sinkt. Ein Backend kann bei drei Nutzern pro Stunde gut laufen; bei achtzig gleichzeitigen Nutzern braucht es wesentlich mehr, um standzuhalten.

Das spiegelt George Akerlofs Theorie des „Market for Lemons“ (Informationsasymmetrie). Weil Käufer – Management oder Endnutzer – die interne Codequalität von außen nicht prüfen können, füllt sich der Markt rasch mit billig erzeugten „Zitronen“ und gute Engineering-Arbeit bleibt unsichtbar.

Wenn der Markt vom Lärm schneller, aber schlampiger KI-Produkte gefüllt wird, wird diese unsichtbare Qualität wirtschaftlich bestraft. Der Aufwand von Engineers für sauberen, sicheren und leistungsfähigen Code wird von Aussagen wie „Das haben wir mit KI in zehn Minuten gemacht“ übertönt – bis der erste große Sicherheitsvorfall oder die erste Skalierungskrise eintritt.

Das Problem des „vorherigen Vibe Coders“

In der Branche ist es ein Running Gag, dass ein Entwickler beim Blick in eine Codebasis sofort sagt: „Der Entwickler vor mir hat alles zu Spaghetti gemacht.“ Nun kommt eine neue Figur hinzu: „der vorherige Vibe Coder“.

Unternehmen können glauben, heute mit KI billig Produkte zu bauen. Ein plausibles Ergebnis ist, dass sie bei einem späteren Feature oder kritischen Fix in einem Sumpf von Technikschulden mit schwachen Standards und wenig erhaltenem menschlichem Verständnis landen.

Dann kann die Sanierung verlangen, dass Senior Engineers den Spaghetti-Haufen gegen hohe Kosten aufräumen und refaktorieren. Das ist eine Projektion, keine allgemeingültige Prognose: Die Kosten der Softwareentwicklung sind möglicherweise nicht verschwunden, sondern mit Zinsen an den „nächsten Entwickler“ verschoben worden.

Was passiert, wenn Modelle besser werden? Die Jevons-Falle

Techno-Optimisten werden einwenden: „Das sind Probleme heutiger Modelle (GPT-5.6, Fable 5). Sobald künftige Modelle perfekt sind, verschwinden diese Fehler.“

Das übersieht zwei grundlegende Tatsachen.

Das Gesetz der Spezifikationsäquivalenz

Ganz gleich, wie intelligent eine KI ist: Der Input, der ihr sagt, was sie tun soll, muss weiterhin von Menschen kommen. Ein hochkomplexes System absolut präzise und ohne logische Lücken zu spezifizieren, verlangt nicht weniger mentale Arbeit als Programmieren. „Schreibe ein Zahlungssystem“ reicht nicht; jede Erstattungsregel, Steuerklasse und Regel zur Betrugserkennung muss definiert sein. Dieser Spezifikationsprozess ist selbst eine neue Form des Programmierens – und weiterhin vollständig anfällig für menschliche Fehler.

Jevons-Paradox und die Erhaltung der Komplexität

Als Kohlemaschinen effizienter wurden, sank der globale Kohleverbrauch nicht; die Zahl kohlebetriebener Maschinen explodierte und der Verbrauch stieg. Wenn KI-Modelle besser und Code günstiger werden, werden wir nicht weniger Code schreiben. Stattdessen wachsen Umfang und Komplexität der Systeme. Wird KI zehnmal intelligenter, bauen wir zehnmal komplexere Systeme. Komplexität bleibt erhalten; sie verschiebt sich nur auf eine höhere Ebene.

Und vor allem hat KI keine reale Verantwortung (skin in the game). Sie bezahlt keine AWS-Rechnung, wenn sie scheitert, steht nicht um drei Uhr morgens wegen eines Datenbank-Locks auf und steht nach einer Sicherheitsverletzung nicht vor Gericht. Verantwortung ist das Einzige, was nicht delegiert werden kann. Engineering bedeutet deshalb nicht nur, Code zu schreiben, sondern Verantwortung für ihn zu tragen.

Fazit

KI zerstört Software Engineering nicht. Im Gegenteil: Sie hebt die Bedeutung von Architekturvision, Disziplin, Sicherheit und Leistung stärker hervor als zuvor.

Wenn denen, die mit KI „schnellen Müll“ erzeugt haben, die Rechnung für Technikschulden präsentiert wird, werden wieder die verantwortungsvollen Engineers gewinnen, die Chaos beherrschen und unsichtbare Qualität schätzen.