Vibe Coding im Unternehmen: Wo KI-Code trägt — und wo er teuer wird

Vibe Coding bezeichnet das Erzeugen von Software durch Anweisungen in natürlicher Sprache: Sie beschreiben das Ziel, ein Sprachmodell schreibt den Code, den Sie selbst nicht mehr lesen. Für Prototypen, Auswertungen und kleine interne Werkzeuge funktioniert das hervorragend. Teuer wird es dort, wo daraus dauerhaft betriebene Software wird — wegen Wartbarkeit, fehlender Tests, ungeprüfter Abhängigkeiten und unklarer Zuständigkeit.

1. Was Vibe Coding ist — und was der Erfinder dazu sagte

Der Begriff stammt von Andrej Karpathy, Mitgründer von OpenAI und früherer KI-Chef bei Tesla. Anfang Februar 2025 beschrieb er auf X eine Arbeitsweise, bei der man sich ganz auf das Sprachmodell einlässt, jede vorgeschlagene Änderung annimmt und Fehlermeldungen einfach zurück in den Chat kopiert, bis es läuft. Der entscheidende Teil seiner Beschreibung: dass man dabei vergisst, dass der Code überhaupt existiert.

Diese Formulierung ist keine Marketing-Übertreibung, sondern die eigentliche Definition. Vibe Coding ist nicht dasselbe wie „mit KI programmieren". Ein Entwickler, der sich Vorschläge erzeugen lässt, sie liest, prüft und anpasst, betreibt KI-gestützte Entwicklung. Vibe Coding beginnt dort, wo der Prüfschritt entfällt. Genau diese Auslassung macht die Methode so schnell — und begründet jedes Problem, das später auftaucht.

Bemerkenswert ist, wie Karpathy den Ansatz selbst einordnete: als tauglich für Wegwerf-Projekte am Wochenende. Diese Einschränkung ging auf dem Weg vom Beitrag in die Konferenzfolien verloren. Wer heute im Unternehmen über Vibe Coding diskutiert, diskutiert also meist über etwas anderes, als der Urheber gemeint hat.

Zwei Nachbarthemen grenzen wir bewusst ab: Wie Sie eine Anweisung an ein Sprachmodell überhaupt so formulieren, dass etwas Brauchbares herauskommt, behandelt unser Beitrag zu Prompt Engineering. Welche Werkzeugklassen im Mittelstand sonst noch im Einsatz sind, zeigt die Übersicht zu KI-Tools für Unternehmen. Hier geht es ausschließlich um die Software, die dabei entsteht, und darum, was im Betrieb mit ihr passiert.

2. Was die Forschung bisher zeigt

Die Debatte läuft überwiegend mit Anekdoten. Es gibt aber belastbare Untersuchungen, und ihr Bild ist differenzierter als beide Lager behaupten. Drei Befunde sind für die Entscheidung im Unternehmen relevant:

Zur Einordnung der 19-Prozent-Zahl gehört eine Ehrlichkeit, die in vielen Zitaten fehlt: Die Autoren grenzen ihr Ergebnis selbst ein. Untersucht wurden sehr erfahrene Entwickler in Projekten, die sie seit Jahren kennen — dort ist der Vorsprung des Menschen naturgemäß am größten. Für jemanden, der eine Sprache nicht beherrscht oder eine fremde Aufgabe angeht, kann das Ergebnis umgekehrt ausfallen. Die Studie widerlegt den Nutzen von KI-Werkzeugen also nicht. Sie widerlegt die Annahme, der Gewinn sei überall gleich groß und zuverlässig spürbar.

Für die Praxis folgt daraus eine unbequeme Konsequenz: Ihr Gefühl ist kein Messwert. Wenn Sie wissen wollen, ob ein Werkzeug Ihrem Team hilft, brauchen Sie eine schlichte Vorher-Nachher-Messung an einer wiederkehrenden Aufgabe — nicht die Einschätzung nach dem ersten begeisterten Nachmittag.

3. Die Ampel: Was Sie im Unternehmen so bauen dürfen

