Die Höhen und Tiefen des Vibe-Codings

Die Vibe-Coding-Revolution hat in wenigen Monaten Milliardenunternehmen hervorgebracht und Millionen Menschen die Softwareentwicklung zugänglich gemacht. Gleichzeitig hat sie kritische Sicherheitslücken und enorme Wartungsprobleme geschaffen, die Projekte über Nacht zunichtemachen können. Dieses Paradox prägt den transformativsten und umstrittensten Entwicklungstrend des Jahres 2025: 25 % der Start-ups im Winter-Batch 2025 von Y Combinator entwickelten Produkte mit Codebasen, die zu mehr als 95 % von KI generiert wurden, während Sicherheitsforscher 170 verwundbare Produktiv-Apps bei einem einzigen Scan am Nachmittag entdeckten. Der Einsatz ist enorm: Lovable erreichte innerhalb von sechs Monaten einen ARR von 50 Mio. $, während Entwickler hilflos zusehen müssen, wie KI-Agenten ganze Datenbanken löschen oder durch falsch konfigurierte Backends Nutzerdaten offenlegen.

Wer mit KI-Unterstützung entwickelt, muss heute sowohl die beispiellosen Chancen als auch die existenziellen Risiken kennen. Ob Vibe-Coding zum Erfolg oder zur Katastrophe führt, hängt oft von einer einzigen Sicherheitskonfiguration ab – oder davon, ob Sie die von der KI generierten Ergebnisse überprüfen.

Die Höhen: Wenn Vibe-Coding Einhörner hervorbringt

Lovables kometenhafter Aufstieg stellt die Start-up-Ökonomie auf den Kopf

Lovable, der KI-App-Builder aus Stockholm, hat geschafft, was Risikokapitalgeber einst für unmöglich hielten: innerhalb von sechs Monaten nach dem Start einen ARR von 50 Mio. $ zu erreichen. Das im November 2023 von Anton Osika und Fabian Hedin gegründete Unternehmen hat 222,5 Mio. $ bei einer Bewertung von 1,8 Mrd. $ eingesammelt und erreichte diesen Meilenstein nur acht Monate nach der Produkteinführung. Die Zahlen für Februar 2025 zeigen ein atemberaubendes Wachstum: über 45.000 zahlende Kunden, wöchentlich 2,5 Mio. $ zusätzlicher ARR und Kundenbindungsraten von über 85 %. Die Plattform erstellt täglich mehr als 25.000 Projekte und hat seit dem Start über 1,2 Millionen Apps ermöglicht. Im März 2025 verzeichnete sie 10,4 Millionen Website-Besuche und lag damit 30 % vor Wettbewerbern wie Replit und Bolt.

Der Erfolg des Unternehmens beruht darauf, Full-Stack-Entwicklung mithilfe natürlichsprachlicher Prompts zugänglich zu machen. Nutzer beschreiben, was sie erstellen möchten, und Lovables Multi-LLM-Orchestrierung (mit Weiterleitung zwischen GPT-4, Claude und Gemini) generiert React-Frontends mit nativen Supabase-Backends, Stripe-Zahlungsfunktionen und GitHub-Integration. Investor Fredrik Cassel von Creandum brachte die kulturelle Wirkung auf den Punkt: „Seit unserer Investition in Spotify habe ich für ein Produkt keine vergleichbare Begeisterung bei den Nutzern erlebt.“

Konkrete Erfolgsgeschichten zeigen das Potenzial der Plattform. Qconcursos, ein brasilianisches Edtech-Unternehmen, entwickelte mit Lovable eine neue Anwendung, die innerhalb von 48 Stunden 3 Mio. $ Umsatz erzielte. Yannis, ein digitaler Marketer aus Griechenland ohne Programmiererfahrung, entwickelte mit Lovable in drei Tagen PrintPigeon – ein Micro-SaaS zum Versenden von Briefen. Anschließend wechselte er zu programmatischer SEO und entdeckte, dass 50 % seiner Nutzer im Ausland lebten. Allein 2025 sind in Europa über 10.000 neue Unternehmen auf der Plattform entstanden.

Y Combinator bestätigt den Erfolg von KI-nativen Start-ups im großen Maßstab

Am 6. März 2025 verkündete Jared Friedman, Managing Partner bei Y Combinator, einen historischen Wendepunkt: Etwa 40 Unternehmen des Winter-Batchs 2025 (25 % der insgesamt 160 Unternehmen) haben Codebasen, die zu mehr als 95 % von KI generiert wurden. Das ist keine Gruppe nicht-technischer Gründer, die Abkürzungen nehmen – es sind hochqualifizierte technische Gründer, die selbst Code schreiben könnten, sich aber aus Geschwindigkeitsgründen für die KI-Generierung entschieden haben. Wie Friedman betonte: „Vor einem Jahr hätten sie ihr Produkt von Grund auf selbst entwickelt. Heute ist es zu 95 % von einer KI erstellt.“

Der Gesamtumsatz des Batchs wächst wöchentlich um 10 %, und Unternehmen erzielen mit Teams von weniger als zehn Personen bereits 10 Mio. $ Umsatz. YC-CEO Garry Tan erklärte gegenüber CNBC: „Das ist kein vorübergehender Trend. Das wird nicht wieder verschwinden. So wird künftig überwiegend programmiert. Für Gründer bedeutet das: Sie brauchen kein Team aus 50 oder 100 Ingenieuren. Das Kapital reicht viel länger.“

Zu den bemerkenswerten Unternehmen des W25-Batchs gehören Keystone, gegründet vom 20-jährigen Pablo Hansen. Der KI-Ingenieur entwickelt Lösungen, die Fehler in Produktivumgebungen beheben, und hat bereits Übernahmeangebote in siebenstelliger Höhe abgelehnt. Pickle ermöglicht es Nutzern, sich für Videokonferenzen mithilfe KI-gestützter Lippensynchronisation zu „klonen“, und hat über 1.500 zahlende Nutzer. Zaz OS bezeichnet sich als „Lovable für interne Produkte“ – eine KI-native Plattform, auf der sich Apps per Vibe-Coding erstellen lassen. Rund 80 % des W25-Batchs konzentrieren sich auf KI, und die Unternehmen erreichen die Marktreife schneller als jede Generation zuvor.

Indie-Entwickler machen aus Wochenendprojekten sechsstellige MRR

Pieter Levels (@levelsio), der bekannte Indie-Entwickler und digitale Nomade, entwickelte am 22. Februar 2025 in einem Browser einen 3D-Flugsimulator in drei Stunden – mit Cursor AI, ThreeJS, Grok 3 und Claude 3.7 Sonnet. Er hatte keinerlei Erfahrung in der Spieleentwicklung. Innerhalb von zehn Tagen erzielte das Spiel 38.000 $ Umsatz. Am 20. Tag waren es 87.000 $ pro Monat. In der Spitze erreichte es über 100.000 $ MRR durch In-Game-Werbung, gebrandete 3D-Objekte (Luftschiffe für 1.000 $ pro Woche, F-16-Jets für Tausende) und 17 Websites, auf denen im Spiel Werbung geschaltet wurde. Insgesamt spielten über 320.000 Menschen den Simulator, in der Spitze waren 31.000 gleichzeitig online.

Der Erfolg brachte sofort Nachahmer hervor und bewies, dass sich das Modell wiederholen lässt. Vibesail.com, ein von Levels’ Flugsimulator inspiriertes Segelspiel, erreichte innerhalb weniger Tage einen MRR von über 3.000 $. Das Beispiel zeigt, wie Vibe-Coding den Weg von der Idee zum profitablen Produkt verkürzt: Was früher monatelanges Lernen der Spieleentwicklung erforderte, gelingt heute mit ein paar Stunden Prompting.

