Vibe Coding im Unternehmen: Die Entscheidungsgrundlage

In vielen Führungsrunden fällt inzwischen derselbe Satz: „Das hat jemand an einem Wochenende mit KI gebaut.“ Mal ist es ein internes Werkzeug aus dem Vertrieb, mal der Prototyp eines Dienstleisters, mal ein Konkurrenzprodukt, das plötzlich auftaucht. Die Frage an die Geschäftsleitung ist dann selten technisch. Sie lautet: Lohnt sich das für uns, sollten wir selbst so arbeiten, und wer haftet, wenn es schiefgeht?

Um diese Frage sauber zu beantworten, braucht es zuerst eine klare Begriffsklärung. Denn „Vibe Coding“ wird inzwischen für fast alles verwendet, was mit KI und Software zu tun hat. Das verwischt genau die Unterscheidung, auf die es für Ihre Entscheidung ankommt.

Die Unterscheidung, auf die es ankommt: geprüft oder ungeprüft

Den Begriff hat der KI-Forscher Andrej Karpathy Anfang 2025 geprägt. Er beschrieb damit eine Arbeitsweise, bei der man einer KI in Alltagssprache sagt, was man haben möchte, die Vorschläge ungeprüft übernimmt und Fehlermeldungen einfach zurück an die KI gibt. Der Code selbst wird dabei nicht mehr gelesen. Karpathy selbst hielt das ausdrücklich für Wegwerf-Projekte am Wochenende für geeignet.

Der Entwickler und Autor Simon Willison hat daraus eine Definition gemacht, die sich für Entscheider gut eignet: Vibe Coding heißt, Software mit einem Sprachmodell zu bauen, ohne den erzeugten Code zu prüfen. Wenn dagegen ein Mensch den KI-Code liest, testet und erklären kann, was er tut, ist das schlicht Softwareentwicklung, nur mit einem neuen Werkzeug. Willisons eigene Regel: Er übernimmt keinen Code, den er einer anderen Person nicht genau erklären könnte.

Für Sie heißt das: Die entscheidende Frage ist nicht, ob KI beteiligt war, sondern ob jemand den Code verstanden und geprüft hat. Begriffe wie Coding-Agent, Prototyp oder technische Schulden finden Sie kurz erklärt im Glossar.

Wo Vibe Coding echten Wert hat

Es wäre ein Fehler, Vibe Coding pauschal abzulehnen. Willison beschreibt zwei Stärken, die auch im Unternehmen zählen:

• Die Einstiegshürde sinkt fast auf null. Auch ohne Informatikstudium lassen sich kleine, sehr spezifische Werkzeuge bauen, etwa um lästige Routinearbeit zu automatisieren. Eine Idee wird so greifbar, bevor jemand ein Projekt beantragt.
• Erfahrene Entwickler lernen schnell, was die Werkzeuge können. Wer viele kleine Experimente baut, entwickelt ein Gespür dafür, wo KI hilft und wo nicht. Für Ihr Entwicklungsteam sind solche Experimente der günstigste Weg, Erfahrung aufzubauen, bevor Sie über Lizenzen für alle oder neue Arbeitsweisen entscheiden.

Für die Geschäftsleitung ist das eine Chance: schnelle Prototypen, um eine Idee greifbar zu machen, bevor Budget in ein echtes Projekt fließt. Die Frage, die Sie stellen sollten: Wofür genau wird der Prototyp gebraucht, und wann ist er „fertig genug“, um ihn wegzuwerfen?

Wann es riskant wird

Willison nennt vier Prüffragen, ab wann Vibe Coding nicht mehr harmlos ist. Sie lassen sich direkt in Leitungssprache übersetzen:

• Wie hoch ist der Einsatz? Kann ein Fehler Geld, Ruf oder Menschen schaden? Sobald andere die Software nutzen, steigt das Gewicht dieser Frage erheblich.
• Sind Zugangsdaten im Spiel? Wer nicht versteht, wie der Code funktioniert, merkt nicht, wenn Passwörter oder Schlüssel ungewollt offenliegen.
• Werden vertrauliche Daten verarbeitet? Ohne Codeverständnis ist unklar, ob Daten den eigenen Rechner oder das eigene Netz verlassen.
• Hängen nutzungsabhängige Kosten daran? Willison berichtet von Fällen, in denen ungeprüft gebaute Anbindungen an kostenpflichtige Dienste ohne Ausgabengrenze Rechnungen in Tausenderhöhe verursacht haben.

