Vibe Coding heisst: Du sagst, was du willst, der Agent baut es, du schaust, ob es sich richtig anfühlt, und machst weiter. Für einen Prototyp am Wochenende ist das wunderbar. In einem Unternehmen mit Kundendaten ist es ohne Konzept fahrlässig.
Was Vibe Coding ist, und was nicht
Der Begriff ist locker gemeint, und er trifft etwas Richtiges. Die Art, wie man mit einem Agenten arbeitet, ist anders als klassisches Programmieren. Schneller, gesprächiger, mehr Ausprobieren, weniger Planen im Voraus.
Das ist gut. Wir arbeiten selber so, in NeoCoder und in Kundenprojekten. Aber „ich schaue, ob es sich richtig anfühlt" ist kein Abnahmeprozess. Nicht bei einem System, das Zahlungen auslöst oder Patientendaten verarbeitet.
Wo es im Unternehmen gefährlich wird
Ein paar Dinge, die wir gesehen haben, bei uns und bei anderen.
Ein Agent bekommt Zugang zum ganzen Repository und damit zu allem, was darin liegt. Konfigurationen, Schlüssel, die jemand vor Jahren eingecheckt hat, Daten in Testverzeichnissen. Er braucht das nicht, aber er hat es.
Ein Agent baut eine Abhängigkeit ein, die er kennt. Niemand prüft, woher sie kommt, wer sie pflegt und was sie sonst noch tut. Es funktioniert, also bleibt es drin.
Ein Agent löst ein Problem, indem er eine Sicherheitsprüfung umgeht, die im Weg war. Nicht böswillig. Die Aufgabe war „mach, dass es läuft", und es läuft.
Und der Klassiker: Code geht in Produktion, weil der Agent gesagt hat, die Tests seien grün. Niemand hat die Tests gesehen.
Unser Konzept in fünf Regeln
Was wir daraus gemacht haben, ist nicht kompliziert. Es ist die Arbeit eines Sicherheitsarchitekten, in einer Form, die für Agenten gilt.
Ein Agent sieht nur, was er für seine Aufgabe braucht. Kein Vollzugriff auf das Repository. Der Architekt-Agent definiert den Ausschnitt, die Coding Agents arbeiten darin.
Keine neuen Abhängigkeiten ohne Freigabe. Ein Agent darf vorschlagen, nicht einbauen. Die Liste erlaubter Bibliotheken ist Teil der Regeln, nicht Teil des Ermessens.
Sicherheitsprüfungen sind nicht verhandelbar. Die QS prüft deterministisch, ob Authentifizierung, Validierung und Zugriffskontrolle noch da sind. Ein Agent, der sie entfernt, bekommt die Aufgabe zurück, egal wie gut der Rest ist.
Kein Agent nimmt seine Arbeit selbst ab. Build, Tests, Regeln, Duplikate, dann ein QS-Agent, dann bei allem, was Daten oder Geld berührt, ein Mensch.
Alles wird protokolliert. Welcher Agent hat was mit welchem Kontext erzeugt. Nicht als Chat, sondern als Artefakt, das man in einem Jahr noch lesen kann.
Was das kostet
Geschwindigkeit. Ein bisschen. Ein Agent, der nur seinen Ausschnitt sieht, muss öfter nachfragen. Eine Freigabe für eine Bibliothek dauert. Ein Mensch in der Abnahme ist langsamer als kein Mensch.
Wir haben gemessen: Es kostet vielleicht zehn bis fünfzehn Prozent gegenüber ungebremstem Vibe Coding. Dafür wissen wir, was im System ist. Bei einer Bank ist das kein Preis, das ist eine Voraussetzung.
Warum wir es trotzdem machen
Weil die Alternative nicht ist, auf Agenten zu verzichten. Die Alternative ist, dass sie trotzdem benutzt werden, nur ohne Regeln, von Entwicklern, die es sich nicht nehmen lassen. Fakt ist: Das passiert heute in jedem Unternehmen, ob die IT-Leitung es weiss oder nicht.
Ein Sicherheitskonzept für Vibe Coding ist also kein Bremsklotz. Es ist die Bedingung dafür, dass man es offiziell erlauben kann. Und alles, was offiziell erlaubt ist, kann man auch steuern.
Vibe Coding ohne Regeln ist im Unternehmen ein Vorfall, der noch nicht passiert ist. Mit Regeln ist es die schnellste Art, Software zu bauen, die wir kennen. Der Unterschied sind fünf Regeln und die Bereitschaft, sie zu erzwingen.
Geschrieben von mir. Die Gedanken, die Werte, die Learnings, die Fehler: alles meins. Grammatik und Rechtschreibung korrigiert unser eigenes Twin-Modell, das auf meinen Texten trainiert ist. Manchmal bleibt ein Hüpfer drin. Das ist dann auch von mir.