Die Frage „ist Vibe Coding gut?" lässt sich nicht allgemein beantworten, weil sie falsch gestellt ist. Sinnvoll ist die Frage nach dem Einsatzzweck. Wir arbeiten in Projekten mit einer bewusst einfachen Ampel. Sie ist unsere Einordnung aus der Projektpraxis, kein Branchenstandard — aber sie beendet in Workshops zuverlässig die Grundsatzdiskussion, weil sie den Streit vom Werkzeug auf den Anwendungsfall verschiebt.

Der Sprung von Gelb auf Rot hat einen gemeinsamen Nenner: Sobald Software schreibend in ein System eingreift oder personenbezogene Daten verarbeitet, wird aus einem Werkzeug ein Betriebsmittel. Ab diesem Punkt gelten dieselben Anforderungen wie für jede andere Fachanwendung — unabhängig davon, ob ein Mensch oder ein Modell den Code getippt hat. Wie eng dieser Rahmen bei Systemen wird, die selbstständig handeln, zeigt unser Beitrag zu Agentic AI und autonomen Agenten; dort geht es um Freigaben und Rechteschnitt, hier um die Entstehung des Codes.

Ein gutes Beispiel für die mittlere Ampelstufe ist das Kundenportal. Eine Oberfläche mit Auftragsliste ist schnell erzeugt; sobald sie aber kundenspezifische Preise, Belege und mehrere Nutzer je Kundenunternehmen abbildet, verlässt sie den unkritischen Bereich — ein Rechtefehler zeigt Kunde A die Daten von Kunde B, mit Meldefrist. Warum vor dem Bauen erst eine Inventur der vorhandenen Bordmittel steht, beschreibt der Beitrag Kundenportal: bauen, kaufen oder Shop-Konto ausbauen?.

4. Wo es nach der ersten Woche teuer wird

Vibe Coding scheitert selten am ersten Tag. Es scheitert an Tag zwanzig, und dann leise. Diese fünf Kostenstellen sehen wir am häufigsten, wenn wir Werkzeuge übernehmen, die in einer Fachabteilung entstanden sind:

Keine dieser Kostenstellen ist ein Argument gegen KI-gestützte Entwicklung. Sie sind ein Argument dagegen, den Prüfschritt wegzulassen und die Übergabe nicht mitzudenken. Der Aufwand, der hier entsteht, ist außerdem kein Naturgesetz: Er lässt sich am Anfang für wenige Stunden einkaufen oder am Ende für einige Tage bezahlen.

5. Sicherheit: erfundene Pakete und echte Angriffe

Ein Sicherheitsproblem verdient besondere Aufmerksamkeit, weil es sich nicht durch Sorgfalt beim Lesen erledigt. Sprachmodelle schlagen regelmäßig Programmbibliotheken vor, die es gar nicht gibt. Eine Untersuchung, die 2025 auf dem USENIX Security Symposium vorgestellt wurde, hat dafür 576.000 erzeugte Code-Beispiele aus 16 Modellen ausgewertet: Bei kommerziellen Modellen enthielten 5,2 Prozent der Vorschläge erfundene Paketnamen, bei quelloffenen Modellen 21,7 Prozent. Insgesamt kamen über 205.000 verschiedene Fantasienamen zusammen.

Der eigentliche Angriff entsteht aus der Wiederholbarkeit. Fragt man dasselbe zehnmal, taucht ein erheblicher Teil derselben erfundenen Namen jedes Mal wieder auf. Angreifer können solche Namen also vorhersagen und vorab als echtes Paket registrieren — mit Schadcode darin. Wer den Vorschlag des Modells ungeprüft installiert, holt sich die Hintertür selbst ins Haus. Die Fachwelt nennt dieses Muster „Slopsquatting". Auch das OWASP-Projekt für KI-Anwendungen führt die Lieferkette und die ungeprüfte Weiterverarbeitung von Modell-Ausgaben als eigene Risikoklassen.

Gegen dieses Risiko hilft kein besseres Modell, sondern ein kurzer Handgriff. Vier Punkte gehören für uns zum Minimum, sobald erzeugter Code das Notizbuch verlässt:

• Jede Abhängigkeit gegen das offizielle Verzeichnis prüfen — existiert das Paket wirklich, seit wann, wer pflegt es, wie viele nutzen es?
• Vorschläge nie blind installieren. Ein unbekannter Name ist ein Grund zum Nachschlagen, nicht zum Bestätigen.
• Getrennte Umgebungen nutzen — was ausprobiert wird, läuft nicht auf demselben Rechner wie Ihre produktiven Zugänge.
• Zugangsdaten niemals im erzeugten Code lassen. Modelle schreiben Schlüssel gern direkt in die Datei, wo sie später im Backup und im Repository landen.

