2026: Eine KI-Odyssee — Der Vibe-Coding-Kater von 2025

2025 wurde „Vibe Coding“ zu einem echten Workflow – zum Besseren oder zum Schlechteren: Die Idee war, dass ich der KI beschreibe, was ich haben möchte, akzeptiere, was das Modell mir liefert, ihm dann die Fehlermeldungen zurückmelde – und das immer wieder von vorn. Der Code „funktionierte“ irgendwann, aber oft hatte ich ihn tatsächlich weder gelesen noch verstanden (besonders, wenn er in einer mir unbekannten Sprache geschrieben war).

Der Begriff „Vibe Coding“ wurde von Andrej Karpathy in einem viralen Beitrag geprägt, in dem er einen Modus beschrieb, bei dem man „vergisst, dass der Code überhaupt existiert“. Simon Willison lieferte später die klarste Definition, die Entwicklerteams für Richtlinien und Code-Reviews verwenden können: Vibe Coding bedeutet, „Code mit KI zu generieren, ohne sich um den produzierten Code zu kümmern“.

Diese Haltung kann für Prototypen und Einweg-Tools vollkommen rational sein. Gemeint sind kleine Black-Box-Module, die einfache Aufgaben erledigen und dabei offenbar korrekt funktionieren – das klassische „Es reicht mir, dass es diese eine Sache für mich erledigt“, das für Maker und Hobbyisten völlig ausreicht.

Das böse Erwachen kommt, wenn aus diesen „Wegwerf“-Artefakten Abhängigkeiten, Umsatzmerkmale oder eingebettete Firmware werden, die über Jahre gepflegt, geprüft und abgesichert werden müssen. Wenn 2025 das Jahr war, in dem alle schneller auslieferten, ist 2026 das Jahr, in dem viele Teams entdecken, was sie tatsächlich ausgeliefert haben.
 

Was mit „Vibe Coding“ gemeint ist (und was nicht)

Viele Entwickler nutzten KI im Jahr 2025, ohne Vibe Coding zu betreiben: zum Generieren von Boilerplate-Code, beim Erstellen von Tests, zum Erklären unbekannter APIs oder für den ersten Entwurf, der dennoch einem normalen Review unterzogen wurde. Das ist einfach KI-gestützte Entwicklung.

Vibe Coding ist der Modus „Niemand ist für das Innenleben verantwortlich“. Ab hier geht es nicht mehr um das Tool, sondern um die Grundhaltung: Behandeln wir KI-Ergebnisse als nicht vertrauenswürdigen Code, der wie jeder externe Beitrag eine Überprüfung, Tests und Sicherheitsprüfungen bestehen muss? Oder nutzen wir sie als Abkürzung, um genau diese Anforderungen zu umgehen?

In der Praxis gelangen Teams durch kleine, nachvollziehbare Schritte ins Vibe Coding: ein schnelles Skript hier, eine Glue-Schicht dort, eine „temporäre“ Automatisierung, ein generiertes Migrationsskript, ein generierter CI-Workflow, ein generiertes Terraform-Modul. Jede einzelne Komponente wirkt plausibel. Das Ergebnis auf Systemebene ist jedoch eine Codebasis mit mehr Oberfläche, mehr Abhängigkeiten und weniger Menschen, die wirklich verstehen, warum sie funktioniert.

Die Geschwindigkeit ist gestiegen, die Stabilität nicht

Die wohl ernüchterndste offizielle Erkenntnis liefert eine von DORA durchgeführte Untersuchung zur Einführung generativer KI. Im DORA-Report 2024 berichtete Google, dass mit zunehmender KI-Nutzung eine geschätzte Reduktion der Auslieferungsstabilität um 7,2 % und eine Reduktion des Durchsatzes um 1,5 % einherging.

DORAs Bericht 2025 interpretierte diese Zahlen als geschätzte Veränderung pro 25 % KI-Anteil und betonte die Lücke zwischen dem Geschwindigkeitsempfinden der Entwickler und dem, was die Performance tatsächlich widerspiegelt.

Dieses Muster passt exakt zu dem, worauf Vibe Coding abzielt: lokale Geschwindigkeit (etwas schnell zum Laufen bringen) statt globaler Zuverlässigkeit (ein System im Wandel stabil halten). KI macht Änderungen billiger, und das führt zu größeren Diffs und häufigeren Änderungen. Wenn Ihr Release-Management ohnehin schon nicht sauber ist, werden die Konsequenzen durch KI noch verschlimmert.