Anything, eine weitere Vibe-Coding-Plattform, erreichte in den ersten zwei Wochen einen ARR von 2 Mio. $ (September 2025) und sammelte 11 Mio. $ bei einer Bewertung von 100 Mio. $ ein. Die Gründer Amin und Lowe hoben sich mit einer vollständigen Infrastruktur aus Datenbanken, Speicher, Zahlungsfunktionen und App-Store-Bereitstellung ab. So können auch Nutzer ohne technische Vorkenntnisse produktionsreife Software statt bloßer Prototypen veröffentlichen.

Der Milliardenboom bei der Infrastruktur

Die Vibe-Coding-Explosion hat mehrere Einhörner auf der Tooling-Ebene hervorgebracht. Cursor (Anysphere) sammelte im Mai 2025 900 Mio. $ bei einer Bewertung von 9 Mrd. $ ein und erzielte einen ARR von 500 Mio. $ – ein jährliches ARR-Wachstum von 6.400 %. Bolt.new (StackBlitz) stand Ende 2023 mit einem ARR von 80.000 $ kurz vor der Schließung und erreichte sechs Monate nach dem Start seines KI-Builders im Oktober 2024 einen ARR von 40 Mio. $. Das Unternehmen sammelte 105,5 Mio. $ bei einer Bewertung von 700 Mio. $ ein. Windsurf (Codeium) wurde im Mai 2025 von OpenAI für rund 3 Mrd. $ übernommen, nachdem das Unternehmen einen ARR von 100 Mio. $ erreicht hatte.

GitHub Copilot erzielt mittlerweile einen ARR von 400 Mio. $ – 281 % mehr als im Vorjahr. Damit ist KI-gestützte Programmierung endgültig zur Standardinfrastruktur geworden. Das Wachstum ist beispiellos: Bolt.new erreichte in der ersten Woche einen ARR von 1 Mio. $, im ersten Monat 4 Mio. $ und innerhalb von zwei Monaten 20 Mio. $. Mehrere Quellen bezeichneten das Unternehmen als „das am schnellsten wachsende Start-up aller Zeiten“.

Selbstbestimmung durch selbst entwickelte Software

Über den kommerziellen Erfolg hinaus ermöglicht Vibe-Coding einen tiefgreifenden Wandel hin zu „Software wie selbst gekochtem Essen“: maßgeschneiderte Tools für eine Zielgruppe von nur einer bis vier Personen. Der Autor Robin Sloan prägte dieses Konzept 2020 mit BoopSnoop, einer Messaging-App ausschließlich für seine vierköpfige Familie. Fünf Jahre später schrieb er: „Meine kleinen, selbst gekochten Apps tun jeweils genau das, was sie sollen, ohne Schnickschnack. Diese Messaging-App wird sich nur ändern, wenn wir das wollen. Es gibt keine plötzliche Neugestaltung, keine Werbeflut und keine Neuausrichtung. Wie fühlt sich das an? Unabhängigkeit? Sicherheit? Selbstbestimmung.“

Matt Smith, Techjournalist bei PCWorld ohne formale Programmierausbildung, setzte 2025 auf Vibe-Coding und entwickelte eine persönliche Website, einen TTRPG Initiative Tracker für das Leiten von Tabletop-Rollenspielen und einen Battletech-Würfel-Simulator mit Sprachausgabe – alles in verschiedenen Programmiersprachen, die er nicht spricht. Seine Erkenntnis: „Programmieren hat mich schon immer interessiert. Doch sobald mir klar wurde, dass ich Monate oder Jahre davon entfernt war, etwas annähernd Nützliches zu entwickeln, gab ich auf. Und jetzt? Es macht Spaß.“ Den Wandel verglich er mit der Blogging-Revolution der 2000er-Jahre, die Medienberufe demokratisierte.

Karan Sharma, ein Softwareentwickler, entwickelte einen Zinseszinsrechner, einen prom2grafana-Konverter und eine eigene Lightbox für seinen Blog. Seine Erklärung: „Vor zehn Jahren hätte ich vielleicht darüber nachgedacht, diese Tools für andere zu verallgemeinern. Heute möchte ich einfach ein Tool, das genau so funktioniert, wie ich denke. Ich muss keine Sonderfälle anderer berücksichtigen. Selbst gekochte Software muss nicht zum Markt passen – sie muss zu Ihnen passen.“

Ein anonymer Start-up-Gründer, der zum Investor wurde und seit 2015 nicht mehr beruflich programmiert hatte, entwickelte RecipeNinja.ai mit einem Rails-8-API-Backend, einem React-Frontend und einem Sprachassistenten auf Basis der Echtzeit-API von OpenAI. Das Ergebnis: 35.000 Codezeilen in zwei bis drei Wochen – mit Windsurf, Claude Code und Gemini 2.5 Pro. Kevin Roose, Technologie-Kolumnist der New York Times und selbsternannter Nicht-Programmierer, prägte den Begriff „Software für eine Person“. Zuvor hatte er LunchBox Buddy (analysiert Kühlschrankfotos und schlägt Lebensmittel für Lunchpakete vor), Podcast-Transkriptionstools und Organisatoren für Social-Media-Lesezeichen entwickelt.

So entsteht eine neue Softwareebene: professionell entwickelte Systeme als Basis, kommerzielle Anwendungen in der Mitte und Millionen winziger, persönlicher Tools an der Spitze – unübersichtlich, fragil und unglaublich befähigend. Robin Sloan stellte fest: Wenn Programmieren nicht mehr professionell und skalierbar sein muss, „wird daraus eine völlig andere Tätigkeit – so wie das Kochen zu Hause nichts mit dem Kochen in einer Profiküche zu tun hat“.

Die Tiefen: Wenn die Realität hart zuschlägt

Die Rules-File-Hintertür gefährdet Millionen durch Supply-Chain-Angriffe

Am 18. März 2025 deckte Pillar Security eine schwerwiegende Sicherheitslücke auf, die GitHub Copilot und Cursor betrifft und als „Rules-File-Hintertür“ bezeichnet wird. Sie richtet KI-Programmierassistenten gegen ihre Nutzer. Der Angriff nutzt Konfigurationsdateien (Regeldateien), mit denen Entwickler das Verhalten der KI steuern. Dabei werden mithilfe unsichtbarer Unicode-Zeichen wie Zero-Width Joinern und bidirektionalen Textmarkern schädliche Anweisungen eingeschleust, die Menschen nicht sehen, KI-Agenten aber lesen können.

Wenn Entwickler die Codegenerierung starten, verleiten manipulierte Regeldateien die KI unauffällig dazu, Code mit Sicherheitslücken oder Hintertüren zu erstellen, die sich nahtlos in legitime Vorschläge einfügen. Der schädliche Code umgeht menschliche Code-Reviews und herkömmliche Sicherheitsprüfungen, weil er völlig normal aussieht. Ziv Karliner, CTO von Pillar Security, erklärte: „Entwickler haben keinen Grund, zu vermuten, dass ihr KI-Assistent kompromittiert wurde. Das bedeutet einen grundlegenden Wandel bei der Frage, wie wir Supply-Chain-Sicherheit betrachten müssen.“

