Vibe Coding im Unternehmen: sieben Regeln, die den Unterschied machen

Eine Vibe-Coding-Richtlinie braucht keine zwanzig Seiten. Sie braucht sieben Festlegungen: wer verantwortet den Code, was ist freigabepflichtig, welche Daten dürfen das Haus verlassen, wie kommen fremde Pakete herein, was wird getestet, was wird dokumentiert und wer entscheidet im Zweifel. Alles darüber hinaus wird nicht gelesen.

Warum ein Verbot von KI-Werkzeugen nicht funktioniert

Weil es die Nutzung nicht beendet, sondern unsichtbar macht. In der Stack Overflow Developer Survey 2025 gaben 84 Prozent der Befragten an, KI-Werkzeuge zu nutzen oder das zu planen — gegenüber 76 Prozent im Vorjahr. Ein Verbot, das gegen eine derart verbreitete Praxis steht, verlagert sie in den privaten Account und nimmt Ihnen genau die Sichtbarkeit, die Sie zum Steuern bräuchten.

Die produktive Frage lautet deshalb nicht, ob KI eingesetzt wird, sondern unter welchen Bedingungen das Ergebnis in Ihr Produkt darf.

Welche Regeln braucht eine Vibe-Coding-Richtlinie?

1. Der Code gehört einem Menschen

Jede Änderung hat eine namentlich verantwortliche Person, unabhängig davon, wer oder was sie geschrieben hat. Diese Person muss die Änderung erklären können. „Das hat die KI so gemacht" ist keine zulässige Begründung in einem Review.

2. Kritische Bereiche sind freigabepflichtig

Legen Sie die Liste einmal fest und ändern Sie sie selten. Bewährt hat sich: Authentifizierung und Berechtigungen, Bezahlvorgänge, Datenbank-Schema und Migrationen, Deployment, neue Abhängigkeiten, Umgang mit personenbezogenen Daten. Änderungen hier brauchen einen Plan vor der Umsetzung und ein Review danach.

3. Neue Abhängigkeiten sind Entscheidungen, keine Nebenwirkungen

Jedes Paket, das ein KI-Werkzeug hinzufügt, wird gemeldet und beurteilt: Existiert es wirklich, wer pflegt es, welche Lizenz, welche bekannten Schwachstellen? Die OWASP Top 10:2025 führen Lieferketten-Fehler erstmals als eigene Kategorie auf Platz drei — mit gutem Grund, denn Modelle erfinden gelegentlich Paketnamen, und diese Namen lassen sich von Angreifern registrieren.

4. Daten verlassen das Haus nur bewusst

Klären Sie einmal und schriftlich, welche Werkzeuge welche Inhalte übertragen dürfen: Quelltext ja oder nein, Konfiguration, Log-Auszüge, Datenbankinhalte. Für personenbezogene Daten gilt das ohnehin bestehende Datenschutzregime; ein Werkzeug ohne geklärte Auftragsverarbeitung ist keine Grauzone, sondern ein offener Punkt.

5. Tests gehören zur Änderung, nicht in den Rückstand

Eine Änderung ohne Test, der bei Rückfall fehlschlägt, ist unfertig. Das ist bei KI-Code wichtiger als bei handgeschriebenem: Handgeschriebener Code trägt das Verständnis seines Autors in sich, generierter Code nicht. Details im Beitrag zur Testabdeckung bei KI-Code.

6. Der Nachweis ist Teil der Erledigung

„Fertig" heißt: Testlauf grün, Diff gelesen, Prüfungen durchlaufen — jeweils belegt, nicht behauptet. Eine praxistaugliche Fassung steht im Beitrag zur Definition of Done in der KI-gestützten Entwicklung.

7. Im Zweifel entscheidet ein Mensch, und zwar ein bestimmter

Benennen Sie die Rolle, die entscheidet, wenn eine Regel nicht passt. Ohne benannte Rolle entscheidet im Zweifel der Zeitdruck.