Es gibt auch eine zweite, weniger angenehme Möglichkeit: Manchmal spart KI erfahrenen Entwicklern in vertrauten Codebasen keine Zeit, selbst wenn es sich so anfühlt. Eine randomisierte kontrollierte Studie von METR fand heraus, dass erfahrene Open-Source-Entwickler mit frühen KI-Tools von 2025 etwa 19 % länger brauchten als ohne, obwohl sie glaubten, schneller zu sein. Das Fazit daraus ist nicht „KI ist schlecht“, sondern: „Ihr Bauchgefühl ist kein Messinstrument.“ Reduziert ein Workflow das Verständnis oder erhöht den Prüfaufwand, kann die Geschwindigkeitsbilanz kippen.

Qualitätsprobleme, die im Demo-Betrieb verborgen bleiben

Vibe-Code besteht oft oberflächliche Tests, weil er auf Plausibilität optimiert ist („so plausibel, dass ich es kaum glauben kann!“). Später scheitert er oft auf teure, schwer zu diagnostizierende Weise:

• Überanpassung: Fragiler Code, der ausschließlich von den heutigen Eingaben, APIs oder HTML-Strukturen ausgeht, ohne Verträge oder Versionsverwaltung.
• Versteckte Komplexität: Kleine „One-File“-Skripte, die nach und nach Retry-Logik, Caching, Parallelität und Fehlerbehandlung ansammeln, bis sie zu vollständigen Systemen werden.
• Unbemerkte Performance-Probleme: N+1-Abfragen, quadratische Schleifen, ungebremste Warteschlangen, eager loading oder „einfach Caching hinzufügen“-Muster, die eigentliche Ursachen verdecken.
• Konfigurationsfallen: CI/CD-Workflows, Cloud-IAM-Regeln, Kubernetes-Manifeste und Terraform-Module, die „funktionieren“, aber gefährliche Defaults enthalten.
• Test-Theater: Generierte Tests, die das aktuelle Verhalten statt des beabsichtigten prüfen oder die das eigentliche Risiko einfach ausblenden.

Der durchgehende Knackpunkt ist fehlende Intention. Von Menschen geschriebene Systeme enthalten meist irgendeine Spur des „Warum“. Vibe-Code enthält oft nur das „Was“: Er macht jetzt das, also prüfen die Tests, ob es das jetzt macht.

Sicherheit: „Es kompiliert“ ist keine Sicherheitseigenschaft

Vibe-Code ist meist optimiert für „funktioniert auf meinem Rechner“ statt für „ist unter widrigen Bedingungen sicher“. Dieser Unterschied ist nicht theoretisch. Eine empirische Studie zu KI-generierten Code-Snippets fand eine „hohe Wahrscheinlichkeit von Sicherheitslücken“, darunter viele Python- und JavaScript-Beispiele mit Common-Weakness-Enumeration-relevanten Problemen in realen GitHub-Projekten.

Solche Studien sind kein Urteil über einzelne Tools; statische Analysen haben False Positives, und „gefundene Schwachstelle“ bedeutet nicht immer „in Ihrem Kontext ausnutzbar“. Aber die Richtung ist klar: Plausibler Code ist nicht unbedingt sicherer Code, und Sicherheit ist genau die Art von nicht-funktionaler Anforderung, die beim Vibe Coding ignoriert wird.
 

Die Sicherheitsrisiken, die in KI-lastigen Codebasen am häufigsten auftreten, sind auch die altbekannten Klassiker:

• Injection und unsichere Konstruktion: SQL-Injection, Command-Injection, unsichere Deserialisierung, Template-Probleme und schwache Eingabevalidierung.
• Geheimnis-Leakage: Schlüssel in „temporären“ Skripten, Tokens in Logs und Debug-Endpunkte, die bis in die Produktion gelangen.
• Auth- und Session-Fehler: DIY-Authentifizierungs-Logik, fehlende Autorisierungsprüfungen und Missverständnisse über Identitätsgrenzen zwischen Diensten.
• Krypto-Fallen: „Do-It-Yourself“-Zufallszahlen, falsche Modi, falsche Schlüsselverwaltung und unsichere Defaults, die dennoch Tests bestehen.

Vibe Coding ist nicht einzigartig unsicher; es ist auf sehr spezifische Weise unsicher: Es macht es leicht, viel Code zu produzieren, ohne das Verständnis, das man bräuchte, um die Sicherheitsannahmen zu erkennen, die Sie unbewusst getroffen haben.

Lieferketten-Risiko: Paket-Halluzinationen und „Dependency-förmige“ Angriffe

Sobald Sie KI-Ergebnisse übernehmen, ohne sie zu lesen, wird die Abhängigkeitskette zur primären Angriffsfläche. Eines der Risiken ist „Package Hallucination“: Das Modell schlägt eine Abhängigkeit vor, die es gar nicht gibt. Ein Angreifer kann ein Paket unter diesem Namen veröffentlichen und warten, bis es jemand installiert. USENIX hat das Phänomen analysiert und als Variante des Package-Confusion-Risikos in der Software-Lieferkette beschrieben.

