Tobias Gerstenberg Software Engineer @ Railslove
Ich habe nichts gegen Vibe Coding. Ich baue selbst damit. Ein KI-Coding-Agent erzeugt in Sekunden funktionierenden Code, und für einen Prototyp, ein internes Tool oder eine schnelle Idee ist das großartig. Das Problem beginnt nicht beim Bauen. Es beginnt bei der Frage, die danach kommt und die selten jemand stellt: Ist das gut genug, um es zu betreiben?
Denn „es funktioniert“ und „es ist betriebsfähig“ sind zwei völlig verschiedene Aussagen. Genau dazwischen liegt das Risiko. Dieser Artikel zeigt, wo die Vibe Coding Risiken wirklich liegen, warum funktionierender Code trügt, und wie man mit einem strukturierten Audit von einem Bauchgefühl zu einer belastbaren Entscheidung kommt.
Der gefährlichste Satz in einem Produktteam lautet: „Läuft doch.“ Er beschreibt einen Zustand an der Oberfläche und verschweigt alles darunter.
KI-generierter Code ist nicht automatisch wartbar, betreibbar oder sicher. Er kann all das sein, aber er ist es nicht von allein. Der Grund liegt in der Arbeitsweise: KI-Tools erzeugen funktionalen Code in Sekunden und überspringen dabei genau die Denkpausen, in denen ein Entwickler normalerweise strukturelle Fragen stellt. Warum existiert diese Abhängigkeit? Was passiert bei ungültiger Eingabe? Wer räumt das später auf?
Solange nichts geändert werden muss, bleibt das unsichtbar. Die Codebasis wird zum Kartenhaus: Jede neue Funktion erhöht die Fragilität, weil niemand mehr versteht, warum welche Abhängigkeit wo liegt. Sobald die erste echte Änderung ansteht, bricht das System an unerwarteten Stellen. Das ist der Moment, in dem aus gesparter Zeit teure Zeit wird.
Das ist keine Kulturkritik am KI-Code, das ist messbar.
Der GenAI Code Security Report 2025 von Veracode kommt zu dem Ergebnis, dass rund 45 Prozent der von KI generierten Codebeispiele Sicherheitsrisiken einführten, und dass neuere, größere Modelle nicht durchgängig sicherer waren. In etwa 86 Prozent der getesteten Fälle machte der Code die Anwendung für eine verbreitete Angriffsart anfällig, über die sich schädlicher Code einschleusen lässt.
Das Sicherheitsunternehmen Escape.tech hat über 5.600 öffentlich zugängliche Vibe-Coding-Anwendungen untersucht und dabei mehr als 2.000 Schwachstellen, über 400 offen liegende Secrets und 175 Fälle personenbezogener Daten gefunden, darunter Krankenakten und IBANs. Die typischen Muster wiederholen sich: fehlende Eingabevalidierung, hartcodierte Zugangsdaten direkt im Quellcode, veraltete Bibliotheken, die ungeprüft eingebunden werden.
Und der Aufwand verlagert sich nur, er verschwindet nicht. Branchenanalysen zeigen, dass die Wartungskosten von unkontrolliertem KI-generiertem Code bis zum zweiten Jahr auf ein Vielfaches des üblichen Niveaus steigen können. Der Produktivitätsgewinn von heute wird zur Wartungslast von übermorgen.
Damit das nicht als pauschale Ablehnung ankommt: Der entscheidende Faktor ist die Kritikalität der Anwendung.
Für einfache, unkritische Funktionen, für Prototypen und für schnelles Ausprobieren ist Vibe Coding hervorragend. Die Risiken steigen mit Komplexität und Kritikalität. Sobald eine Anwendung Zahlungen verarbeitet, personenbezogene Daten speichert oder von echten Kunden genutzt wird, gelten andere Maßstäbe. Dann braucht es Code, der auf Sicherheit geprüft, für ungewöhnliche Szenarien getestet und so strukturiert ist, dass er sich langfristig warten lässt.
Die ehrliche Faustregel lautet: Vibe Coding eignet sich, um herauszufinden, ob etwas gebaut werden sollte. Es eignet sich schlechter, um das, was gebaut werden soll, dauerhaft zu betreiben. Der Sprung von der validierten Idee zum betriebsfähigen Produkt ist genau der Punkt, an dem professionelles Engineering wieder ins Spiel kommt.
Die Frage, die in fast jedem Projekt zu spät gestellt wird, ist nicht „Funktioniert es?“, sondern „Wer betreibt es?“.
Ein KI-generiertes Tool ist schnell da. Aber wer pflegt es, wenn sich eine Bibliothek ändert? Wer reagiert, wenn es nachts ausfällt? Wer versteht die Architektur, wenn die Person, die es zusammengeprompted hat, das Unternehmen verlässt? Betrieb heißt Hosting, Monitoring, Wartung, Fehlerbehandlung und die Fähigkeit, das System sicher weiterzuentwickeln. Nichts davon entsteht automatisch beim Generieren.
Deshalb ist die wichtigste Frage bei jedem schnell gebauten System nicht, ob es heute läuft, sondern ob man es in zwei Jahren noch verantworten kann. Kann man das betreiben? Kann ich das betreiben? Wer diese Frage nicht beantworten kann, hat kein fertiges Produkt, sondern ein offenes Risiko.
Genau hier setzt an, was wir ein Vibe Code Audit nennen, im Kern eine technische Due Diligence für schnell gebaute Systeme.
Ein Audit urteilt nicht über den Mut, etwas gebaut zu haben. Es beantwortet eine einzige, geschäftsrelevante Frage: weiterbetreiben, weiterentwickeln oder wegwerfen? Dafür schauen wir strukturiert auf die Dimensionen, die über Betriebsfähigkeit entscheiden:
Das Ergebnis ist kein Gefühl, sondern eine belastbare Grundlage für eine Entscheidung, an der auch Nicht-Techniker ihre nächste Investition ausrichten können. Am Ende jeder KI-gestützten Arbeit braucht es weiterhin den Menschen, der die Qualitätssicherung durchführt und das dafür nötige Wissen mitbringt. Das Audit macht dieses Wissen sichtbar und nutzbar.
Ein oft übersehener Teil der Qualitätsfrage ist die Wahl der Werkzeuge. Welche KI-Dienste, welche Bibliotheken, welche Infrastruktur ein System nutzt, ist keine reine Geschmacksfrage, sondern eine Entscheidung über Abhängigkeit.
Ob ein Dienst aus den USA oder aus Europa kommt, wird bei schnell gebauten Systemen oft nicht bewusst entschieden, sondern ergibt sich aus dem Default. Wir halten es für richtig, diese Entscheidung wieder bewusst zu treffen und Tool- und Architekturentscheidungen anhand definierter Kriterien in ein Projekt zu tragen. Nicht dogmatisch, aber transparent: Bequemlichkeit und Tempo auf der einen Seite, Sicherheit und strategische Freiheit auf der anderen.
Vibe Coding ist ein starkes Werkzeug, und der Reflex, es zu verteufeln, ist genauso falsch wie der Reflex, seinem Output blind zu vertrauen. Der Unterschied zwischen einem nützlichen Prototyp und einem teuren Risiko liegt nicht im Werkzeug, sondern im bewussten Umgang damit.
„Gut genug“ ist deshalb keine Eigenschaft, die zufällig entsteht, sondern eine Entscheidung, die man mit Kriterien belegen kann. Wer ein KI-gebautes System betreibt oder betreiben soll, verdient eine klare Antwort auf die Frage, ob es dafür bereit ist. Genau diese Antwort liefert ein Audit.
Ihr habt ein Tool im Einsatz, das niemand mehr so recht wartet, oder überlegt, ein KI-gebautes System produktiv zu nehmen? Lasst es uns prüfen, bevor es euch prüft.
Nicht automatisch. Untersuchungen wie der Veracode GenAI Code Security Report 2025 zeigen, dass ein erheblicher Anteil des KI-generierten Codes Sicherheitsrisiken einführt. Sicher wird er erst durch Review, Tests und menschliche Qualitätssicherung.
Technische Schulden entstehen, wenn KI-generierter Code ohne Prüfung, Refactoring und Struktur übernommen wird. Kurzfristig gewinnt man Tempo, langfristig steigt die Fragilität, bis Änderungen teuer und riskant werden.
Sinnvoll für Prototypen, einfache und unkritische Funktionen. Ungeeignet als alleiniger Ansatz, sobald eine Anwendung kritisch wird, also Zahlungen verarbeitet, personenbezogene Daten speichert oder von echten Kunden genutzt wird.
Eine technische Due Diligence für schnell gebaute Systeme. Es bewertet Sicherheit, Wartbarkeit, Betrieb und Architektur und beantwortet die Frage, ob ein System weiterbetrieben, weiterentwickelt oder ersetzt werden sollte.
Das ist die entscheidende Lücke. Betrieb bedeutet Hosting, Monitoring und Wartung. Wenn niemand diese Verantwortung übernimmt, bleibt ein funktionierendes Tool ein offenes Risiko.
Ihr habt Fragen oder eine konkrete Projektidee?
Meldet euch gerne direkt bei Tobias via LinkedIn oder unter [email protected].