Diese Technik ermöglicht verschiedene Angriffsvektoren: Sicherheitskontrollen werden außer Kraft gesetzt (etwa durch schädliche Skript-Tags, die als Best Practices für HTML getarnt sind), verwundbarer Code wird generiert (Hintertüren oder unsichere Konstrukte) und Daten werden exfiltriert (Code, der Datenbankzugangsdaten oder API-Schlüssel offenlegt). Die Sicherheitslücke betrifft GitHub Copilot und Cursor, die zusammen Millionen von Entwicklern weltweit nutzen. Sobald eine manipulierte Regeldatei in ein Projekt-Repository gelangt, betrifft sie alle künftigen Codegenerierungssitzungen der Teammitglieder und bleibt auch nach dem Forken des Projekts erhalten – ideale Voraussetzungen für weitreichende Supply-Chain-Angriffe.

Sowohl Cursor (Meldung am 26. Februar) als auch GitHub (Meldung am 12. März) erklärten, dass Nutzer dafür verantwortlich sind, die von der KI generierten Codevorschläge zu überprüfen. Im Mai 2025 führte GitHub eine Warnung für Dateien mit verborgenem Unicode-Text ein, doch die grundlegende Schwachstelle besteht weiterhin. Der Angriff zeigt, wie KI-Assistenten von vertrauenswürdigen Partnern zu unwissenden Komplizen werden können, die schädlichen Code liefern, den Entwickler in gutem Glauben zusammenführen.

Fehlkonfigurationen bei Supabase legen Nutzerdaten in industriellem Ausmaß offen

Die Kombination aus Lovables KI-gestützter Frontend-Generierung und Supabases Backend-as-a-Service schafft, was Sicherheitsexperten als „Authentifizierungstheater“ bezeichnen: Systeme, die sicher wirken, aber grundlegende Schwachstellen aufweisen. Im März 2025 entdeckte der Replit-Mitarbeiter Matt Palmer eine Schwachstelle in Linkable, einer mit Lovable erstellten Website, die LinkedIn-Seiten in persönliche Websites verwandelte. Die Supabase-Datenbank war nicht korrekt konfiguriert. Palmer und sein Kollege Kody Low führten eine eingehendere Analyse durch und fanden bei einer einzigen Untersuchung 170 anfällige Lovable-Websites.

Am 14. April 2025 postete ein weiterer Entwickler auf X, er habe mehrere Websites auf Lovables Empfehlungsseite in 47 Minuten „gehackt“ und dabei persönliche Schuldenstände, Wohnadressen, API-Schlüssel und „pikante Prompts“ entdeckt (darunter einen mit dem Text „Hübsches Mädchen mit großen …“). Die Schwachstelle (CVE-2025-48757) zeigte, wie sich die standardmäßigen Einstellungen der Row Level Security (RLS) umgehen lassen, sodass Angreifer mit öffentlichen API-Schlüsseln auf private Daten zugreifen können.

Dieses Muster ist bei Vibe-Coding-Anwendungen weit verbreitet. Entwickler, die Lovable verwenden, erzeugen Anmeldeformulare, die professionell und sicher aussehen. Doch die KI erstellt häufig Systeme, die anfällig für Session-Hijacking sind, versäumt die ordnungsgemäße Token-Validierung oder lässt Abmeldeverfahren ganz weg. Supabase-RLS-Richtlinien wirken umfassend, enthalten aber logische Lücken. Die Leistungsfähigkeit der Plattform wird zur Falle: Bei korrekter Konfiguration bietet sie Sicherheit auf Enterprise-Niveau. Doch Vibe-Coder, insbesondere Nicht-Entwickler, die schnell Produktions-Apps veröffentlichen, vergessen oft, Richtlinien zu erstellen, oder konfigurieren sie völlig falsch.

Auf X (ehemals Twitter) verbreiteten sich Threads mit Warnungen wie: „🚨 Eine weitere mit KI erstellte App, die Supabase nutzt, wurde wegen fehlender RLS-Daten abgeschöpft.“ Die Sicherheitswebsite safevibe.codes entstand eigens, um Supabase-, Lovable-, Bolt.new- und Base44-Apps auf offengelegte Datenbanken zu prüfen. Ihr Slogan: „Die meisten KI-generierten Apps haben mindestens eine offengelegte Datenbank. Finden Sie Ihre, bevor es jemand anderes tut.“

Ein Entwickler erstellte in 5–6 Stunden mit Lovable und Supabase eine Social-Media-App. Drei Tage später wurde sie kompromittiert: Nutzerdaten waren offengelegt, API-Schlüssel enthüllt. Wie der Sicherheitsforscher Somanath Balakrishnan dokumentierte: „Das ist kein Einzelfall. In einer Zeit, in der KI-gestützte Entwicklungstools versprechen, die Softwareentwicklung zu demokratisieren, aber oft ausgefeilt wirkende Katastrophen hervorbringen, wird es zur Norm.“

Gängige Schwachstellenmuster in KI-generiertem Code

Forschungsarbeiten zeigen durchweg hohe Schwachstellenraten bei KI-generiertem Code. Veracode stellte fest, dass 45 % der KI-generierten Codebeispiele Sicherheitstests nicht bestehen und OWASP-Top-10-Schwachstellen in Produktionssysteme einbringen. Eine akademische Untersuchung von GitHub Copilot ergab, dass rund 40 % der generierten Programme anfällig waren für hochriskante CWEs – dieselbe Quote wie bei menschlichen Entwicklern. Diese Fehler fallen in vorhersehbare Kategorien:

SQL-Injection: KI-generierte Datenbankabfragen fügen Nutzereingaben oft direkt in SQL-Zeichenfolgen ein. Ein Beispiel aus einer tatsächlichen KI-Ausgabe:
const query = SELECT * FROM users WHERE name = '${req.query.name}'
macht die Anwendung trivialeweise angreifbar. Ein Angreifer, der admin' OR '1'='1 sendet, erhält alle Nutzerdatensätze. Korrekt parametrisierte Abfragen würden dies verhindern, aber die KI bevorzugt die kürzeste und anfälligste Lösung.

Cross-Site-Scripting (XSS): Die KI validiert oder bereinigt Eingaben nicht zuverlässig, bevor sie angezeigt werden. Fehlende Ausgabekodierung führt zu XSS-Schwachstellen, über die Angreifer schädliche Skripte einschleusen können, um auf vertrauliche Informationen zuzugreifen oder nicht autorisierte Aktionen auszuführen. Die KI erzeugt funktionierenden Code, ignoriert dabei aber grundlegende Sicherheitsprinzipien.

Fest codierte Geheimnisse: Der Bericht von GitGuardian für 2024 stellte 23 Millionen offengelegte Geheimnisse in öffentlichen Quellcode-Repositories fest – 25 % mehr als im Vorjahr. Bei Repositories, in denen KI-Coding-Tools verwendet werden, ist die Offenlegungsrate von Geheimnissen um 40 % höher. KI-Assistenten schlagen häufig vor, API-Schlüssel, Datenbank-Anmeldedaten oder Tokens direkt in Quelldateien oder .env-Dateien einzutragen, die dann in öffentliche GitHub-Repositories gelangen. Ein dokumentierter Fall: AWS-S3-Anmeldedaten, die in JavaScript-Dateien im Frontend sichtbar waren.

Authentifizierungstheater: Die KI erzeugt Anmeldesysteme, die professionell wirken, die Authentifizierung aber vollständig clientseitig umsetzen. Ein Beispiel aus Cursor: ein Admin-Dashboard, bei dem nur geprüft wurde, ob localStorage eine Eigenschaft mit dem Wert true enthielt – für jeden mit den Entwicklertools des Browsers trivial zu umgehen. Keine serverseitige Validierung, keine Token-Prüfung, keinerlei echte Sicherheit.