Der Kernpunkt ist hier: KI macht „Probieren Sie diese Bibliothek“ zum Standardvorschlag. Im Vibe-Coding-Modus fühlt sich das Hinzufügen von Abhängigkeiten günstiger an, als den eigenen Code zu verstehen. Das erhöht:

• die Zahl der transitiven Abhängigkeiten, denen Sie implizit vertrauen,
• die Geschwindigkeit, mit der unbekannte Pakete in Ihren Build gelangen, und
• die Schwierigkeit, beim nächsten Vorfall die Lieferkette zu prüfen und zu patchen.

Im Embedded- und Industrieumfeld werden Fehler unverzeihlich

Websoftware kann oft „sanft“ versagen, d. h., sie stolpert, ohne sofort physischen Schaden oder dauerhafte Folgen zu verursachen: Ein Endpoint liefert 500er, eine Funktion wird vorübergehend abgeschaltet, Traffic wird umgeleitet, ein Rollback läuft, Nutzer versuchen es später erneut. Bei Embedded-Systemen hingegen können Fehler direkt zu Einsatzdefekten, Timing-Bugs, Sicherheitsvorfällen oder dauerhaften Schäden führen. Vibe-Code-Firmware ist insbesondere anfällig für:

• Gutgläubigkeit bzgl. Hardwaredetails: Register-Namen, Bitfelder, Timing-Werte und „magische Zahlen“, die plausibel, aber falsch sind.
• Nebenläufigkeits- und Interrupt-Probleme: Race Conditions rund um ISRs, DMA, RTOS-Primitiven und gemeinsam genutzte Puffer, die erst unter Last auftreten.
• HAL-Fehlanwendung: Kombination von Hersteller-HAL-Aufrufen mit direkten Registerzugriffen, was Annahmen verletzt (und nicht reproduzierbare Bugs erzeugt).
• Protokoll-Randfälle: I²C/SPI/UART-Treiber, die Smoke-Tests bestehen, aber bei Clock Stretching, Störungen, Bus-Kollisionen oder längeren Kabeln scheitern.
• Watchdog- und Recovery-Lücken: Code, der „im Labor funktioniert“, aber kein robustes Brownout-Handling, Safe-Boot oder Recovery-Pfade besitzt.

Das ist alles nicht neu. Was sich mit Vibe Coding ändert, ist, wie leicht kaum verstandener Code in die Codebasis gelangt und wie lange er überlebt, solange er „meistens funktioniert“.

Der menschliche Faktor: Misstrauen, Übervertrauen und Skill-Schulden

Selbst auf dem Höhepunkt des Hypes vertrauten Entwickler KI-Ergebnissen nicht uneingeschränkt. Die Stack-Overflow-Umfrage 2025 zeigte unter anderem, dass mehr Entwickler der KI-Genauigkeit misstrauten als ihr vertrauten, und nur ein kleiner Teil hatte „hohes“ Vertrauen.

Die Falle: Wenig Vertrauen führt nicht automatisch zu sorgfältiger Überprüfung. In der Praxis entsteht daraus oft „so lange weiter prompten, bis die Tests durchlaufen“ – das kann zu Cargo-Cult-Verifizierung führen, besonders wenn Tests dünn sind, ganz fehlen oder ausschließlich vom aktuellen Verhalten abgeleitet sind.

Die langfristigen Kosten reichen von technischen Schulden bis zu Skill-Schulden. Wenn Code zu etwas wird, das man steuert statt schreibt, bleiben weniger Personen, die an der Hardware debuggen, Randfälle durchdenken, Systeme vereinfachen und die „langweilige“ Arbeit für stabile Schnittstellen machen können. Das fällt erst auf, wenn das System außerhalb des abgedeckten Realitätsausschnitts versagt.

Governance holt auf: Behandeln Sie KI wie einen nicht vertrauenswürdigen Programmierer

Die praktische Antwort, die sich im Übergang von 2025 zu 2026 durchsetzt, lautet „Policy + Pipeline“, nicht „Tool verbieten“. Das SSDF-Community-Profil von NIST für generative KI ist eindeutig: Es geht davon aus, dass sämtlicher Quellcode vor der Nutzung auf Schwachstellen und andere Probleme geprüft werden muss – unabhängig davon, ob er von Menschen oder KI geschrieben wurde.

Nur diese Haltung ist skalierbar. Die Frage ist nicht „Hat eine KI das geschrieben?“, sondern: „Würden wir das von einem externen Programmierer akzeptieren?“