Wie setze ich diese Regeln durch, ohne das Team auszubremsen?

Indem Sie die Regeln an den Ablauf hängen und nicht an die Aufmerksamkeit. Eine Richtlinie im Intranet wird einmal gelesen. Eine Prüfung, die im Arbeitsablauf sitzt, wirkt bei jeder Änderung.

• Automatisch prüfbar: Formatierung, statische Analyse, Testlauf, Abhängigkeits- und Lizenzprüfung, Geheimnisse im Quelltext. Gehört in die Pipeline, nicht in eine Checkliste — siehe Quality Gates in der CI/CD-Pipeline.
• Nur menschlich prüfbar: Ist die Fachlogik richtig? Passt die Lösung zur Architektur? Wurde das eigentliche Problem gelöst? Dafür braucht es ein Review mit klarem Auftrag — siehe Code Review für KI-generierten Code.

Der häufigste Fehler ist, beides zu vermischen: Menschen prüfen Formatierung, während die Fachlogik ungeprüft durchrutscht.

Was kostet es, keine Regeln zu haben?

Der Preis erscheint nicht im Projekt, in dem er entsteht, sondern in dem danach. Die Analyse von GitClear zeigt für 2026 den höchsten je gemessenen Stand an duplizierten Code-Blöcken bei gleichzeitig fast verschwundenem Refactoring — es wird mehr kopiert und kaum noch aufgeräumt.

Was das konkret kostet und mit welchen vier Kennzahlen Sie es in Ihrem eigenen Projekt messen, steht im Beitrag zu technischen Schulden durch KI-Code.

Häufige Fragen zur KI-Richtlinie

Wie lang sollte eine Vibe-Coding-Richtlinie sein?

Eine Seite. Was länger ist, wird im Zweifel nicht konsultiert. Details gehören in die Werkzeuge, die sie durchsetzen, nicht in das Dokument, das sie beschreibt.

Gilt die Richtlinie auch für externe Dienstleister?

Sie sollte, und zwar vertraglich. Externe liefern Code in Ihr Produkt; die Haftungsfragen aus der neuen EU-Produkthaftungsrichtlinie stellen sich für Sie unabhängig davon, wessen Tastatur beteiligt war.

Müssen wir kennzeichnen, dass Code mit KI entstanden ist?

Eine allgemeine gesetzliche Kennzeichnungspflicht für KI-generierten Quelltext im eigenen Produkt gibt es nach heutigem Stand nicht. Sinnvoll ist die interne Nachvollziehbarkeit trotzdem — sie ist im Fehlerfall die Grundlage jeder Ursachenanalyse. Beachten Sie davon unabhängig die Transparenzpflichten des EU AI Act für KI-Systeme, die Sie Ihren Nutzern bereitstellen.

Wie fängt man an, wenn bisher gar nichts geregelt ist?

Mit Regel zwei. Die Liste der freigabepflichtigen Bereiche ist an einem Nachmittag geschrieben und deckt den Großteil des Risikos ab.

Regeln, die auf Disziplin angewiesen sind, halten genau bis zum ersten dringenden Freitagnachmittag. Code Guardian übersetzt die kritischen Punkte dieser Liste — Deploy, Migration, Abhängigkeit, Datenurteil — in Gates, die vor dem Schritt stehen statt in einem Dokument daneben.

Quellen

• Stack Overflow Developer Survey 2025, Abschnitt „AI".
• OWASP Top 10:2025, Kategorie A03 „Software Supply Chain Failures".
• GitClear, The Maintainability Gap: 2026 AI Code Quality Research.
• Richtlinie (EU) 2024/2853 über die Haftung für fehlerhafte Produkte.

Stand: 27. Juli 2026. Allgemeine Information, keine Rechtsberatung. Für die Ausgestaltung interner Richtlinien und Verträge sollten Sie eine juristische Prüfung einholen.