Vibe Coding braucht Produktions-Governance

Die Diskussion über Vibe Coding wird erwachsen.

Am Anfang war vor allem die Geschwindigkeit spannend. Ein Gründer konnte eine Idee beschreiben und einen funktionierenden Prototyp bekommen. Eine Produktmanagerin konnte einen Workflow ausprobieren, bevor ein ganzes Team daran arbeitete. Ein Entwickler konnte mit Claude Code, Cursor, Codex-artigen Agenten, Lovable, Replit, Devin oder internen Tools schneller durch die Umsetzung kommen.

Diese Geschwindigkeit ist real. Sie ist aber nicht mehr die ganze Geschichte.

Die sinnvolle Frage lautet inzwischen, was passiert, wenn vibe-gecodete Arbeit kein Demo mehr ist, sondern Produktionssysteme, Kundendaten, Infrastruktur, Billing, Betrieb oder interne Geschäftsprozesse berührt.

Dort sitzt das Risiko. Nicht in KI-gestütztem Coding selbst, sondern im fehlenden Übergang von “funktioniert” zu “ist verantwortete Software”.

Der Prototyp kann leise kritisch werden

Produktionsrisiko kommt selten mit einem großen Launch.

Es kommt durch eine nützliche Abkürzung.

Jemand baut ein internes Dashboard, weil die manuelle Tabelle nervt. Jemand verbindet einen KI-generierten Workflow mit einer echten Datenbank. Jemand lässt einen Agenten ein Deployment-Skript patchen. Jemand übernimmt eine generierte Authentifizierungsänderung, weil die Tests grün sind. Jemand veröffentlicht ein kleines Tool, das nur drei Personen nutzen, und plötzlich hängt ein Teil des Unternehmens daran.

Keiner dieser Schritte ist automatisch fahrlässig. So beginnt nützliche Software oft.

Das Problem ist, dass KI die Reibung so stark senkt, dass der Übergang passieren kann, bevor die Organisation ihn bemerkt. Ein Prototyp gewinnt Nutzer. Ein Skript wird zum Prozess. Eine generierte Komponente wird Teil des Produkts. Eine vom Agenten erstellte Konfiguration wird Teil des Delivery-Systems.

Wenn sich an diesem Punkt das Governance-Modell nicht ändert, betreibt das Unternehmen Produktionssoftware mit Prototyp-Ownership.

”Es funktioniert” ist kein Release-Kriterium

Vibe Coding ist gut darin, sichtbaren Fortschritt zu erzeugen.

Ein Screen erscheint. Ein Flow funktioniert. Eine Datenbankabfrage liefert Daten. Ein Test ist grün. Ein Deployment läuft durch. Das Demo überzeugt.

Produktionssoftware braucht aber mehr als sichtbaren Fortschritt.

Sie braucht Antworten auf weniger aufregende Fragen:

• Wer besitzt diesen Code nach der ersten Version?
• Welche Daten darf er lesen oder verändern?
• Welche Credentials nutzt er?
• Was passiert bei einem Fehler?
• Wie wird mehr als nur der Happy Path getestet?
• Welche Logs und Alerts gibt es?
• Welche Sicherheitsannahmen hat der Agent getroffen?
• Welche Teile sind kopiert, generiert oder vom Team nicht wirklich verstanden?
• Wie wird diese Software später sicher geändert?

Diese Fragen sind keine Bürokratie. Sie sind der Unterschied zwischen einem nützlichen Prototyp und einer Geschäftsabhängigkeit.

Wenn KI-generierte Arbeit in Produktion geht, muss aus “es funktioniert” werden: “Wir wissen, warum es funktioniert, wo es scheitern kann und wer verantwortlich ist.”

Governance sollte an der Schwelle beginnen

Die Antwort ist nicht, Vibe Coding zu verbieten. Damit würde man eine nützliche Fähigkeit wegwerfen.

Die bessere Antwort ist, Schwellen zu definieren.

Ein Team kann explorative KI-Arbeit leichtgewichtig behandeln, solange sie in einer Sandbox bleibt. Menschen können experimentieren, Prototypen bauen, Produktideen vergleichen und interne Entwürfe erzeugen. Die Governance kann minimal sein, weil der Schadensradius minimal ist.