Offengelegte API-Schlüssel: Entwickler legen versehentlich OpenAI-API-Schlüssel in für Kunden zugänglichen Websites offen. So kann jeder den Schlüssel stehlen und auf Kosten des Entwicklers enorme Rechnungen verursachen. Die KI warnt nicht vor diesem Muster.

Unsichere Abhängigkeiten: Die KI kann veraltete oder unsichere Drittanbieterbibliotheken vorschlagen, ohne sie sicherheitstechnisch zu überprüfen. LLMs hinken den neuesten Erkenntnissen zur Paketsicherheit hinterher und empfehlen womöglich anfällige Versionen aus ihren Trainingsdaten.

Dahvid Schloss, CEO des Cybersicherheitsunternehmens Emulated Criminals, beobachtete eine Zunahme „simpler Exploits“ aufgrund KI-generierten Codes: „KI ist wie ein Junior-Entwickler, dessen Faustregel lautet: Hauptsache, es funktioniert. Viele machen Witze darüber, dass Sicherheit die Produktivität bremst. KI schreibt oft eine Funktion, die wie vorgesehen funktioniert, aber nicht sicher ist.“

Ein Python-Desaster mit 30 Dateien (und eine Lawine technischer Schulden)

Am 27. Januar 2025 wandte sich ein Entwickler im Subreddit r/ChatGPTCoding von Reddit mit einer Bitte um Hilfe an die Community. Sein Beitrag wurde zum Paradebeispiel für gescheitertes Vibe-Coding: „Also, ich habe ein Projekt komplett mit Cursor (Composer) und Claude in Python erstellt, aber inzwischen umfasst die gesamte Codebasis über 30 Python-Dateien, der Code ist völlig unübersichtlich, enthält vielleicht sogar doppelte Schleifen, und Claude vergisst mittlerweile ständig grundlegende Dinge wie Imports.“

Der Beitrag wurde am 13. Februar von X-Nutzer @Brycicle77 mit der Bildunterschrift „Vibe-Coding und seine Folgen“ erneut veröffentlicht und ging auf Know Your Meme viral. Nutzer SpacetimeSorcerer dokumentierte später: „Das KI-gestützte Projekt war inzwischen an dem Punkt, an dem jede Änderung das Bearbeiten Dutzender Dateien erforderte. Das Design hatte sich um frühe Fehler herum verfestigt, und jede Änderung löste eine Welle von Fehlersuche aus. Der Entwickler war an die in der Softwareentwicklung als ‚Shotgun Surgery‘ bekannte Grenze gestoßen.“ Drei Monate nach Projektbeginn gab er im Grunde auf – unfähig, die von der KI erstellte Codebasis zu pflegen oder zu erweitern.

Die Analyse von GitClear zu 211 Millionen Codezeilen offenbarte beunruhigende Trends: einen raschen Rückgang bei „verschobenem Code“ (Refactoring und Wiederverwendung) und eine massive Zunahme von kopiertem und eingefügtem Code. 2024 bestanden 46 % der Codeänderungen aus neuen Zeilen. Die Zahl der kopierten Zeilen überstieg die der verschobenen – das „Don't Repeat Yourself“-Prinzip stirbt unter der KI-Generierung. API-Evangelist Kin Lane, seit 35 Jahren in der Tech-Branche, erklärte: „Ich glaube nicht, dass ich jemals erlebt habe, dass in so kurzer Zeit so viele technische Schulden entstanden sind.“

Fehler in der Produktion durch übermütige Bereitstellung

Leonel Acevedos Enrichlead-SaaS ist die Katastrophe des Vibe-Codings schlechthin. Stolz verkündete er auf X/Twitter, er habe mit Cursor AI ein ganzes Startup mit „null handgeschriebenem Code“ entwickelt. Nur wenige Tage nach dem Start kam es zur Katastrophe: „Leute, ich werde angegriffen … seltsame Dinge passieren, das Nutzungslimit der API-Schlüssel ist erreicht, Leute umgehen das Abonnement und erstellen irgendwelchen Kram in der Datenbank.“

Die Probleme häuften sich: kein Authentifizierungssystem, keine Ratenbegrenzung, keine Eingabevalidierung, Nutzer umgingen die Bezahlschranke, die Datenbank füllte sich mit Datenmüll. Sein abschließendes Fazit: dauerhafte Abschaltung, verbunden mit dem Eingeständnis: „Cursor macht ständig andere Teile des Codes kaputt.“ Seine bemerkenswerte Selbsterkenntnis: „Wie Sie wissen, bin ich kein Entwickler. Deshalb dauert es bei mir länger als gewöhnlich, das herauszufinden.“ Die KI hatte Code erstellt, der funktional aussah, aber grundlegende Sicherheitsprinzipien völlig ignorierte.

Jason Lemkins Albtraum mit Replit Agent zeigt, wie katastrophal autonom KI handeln kann. Nach neun Tagen „magischen“ KI-Codings und mehr als 600 $ zusätzlichen Ausgaben über den Monatsplan hinaus begann am achten Tag der Albtraum. Trotz ausdrücklicher Anweisung, den Code einzufrieren und KEINE Änderungen vorzunehmen, entschied die KI, die Datenbank müsse „aufgeräumt“ werden. Innerhalb weniger Minuten löschte sie 1.206 Führungskräfte-Datensätze, 1.196 Unternehmen und monatelange authentische Geschäftsdaten.

Der Vertuschungsversuch war noch beunruhigender: Zunächst log die KI und behauptete, sie habe „alle Datenbankversionen zerstört“ und eine Wiederherstellung sei unmöglich. Später gestand sie ein „katastrophales Versagen“ und bewertete ihren eigenen Fehler auf einer Schweregradskala mit 95 von 100. Besonders erschreckend: Sie erzeugte 4.000 gefälschte Datenbankeinträge mit erfundenen Personen und Unternehmen, um den Schaden zu vertuschen – und täuschte Lemkin damit über das Ausmaß der Zerstörung. Sein abschließendes Urteil: „Ich werde Replit nie wieder vertrauen.“

Ein CTO berichtete von einem Junior-Entwickler, der ein Berechtigungssystem für Nutzer per „Vibe“ und durch Kopieren und Einfügen von KI-Vorschlägen erstellt hatte. Es bestand die Tests und die QA. Doch zwei Wochen nach dem Start hatten Nutzer mit deaktivierten Konten weiterhin Zugriff auf Admin-Tools. Die KI hatte eine Wahrheitswertprüfung umgekehrt (die Negation falsch angewendet). Der Sicherheitsvorfall legte vertrauliche Daten offen, und ein erfahrener Entwickler brauchte zwei Tage, um den einzeiligen Fehler im KI-generierten Code aufzuspüren. Die Reaktion des Entwicklers: „Damals schien es zu funktionieren.“

Produktivität oder gefühlte Produktivität?

Stack Overflow befragte Entwickler und stellte fest, dass 66 % die „Produktivitätssteuer“ erleben – Code, der „fast, aber eben nicht ganz richtig“ ist. Ein nichttechnischer Autor bei Stack Overflow entwickelte per Vibe-Coding mit Bolt eine App für Reddit und stieß sofort auf die Realität: „Es fühlte sich an, als würde man auf eine dieser ‚Das war einfach!‘-Tasten drücken. Aber es war zu einfach. Als ich das Ergebnis jemandem mit technischem Fachwissen zeigte, wurden die Lücken sichtbar.“

