Alle Beiträge

KIVeröffentlicht am 20. November 2025Aktualisiert am 10. September 20267 Min Lesezeit

Vibe Coding: Wann KI-generierter Code produktionsreif ist

Was Vibe Coding von KI-unterstützter Entwicklung unterscheidet und warum Produktionsreife am Entwicklungsprozess hängt, nicht am Werkzeug.

Von Michael Schuster

Quelltext auf einem dunklen Bildschirm in Nahaufnahme

Software entsteht heute oft im Gespräch mit einem KI-Modell. Du beschreibst, was ein Programm tun soll, und das Modell schreibt den Code, passt ihn an und behebt Fehler, die du ihm zurückmeldest. Für diese Arbeitsweise hat sich der Begriff Vibe Coding durchgesetzt.

Ob so entstandene Software im Unternehmen produktiv eingesetzt werden kann, lässt sich nicht mit Ja oder Nein beantworten. Es hängt weniger davon ab, ob eine KI den Code geschrieben hat, als davon, was danach mit dem Code passiert.

Was Vibe Coding ist

Den Begriff hat der KI-Forscher Andrej Karpathy im Februar 2025 geprägt. Er beschrieb damit eine Arbeitsweise, bei der man sich ganz auf das Modell verlässt und den Code selbst weitgehend ignoriert: Änderungen werden übernommen, ohne sie im Detail zu lesen, Fehlermeldungen gehen zurück an das Modell, bis das Programm läuft. Karpathy sah das eher für kleine Wochenendprojekte zum Ausprobieren.

Seitdem wird der Begriff oft für jede Form von Programmierung mit KI verwendet. Das verwischt eine Unterscheidung, auf die unter anderem der Entwickler Simon Willison hingewiesen hat: Wer Code von einer KI schreiben lässt, ihn aber prüft, gründlich testet und erklären kann, wie er funktioniert, betreibt Softwareentwicklung mit KI-Unterstützung. Vibe Coding im ursprünglichen Sinn lässt genau diese Schritte weg.

Für die Frage nach der Produktionsreife ist diese Trennung entscheidend:

  • KI-unterstützte Entwicklung: Die KI schreibt Code, schlägt Lösungen vor oder erklärt bestehenden Code. Entwickler prüfen, testen und verantworten das Ergebnis. KI-generierter Code ist hier ein normaler Bestandteil professioneller Softwareentwicklung.
  • Vibe Coding: Das Ergebnis wird danach beurteilt, ob es zu funktionieren scheint. Wie es funktioniert und was es sonst noch tut, prüft niemand systematisch.
  • Prompt-to-Production: Ergebnisse aus Vibe Coding gehen ohne ausreichende Prüfung in den produktiven Betrieb. An dieser Stelle wird aus einem nützlichen Werkzeug ein Risiko.

Wie weit du damit heute kommst

Mit aktuellen Modellen und Werkzeugen lassen sich Prototypen, kleine Anwendungen, Skripte und Oberflächen oft deutlich schneller bauen als früher, teilweise auch von Menschen, die nicht programmieren können. Das hat einen echten Wert: Ideen lassen sich ausprobieren, bevor jemand Wochen in ein Konzept steckt.

Wie viel Zeit das spart und wie gut das Ergebnis wird, hängt stark von der Aufgabe ab. Ein neues, abgegrenztes Projekt mit klarem Ziel ist etwas anderes als eine Änderung in einem über Jahre gewachsenen System. Dort steckt viel Wissen nicht im Code, sondern in Absprachen, Sonderfällen und Entscheidungen, die nirgends dokumentiert sind. Was das Modell nicht als Kontext bekommt, kann es nicht berücksichtigen.

Wo die Risiken liegen

