Vibe Coding: Warum die Sicherheitswarnungen berechtigt sind – und was sie übersehen

Kaum ein Begriff hat sich in den letzten Jahren so schnell von der Nische zum Massenphänomen entwickelt wie „Vibe Coding" – Software bauen, indem man einer KI in natürlicher Sprache beschreibt, was entstehen soll, statt selbst jede Zeile zu schreiben. Gerade macht eine Studie die Runde, die zeigt, wie riskant das in der Praxis oft ausgeht: Injection-Schwachstellen, offene Datenbanken, hartcodierte Zugangsdaten. Ein Fall aus dem Februar hat das greifbar gemacht – ein per Vibe Coding gebautes soziales Netzwerk verlor durch eine falsch konfigurierte Datenbank anderthalb Millionen API-Schlüssel und 35.000 E-Mail-Adressen.

Wir bauen bei Luftschloss selbst Individualsoftware mit genau diesen Werkzeugen – Claude Code, Codex – und unterrichten Vibe Coding sogar in unseren Seminaren. Die Kritik trotzdem ernst zu nehmen, statt sie wegzuwischen, halte ich für den einzig ehrlichen Umgang damit.

Was an der Kritik stimmt

Die Zahlen sind eindeutig: Injection-Angriffe sind die mit Abstand häufigste Schwachstellenkategorie in untersuchten vibe-gecodeten Projekten, gefolgt von Path-Traversal-Lücken, Authentifizierungsfehlern und im Code hinterlegten Zugangsdaten. Das sind keine exotischen Angriffsvektoren, sondern die Klassiker der Webentwicklung – Fehler, die seit zwanzig Jahren bekannt sind und trotzdem entstehen, wenn niemand gezielt danach sucht. Ein Sprachmodell schreibt im Zweifel Code, der funktioniert, nicht zwangsläufig Code, der sicher ist. Diese beiden Ziele fallen nur zusammen, wenn jemand explizit auf das zweite achtet.

Bemerkenswert an der aktuellen Studie ist die Verteilung: Es gibt keine gleichmäßige Mittelmäßigkeit, sondern zwei Lager. Ein großer Teil der Projekte liegt im kritischen Bereich, eine kleine Gruppe erreicht ein sehr hohes Sicherheitsniveau. Genau diese Polarisierung ist der eigentlich interessante Befund – nicht der Durchschnitt, sondern der Abstand zwischen den beiden Gruppen.

Warum mich das an die 95-Prozent-Debatte erinnert

Diese Polarisierung kenne ich aus einem anderen Zusammenhang: Warum die meisten KI-Projekte in Unternehmen keinen Ertrag bringen. Auch dort trennt nicht das Modell die erfolgreichen von den gescheiterten Projekten, sondern Prozessdisziplin, Integration und Verantwortung. Bei Vibe Coding ist das Muster identisch, nur auf Code statt auf Geschäftsprozesse angewendet: Wer ein Sprachmodell Code schreiben lässt und das Ergebnis ungeprüft deployt, bekommt irgendwann eine offene Datenbank. Wer denselben Prozess mit Review, Standards und klaren Grenzen umgibt, bekommt etwas anderes.

Was das für unsere eigene Praxis bedeutet

Genau deshalb haben wir für unsere internen Tools nie auf Standards verzichtet, nur weil die Entwicklung schneller geworden ist. In unserem zentralen Tool-Index wird jedes Werkzeug gleich deployt, dokumentiert und sichtbar gemacht – auch wenn es in einem Nachmittag mit KI-Unterstützung entstanden ist. Diese Disziplin ist kein Widerspruch zur Geschwindigkeit von Vibe Coding, sondern deren Voraussetzung. Der Fehler, den die gescheiterten 46 Prozent der untersuchten Projekte vermutlich gemacht haben, ist nicht, KI zum Programmieren genutzt zu haben – es ist, den Teil der Softwareentwicklung wegzulassen, der nie an ein Modell delegierbar war: Verantwortung für das, was live geht.

Dasselbe Prinzip gilt für die Frage, wann sich Individualsoftware überhaupt lohnt, die ich an anderer Stelle beschrieben habe: KI schreibt Code, sie übernimmt aber nicht die Entscheidung, was die Software bewusst nicht können soll – und genau diese Entscheidung schließt Sicherheitslücken, bevor sie entstehen, statt sie hinterher zu patchen.

Die Marktreaktion, die zu weit geht

Die Sorge, Vibe Coding untergrabe grundsätzlich das SaaS-Geschäftsmodell, weil jeder sich seine Software jetzt selbst baut, halte ich für verfrüht. Was tatsächlich passiert, ist eine Verschiebung: Standardsoftware für standardisierte Prozesse bleibt sinnvoll, aber die Schwelle für maßgeschneiderte Lösungen ist gesunken. Das ändert, wer Software baut – nicht, dass Sicherheit, Wartung und Betrieb plötzlich überflüssig würden. Die Unternehmen, die aus dieser Verschiebung Kapital schlagen, werden vermutlich nicht die sein, die am schnellsten bauen, sondern die, die am zuverlässigsten betreiben.

Fazit

Die Sicherheitswarnungen zu Vibe Coding sind berechtigt, und die Zahlen dahinter sind kein Grund, sie zu relativieren. Was sie übersehen, ist die Schlussfolgerung, die viele Schlagzeilen daraus ziehen: dass das Problem in der Technologie liegt. Es liegt, wie fast immer bei KI-gestützter Arbeit, in der Disziplin drumherum – und die lässt sich aufbauen, unabhängig davon, wie schnell der Code selbst entsteht.