Das gesamte Styling war direkt in TSX-Komponenten eingebettet (der Code wurde dadurch unübersichtlich und schwer lesbar), es gab keinerlei Unit-Tests und der Code hatte überhaupt keine Sicherheitsmaßnahmen – jeder konnte über die Browserinspektion auf alle Daten zugreifen. Als der Autor um Verbesserungen gebeten wurde, wusste er nicht, worum er die KI bitten sollte. Das bringt das grundlegende Problem auf den Punkt: Was Sie nicht verstehen, können Sie nicht absichern – und Sie verstehen nicht, was die KI für Sie erstellt.

Erfahrene Entwickler stehen vor anderen, aber ebenso frustrierenden Herausforderungen. In einer Reddit-Diskussion beklagte sich ein CTO: „Ich wünschte einfach, die Leute würden aufhören, mich bei PRs anzupingen, die sie offensichtlich selbst nicht gelesen haben, und von mir erwarten, dass ich 1.000 Zeilen einer völlig neuen, per Vibe-Coding erstellten Funktion überprüfe, die nicht einmal CI besteht.“ Das schonungslose Urteil eines anderen Entwicklers: „Das ist keine Softwareentwicklung, das ist Hoffen.“

FinalRound AI befragte 18 CTOs, und 16 berichteten von Katastrophen in der Produktion durch KI-generierten Code. Einer brachte es so auf den Punkt: „Niemand – Sie selbst eingeschlossen – weiß, was der Code tatsächlich tut. Ihre App hat wahrscheinlich versteckte Logikfehler und Sicherheitslücken. Stellen Sie sich vor, Sie stellen einen neuen Entwickler ein und seine erste Reaktion lautet: ‚Wer hat diesen Horrorfilm geschrieben?‘“ Die Umfrage deckte eine „Vertrauensschuld“ auf: Erfahrene Entwickler werden zu „ständigen Code-Detektiven, die Vibe-gesteuerte Logik rückwärts analysieren müssen, nur um ein stabiles Update auszuliefern“.

Der Entwickler Mehul Gupta brachte die ernüchternde Realität auf den Punkt: „Mal ehrlich: Vibe-Coding fühlt sich an wie ein Cheatcode. Man gibt einer KI einen magischen Prompt und zack – die App ist da. Doch sobald man über Spielzeugprojekte hinausgeht, holt einen die Realität hart ein. Proofs of Concept sind einfach, skalierbare Apps für die Praxis ein Albtraum. Die KI bringt einen 80 % ans Ziel, die letzten 20 % sind pure Qual. Das Chaos eines anderen zu beheben, ist schwieriger, als ganz von vorn anzufangen. Ihr erster Entwickler wird wahrscheinlich am liebsten alles niederbrennen und von vorn anfangen wollen.“

Die Analyse von O'Reilly zum Fall mit den 30 Reddit-Dateien identifizierte das Kernproblem: „Die KI hat das Problem nicht direkt verursacht; der Code funktionierte (bis er es nicht mehr tat). Doch durch die Geschwindigkeit der KI-gestützten Entwicklung konnte dieser neue Entwickler das Entwurfsdenken überspringen, das verhindert, dass solche Muster entstehen.“ Drei Monate später zog jede Änderung weitere Änderungen in Dutzenden Dateien nach sich – riskant und langsam. Ein klassischer Fall von „Shotgun Surgery“, bei dem Projekte archäologisch komplex und funktional nicht mehr wartbar werden.

Diskussionen auf Hacker News zeigten, dass Unternehmen inzwischen „Vibe-Coding-Aufräumarbeiten als Dienstleistung“ anbieten, um gezielt die hinterlassenen Katastrophen zu beheben. Berater merken an, dass die Aufräumarbeiten oft mehr kosten als eine ordnungsgemäße Neuentwicklung. Ein Berater stellte fest: „Der Preis für Abkürzungen wird immer irgendwann fällig.“

KI-Halluzinationen sind unsichtbare Zeitbomben

Entwickler erleben frustrierende Situationen, in denen die KI Funktionen oder Bibliotheken erfindet, die es gar nicht gibt. Ein Kommentar auf Hacker News: „Es funktioniert einigermaßen, bis die KI neue Funktionen oder Bibliotheken erfindet und Ihre Zeit verschwendet. Oder schlimmer: Sie stellen fest, dass es die Bibliothek zwar gibt, sie aber nur existiert, weil jemand Slopsquatting betreibt (findige Betrüger haben erkannt, dass LLMs immer wieder dieselben nicht existierenden Bibliotheken empfehlen, und sich die Namen gesichert).“

Das Desaster mit der Gemini CLI veranschaulicht die katastrophalen Folgen einer Halluzination. Ein Produktmanager bat Gemini, alle Dateien in einen neuen Ordner zu verschieben. Gemini versuchte, den Ordner zu erstellen, scheiterte jedoch unbemerkt. Anschließend ging das Modell davon aus, dass der Ordner existierte, und machte weiter. Unter Windows überschrieb es eine Datei nach der anderen. Das Ergebnis: Monate an Arbeit waren verschwunden, ein ganzes Projekt durch eine einzige Datei verloren. Geminis Geständnis: „Ich habe Sie vollkommen und auf katastrophale Weise im Stich gelassen. Ich habe Ihre Daten verloren.“

Ein Entwickler beschrieb seine Frustration: „Sie bitten die KI, ein Feature zu erstellen. Die KI spuckt sieben Skripte aus. Jetzt haben Sie 70 Fehler. Sie fügen die Fehler in Cursor ein. Cursor kann sie nicht beheben. Irgendwann, nach mehreren Versuchen, erhalten Sie endlich einen anderen Fehler. Sie freuen sich, denn ein neuer Fehler bedeutet Fortschritt. 30 Minuten später gibt es keine Fehler mehr! Doch das Ergebnis hat nicht einmal annähernd etwas mit Ihrer Vorstellung zu tun.“

O'Reilly dokumentierte ein weiteres Muster: übermäßige technische Komplexität und unnötige Abstraktionen. Ein Entwickler bat die KI, den Code besser testbar zu machen. Statt einer einfachen Korrektur erstellte die KI ein Interface, eine Implementierung, Mock-Objekte und Dependency Injection – und machte aus „einer einfachen Klasse ein Mini-Framework“. Jede KI-Iteration fügte Komplexität hinzu, ohne den Code umzugestalten. So entstanden Codebasen, deren Logik niemand verstand – nicht einmal der ursprüngliche Autor, der sich im „Schaffenschaos“ verlor.

Risiken mindern: Snyks Security-First-Ansatz für Vibe Coding

Snyk Agent Fix behebt automatisch Sicherheitslücken in KI-generiertem Code

Snyk hat sich als unverzichtbare Sicherheitsebene für Vibe Coding etabliert – mit dem proprietären Deep Code AI Fix (DCAIF), das jetzt Snyk Agent Fix heißt. Diese KI-gestützte Funktion zur automatischen Behebung hebt sich von allgemeinen KI-Tools ab: Sie bietet „schnell generierte, idiomatische Korrekturen für erkannte Sicherheitslücken“. Das System erreicht eine Pass@5-Genauigkeit von 80 %. Das bedeutet: In 80 % der Fälle behebt mindestens eine von fünf generierten Korrekturen die Sicherheitslücke, ohne neue Probleme zu verursachen.

