Ratgeber
Vibe Coding im Unternehmen: sieben Risiken und wie man sie prüfbar macht
Für Prototypen eine Errungenschaft, für Betriebsdaten ein Problem. Die sieben Risiken einzeln — jedes mit dem Prüfschritt, der es entschärft.
Stand: 18. August 2026 · MCP Baldux
Vibe Coding heißt, einer KI in normaler Sprache zu beschreiben, was entstehen soll, und den erzeugten Code weitgehend ungeprüft zu übernehmen; im Unternehmen wird das tragfähig, sobald jedes der sieben typischen Risiken einen eigenen, nachweisbaren Prüfschritt bekommt.
Woher der Begriff kommt
Andrej Karpathy prägte den Ausdruck am 2. Februar 2025 in einem Beitrag auf X: Man gebe sich ganz den Vibes hin und vergesse, dass der Code überhaupt existiert. Gemeint war eine Arbeitsweise, in der das Ergebnis daran gemessen wird, ob es läuft und sich richtig anfühlt. Am 6. November 2025 kürte das Collins Dictionary „vibe coding“ zum Wort des Jahres und beschrieb es als das Schreiben von Computercode mithilfe künstlicher Intelligenz, angestoßen durch natürliche Sprache.
Der Begriff beschreibt also keine Technik, sondern eine Freigabepraxis. Dieselben Modelle, dieselben Werkzeuge, ein anderer Umgang mit dem Ergebnis. Das ist wichtig, weil die Debatte häufig so geführt wird, als ginge es um die Frage, ob KI Code schreiben darf. Die Frage ist, wer ihn freigibt.
Was die Zahlen zeigen
Belastbare Erhebungen zum Feld sind noch dünn, und die aussagekräftigste stammt von einem Marktteilnehmer — das gehört dazugesagt. Der Sicherheitsanbieter Escape.tech untersuchte 2025 über 5.600 öffentlich erreichbare Anwendungen, die auf diese Weise entstanden waren, und meldete daraus mehr als 2.000 Schwachstellen, über 400 offengelegte Zugangsgeheimnisse und 175 Fälle offen zugänglicher personenbezogener Daten. Als Anbieterstudie ist das ein Hinweis, kein Beweis.
Härter belegt ist der Einzelfall CVE-2025-48757 vom 29. Mai 2025 mit einem Schweregrad von 9,3 von 10: Bei Anwendungen, die mit einem verbreiteten KI-App-Baukasten erzeugt wurden, war die zeilenweise Zugriffsbeschränkung der Datenbank unzureichend gesetzt — Unbefugte konnten ohne Anmeldung Tabellen auslesen. Ein Einzelfall, aber ein lehrreicher: Die Sichtbarkeit der Oberfläche sagt nichts über die Zugriffslogik dahinter.
Dazu kommen die schon genannten Befunde zur Codequalität: 45 % verwundbare Beispiele bei Veracode 2025, unsicherer Code bei gleichzeitig höherem Sicherheitsgefühl in der Studie von Perry und Kollegen (2023), und 19 % längere Bearbeitungszeit statt der erwarteten Beschleunigung in der METR-Studie 2025. Zusammengenommen ergibt das ein konsistentes Bild: Das Erzeugen ist gelöst, das Prüfen nicht.
Die sieben Risiken — und wie jedes prüfbar wird
| Risiko | Was schiefgeht | So wird es prüfbar |
|---|---|---|
| Sicherheit | Berechtigungen zu weit geöffnet, Zugangsgeheimnisse im Quelltext, ungeprüfte Eingaben | Eine Prüfrolle mit Blockaderecht, die jede Änderung gegen dieselbe Frage laufen lässt: Kommt jemand an Daten, der nicht darf? |
| Datenmodell | Struktur entsteht nebenbei; Widersprüche fallen erst auf, wenn Daten drin sind | Datenmodell und führendes System werden vor der ersten Zeile Code entschieden und schriftlich festgehalten. |
| Rechte und Lizenz | Fremdbausteine kommen mit, ohne dass jemand ihre Bedingungen kennt | Herkunft und Lizenz jedes Bausteins werden erfasst; die Rechteaufteilung steht vor der Beauftragung im Vertrag. |
| Wartbarkeit | Der Code läuft, aber niemand kann ihn ändern — auch die KI nicht mehr | Die Architekturrolle prüft gegen die Frage, ob der Aufbau in zwei Jahren noch trägt; Tests und Dokumentation entstehen mit. |
| Nachvollziehbarkeit | Es gibt ein Ergebnis, aber keine Antwort darauf, wie es zustande kam | Jede Freigabe hinterlässt ein Protokoll: was geändert wurde, wer geprüft hat, was beanstandet wurde. |
| Skalierung | Was mit zehn Datensätzen funktioniert, bricht bei zehntausend | Lastannahmen gehören in den Plan; die Integrationsrolle prüft das Verhalten bei Ausfall und Überlast. |
| Abhängigkeit | Die Anwendung lebt in einer fremden Plattform und lässt sich nicht herausnehmen | Übergabe des Quellstands in Ihr eigenes Verzeichnis, Betrieb auf einem Server, dessen Vertrag auf Ihren Namen läuft. |
Auffällig an dieser Aufstellung: Keine der rechten Spalten verlangt ein besseres Modell. Alle sieben Gegenmaßnahmen sind organisatorisch — sie legen fest, wer wann was prüft und was dabei festgehalten wird. Genau deshalb lässt sich Vibe Coding im Unternehmen nicht durch Modellwahl absichern, sondern nur durch einen Ablauf.
Wo Vibe Coding die richtige Wahl ist
Es wäre falsch, die Arbeitsweise pauschal abzulehnen. Für einen Machbarkeitsnachweis, ein Wegwerf-Werkzeug oder ein internes Experiment ist sie eine echte Errungenschaft: Eine Idee, die früher eine Woche Vorarbeit brauchte, ist in einer Stunde sichtbar. Wer eine Annahme prüfen will, muss dafür kein Budget mehr beantragen.
Die Faustregel ist einfach: Solange ein Fehler nur Ihre eigene Zeit kostet, ist Vibe Coding richtig. Sobald ein Fehler Kundendaten, Geld oder einen Ablauf trifft, auf den sich der Betrieb verlässt, braucht es eine Prüfung, die vom bauenden Modell unabhängig ist. Der Übergang ist kein Technologiewechsel — es ist derselbe Bau mit einem zusätzlichen Schritt davor und einem Protokoll danach.
Häufige Fragen zu Vibe Coding im Unternehmen
Ist Vibe Coding sicher genug für Unternehmen?
Für Prototypen ja, für Software mit echten Betriebsdaten nicht. Es fehlt der Schritt, der die erzeugte Lösung gegen eine andere Frage prüft als die, mit der sie entstanden ist. Ergänzt man diesen Schritt und hält ihn fest, ist es kein Vibe Coding mehr, sondern verifizierte KI-Entwicklung.
Welche Risiken hat Vibe Coding konkret?
Sieben kommen regelmäßig vor: zu weit geöffnete Zugriffsrechte, ein nebenbei entstandenes Datenmodell, ungeklärte Lizenzen mitgebrachter Bausteine, schlechte Änderbarkeit, fehlende Nachvollziehbarkeit, Verhalten unter Last und Abhängigkeit von einer fremden Plattform. Jedes davon lässt sich einzeln entschärfen.
Wem gehört Code, der so entstanden ist?
Ihre Anwendung gehört Ihnen: Sie nutzen sie, betreiben sie, lassen sie weiterentwickeln, hosten sie selbst oder lassen hosten. Das Baldux-Framework darunter bleibt unser Eigentum und ist für genau diese Anwendung unbefristet lizenziert — kein Weiterverkauf, keine Unterlizenz, kein Herauskopieren, keine Nutzung in anderen Projekten, auch nicht durch andere Agenturen oder Ihre Mitarbeitenden. Änderungen am Framework fallen an Baldux; die Entwicklungsplattform und die Engine werden nie ausgeliefert. Einzelheiten: AGB Ziffer 12–17 und /lizenz.
Was kostet Vibe Coding wirklich?
Die Erzeugung ist billig, die Nacharbeit nicht. Die METR-Studie von 2025 fand bei erfahrenen Entwicklern 19 % längere Bearbeitungszeit mit KI-Werkzeugen, obwohl 24 % Beschleunigung erwartet worden waren. Was am Anfang gespart wird, taucht später als Prüf- und Korrekturaufwand wieder auf — nur ungeplant.
Vibe Coding, Agentic Coding, Low-Code — worin liegt der Unterschied?
Vibe Coding erzeugt Code ohne eigenen Prüfschritt. Agentic Coding lässt Agenten mehrere Schritte selbständig ausführen, sagt aber nichts über Kontrolle. Low-Code setzt Anwendungen aus fertigen Bausteinen einer Plattform zusammen. Verifizierte KI-Entwicklung verbindet den agentischen Bau mit unabhängiger Prüfung und einem Protokoll je Schritt.
Quellen
- Andrej Karpathy auf X, 2. Februar (2025)
- Collins Dictionary, Wort des Jahres (2025)
- Escape.tech (Sicherheitsanbieter), Analyse öffentlich erreichbarer Anwendungen (2025)
- NIST National Vulnerability Database, CVE-2025-48757 (2025)
- Veracode (Anbieter für Anwendungssicherheit), GenAI Code Security Report (2025)
- METR, Studie zu KI-Werkzeugen bei erfahrenen Entwicklern (2025)