Vibe Coding im Unternehmen sicher einsetzen: Richtlinien, Tests und Code Reviews

Montagmorgen, kurz vor dem Sprint Planning: Eine Entwicklerin zeigt einen Pull Request mit mehreren hundert Zeilen Code. Ein KI-Assistent hat eine neue API-Anbindung, Datenbankzugriffe und Fehlerbehandlung in wenigen Minuten erzeugt. Der Code wirkt auf den ersten Blick plausibel, die Anwendung läuft lokal. Doch im Diff stehen Zugangsdaten in einer Konfigurationsdatei, eine Berechtigungsprüfung fehlt und ein SQL-Statement wurde per Zeichenkette zusammengesetzt. Genau hier entscheidet sich, ob Vibe Coding im Unternehmen ein Beschleuniger oder ein neues Betriebsrisiko wird.

Mit Vibe Coding ist das Arbeiten gemeint, bei dem Entwicklerinnen und Entwickler Anforderungen in natürlicher Sprache beschreiben und KI-Werkzeuge daraus Code, Tests, Dokumentation oder Konfiguration erzeugen lassen. Das kann sehr produktiv sein, etwa für Prototypen, wiederkehrende Routinen, Testgerüste oder die Analyse bestehender Codebasen. Es ersetzt aber weder Architekturentscheidungen noch fachliche Verantwortung oder sorgfältige Prüfung.

Bei uns erleben wir in Programmiertrainings immer wieder: Teams brauchen nicht zuerst eine lange Liste verbotener Tools. Sie brauchen einen klaren Workflow, der festlegt, welche Aufgaben sich eignen, welche Informationen nicht in Prompts gehören und wann ein Mensch verbindlich entscheidet.

Infografik zu Vibe Coding im Unternehmen sicher einsetzen: Richtlinien, Tests und Code Reviews (KI-generiert).

Vibe Coding beginnt mit einer präzisen Aufgabe

Je unklarer die Aufgabenbeschreibung, desto größer ist das Risiko, dass die KI Annahmen trifft, die fachlich oder technisch nicht passen. „Baue eine sichere Anmeldung“ ist keine ausreichende Anforderung. Sie lässt offen, welche Identitäten zugelassen sind, welche Rollen existieren, wie Sitzungen verwaltet werden und welche Sicherheitsvorgaben gelten.

Beschreibe den Arbeitsauftrag so, dass ein Teammitglied ihn auch ohne KI umsetzen könnte:

• Welches fachliche Problem soll gelöst werden?
• Welche Eingaben, Ausgaben und Sonderfälle gibt es?
• Welche bestehenden Schnittstellen, Bibliotheken und Architekturvorgaben müssen berücksichtigt werden?
• Welche Qualitätsanforderungen gelten, etwa Laufzeit, Barrierefreiheit, Protokollierung oder Datenschutz?
• Welche Akzeptanzkriterien müssen erfüllt sein?
• Welche Teile des Systems dürfen nicht verändert werden?

Die KI kann dann beispielsweise einen ersten Implementierungsvorschlag, Testfälle oder eine Erklärung zu einer vorhandenen Funktion liefern. Der Auftrag sollte aber nicht lauten: „Mach das irgendwie passend.“ Gerade bei gewachsenen Anwendungen ist „passend“ ohne Kontext häufig falsch.

Eine gute Praxis ist, die Ergebnisse der KI als Entwurf zu behandeln. Die Entwicklerin oder der Entwickler übernimmt die fachliche Steuerung, prüft Annahmen und integriert nur nachvollzogene Änderungen. Das gilt auch dann, wenn der erzeugte Code elegant aussieht oder ohne Fehler kompiliert.

Teamrichtlinien schaffen Klarheit statt Misstrauen

Eine belastbare Richtlinie für KI-gestütztes Programmieren muss kurz genug sein, damit sie im Alltag verwendet wird. Sie sollte nicht nur Regeln aufzählen, sondern konkrete Entscheidungen erleichtern. Wichtig sind insbesondere vier Bereiche: zugelassene Werkzeuge, schützenswerte Informationen, Qualitätsanforderungen und Verantwortlichkeiten.

Lege zuerst fest, welche KI-Dienste für welchen Zweck genutzt werden dürfen. Nicht jedes Tool verarbeitet Eingaben gleich, nicht jedes Konto hat dieselben Einstellungen und nicht jede Erweiterung im Editor ist für Unternehmenscode geeignet. Prüfe mit den zuständigen Stellen, welche Daten verarbeitet werden und welche Vertrags-, Datenschutz- und Sicherheitsvorgaben im Unternehmen gelten.

Danach braucht das Team eine eindeutige Grenze für Inhalte in Prompts. Nicht eingegeben werden sollten:

• Passwörter, API-Schlüssel, Zertifikate und private Schlüssel
• vollständige Produktivdaten oder personenbezogene Datensätze
• interne Sicherheitskonzepte, nicht veröffentlichte Schwachstellen und vertrauliche Architekturdetails
• Quellcode aus besonders sensiblen Komponenten, wenn die Freigabe dafür fehlt
• Kundendaten, Tickets oder Logdateien mit vertraulichen Informationen