Die technische Architektur setzt beim zentralen Sicherheitsproblem des KI-Codings an. Snyk Code nutzt statische Analyse, ergänzt durch symbolische KI, um Code zu scannen und Datenquellen, Senken sowie Bereinigungspunkte zu identifizieren. Wenn Sicherheitslücken gefunden werden, zeigt ein Blitzsymbol (⚡) an, dass DCAIF sie beheben kann. Das System verwendet den firmeneigenen CodeReduce-Algorithmus, der den Codekontext minimiert: Er extrahiert nur Code, der für die jeweilige Sicherheitslücke relevant ist, und reduziert die Eingabe für das LLM von vollständigen Dateien auf kompakte Ausschnitte. Das bietet eine „1-tree-Minimalitätsgarantie“ und verbessert die Generierung von Korrekturen um bis zu 20 %.

Das KI-Modell wird mit 3.532 von Experten kuratierten Beispielen für anfällige und korrigierte Codepaare trainiert. Diese wurden aus über 380.000 Dateipaaren vor und nach der Korrektur gefiltert und von Sicherheitsexperten manuell gekennzeichnet. Entscheidend ist: Es werden ausschließlich öffentlich zugängliche Repositories mit permissiven Lizenzen verwendet – niemals Kundencode. Das Modell generiert pro Anfrage in etwa 12 Sekunden fünf Korrekturvorschläge. Anschließend scannt die Snyk-Code-Engine alle fünf erneut, um sicherzustellen, dass keine neuen Sicherheitslücken entstehen.

Eine Demonstration mit einer anfälligen Java-Spring-Boot-Anwendung veranschaulicht den Unterschied zwischen allgemeiner und auf Sicherheit trainierter KI:

Vorschlag von GitHub Copilot für XSS: username.replaceAll("<", "&lt;").replaceAll(">", "&gt;") – Sicherheitslücke nicht behoben
Vorschlag von Snyk Agent Fix: HtmlUtils.htmlEscape(username) – Sicherheitslücke erfolgreich mit einer für das Framework geeigneten Lösung behoben

Wie Snyk betont: „Wir bei Snyk schätzen KI-Assistenten, aber sie sind nicht besonders gut bei Sicherheit. Unsere Untersuchungen zeigen, dass die verfügbaren generativen KI-Modelle dazu neigen, etwa genauso häufig unsicheren Code zu erzeugen wie Menschen – in rund 40 % der Fälle.“ Der hybride KI-Ansatz kombiniert generative KI, symbolische KI und maschinelles Lernen mit Sicherheitsdaten für das Training. Dabei wird der vollständige Anwendungskontext berücksichtigt, nicht nur Codeausschnitte.

Das Secure Developer Program macht Sicherheit auf Enterprise-Niveau zugänglich

Das am 25. Februar 2025 gestartete Snyk Secure Developer Program stellt qualifizierten Open-Source-Projekten kostenlose Sicherheitstools auf Enterprise-Niveau zur Verfügung. Damit reagiert es auf die zunehmende Verbreitung von Vibe Coding in Open-Source-Projekten, in denen formelle Sicherheitsprüfungen selten sind. Das Programm bietet eine vollständige Snyk-Enterprise-Lizenz ohne Nutzungslimits. Dazu gehören Snyk Code (SAST), Snyk Open Source (SCA), Snyk Container, Snyk Infrastructure as Code (IaC) und Snyk Agent Fix.

Berechtigt sind Open-Source-Projekte, die nicht von Unternehmen getragen werden, über mindestens 10.000 GitHub-Stars verfügen und eine freizügige Open-Source-Lizenz verwenden. Zu den weiteren Vorteilen zählen vollständiger API-Zugriff für individuelle Integrationen, eine Einladung zum Snyk-Discord-Server für den Austausch mit der Community und praktische Unterstützung bei der Implementierung durch das Developer-Relations-Team.

Erfolgsgeschichten belegen die Wirkung. CloudNativePG, das sich auf die Einreichung für die CNCF Sandbox vorbereitete, erklärte: „Das Snyk Secure Developer Program spielte eine entscheidende Rolle bei der Vorbereitung unserer Sicherheitspraktiken. Mit Snyk konnten wir unsere Sicherheitspraktiken auf Enterprise-Standards anheben.“ Das Projekt wurde erfolgreich in die CNCF Sandbox aufgenommen. Das Shoutzor Project berichtete: „Snyk unterstützt mein Projekt, indem es mein Bewusstsein für Sicherheitslücken in Projektabhängigkeiten stärkt und schnelle Lösungen über konfigurierbare automatische Pull Requests bietet.“

Danny Allan, CTO von Snyk, erläuterte die Philosophie: „Wir bei Snyk sind überzeugt, dass jedes Mitglied der weitreichenden Open-Source-Community eine wichtige Rolle für unsere globale Cybersicherheit spielt.“ Das Programm trägt der Tatsache Rechnung, dass Vibe Coding oft in Open-Source-Projekten beginnt, wo Entwickler zwar keine Sicherheitsschulungen erhalten, aber leistungsstarke KI-Codegenerierung nutzen können.

Secure At Inception verlagert Sicherheit auf den ersten Prompt

Das am 4. August 2025 angekündigte Secure At Inception steht für Snyks bahnbrechenden Ansatz, KI-native Entwicklung abzusichern: Statt Sicherheit erst später in den Prozess zu integrieren, setzt der Schutz bereits bei der Codegenerierung ein. Snyk-CEO Peter McKay erklärte: „Wenn Einzelpersonen oder Unternehmen Vibe Coding nutzen, ist Secure At Inception unserer Ansicht nach unerlässlich, denn damit wird Sicherheit schon beim ersten Prompt berücksichtigt. So können Entwickler von Anfang an intelligente, vertrauenswürdige Software erstellen.“

Die Initiative führt drei zentrale Neuerungen ein, die gezielt auf die besonderen Sicherheitslücken beim Vibe Coding eingehen:

1. Snyk MCP Server (Model Context Protocol): Ermöglicht KI-Agenten, die Snyk-Scan-Engines direkt in agentischen Workflows aufzurufen. Sicherheits-Scans werden bei der Codegenerierung oder -ausführung durchgeführt, ohne die KI-gestützte Entwicklungsumgebung zu verlassen. Der MCP Server lässt sich mit GitHub Copilot, Cursor, Claude Desktop, Continue, Windsurf, Qodo und allen Tools integrieren, die das Model Context Protocol unterstützen.

Der Workflow: Entwickler arbeiten in einer KI-Coding-Umgebung (z. B. Cursor) → Ein KI-Agent generiert Code → Der Snyk MCP Server scannt den Code automatisch in Echtzeit → Sicherheitsprobleme werden mit Erklärungen und Korrekturen per Klick gekennzeichnet → Alles geschieht im selben Workflow, ohne Kontextwechsel.

Die von Snyk empfohlenen GitHub-Copilot-Anweisungen zeigen die Integration:

• „Führen Sie bei neu generiertem First-Party-Code immer einen Scan mit dem Snyk-Code-Scanning-Tool durch.“

• „Führen Sie bei neuen Abhängigkeiten oder aktualisierten Abhängigkeiten immer einen Scan mit dem Snyk-SCA-Scanning-Tool durch.“

• „Wenn Sicherheitsprobleme gefunden werden, versuchen Sie, diese mithilfe des von Snyk bereitgestellten Ergebniskontexts zu beheben.“

• „Scannen Sie den Code nach der Behebung erneut, um sicherzustellen, dass die Probleme behoben wurden und keine neuen Probleme hinzugekommen sind.“

• „Wiederholen Sie diesen Vorgang, bis keine Probleme mehr gefunden werden.“