Die Schwelle ändert sich, sobald die Arbeit Folgendes berührt:

• Kundendaten;
• Produktionsdatenbanken;
• Authentifizierung oder Autorisierung;
• Payment, Billing oder Verträge;
• Infrastruktur und Deployment;
• regulierte oder sensible Workflows;
• operative Prozesse, von denen Menschen abhängen;
• öffentliche Nutzererlebnisse;
• Codepfade, die schwer zu reviewen oder zurückzurollen sind.

Ab diesem Punkt braucht die Arbeit einen anderen Weg. Nicht zwingend einen langsamen Weg, aber einen verantworteten Weg.

Dazu gehören menschlicher Review, Versionierung, Tests, Deployment-Regeln, Rollback-Denken und klare Verantwortung. Dazu gehört auch eine explizite Prüfung, was das KI-Tool sehen und tun durfte.

Ownership ist die fehlende Kontrolle

Viele KI-Coding-Fehler werden als technische Fehler beschrieben: schlechter Code, unsichere Defaults, kaputte Konfiguration, schwache Tests, chaotische Architektur.

Darunter liegen oft Ownership-Fehler.

Das Team hat nicht entschieden, wem generierter Code gehört. Es hat nicht entschieden, welche Agentenänderungen Review brauchen. Es hat nicht entschieden, ob ein internes Tool zu Produkt, Engineering, Operations oder niemandem gehört. Es hat nicht entschieden, wann ein nützliches Experiment in den normalen Delivery-Prozess überführt werden muss.

Also schwebt die Arbeit.

Das ist gefährlich, weil KI-generierte Software fertiger aussehen kann, als sie ist. Sie kann eine polierte Oberfläche, plausible Tests, selbstbewusste Erklärungen und ein funktionierendes Deployment haben. Die Oberfläche kann produktionsreif wirken, bevor die eigentliche Ownership existiert.

Für Gründer und CTOs ist die praktische Frage simpel:

Wenn das am Montag um 09:00 kaputtgeht, wer behebt es?

Wenn die Antwort unklar ist, ist das System noch nicht produktionsverwaltet.

Wie Produktions-Governance aussieht

Produktions-Governance muss nicht schwergewichtig sein.

Für KI-gestützte Arbeit reicht als erster Schritt ein kleiner Satz von Regeln, den alle verstehen.

Bevor KI-generierte oder vibe-gecodete Arbeit in Produktion geht, sollte es geben:

• einen benannten Owner;
• eine kurze Beschreibung des Geschäftszwecks;
• eine Liste der berührten Systeme und Daten;
• Versionierung und Review;
• Tests für die kritischen Pfade;
• einen Deployment- und Rollback-Weg;
• Berechtigungsgrenzen für Tools und Credentials;
• grundlegende Logs oder Observability;
• eine Notiz, was der Agent generiert und was ein Mensch geprüft hat.

Das kann in ein Pull-Request-Template, eine Checkliste für interne Tools oder eine schlanke Architektur-Notiz passen.

Der Wert liegt nicht im Dokument. Der Wert liegt darin, den Übergang vom Experiment zum verantworteten System zu erzwingen.

KI-Geschwindigkeit braucht Release-Grenzen

KI-Coding-Tools sind am stärksten, wenn die Aufgabe klar und die Feedbackschleife eng ist. Sie sind schwächer, wenn Grenzen nur implizit sind.

Darum sind Release-Grenzen wichtig.

Ein Agent kann Code entwerfen. Das heißt nicht, dass er deployen darf. Ein Agent kann eine Konfigurationsdatei ändern. Das heißt nicht, dass er Produktionsinfrastruktur verändern darf. Ein Agent kann eine Migration generieren. Das heißt nicht, dass sie gegen Kundendaten laufen darf. Ein internes Tool kann einem Team helfen. Das heißt nicht, dass es ohne Ownership zu einer stillen Abhängigkeit werden darf.

Gute Teams trennen diese Schritte.