Das minimale Sicherheitsnetz für KI-lastige Teams

Wenn Sie die Geschwindigkeitsvorteile von KI ohne Vibe-Coding-Kater nutzen wollen, brauchen Sie ein festes Fundament. Die genauen Tools variieren, aber die Prinzipien bleiben stabil:

Halten Sie die Diffs klein. KI macht es leicht, große Änderungen auszuliefern. Das wird durch geringere Zuverlässigkeit bestraft. Nutzen Sie Pull-Request-Größenlimits, gestufte Rollouts und Feature Flags.

Fordern Sie aussagekräftige Tests. Unit-Tests reichen nicht, wenn Schnittstellen die Fehlerquellen sind. Ergänzen Sie Vertragstests, Fuzzing (wo relevant) und Regressionstests, die mit Vorfällen verknüpft sind.

Aktivieren Sie blockierende Scanner. Statische Analyse, Secret Scanning, Abhängigkeits- und Container/IaC-Scans sollten standardmäßig laufen, und „Warn-only“ sollte nur temporär genutzt werden.

Sperren Sie Abhängigkeiten und verfolgen Sie deren Herkunft. Nutzen Sie Lockfiles, festgelegte Versionen, reproduzierbare Builds, SBOMs und signierte Artefakte. „Installiere einfach das vorgeschlagene Paket“ ist kein Workflow.

Machen Sie Reviews zum Thema Intention, nicht Syntax. Fordern Sie eine kurze Design-Notiz oder PR-Beschreibung, die Zweck, Risiken und Tests der Änderung erklärt.

Instrumentieren Sie die Produktion. KI verschiebt den Aufwand vom Coden zum Debugging. Beobachtbarkeit ist Pflicht: Logs, Metriken, Tracing und explizite SLOs sorgen für Tempo ohne Chaos.

Das alles ist nicht neu. Der Punkt ist: KI erhöht den Druck auf diese Grundlagen, weil sie die Grenzkosten für Änderungen senkt.

Recht und Compliance: Herkunftsfragen bleiben

Vibe Coding kollidiert auch mit Compliance, weil es die Herkunft verschleiert: Welche Daten haben das Ergebnis beeinflusst, welche Lizenzbedingungen gelten, und wer ist für das Ausgelieferte verantwortlich? Die Regulierungsbehörden werden aktiv, wenn auch unterschiedlich schnell. Die Europäische Kommission veröffentlichte am 10. Juli 2025 einen „General-Purpose AI Code of Practice“ als freiwilliges Instrument, um Anbietern die Einhaltung der allgemeinen KI-Pflichten gemäß KI-Verordnung ab 2. August 2025 zu erleichterna>.

Im Vereinigten Königreich wurde das Thema Urheberrecht und KI-Training explizit als aktuelles Politikum adressiert; die Konsultation lief vom 17. Dezember 2024 bis 25. Februar 2025.

Die praktische Konsequenz für die Technik: Wenn Ihre Organisation Lizenz- oder Compliance-Anforderungen hat, umgeht KI-generierter Code diese nicht auf magische Weise. Behandeln Sie Herkunft als Betriebsanforderung – und nicht als philosophische Debatte, die aufgeschoben werden kann, bis die Rechtsabteilung anklopft.

Die eigentliche Lektion von 2025

2025 hat es günstiger gemacht, Software zu erstellen. Das Eigentum an Software wurde jedoch nicht billiger.

Teams, die Vibe Coding auf Prototypen beschränkten, wurden schneller. Teams, bei denen es in die Produktion gelangte, kauften sich einen dreiteiligen Kater ein:

• Mehr Instabilität, weil die Änderungsgeschwindigkeit die Disziplin beim Ausliefern überholt hata>.
• Mehr Sicherheitsrisiko, weil plausibler Code nicht sicherer Code ist und Fehler bei Abhängigkeiten sich im großen Maßstab leichter einschleichena>.
• Mehr Unklarheit bei der Verantwortlichkeit, weil Fragen zu Herkunft, Review und Lizenzen später auftauchen – meist, wenn es um Geld geht.

Natürlich spricht all das nicht dafür, KI-Tools grundsätzlich zu meiden. Es spricht für die langweilige, aber richtige Haltung: KI beschleunigt die Entwicklung, ersetzt sie aber nicht.

Fragen oder Kommentare?

Wenn Sie Fragen oder Kommentare haben, freue ich mich über Ihre Erfahrungen. Schreiben Sie mir an brian.williams@elektor.com oder besuchen Sie mich auf X unter @briantw.

Anmerkung der Redaktion: Dieser Artikel (230181-R-01) erscheint in Elektor März/April 2026.