Die typischen Probleme von ungeprüftem KI-Code sind nicht grundsätzlich neu. Auch Menschen schreiben fehlerhaften und unsicheren Code. Neu ist, wie schnell viel Code entsteht, den im Team niemand im Detail kennt.

  • Unauffällige Fehler: Code funktioniert in den ausprobierten Fällen und rechnet in Sonderfällen falsch, verliert Daten oder bricht ab. Wer nur prüft, ob es läuft, sieht das nicht.
  • Sicherheitslücken: fehlende Prüfung von Eingaben, zu weit gefasste Berechtigungen, ungeschützte Schnittstellen oder Zugangsdaten, die im Code oder im Browser landen.
  • Abhängigkeiten: Das Modell bindet Bibliotheken ein, die veraltet, unsicher oder unnötig sind, und schlägt gelegentlich Pakete vor, die es gar nicht gibt.
  • Datenschutz: Personenbezogene Daten werden gespeichert, protokolliert oder an Dienste übertragen, ohne dass das jemand bewusst entschieden hat.
  • Wartbarkeit: Code, den niemand versteht, lässt sich schwer ändern. Jede Änderung wird zu einem neuen Versuch mit dem Modell, mit dem Risiko, an anderer Stelle etwas kaputtzumachen.
  • Verantwortung: Wenn etwas schiefgeht, muss jemand den Fehler finden, beheben und dafür geradestehen. „Das hat die KI geschrieben“ ersetzt diese Rolle nicht.

Was Software produktionsreif macht

Ob Code von einem Menschen, einer KI oder beiden stammt: Für den produktiven Einsatz zählt der Prozess drumherum. Je nach Anwendung gehören dazu:

  • Anforderungen: Es ist geklärt, was die Software tun soll, was ausdrücklich nicht und welche Sonderfälle es gibt.
  • Architektur: Aufbau, Datenhaltung und Verbindungen zu anderen Systemen sind bewusst entschieden.
  • Code Review: Jemand, der den Code versteht, liest und prüft ihn.
  • Tests: Automatische Tests decken die wichtigen Fälle ab, auch Fehler und Grenzfälle.
  • Security: Eingaben werden geprüft, Anmeldung und Berechtigungen sind sauber gelöst.
  • Secrets: API-Schlüssel und Passwörter liegen nicht im Code und sind nur dort verfügbar, wo sie gebraucht werden.
  • Datenschutz: Es ist klar, welche personenbezogenen Daten wo, wie lange und auf welcher Grundlage verarbeitet werden.
  • Abhängigkeiten: Eingebundene Bibliotheken und Dienste sind bekannt und werden aktuell gehalten.
  • CI/CD: Änderungen laufen über einen festen Weg mit automatischen Prüfungen, bevor sie live gehen.
  • Monitoring: Fehler und Ausfälle fallen auf, bevor Kunden sie melden.
  • Dokumentation und Wartbarkeit: Jemand anderes kann die Software später verstehen und ändern.
  • Verantwortlichkeiten: Es ist festgelegt, wer die Anwendung betreibt und wer bei Problemen reagiert.

KI kann bei vielen dieser Schritte helfen, etwa Tests schreiben, Code erklären oder mögliche Sicherheitsprobleme aufzeigen. Die Schritte selbst fallen dadurch nicht weg.

Das Risiko entscheidet, nicht die Branche

Statt ganze Branchen pauschal auszuschließen, hilft eine Einordnung nach Risiko. Die Leitfrage lautet: Was passiert, wenn die Software falsch arbeitet, ausfällt oder Daten preisgibt?

  • Experiment oder Prototyp: Die Software dient zum Ausprobieren und wird danach verworfen oder neu gebaut. Vibe Coding passt hier gut, solange keine echten Kundendaten und keine Zugänge zu produktiven Systemen im Spiel sind.
  • Internes Hilfstool: ein kleines Werkzeug für das eigene Team, etwa zum Umwandeln von Dateien oder für eine einfache Auswertung. Ein Blick in den Code, einige Tests und eine klare Zuständigkeit reichen oft. Sobald das Tool auf Unternehmensdaten zugreift, gehören Berechtigungen und sichere Zugangsdaten dazu.
  • Öffentliches Marketingtool: ein Rechner, ein Quiz oder eine Landingpage, die jeder aufrufen kann. Hinzu kommen Eingabeprüfung, Schutz vor Missbrauch, Datenschutz bei Formularen und Tracking sowie Barrierefreiheit.
  • Anwendung mit personenbezogenen Daten: Hier braucht es Code Review, Tests, ein Berechtigungskonzept und eine Klärung, wo die Daten verarbeitet werden.
  • Geschäftskritisches System: Wenn ein Ausfall Umsatz kostet oder Abläufe blockiert, gehören Architektur, CI/CD, Monitoring und ein Plan für Störungen dazu.
  • Regulierte oder sicherheitskritische Anwendung: etwa im Gesundheits- oder Finanzbereich. Hier gelten zusätzliche Anforderungen an Entwicklung, Dokumentation und Nachweise. Ob und wie KI-Werkzeuge dabei eingesetzt werden dürfen, hängt von den jeweiligen Vorgaben ab. Ungeprüfter Code hat dort keinen Platz.