Die zweite Sicherheitsfrage betrifft Ihre Daten, nicht Ihren Code: Was passiert mit dem, was Sie in das Werkzeug eingeben? Welche Werkzeuge welche Inhalte sehen dürfen, sollten Sie einmal grundsätzlich klären; die Kriterien dafür haben wir im Beitrag zu ChatGPT und Datenschutz im Unternehmen zusammengestellt.

Wer den erzeugten Code lieber gar nicht erst nach außen gibt, denkt schnell an ein selbst betriebenes Modell. Das beantwortet die Datenfrage und stellt sofort eine neue: Die lokale Programmierschnittstelle von Ollama kennt keine Authentifizierung, und ab Werk verarbeitet sie nur eine Anfrage gleichzeitig. Beides gehört geklärt, bevor mehrere Kolleginnen und Kollegen darauf zugreifen. Wie Sie Ollama sicher im eigenen Netz betreiben und welche Modelle lizenzrechtlich überhaupt infrage kommen, behandeln wir gesondert.

6. Die Grenze ziehen: Was ins Review gehört und wann ein Entwickler ran muss

Die Ampel oben beantwortet, ob etwas gebaut werden darf. Bleibt die Frage, wer es verantwortet. In der Praxis lässt sich das an einer einzigen Frage festmachen: Wer trägt den Schaden, wenn das Werkzeug still das Falsche tut? Danach sortieren wir.

Das darf ohne Entwickler entstehen und laufen:

• Alles, dessen Ergebnis ein Mensch sieht und beurteilt, bevor es weiterverwendet wird.
• Werkzeuge, die ausschließlich lesen — Auswertungen, Übersichten, Vergleiche, Suchhilfen.
• Anwendungen auf einer Datenkopie, die bei einem Fehler einfach neu gezogen wird.
• Alles, was ohne Verlust weggeworfen werden kann, weil es in zwei Stunden neu entsteht.

Das gehört ins Review oder in Entwicklerhand:

• Jeder schreibende Zugriff auf ein System, das andere Menschen weiterverwenden.
• Alles mit personenbezogenen Daten — auch die vermeintlich harmlose Adressliste.
• Werkzeuge, die unbeaufsichtigt nach Zeitplan laufen und deren Fehler niemand bemerkt.
• Alles, was mehr als eine Person nutzt oder länger als ein Quartal leben soll.
• Jede Anbindung nach außen: Schnittstellen, Zahlungsdienste, Versand, Marktplätze.

Praktisch bewährt hat sich eine schlichte Hausregel, die in zwei Sätze passt: Wer ein Werkzeug baut, trägt es auch — und wer es nicht tragen kann, meldet es vorher an. Diese Regel kostet nichts, verhindert aber die stille Schatten-IT, die sonst über Monate entsteht. Ergänzen Sie sie um ein einfaches Verzeichnis, in dem steht, welches Werkzeug wofür da ist, wer zuständig ist und welche Daten es anfasst.

Vor der Frage, wie eine eigene Anwendung entsteht, steht die Frage, ob sie überhaupt entstehen muss. Für Formulare, Freigaben und Erfassungen innerhalb der eigenen Belegschaft ist eine Low-Code-App auf der vorhandenen Microsoft-Plattform meist die wirtschaftlichere Wahl. Die Rechnung kippt erst bei vielen betriebsfremden Nutzern, bei hoher Last oder wenn eine eigene Oberfläche gefordert ist. Die Entscheidungstabelle dazu steht im Beitrag zu Power Apps im Mittelstand.

7. Wie wir das in eigenen Projekten handhaben

Wir entwickeln Plugins, Schnittstellen und Web-Anwendungen für den Handel und setzen KI-Werkzeuge dabei täglich ein. Unsere Erfahrung deckt sich mit den Studien: Der Gewinn ist real, aber er liegt woanders, als der erste Eindruck vermuten lässt. Am stärksten hilft die KI beim Einstieg in fremden Code, bei Routinearbeit wie Testfällen und Migrationsskripten und bei allem, was viel Tipparbeit und wenig Entscheidung ist.