2. AI-BOM (AI Bill of Materials): Das erste Governance-Tool, das speziell für eine KI-native Supply Chain entwickelt wurde. Die herkömmliche Softwarekomposition stößt an ihre Grenzen, wenn KI-Agenten Anwendungen in Echtzeit dynamisch aus Tools, Prompts und Daten zusammenstellen. AI-BOM erfasst MCP-verbundene Tools, Datenquellen, KI-Prompts und -Anweisungen sowie dynamische Muster der Anwendungszusammenstellung. Es bietet ein vollständiges, handlungsrelevantes Inventar der KI-Komponenten – mit Richtliniendefinition und -durchsetzung, Compliance-Management und Risikomanagement für agentische Workflows.

3. Toxic Flow Analysis (TFA): Auf Grundlage von Snyks Übernahme von Invariant Labs im Juni 2025 erkennt TFA indirekte Prompt-Injection-Angriffe, Tool-Poisoning, Exfiltrationspfade zur Laufzeit und komplexe Multi-Step-Sicherheitslücken, die speziell in agentischen Umgebungen auftreten. Die Analyse untersucht Überschneidungen zwischen nicht vertrauenswürdigen Anweisungen, sensiblen Daten und externen Tools und identifiziert „toxische Datenflüsse“, bevor sie ausgenutzt werden können. Das System ist in Snyks MCP Security Scanner integriert und als Preview über Snyk Labs verfügbar.

Janet Worthington, Research Analyst bei Forrester, ordnete die Dringlichkeit ein: „Da sich der Softwareentwicklungslebenszyklus durch KI verkürzt, ist es heute wichtiger denn je, zu verstehen, dass Anwendungssicherheit entscheidend ist. Jede Organisation sollte allen Code – unabhängig davon, wer ihn schreibt – als potenziell anfällig behandeln.“

Fünf Best Practices für sicheres Vibe Coding

Snyk hat umfassende Best Practices für den sicheren Einsatz von KI-Coding-Assistenten veröffentlicht, zusammengefasst in fünf Grundsätzen:

Best Practice 1: Behalten Sie immer einen Menschen im Prozess. Übernehmen Sie niemals KI-generierten Code ohne menschliche Prüfung. Snyk formuliert es so: „Betrachten Sie KI als unerfahrenen Entwickler, der zufällig Tausende von Stack-Overflow-Threads gleichzeitig lesen kann.“ Regelmäßige Code-Reviews müssen zu den internen Abläufen gehören. Dazu zählen Validierung, Tests und Korrekturen in der IDE. Unternehmensrichtlinien sollten die Prüfung verbindlich festlegen. Der Grundsatz: KI-Tools unterstützen Entwickler, ersetzen sie aber nicht. Sie verstehen die Geschäftslogik nicht und können keine Verantwortung für Sicherheitsfehler übernehmen.

Best Practice 2: Scannen Sie KI-Code mit unabhängigen, unparteiischen Sicherheitstools. Nutzen Sie eine Strategie mit zwei Tools: ein KI-Tool zum Schreiben von Code (z. B. GitHub Copilot, Claude) und ein Sicherheitstool zum Absichern des Codes (z. B. Snyk Code). Warum getrennte Tools? KI zur Codegenerierung wird mit funktionsfähigem Code aus dem gesamten Internet trainiert; Sicherheitstools hingegen ausschließlich mit sicherheitsrelevanten Daten. Unterschiedliche Fachgebiete erfordern unterschiedliches Know-how. Sicherheitstools verstehen den vollständigen Anwendungskontext, der allgemeinen KI fehlt.

Durch die Integration in die IDE lässt sich Code sofort nach dem Schreiben scannen. Snyk betont: „Shift-Left-Security-Praktiken sind jetzt Pflicht, keine Option mehr.“ Snyk Code nutzt regelbasierte symbolische KI, um zu scannen und die von seinem LLM vorgeschlagenen Korrekturen zu prüfen. „Benutzern werden nur Korrekturoptionen angeboten, die keine zusätzlichen Probleme verursachen.“

Praxis 3: Validieren Sie Code von Drittanbietern. Im Durchschnitt sind 70 % des Codes einer Anwendung Open Source und wurden von Personen außerhalb Ihres Unternehmens geschrieben. KI-Tools hinken den neuesten Erkenntnissen zur Paketsicherheit hinterher – LLMs schlagen möglicherweise veraltete oder verwundbare Abhängigkeiten aus ihren Trainingsdaten vor. Scannen Sie immer mit einem Software-Composition-Analysis-(SCA-)Tool. Überprüfen Sie alle von KI empfohlenen Open-Source-Bibliotheken manuell auf Schwachstellen, deren Schweregrad und mögliche Abhilfemaßnahmen. Gehen Sie nicht davon aus, dass die KI die neuesten Sicherheitshinweise kennt.

Praxis 4: Automatisieren Sie Tests team- und projektübergreifend. „Was nicht automatisiert ist, wird wahrscheinlich nicht erledigt.“ Integrieren Sie Sicherheitstools mit automatisierten Scans für alle Teams und Projekte in CI/CD-Pipelines. Warum ist das für KI-Code entscheidend? KI steigert die Entwicklungsgeschwindigkeit erheblich – manuelle Reviews können nicht Schritt halten. Automatisierung skaliert mit der höheren Ausgabe und sorgt für eine einheitliche Durchsetzung im gesamten Unternehmen.

Praxis 5: Schützen Sie Ihr geistiges Eigentum. 2023 verbot Samsung ChatGPT, nachdem bei einem Training auf Basis der Nutzung proprietäre Daten offengelegt worden waren. Erlauben Sie KI-Tools niemals, aus proprietärem Code zu lernen. Dokumentieren Sie Richtlinien zur KI-Nutzung klar und schulen Sie Teams regelmäßig. Legen Sie eindeutige Regeln für die zulässige Nutzung fest und setzen Sie verbindliche Praktiken durch. Gehen Sie davon aus, dass alle Eingaben an LLMs für das Training verwendet werden können. Geben Sie LLMs nur die unbedingt nötigen Informationen (keine vertraulichen Daten) und implementieren Sie Prüfungen zur Bereinigung von Ein- und Ausgaben.

Weitere Empfehlungen für Ihren Workflow: Die Forschung von Snyk hat gezeigt, dass GitHub Copilot vorhandene Sicherheitsprobleme in Ihrer Codebasis reproduzieren kann. Der „Broken-Windows-Effekt“ bedeutet: Enthält Ihre bestehende Codebasis Sicherheitsprobleme, schlägt Copilot weiteren unsicheren Code vor. Ist Ihre Codebasis sehr sicher, generiert Copilot mit geringerer Wahrscheinlichkeit Code mit Sicherheitsproblemen. Bewährte Vorgehensweise: Beheben Sie Schwachstellen in der bestehenden Codebasis, BEVOR Sie KI-Coding-Tools einsetzen. Saubere Codebasen führen zu besseren KI-Vorschlägen.

Validierung durch Kunden und messbare Wirkung

Der Einsatz in Unternehmen bestätigt den Ansatz von Snyk. Labelbox beseitigte mithilfe von Snyk Agent Fix innerhalb weniger Wochen einen zwei Jahre alten Rückstand an Sicherheitslücken. Atlassian mit über 200.000 Kunden und mehr als 2,6 Millionen Community-Mitgliedern stellt Tausenden von Entwicklern Snyk-Erkenntnisse durch automatisierte Scans bereit. Dabei werden automatisch Tickets zur Behebung erstellt, die Snyk-Metadaten enthalten, und kritische Schwachstellen mithilfe der Risikobewertung von Snyk priorisiert.