Sie lassen KI die Umsetzung beschleunigen, halten Release-Autorität aber an Evidenz und Verantwortung gebunden. Sie nutzen Branch-Protection, CI-Checks, Command-Freigaben, Pfadgrenzen, getrennte Credentials und Review-Regeln. Riskante Aktionen bleiben hinter menschlicher Freigabe, bis der Workflow sich bewährt hat.

Es geht nicht darum, alles zu verlangsamen. Es geht darum zu verhindern, dass Geschwindigkeit die Teile der Softwarelieferung überspringt, die das Geschäft schützen.

Ein praktisches Betriebsmodell

Teams, die Vibe Coding oder agentische Entwicklung einführen, können mit drei Spuren starten.

Die erste Spur ist Exploration. Jeder darf KI nutzen, um Ideen zu skizzieren, Wegwerf-Prototypen zu bauen, Code zu untersuchen oder mögliche Ansätze zu entwerfen. Die Arbeit bleibt außerhalb der Produktion und nutzt keine sensiblen Credentials.

Die zweite Spur ist unterstützte Lieferung. KI-generierte Änderungen gehen durch den normalen Engineering-Prozess: Issue, Branch, Pull Request, Tests, Review und Deployment. Der Agent hilft, aber das Team besitzt das Ergebnis.

Die dritte Spur ist kontrollierte Automation. Agenten dürfen wiederkehrende Aufgaben ausführen, Pull Requests öffnen, Dependencies aktualisieren, Releases vorbereiten oder in CI arbeiten. Diese Spur braucht strengere Berechtigungen, Audit-Logs, Rollback-Wege und klare Policy-Gates.

Der Fehler ist, diese Spuren zu vermischen.

Exploration sollte nicht still Produktions-Credentials bekommen. Unterstützte Lieferung sollte Review nicht überspringen, nur weil das Demo gut aussah. Kontrollierte Automation sollte sich nicht hauptsächlich auf eine Prompt-Datei als Sicherheitsmechanismus verlassen.

Was das für Kunden bedeutet

Für Gründer kann Vibe Coding ein sehr guter Weg sein, um eine Produktidee zu validieren. Aber bevor der Prototyp zum Produkt wird, müssen Architektur, Datenmodell, Sicherheitsannahmen und Ownership explizit werden.

Für CTOs ist die Frage nicht, ob Entwickler KI nutzen. Sie tun es, oder sie werden es bald tun. Die Frage ist, ob die Organisation einen Weg hat, nützliche KI-gestützte Arbeit in wartbare Software zu verwandeln.

Für Product Owner ist die Frage, ob KI-Geschwindigkeit das Produktlernen verbessert oder nur die Menge ungeprüfter Arbeit im System erhöht.

Für Mittelstandsunternehmen ist die Warnung besonders klar bei internen Tools. KI macht es leicht, dass nützliche Schatten-Software im Unternehmen entsteht. Ein Teil davon sollte unbedingt überleben. Aber diese Software sollte in Ownership überführt werden, bevor Menschen davon abhängen.

Der sinnvolle Mittelweg

In der Vibe-Coding-Debatte gibt es zwei bequeme Positionen.

Die eine sagt: KI-Coding ist magisch und die alten Regeln gelten nicht mehr.

Die andere sagt: KI-Coding ist unseriös und ernsthafte Teams sollten es meiden.

Beides verfehlt den Punkt.

KI-gestützte Entwicklung ist gerade deshalb nützlich, weil sie die Ökonomie von Softwarearbeit verändert. Mehr Ideen können ausprobiert werden. Mehr repetitive Umsetzung kann verdichtet werden. Mehr Teams können Workflows erkunden, die früher monatelang auf Kapazität gewartet hätten.

Aber Software wird real, sobald Menschen davon abhängen.

Ab diesem Punkt braucht die Arbeit Ownership, Evidenz, Grenzen und einen Release-Weg.

McDougall Digital hilft Teams, diesen Mittelweg zu bauen: schnelle KI-gestützte Lieferung mit Architektur, Governance, Tests und operativer Verantwortung darum herum. Das Ziel ist nicht, Vibe Coding durch einen besseren Namen seriös wirken zu lassen. Das Ziel ist, dass nützliche Experimente zu verlässlicher Software werden können, ohne Prototyp-Risiko in die Produktion mitzunehmen.