Seine Empfehlung: Bevor etwas Vibe-codiertes anderen Menschen zur Verfügung gestellt wird, sollte jemand mit Erfahrung draufschauen. Welche Verantwortung daraus für die Leitung folgt, vertiefen wir in Risiken von Vibe Coding: Was die Leitung verantwortet.

Prototyp ist nicht Produkt

Wie groß die Lücke zwischen „gebaut“ und „betrieben“ ist, zeigt eine aktuelle Diskussion auf Reddit mit rund 280 Kommentaren. Anlass war ein Entwickler, der Nachbauten mehrerer bekannter Kreativprogramme mit KI erstellt und frei veröffentlicht hatte. Die Frage: Wenn jeder Software bauen kann, wer kauft dann noch?

Die Antworten waren aufschlussreich für jeden, der Software einkauft oder verkauft. Mehrere Teilnehmer berichten, dass die Nachbauten fehlerhaft und langsam seien. Ein Unternehmer argumentiert, Firmen kauften nie nur Software, sondern einen Anbieter: Support, Kompatibilität, Nachweise wie Sicherheitszertifizierungen, Dokumentation für den Betrieb auf vielen Rechnern und die Gewissheit, dass Sicherheitslücken geschlossen werden. Andere halten fest, dass Bauen etwas anderes sei als Warten, Skalieren und Absichern, und dass die meisten Menschen gar kein Interesse daran haben, ihre Werkzeuge selbst zu bauen. Eine Stimme bringt es auf den Punkt: Eine funktionierende Demo ist noch kein Produkt.

Für Ihr Unternehmen ergeben sich daraus zwei Blickrichtungen. Nach innen: Ein selbst gebautes Werkzeug spart Lizenzkosten, aber jemand muss es pflegen. Diese Pflege ist ein laufender Posten im Business Case, der beim Wochenend-Prototyp nicht auftaucht. Nach außen: Wenn Ihr Angebot vor allem aus Software besteht, die sich leicht nachbauen lässt, verschiebt sich Ihr Wettbewerbsvorteil hin zu Verlässlichkeit, Service und Vertrauen.

Und beim Einkauf: Die Kriterien aus der Diskussion – Support, Kompatibilität, Sicherheitsnachweise, Dokumentation für den Betrieb und die Gewissheit, dass Lücken geschlossen werden – sind auch der Maßstab für Dienstleister, die künftig mit KI-Werkzeugen für Sie bauen. Schneller gebaut heißt nicht, dass diese Punkte entfallen.

Was das für Ihre Entscheidung bedeutet

Sie müssen nicht programmieren können, um gut über Vibe Coding zu entscheiden. Sie brauchen eine klare Linie, die drei Fragen beantwortet:

• Chance: Wo darf schnell und ungeprüft gebaut werden, etwa für Prototypen, Experimente und persönliche Werkzeuge ohne sensible Daten?
• Risiko: Ab wann muss jemand den Code verstehen und prüfen, also sobald Kunden, Kollegen, vertrauliche Daten oder Kosten im Spiel sind?
• Nächster Schritt: Wer entscheidet im Einzelfall, ob aus einem Prototyp ein Produkt werden darf, und mit welchem Budget für Pflege und Betrieb? Die Kostenseite behandeln wir in Was kostet Vibe Coding wirklich?

Diese Linie ist keine Technikfrage, sondern eine Führungsentscheidung, weil sie über Budget, Haftung und die Arbeit Ihres Entwicklungsteams mitentscheidet.

Vibe Coding ist weder Wundermittel noch Spielerei. Es ist ein Werkzeug mit einem klaren Einsatzbereich, und die Grenze dieses Bereichs zieht die Geschäftsleitung.

Sie möchten diese Linie mit Ihrem Führungsteam gemeinsam ziehen, an Ihren eigenen Vorhaben? Dafür ist das Inhouse-Seminar gedacht; für das offene Seminar stehen die Termine noch nicht fest. Melden Sie unverbindlich Ihr Interesse an oder fragen Sie ein Inhouse-Seminar an.