Drei Gewohnheiten haben sich bei uns durchgesetzt. Erstens lesen wir jede erzeugte Änderung, bevor sie übernommen wird — nicht aus Prinzipientreue, sondern weil die Fehler, die dabei auffallen, später Stunden kosten würden. Zweitens beschreiben wir vorher, wie das Ergebnis geprüft wird, statt hinterher zu schauen, ob es zufällig passt. Drittens bekommt jedes Werkzeug einen Namen, einen Zuständigen und einen Ablageort, bevor es zum zweiten Mal benutzt wird.

Die häufigste Stolperfalle in Kundenprojekten ist keine technische. Es ist die Erwartung, dass ein in zwei Stunden erzeugtes Werkzeug auch in zwei Stunden produktionsreif ist. Zwischen „läuft bei mir" und „läuft im Unternehmen" liegen Fehlerbehandlung, Rechte, Protokollierung und Übergabe. Diese Strecke ist genau die Arbeit, die Vibe Coding nicht abnimmt — und sie ist der Grund, warum wir KI-gestützte App-Entwicklung mit Review, Tests und Dokumentation anbieten statt als reine Generierung.

8. Fazit: Nicht das Tempo entscheidet, sondern die Übergabe

Vibe Coding ist eine ehrliche Erleichterung für alles, was klein, lesend und kurzlebig ist. In diesem Feld sollten Sie es Ihrem Team ausdrücklich erlauben, denn dort entstehen in Stunden Werkzeuge, für die früher nie ein Budget da war. Der Fehler liegt nicht im Ausprobieren, sondern im unbemerkten Übergang: wenn aus dem Experiment ein Betriebsmittel wird, ohne dass jemand die Verantwortung dafür übernimmt.

Ziehen Sie diese Linie bewusst und schriftlich. Eine Ampel, ein Verzeichnis der Werkzeuge und die Regel, dass schreibende Zugriffe und personenbezogene Daten ein Review verlangen, reichen als Rahmen für den Anfang völlig aus. Wichtiger als jedes Werkzeug ist die Fähigkeit Ihres Teams, ein Ergebnis zu beurteilen — genau diese Kompetenz bauen wir in unseren KI-Schulungen für Unternehmen auf.

Wenn Sie einen konkreten Anwendungsfall vor sich haben und nicht sicher sind, auf welcher Ampelstufe er steht, schauen wir gemeinsam darauf — und sagen Ihnen ehrlich, ob Ihr Team das selbst bauen kann oder ob es Entwicklung braucht. Soll Ihr Team die Beurteilung dauerhaft selbst leisten, ist eine KI-Schulung im eigenen Haus der schnellere Weg als ein weiteres Werkzeug.

Hinweis: Dieser Beitrag ist eine technische und organisatorische Einordnung, keine Rechtsberatung. Die genannten Studienergebnisse geben den Stand August 2026 wieder und gelten jeweils nur für den untersuchten Rahmen; die Ampel-Einordnung ist unsere Praxis-Empfehlung und kein Standard. Für datenschutzrechtliche Bewertungen im Einzelfall ziehen Sie bitte Ihren Datenschutzbeauftragten oder eine Rechtsberatung hinzu.

9. Häufige Fragen zu Vibe Coding

Was ist Vibe Coding?

Vibe Coding bezeichnet das Erzeugen von Software durch Anweisungen in natürlicher Sprache: Sie beschreiben, was das Programm tun soll, ein Sprachmodell schreibt den Code. Der Begriff stammt von Andrej Karpathy und meint ursprünglich, den erzeugten Code nicht mehr selbst zu lesen. Genau diese Auslassung entscheidet später über die Kosten.

Ist Vibe Coding gut?

Für Prototypen, interne Auswertungen und kleine Hilfswerkzeuge ist es ausgezeichnet: Sie sehen in Stunden, ob eine Idee trägt. Für Software, die dauerhaft laufen, Kundendaten verarbeiten oder von Kollegen gepflegt werden soll, reicht es allein nicht. Die ehrliche Antwort hängt also nicht am Werkzeug, sondern am Einsatzzweck.

Ist Vibe Coding sicher?

