Das Wichtigste in Kürze
- Nur die nächste Abstraktionsstufe: Vibe Coding ist keine Revolution, sondern die nächste Stufe nach Lochkarten, Assembler und COBOL. Jede Generation fürchtete den Kontrollverlust.
- Die KI füllt Lücken mit Annahmen: Wer ohne klare Anforderungen und Architektur startet, bekommt Code, der auf Vermutungen der KI basiert statt auf seinen Zielen.
- Funktionierend heißt nicht sicher: Größere Modelle liefern mehr Features, aber oft schlechtere Sicherheit, weil auch schlechter Code in den Trainingsdaten steckt.
- BMAD bringt Struktur: Die BMAD-Methode führt mit Agenten durch Anforderungen, Architektur, Entwicklung und Prüfung und liefert aus jeder Phase ein sauberes Dokument.
- Snyk prüft vor jedem Release: Die Security-Plattform checkt eigenen und KI-generierten Code auf bekannte Schwachstellen, bevor etwas auf Produktion geht.
- OWASP und NIS 2 als Maßstab: Die OWASP Top 10 benennen die größten Sicherheitsrisiken, NIS 2 macht Cyber-Sicherheit auch für kleinere Firmen zur Pflicht.
Einführung
Vibe Coding klingt verlockend: Sie beschreiben in Alltagssprache, was eine Software tun soll, und die KI schreibt den Code. Das funktioniert tatsächlich, und zwar in einem Tempo, das vor zwei Jahren undenkbar war. Ich habe auf diese Weise an Ostern mein eigenes CRM-System in einer Woche als erste MVP-Version aufgesetzt. Aber genau dieses Tempo ist auch die Gefahr. Denn wer nur an Features denkt, denkt selten an Sicherheit.
In dieser Episode ordne ich das Thema für Sie als Entscheiderin oder Entscheider ein. Sie erfahren, warum Vibe Coding nur die nächste Abstraktionsstufe in der Softwareentwicklung ist, wo die typischen Probleme liegen und mit welchen vier Ebenen ich meine eigenen Projekte absichere: der BMAD-Methode als Entwicklungsframework, Snyk als Prüfplattform, den OWASP Top 10 als Maßstab und NIS 2 als gesetzlichem Rahmen. Als Einstieg empfehle ich zudem ein lesenswertes Fachbuch, das den Weg vom Vibe Coding zum Agentic Engineering beschreibt und deutlich mehr Tiefe bietet als die üblichen Social-Media-Beiträge.
Vibe Coding ist nur die nächste Abstraktionsstufe
Mein Vater war früher bei Braun im Management in Kronberg, und als Kind durfte ich am Wochenende mit in die Firma. Dort gab es Lochkarten, auf denen ich malen durfte. Das war die erste Ebene der Programmierung: Relais, Nullen und Einsen. Übrigens stammt daher auch der Begriff Bug-Fixing. Der erste dokumentierte Bug war eine Motte, die eine Programmiererin in einem Relais fand. Früher waren Fehler also physische Teile, die in Relais hängen blieben.
Dann kam Assembler, und ich habe als Kind auf dem C64 damit programmiert. Prompt sagten die Hardcore-Entwickler: Wir verlieren die Kontrolle, wir wissen doch gar nicht, was so ein Assembler macht. Als ich 1988 bei Nixdorf meine IT-Laufbahn begann und COBOL und Fortran lernte, hieß es wieder: Teufelszeug, wir verlieren die Kontrolle. Jedes Mal waren es diejenigen, die in der alten Technologie zu Hause waren, die den Kontrollverlust beschworen.
Heißt das, die Sorge ist unbegründet? Ganz im Gegenteil. Wir müssen das Thema Kontrolle sehr ernst nehmen. Genau deshalb schaue ich mir in dieser Episode eine Methode aus der klassischen Softwareentwicklung an, mit der ich in meinen Vibe-Coding-Projekten vorgehe: die BMAD-Methode.
Ohne klare Anforderungen füllt die KI die Lücken selbst
Geprägt hat den Begriff Vibe Coding ein Softwareentwickler, der beschrieb, wie er in positiver Stimmung, eben im Vibe, einfach Wünsche formulierte und die KI den Code generierte. Das Prinzip: ausprobieren, bei Fehlern erneut nachfragen. Professionelle Softwareentwickler bekommen an dieser Stelle verständlicherweise Pickel. Denn wenn Anwender Software bauen, denken sie an Funktionen und vielleicht noch an die Benutzeroberfläche, aber mit Sicherheit nicht an die Sicherheit.
Das erste große Problem ist die unstrukturierte Vorgehensweise. Ohne klare Anforderungen füllt die KI die Lücken mit eigenen Annahmen. Ohne saubere Architektur fehlt das Fundament: Was ist eine Datenbank, welche Möglichkeiten gibt es, wo wird gehostet? Dazu kommt das Thema Kontextverlust. Wer lange in Claude Code arbeitet, erlebt irgendwann, dass das System den Zusammenhang vergisst. Im schlimmsten Fall benennt es Variablen, die oben definiert wurden, plötzlich anders.
Und schließlich wird viel zu selten wirklich geprüft. Genau diese Kombination aus fehlender Struktur und fehlender Prüfung macht naives Vibe Coding riskant.
Funktionierender Code ist noch kein sicherer Code
Das zweite große Problem ist die Sicherheit selbst. Studien zeigen, dass größere Modelle nicht automatisch sichereren Code liefern, im Gegenteil: Sie haben auch mehr schlechten Code in den Trainingsdaten. Die Modelle werden auf Features optimiert, nicht auf Security. Deshalb ist das größte Modell nicht immer die beste Wahl. Ein kleineres Modell kann sicherheitstechnisch sogar besser abschneiden.
Dazu kommen die Klassiker: veraltete oder manipulierte Bibliotheken, Passwörter und Schlüssel im Quellcode. Wer seine Zugangsdaten direkt in den Code schreibt, bekommt zwar meist den Hinweis, dass diese damit verbrannt sind und in Umgebungsvariablen gehören. Vielen ist der Weg über das Terminal aber zu umständlich, und sie machen es trotzdem. Fehlende Zugriffskontrollen runden das Bild ab.
Die Zielsetzung ist deshalb klar: das Tempo der KI nutzen, aber mit der Disziplin professioneller Softwareentwicklung. Software muss nachvollziehbar und dokumentiert sein, Schwachstellen müssen früh erkannt werden, und das Ergebnis muss langfristig wartbar bleiben. Eine Blackbox ist nicht wartbar.
Die BMAD-Methode bringt Struktur in jedes KI-Projekt
Es gibt mehrere Ansätze, die Struktur in Vibe-Coding-Projekte bringen. Da ist zum einen ein Framework mit dem bezeichnenden Namen GSD, Getting Shit Done. Es gibt das Spec Kit, das von GitHub kommt. Der Ansatz, den ich im Regelfall favorisiere, weil er für die Zusammenarbeit mit Unternehmen am praktikabelsten ist, ist die BMAD-Methode. Der Name geht auf den Spitznamen des Gründers zurück.
Die Grundidee: ein sauberer, strukturierter Prozess. Erst wird geklärt, was entstehen soll, dann werden die Anforderungen geplant, gebaut und geprüft, und über Lernen und Anpassen läuft das Ganze in einen Dauerzyklus. Dabei gibt es eine wichtige Unterscheidung: Im Quick-Mode kann ich direkt bauen und prüfen. Wenn ich nur einen Button in Rot statt in Grün haben will, brauche ich nicht alle Phasen. Geht es aber um Login-Prozesse oder Berechtigungen, laufe ich jede Phase komplett durch.
Das Ergebnis ist ein sauberes Dokument aus jeder Phase: ein Product Brief mit Idee und Nutzen, ein Anforderungsdokument im Detail, ein Dokument für Benutzeroberfläche und Architektur. Gearbeitet wird mit Tickets, und am Ende steht geprüfter, getesteter und reviewter Code.
Agenten übernehmen die Rollen eines Entwicklungsteams
Umgesetzt wird die BMAD-Methode mit Agenten. Je nach Variante des Frameworks arbeiten fünf oder sechs davon zusammen, einige Varianten haben einen eigenen Dokumentationsagenten. Die Analystin Mary führt die User-Interviews, macht Brainstorming und erstellt den Product Brief. Danach dokumentiert John die Features sauber aus. Es folgt der Architekt, und zwar vor der Entwicklerin und der UX-Designerin.
Die Reihenfolge lässt sich auch mischen, es gibt sogar einen Party-Mode, in dem ich mit mehreren Agenten gleichzeitig diskutieren kann. Die Folien zu dieser Episode habe ich übrigens genau so erstellt: generiert mit Claude und im Gespräch mit diesen Agenten. Die saubere Reihenfolge bleibt aber: Anforderungen klären, Features definieren, Architektur festlegen, entwickeln, Benutzeroberfläche gestalten und dokumentieren.
Das Ganze lässt sich in Claude Code integrieren. Es gibt dafür ein öffentliches GitHub-Repository, das ich gern in die Links zur Episode packe.
Snyk prüft jeden Release, bevor er produktiv geht
In der BMAD-Methode ist Security by Design bereits angelegt. Ich bin aber ein großer Freund davon, das Setup noch einmal zu härten. Der erste Baustein dafür ist Snyk, eine weltweit führende Security-Plattform. Sie prüft eigenen wie KI-generierten Code auf bekannte Schwachstellen. Dabei kann ich mir im manuellen Modus Korrekturen vorschlagen lassen oder die Prüfung fest in meinen Ablauf integrieren.
In Vibe-Coding-Projekten installiere ich Snyk, bevor der erste Release produktiv auf GitHub gepusht wird. Snyk hängt dann vor dem Commit eines Releases: Bevor etwas auf Produktion geht, wird es geprüft, und es geht nur raus, wenn es sauber ist. Getestet werden eigener Code, Open-Source-Bibliotheken, Container und Cloud-Konfigurationen. Die Plattform lässt sich webbasiert nutzen oder über einen eigenen MCP-Server direkt in Claude Code einbinden, was ich empfehle.
Sehr empfehlenswert ist auch die eigene Schulungsplattform Snyk Learn. Dort gibt es kostenfreie Trainings, mit denen Sie wirklich verstehen, was das Werkzeug tut, und zu denen Sie auch per KI Fragen stellen können.
Die OWASP Top 10 sind der Maßstab für sichere Webanwendungen
Der zweite Baustein sind die OWASP Top 10. Dahinter steht die OWASP Foundation, die als weltweiter Standard regelmäßig die zehn größten Sicherheitsrisiken veröffentlicht. Die aktuelle Ausgabe ist die Top 10 von 2025. Dort finden Sie zu jedem Risiko, etwa Broken Access Control, eine Beschreibung des Problems. Es lohnt sich, diese Liste einmal in Ruhe durchzugehen, auch als Entscheiderin oder Entscheider.
Snyk hat die OWASP-Themen bereits ein Stück weit integriert und erklärt sie auf der eigenen Learn-Plattform. Ich habe die OWASP Top 10 trotzdem zusätzlich über ein GitHub-Repository in meine Projekte eingebunden. Denn fast alle KI-Anwendungen sind am Ende webbasierte Applikationen, und genau dafür ist dieser Maßstab gemacht.
NIS 2 macht Cyber-Sicherheit auch für kleinere Firmen zur Pflicht
Der dritte Baustein ist die EU-Richtlinie NIS 2, die Cyber-Sicherheit auch für kleine und mittlere Unternehmen zur Pflicht macht. Auf GitHub gibt es dafür ein sehr schönes NIS-2-Toolkit für kleinere Firmen. Dieses Package integriere ich ebenfalls in Claude: Bevor ein Release rausgeht, wird auch auf NIS 2 geprüft, mit Gap-Analyse, Executive Briefing zu Pflichten, Fristen und Sanktionen, Meldefristen bei Cyber-Security-Vorfällen und Sicherheitsrichtlinien.
Zusammengefasst spielen damit vier Ebenen der Absicherung zusammen: NIS 2 mit den gesetzlichen Pflichten inklusive sicherer Entwicklung und Meldepflichten, BMAD als Entwicklungsframework mit Anforderungen, Architektur und Review vor jeder Auslieferung, die OWASP Top 10 als Maßstab für die wichtigsten Security-Themen und Snyk als Prüfwerkzeug. Natürlich gibt es Überschneidungen. Genau deshalb habe ich Claude Code beauftragt, diese vier Quellen sinnvoll zu kombinieren und daraus eigene Skills zu bauen, nach denen jedes Coding-Projekt abläuft.
Fazit
Was Sie als Entscheiderin oder Entscheider mitnehmen sollten: Vibe Coding ersetzt nur das Schreiben von Code. Software-Architektur und Qualitätssicherung sind wichtiger denn je, weil KI das Tempo massiv erhöht. Sie können in Wahnsinnsgeschwindigkeit Code generieren, aber der ist nicht immer richtig, und in den Trainingsdaten steckt oft auch schlechter Code. Deshalb müssen Profis darüber schauen. Ich selbst frage nicht nur Claude, sondern auch echte Expertinnen und Experten, wenn ich an meine Grenzen stoße.
KI-generierte Tools plus klassische Architektur- und Security-Prinzipien sind das Erfolgsrezept. Mal eben einen Prompt in ein Werkzeug wie Lovable zu werfen, ist kein Vibe Coding, dazu gehört deutlich mehr. Prüfen Sie Ihr nächstes Projekt gegen die vier Ebenen BMAD, Snyk, OWASP Top 10 und NIS 2. Und wie immer gilt: erst Hirn einschalten, dann Technik.
Erwähnte Tools & Ressourcen
- BMAD-Methode: Entwicklungsframework mit Agenten wie Analystin Mary und Product Manager John, das Vibe-Coding-Projekte durch Anforderungen, Architektur, Entwicklung und Review führt; als GitHub-Repository verfügbar.
- Snyk: Führende Security-Plattform, die eigenen und KI-generierten Code, Bibliotheken, Container und Cloud-Konfigurationen vor jedem Release auf bekannte Schwachstellen prüft; per MCP-Server in Claude Code integrierbar.
- Snyk Learn: Kostenfreie Schulungsplattform von Snyk mit Trainings zu Sicherheitsthemen, inklusive der Möglichkeit, per KI Fragen zu stellen.
- OWASP Top 10: Regelmäßig aktualisierte Liste der zehn größten Sicherheitsrisiken für Webanwendungen von der OWASP Foundation, aktuelle Ausgabe von 2025.
- NIS-2-Toolkit für KMU: GitHub-Package zur EU-Richtlinie NIS 2 mit Gap-Analyse, Executive Briefing, Fristen, Sanktionen und Meldepflichten, das sich in den Release-Prozess integrieren lässt.
- Claude Code: KI-Entwicklungsumgebung von Anthropic, in der sich BMAD, Snyk, OWASP und NIS-2-Checks als Skills kombinieren lassen.
Häufige Fragen (FAQ)
Was ist Vibe Coding?
Vibe Coding bedeutet, Software zu entwickeln, indem man in Alltagssprache beschreibt, was sie tun soll, und die KI den Code schreibt. Man formuliert einen Wunsch, probiert das Ergebnis aus und fragt bei Fehlern erneut nach. Technisch ist das nur die nächste Abstraktionsstufe nach Lochkarten, Assembler und Hochsprachen wie COBOL.
Warum ist KI-generierter Code oft unsicher?
KI-Modelle werden auf Features optimiert, nicht auf Sicherheit, und in ihren Trainingsdaten steckt auch viel schlechter Code. Studien zeigen, dass größere Modelle sicherheitstechnisch sogar schlechter abschneiden können. Dazu kommen typische Fehler wie Passwörter im Quellcode, veraltete Bibliotheken und fehlende Zugriffskontrollen.
Was ist die BMAD-Methode?
Die BMAD-Methode ist ein Entwicklungsframework, das Vibe-Coding-Projekte strukturiert: klären, planen, bauen, prüfen, lernen. Agenten übernehmen die Rollen eines Entwicklungsteams, von der Analystin über den Product Manager bis zum Architekten. Aus jeder Phase entsteht ein sauberes Dokument, von Product Brief bis zu geprüftem Code.
Wofür braucht man Snyk in Vibe-Coding-Projekten?
Snyk prüft Code auf bekannte Schwachstellen, bevor ein Release produktiv geht. Die Plattform testet eigenen und KI-generierten Code, Open-Source-Bibliotheken, Container und Cloud-Konfigurationen. Sinnvoll installiert man Snyk, bevor der erste Release auf GitHub gepusht wird, sodass nur sauberer Code auf Produktion geht.
Was sind die OWASP Top 10?
Die OWASP Top 10 sind ein weltweiter Standard der OWASP Foundation, der regelmäßig die zehn größten Sicherheitsrisiken für Webanwendungen benennt, etwa Broken Access Control. Die aktuelle Ausgabe stammt von 2025. Da die meisten KI-Anwendungen webbasiert sind, ist die Liste ein guter Maßstab für jedes Vibe-Coding-Projekt.
Was bedeutet NIS 2 für kleine und mittlere Unternehmen?
NIS 2 ist eine EU-Richtlinie, die Cyber-Sicherheit auch für viele kleinere und mittlere Unternehmen zur Pflicht macht. Dazu gehören sichere Entwicklung, Sicherheitsrichtlinien und Meldepflichten bei Vorfällen mit klaren Fristen und Sanktionen. Auf GitHub gibt es ein Toolkit, mit dem sich diese Pflichten in den eigenen Release-Prozess integrieren lassen.