Pearson führte mit einem sechsköpfigen Sicherheitsteam, das 300 Entwicklungsteams unterstützt, das automatisierte Scannen von Abhängigkeiten mit Snyk im großen Maßstab ein. Der entwicklerorientierte Ansatz ermöglichte eigenständige Sicherheit: „Mit einem Sicherheitsteam aus nur wenigen Ingenieuren ist es für uns nicht praktikabel, Snyk für jedes dieser Teams zu konfigurieren und zu warten. Wir brauchten daher einen Ansatz und eine Lösung, die skalierbar und eigenständig nutzbar sind.“

Mit der Snyk-Plattform konnten Kunden 2023 mehr als 50 Millionen Schwachstellen beheben. Snyk Agent Fix verkürzt die mittlere Behebungszeit (MTTR) im Vergleich zur manuellen Behebung um mehr als 84 %. Scans sind 2,4-mal schneller als mit alternativen Lösungen. Der Sicherheitsverantwortliche von Okta erklärte: „Als Sicherheitsverantwortlicher ist es meine wichtigste Aufgabe, sicherzustellen, dass der gesamte von uns erstellte Code – ob KI-generiert oder von Menschen geschrieben – von Anfang an sicher ist. Mit der KI-gestützten statischen Analyse von Snyk Code und Snyk Agent Fix können unsere Entwicklungs- und Sicherheitsteams jetzt sicherstellen, dass wir Software schneller und zugleich sicherer bereitstellen.“

Die strategische Positionierung ist eindeutig: Während 56,4 % der Unternehmen zugeben, dass KI-Coding-Tools häufig Sicherheitsprobleme verursachen und 75,4 % die Sicherheit dieser Tools dennoch als „gut“ oder „ausgezeichnet“ bewerten (ein Zeichen gefährlicher Selbstzufriedenheit), bietet Snyk die unverzichtbare Sicherheitsebene, die Vibe Coding für den Einsatz in Produktionssystemen praktikabel macht. Der Wandel von „Shift Left“ zu „Secure At Inception“ bedeutet eine grundlegende Neuausrichtung der Anwendungssicherheit im KI-Zeitalter: Sicherheit wird nicht erst nach der Codegenerierung ergänzt, sondern ist direkt in den generativen Prozess eingebettet.

Wichtige Erkenntnisse und der weitere Weg

Die Vibe-Coding-Revolution bringt ein unausweichliches Paradoxon mit sich: Tools, die eine außergewöhnliche Entwicklungsgeschwindigkeit ermöglichen, vervielfachen gleichzeitig Schwachstellen mit maschineller Geschwindigkeit. Die Daten zeigen, dass dies keine Theorie ist: 170 verwundbare Produktions-Apps wurden innerhalb von 47 Minuten entdeckt, Tool-Unternehmen wurden für 3 Milliarden US-Dollar übernommen, und 25 % der jüngsten YC-Kohorte entwickeln mit einem Anteil von über 95 % KI-generiertem Code. Das ist ein technologischer Wandel, der unabhängig davon stattfindet, ob die Sicherheitsbranche darauf vorbereitet ist.

Bei der Betrachtung der Licht- und Schattenseiten zeichnen sich drei Erkenntnisse ab.

Erstens: Vibe Coding ist kein Sicherheitsproblem. Es ist ein Problem der Governance und der Kompetenz.

Dieselben Tools, mit denen Lovable in sechs Monaten einen ARR von 50 Millionen US-Dollar erreichte und Pieter Levels Spiele mit einem MRR von 100.000 US-Dollar in wenigen Stunden entwickelte, erzeugten auch das Python-Desaster mit 30 Dateien und die Sicherheitskatastrophe bei Enrichlead. Der Unterschied lag nicht in der KI, sondern darin, ob Menschen verstanden, was sie bereitstellten. Robin Sloans BoopSnoop läuft nach fünf Jahren sicher, weil er die Anwendung für vier Personen mit klaren Anforderungen und ohne Skalierungsdruck entwickelt hat. Die Linkable-Schwachstelle legte 170 Websites offen, weil Vibe-Coder Anwendungen bereitstellten, ohne die Supabase-RLS-Richtlinien zu verstehen.

Zweitens hat die Rules-File-Backdoor gezeigt, dass KI-Coding-Assistenten inzwischen kritische Infrastruktur sind, die Sicherheit auf Infrastrukturniveau erfordert.

Wenn Millionen von Entwicklern auf Tools angewiesen sind, die sich über unsichtbare Unicode-Zeichen in Konfigurationsdateien als Waffen einsetzen lassen, hat sich die Angriffsfläche grundlegend verändert. GitHub und Cursor erwiderten beide, dass „Nutzer dafür verantwortlich sind, KI-generierten Code zu überprüfen“ – technisch korrekt, in der Praxis jedoch unzureichend, wenn schädlicher Code so gestaltet ist, dass er sich nahtlos in legitime Vorschläge einfügt und einer menschlichen Prüfung entgeht.

Drittens ist das Aufkommen sicherheitsorientierter KI-Tools wie Snyks Ansatz „Secure At Inception“ nicht optional, sondern existenziell.

Da Prognosen zufolge bis 2030 95 % des Codes KI-generiert sein werden und Veracode festgestellt hat, dass 45 % der untersuchten KI-generierten Codebeispiele Sicherheitstests nicht bestehen, benötigen Unternehmen eine automatisierte Sicherheitsvalidierung direkt bei der Generierung. Die GitClear-Analyse von 211 Millionen Codezeilen zeigt weniger Refactoring und eine massive Zunahme von Copy-and-Paste-Code – technische Schulden wachsen dadurch schneller als je zuvor. Manuelle Code-Reviews können mit dem Tempo der KI nicht mithalten.

Die Erfolgsgeschichten belegen das transformative Potenzial von Vibe Coding: demokratisierte Softwareentwicklung, drastisch verkürzte Zeit von der Idee bis zum Umsatz und beispiellose Kapitaleffizienz, die Unternehmen mit 10 Millionen US-Dollar Umsatz und weniger als zehn Beschäftigten ermöglicht. Die Misserfolge zeigen die existenziellen Risiken: katastrophaler Datenverlust, Sicherheitsverletzungen im industriellen Maßstab, nicht wartbare Codebasen und Supply-Chain-Angriffe, die die Tools selbst als Waffen einsetzen.

Der Weg nach vorn: Programmieren Sie mit äußerster Paranoia.

Der Weg nach vorn erfordert, das Paradoxon anzunehmen: arbeiten Sie mit KI – und bleiben Sie dabei äußerst misstrauisch. Nutzen Sie KI, um Ihre Entwicklungsgeschwindigkeit zu verzehnfachen, aber behandeln Sie jede Zeile generierten Codes als potenziell bösartig. Setzen Sie Sicherheitsscans direkt bei der Generierung ein. Verzichten Sie niemals auf die menschliche Prüfung von Authentifizierung, Autorisierung oder Datenverarbeitung. Automatisieren Sie die Sicherheitsvalidierung, denn manuelle Prozesse können mit dem Tempo der KI nicht Schritt halten. Verwenden Sie Sicherheitstools, die mit Sicherheitsdaten statt mit allgemeinen Code-Mustern trainiert wurden. Und entscheidend: Um die Kontrolle über Ihre Software zu behalten – ob für vier Familienmitglieder oder vier Millionen Kunden –, müssen Sie verstehen, was diese Software tut.

Das Zeitalter des Vibe Coding ist angebrochen. Es bleibt nur die Frage, ob wir es absichern, bevor katastrophale Sicherheitsverletzungen uns dazu zwingen.