Nicht von allein. Zwei Risiken sind belegt: Sprachmodelle erfinden Paketnamen, die Angreifer gezielt registrieren, und ungeprüfter Code übernimmt bekannte Schwachstellenmuster. Sicher wird es durch Prüfung: Abhängigkeiten gegen die offiziellen Verzeichnisse abgleichen, Zugriffsrechte eng schneiden und niemals echte Kundendaten in ein ungeprüftes Werkzeug einspielen.

Was kostet Vibe Coding?

Die Werkzeuge selbst kosten wenig, meist eine überschaubare Monatsgebühr je Nutzer. Der eigentliche Aufwand entsteht danach: Prüfung, Tests, Absicherung, Betrieb und die Übergabe an jemanden, der das Werkzeug pflegt. Rechnen Sie deshalb nicht die gesparten Entwicklungsstunden, sondern die Gesamtkosten über zwei Jahre.

Gibt es ein Beispiel für Vibe Coding?

Ein typisches Beispiel aus dem Mittelstand: Eine Mitarbeiterin beschreibt, dass sie zwei Exportdateien monatlich abgleichen muss. Statt der Excel-Bastelei entsteht in einer Stunde ein kleines Werkzeug, das beide Dateien einliest und Abweichungen anzeigt. Es läuft lokal, verarbeitet keine personenbezogenen Daten und ersetzt eine wiederkehrende Handarbeit.

Welche KI wird für Vibe Coding verwendet?

Praktisch alle größeren Sprachmodelle können Code erzeugen; genutzt werden sie über drei Werkzeugklassen: Chat-Oberflächen, KI-gestützte Editoren und Baukästen, die aus einer Beschreibung direkt eine Web-Anwendung erzeugen. Eine seriöse Bestenliste gibt es nicht, weil sich Modelle und Preise laufend ändern. Entscheiden Sie nach Datenhaltung, Anbindung und Prüfbarkeit.

Wie kann ich Vibe Coding lernen?

Beginnen Sie mit einem echten, aber unkritischen Problem aus Ihrem Alltag und bauen Sie es zu Ende, inklusive Test und Übergabe. Nützlicher als ein Kurs zur Bedienung ist die Fähigkeit, Ergebnisse zu bewerten. Genau darauf legen wir in unseren KI-Schulungen den Schwerpunkt, statt auf Werkzeug-Klickwege.

10. Quellen & weiterführende Fachliteratur

Die Zahlen und Befunde in diesem Beitrag stützen sich auf folgende Quellen (geprüft am 29. August 2026). Externe Links öffnen in einem neuen Tab. Die Ampel-Einordnung und die fünf Kostenstellen stammen aus unserer Projektpraxis und sind als solche gekennzeichnet.

• METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (Juli 2025) — randomisierte kontrollierte Studie mit 16 erfahrenen Entwicklern und 246 realen Aufgaben; Quelle der 19-Prozent-Angabe samt der von den Autoren selbst genannten Einschränkungen. Fassung als Fachaufsatz: arXiv 2507.09089.
• Spracklen et al. — We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs (USENIX Security 2025) — Quelle der Zahlen zu erfundenen Paketnamen: 576.000 Code-Beispiele, 5,2 Prozent bei kommerziellen und 21,7 Prozent bei quelloffenen Modellen, über 205.000 eindeutige Fantasienamen und deren Wiederholbarkeit.
• Fraunhofer IESE — Vibe Coding verstehen: Definition, Potenziale und Risiken (November 2025) — Einordnung als Beschleuniger statt Ersatz für Software-Engineering, Notwendigkeit fachlicher Validierung und die Abhängigkeit des Risikos von Komplexität und Kritikalität.
• Sarkar & Drosos — Vibe coding: programming through conversation with artificial intelligence — Befund, dass Programmierkompetenz nicht entfällt, sondern sich zu Kontext-Management und schneller Bewertung erzeugten Codes verlagert.
• OWASP — Top 10 for LLM and Generative AI Applications (2025) — Lieferketten-Risiken und die unzureichende Prüfung von Modell-Ausgaben als eigenständige Risikoklassen für KI-gestützte Anwendungen.
• Wikipedia — Vibe-Coding — Herkunft des Begriffs bei Andrej Karpathy im Februar 2025, Definition und Übersicht der Rezeption samt weiterführender Fachliteratur zur Sicherheit erzeugten Codes.