Diese Regel darf nicht nur im Wiki stehen. Sie gehört in die Einführung neuer Teammitglieder, in Entwicklungsrichtlinien und in die Konfiguration der Werkzeuge. Für technische Geheimnisse braucht es außerdem sichere Alternativen: Secret-Management, Umgebungsvariablen, Platzhalterwerte und Testdaten. Wie Identitäten und Berechtigungen im Cloud-Kontext sauber kontrolliert werden, zeigen wir auch in unserem Beitrag „Microsoft Entra Workload Identities absichern: Service Principals, Managed Identities und KI-Agenten kontrollieren“.

Geheimnisse gehören nie in Prompts, Code oder Repositories

KI kann aus einem eingegebenen Schlüssel keinen sicheren Umgang mit Geheimnissen machen. Das Risiko entsteht schon vorher, wenn sensible Daten in Chats, Editor-Erweiterungen, Quellcode oder Commit-Historien landen. Auch ein später gelöschter Schlüssel kann bereits kopiert, zwischengespeichert oder in einem Fork vorhanden sein.

Deshalb gilt eine einfache Regel: Geheimnisse werden zur Laufzeit bereitgestellt, nicht fest in den Code geschrieben. Verwende dafür den etablierten Secret-Store deines Unternehmens. Lokal arbeitest du mit sicheren Entwicklerkonfigurationen, in Build- und Deployment-Prozessen mit geschützten Variablen und klaren Berechtigungen. Beispielwerte in Dokumentation und Tests müssen erkennbar künstlich sein.

Ergänze technische Kontrollen. Ein Secret-Scan vor dem Commit und in der CI-Pipeline kann versehentlich eingecheckte Schlüssel erkennen. Diese Prüfung ersetzt keine Aufmerksamkeit, senkt aber das Fehlerrisiko erheblich. Wird doch ein Geheimnis veröffentlicht, muss es sofort ersetzt werden. Das Entfernen aus der aktuellen Datei genügt nicht, weil es weiterhin in der Versionshistorie stehen kann.

Tests machen KI-Vorschläge überprüfbar

Ein zentraler Fehler beim Vibe Coding lautet: Der Code funktioniert in einem einzelnen Demo-Fall, also ist er fertig. Produktivcode muss jedoch mehr leisten. Er soll fehlerhafte Eingaben kontrolliert behandeln, Berechtigungen respektieren, bei Last stabil bleiben und sich bei Änderungen nicht unbemerkt anders verhalten.

Formuliere vor der Implementierung überprüfbare Akzeptanzkriterien. Daraus entstehen Tests, die nicht nur den erwarteten Erfolgsfall abdecken:

• Unit-Tests prüfen einzelne Funktionen und fachliche Regeln.
• Integrations-Tests prüfen Datenbank, APIs und weitere technische Grenzen.
• Negativ-Tests prüfen ungültige Eingaben, fehlende Berechtigungen und Fehlerfälle.
• Regressionstests schützen bereits gelöste Anforderungen bei späteren Änderungen.
• Sicherheits-Tests prüfen typische Risiken wie fehlende Autorisierung, Injection oder unsichere Dateiverarbeitung.

KI kann beim Entwurf von Testfällen helfen. Sie kann Randfälle vorschlagen, Testdaten erzeugen oder vorhandene Tests erklären. Dennoch muss das Team prüfen, ob die Tests tatsächlich die richtige Anforderung abbilden. Besonders kritisch sind Tests, die vom selben Modell oder aus derselben fehlerhaften Annahme wie die Implementierung stammen. Dann können Code und Test zwar übereinstimmen, aber gemeinsam falsch sein.

Automatisiere die Ausführung in der Continuous Integration. Ein Pull Request sollte erst zusammengeführt werden können, wenn die vereinbarten Prüfungen erfolgreich sind. Dazu gehören mindestens Build, relevante Tests, statische Analyse und Sicherheitsprüfungen. Die konkreten Werkzeuge unterscheiden sich je nach Technologie, das Prinzip bleibt gleich: Qualität wird nicht erst nach dem Merge festgestellt.

Pull Requests klein halten und nachvollziehbar beschreiben

Große KI-generierte Änderungen sind schwer zu prüfen. Wenn ein Pull Request gleichzeitig Architektur, Datenmodell, Oberfläche, Tests und Konfiguration verändert, kann ein Reviewer kaum beurteilen, ob alle Konsequenzen verstanden wurden. Kleine, fachlich abgegrenzte Änderungen sind sicherer und schneller reviewbar.

Eine gute Pull-Request-Beschreibung beantwortet klar:

• Welches Problem wird gelöst?
• Welche fachlichen und technischen Entscheidungen wurden getroffen?
• Welche Teile wurden mit KI-Unterstützung erstellt oder überarbeitet?
• Welche Tests wurden ausgeführt?
• Welche Risiken, offenen Punkte oder Annahmen gibt es?
• Wie kann der Reviewer die Änderung nachvollziehen?

Es geht nicht darum, KI-Nutzung zu stigmatisieren. Transparenz hilft dem Team, die richtige Prüftiefe zu wählen. Wenn ein Assistent etwa eine neue Authentifizierungslogik vorgeschlagen hat, braucht dieser Bereich mehr Aufmerksamkeit als eine rein kosmetische Umbenennung.

Für viele Teams lohnt sich ein verbindliches Pull-Request-Template. Es macht Qualitätsanforderungen sichtbar und verhindert, dass wichtige Angaben im Zeitdruck vergessen werden.

Code Reviews bleiben eine fachliche Verantwortung

Ein Code Review ist keine formale Zustimmung zum Zusammenführen. Der Reviewer prüft, ob die Änderung fachlich richtig, sicher, verständlich und langfristig wartbar ist. Bei KI-generiertem Code sollte er zusätzlich hinterfragen, ob ungewöhnliche Bibliotheken, unnötige Abstraktionen oder nicht erklärte Logik eingeführt wurden.

Achte im Review besonders auf diese Punkte:

• Stimmen Berechtigungen und Datenzugriffe mit dem Sicherheitsmodell überein?
• Sind Eingaben validiert und Ausgaben sicher verarbeitet?
• Werden Fehler sinnvoll behandelt und ausreichend protokolliert?
• Ist der Code verständlich genug, damit ihn andere Teammitglieder warten können?
• Passt die Lösung zu bestehenden Mustern, Namenskonventionen und Architekturentscheidungen?
• Sind Abhängigkeiten aktuell, vertrauenswürdig und wirklich erforderlich?
• Decken Tests die wesentlichen Fälle und Risiken ab?

Bei sicherheitskritischen Änderungen sollte das Vier-Augen-Prinzip verbindlich sein. Dazu gehören Authentifizierung, Autorisierung, Kryptografie, Berechtigungskonzepte, Zahlungen, Datenlöschungen und Infrastrukturcode. Ein Review durch Personen mit passender Fachkenntnis ist hier wichtiger als Geschwindigkeit.

Für Teams, die Sicherheitswissen strukturiert ausbauen wollen, bietet unser Beitrag „IT-Security-Weiterbildung für Admins: Kurse & Zertifikate“ eine sinnvolle Orientierung. Wer Automatisierung und nachvollziehbare Skripte im Alltag stärken möchte, findet zudem praktische Ansätze in „PowerShell lernen: vom Befehl zum Automatisieren“.

Ein praxistauglicher Workflow für den Alltag

Der sichere Einsatz von Vibe Coding lässt sich als wiederholbarer Ablauf etablieren:

• Aufgabe fachlich beschreiben und Akzeptanzkriterien definieren.
• Prüfen, ob die Aufgabe für KI-Unterstützung geeignet ist.
• Nur freigegebene Werkzeuge und zulässige Informationen verwenden.
• KI-Ergebnis als Entwurf erzeugen, verstehen und lokal überarbeiten.
• Geheimnisse, Berechtigungen und Eingabevalidierung gezielt prüfen.
• Tests ergänzen und automatisiert ausführen.
• Kleine Pull Requests mit transparenter Beschreibung erstellen.
• Verbindliches Code Review durchführen und Rückfragen klären.
• Erst danach zusammenführen und das Verhalten in der Zielumgebung beobachten.

Dieser Workflow muss zum Team passen. Ein kleines Entwicklungsteam braucht meist andere Freigaben als eine Organisation mit mehreren Produkten, zentralem Plattformteam und regulierten Anwendungen. Wie du Weiterbildung und gemeinsame Standards für mehrere Rollen planst, erläutern wir in „Weiterbildung fürs IT-Team planen: so geht’s“.

Kompetenz entscheidet über den Nutzen

Vibe Coding verkürzt den Weg vom Gedanken zum Code. Es verkürzt aber nicht den Weg zur Verantwortung. Wer Anforderungen, Architektur, Tests und Sicherheitsrisiken nicht beurteilen kann, erkennt auch einen überzeugend formulierten Fehler nicht zuverlässig.

Deshalb verbinden wir in unseren Seminaren Programmierung, Datenbanken, Cloud, Microsoft-Technologien, Netzwerke und IT-Service-Management mit konkreten Anwendungsszenarien. Passende Seminare und Termine findest du bei uns auf cmt.de.

Wenn dein Team KI-gestützte Entwicklung einführt, starte nicht mit einem unternehmensweiten Freifahrtschein. Wähle ein überschaubares Vorhaben, vereinbare klare Regeln, messe die Erfahrungen im Review und verbessere den Ablauf gemeinsam. So bleibt Vibe Coding das, was es sein sollte: eine produktive Unterstützung für gute Entwicklerarbeit, nicht ihr Ersatz.