Je höher Fehlerfolgen, Datenschutz- und Sicherheitsrisiko, desto stärker müssen Review, Tests und Governance sein. Viele Anwendungen beginnen als Prototyp und rutschen ohne bewusste Entscheidung in den produktiven Betrieb. Spätestens dann sollte jemand prüfen, auf welcher Stufe die Anwendung inzwischen steht.

Wenn du im Unternehmen damit anfangen willst

  1. Mit einem begrenzten Projekt starten. Ein Prototyp oder ein internes Hilfstool eignet sich besser als das Kernsystem.
  2. Die Risikostufe vorher festlegen. Welche Daten verarbeitet die Anwendung, wer nutzt sie, was passiert bei einem Fehler? Daraus ergibt sich, wie viel Prüfung nötig ist.
  3. Zeit für Review und Tests einplanen. Der Code entsteht schneller, die Prüfung nicht automatisch.
  4. Zugänge und Daten schützen. Keine produktiven Zugangsdaten und keine echten Kundendaten in Experimente, und vorher klären, welche Daten an den KI-Anbieter gehen.
  5. Zuständigkeit klären. Jemand muss die Anwendung verstehen, betreiben und bei Problemen reagieren können.

Bei Admantics nutzen wir KI beim Programmieren und beim Aufbau von Automatisierungen. Was für Kunden live geht, wird von Menschen geplant, geprüft und getestet. Wie wir dabei vorgehen, steht auf unserer Seite zu Marketing Automation.

Häufige Fragen

Werden Programmierer durch Vibe Coding ersetzt?

Die Arbeit verändert sich: Ein Teil des Code-Schreibens verlagert sich auf das Modell. Anforderungen klären, Architektur entscheiden, prüfen und verantworten bleiben Aufgaben, für die es Fachwissen braucht. Wie sich das langfristig auf Berufsbilder und den Arbeitsmarkt auswirkt, lässt sich heute nicht verlässlich sagen.

Kann ich ohne Programmierkenntnisse selbst Software bauen?

Für Prototypen, persönliche Werkzeuge und kleine interne Tools oft ja. Schwierig wird es, sobald andere Menschen die Software nutzen, Daten verarbeitet werden oder sie zuverlässig laufen muss. Dann brauchst du jemanden, der den Code prüfen und die Risiken einschätzen kann.

Welche Tools eignen sich für Vibe Coding?

Es gibt Entwicklungsumgebungen mit eingebauter KI, Assistenten, die direkt in einem Code-Projekt arbeiten, und Browser-Tools, die aus einer Beschreibung eine lauffähige Anwendung erzeugen. Das Angebot ändert sich schnell. Wichtiger als der Name ist, ob du den erzeugten Code einsehen, versionieren und in bestehende Prüfprozesse einbinden kannst.

Was sollte mein Team lernen?

Nicht nur, wie man gute Anweisungen formuliert, sondern vor allem, wie man KI-generierten Code liest, testet und auf Sicherheit prüft. Dazu gehört auch, zu erkennen, wann eine Anwendung die Risikostufe wechselt und mehr Prüfung braucht.

Weiterlesen

Nächster Schritt

Wo liegt dein nächster wirtschaftlicher Hebel?

Im ersten Gespräch schauen wir uns an, wo die Strecke heute reißt: bei der Nachfrage, an der Landingpage oder erst in der Bearbeitung. Danach weißt du, was sich zuerst lohnt.