Vibe-Coding ohne Kontrollverlust: Welche Leitplanken CTOs und IT-Leitungen setzen müssen

Du sitzt in einem Steering-Termin und jemand fragt in die Runde: „Können wir das mit KI nicht schneller bauen?“ Schon startet eine Diskussion über das „Ob“. Das ist aber gar nicht die entscheidende Frage – ob eine KI einen brauchbaren ersten Entwurf liefert, lässt sich fast immer ausprobieren. Entscheidend ist für IT-Verantwortliche: Woran erkennen wir vorab, ob das Ergebnis stimmt? Und wer trägt die Verantwortung, wenn nicht?

Software-Teams lösen diese Frage seit Jahrzehnten mit automatisierten Tests, Code-Reviews und Architektur-Prüfungen. Verlässlichkeit entsteht dadurch, dass jedes Stück Software automatisch gegen etwas Festgelegtes geprüft wird, bevor es ausgeliefert wird. 

Dieselbe Qualitätssicherung, die sich in der Softwareentwicklung etabliert hat, muss nun konsequent auch auf das angewendet werden, was ein KI-Agent vorschlägt. Durch Agenten steigt aber die Frequenz: Weil sie mehr Vorschläge in kürzerer Zeit erzeugen, müssen die etablierten Mechanismen öfter zum Einsatz kommen als bisher. 

Kein Mensch kann im gleichen Tempo die Vorschläge gegenlesen, in dem ein Agent sie erzeugt. In der Praxis ist daher entscheidend, ob deine Organisation schnell genug prüfen kann, was ein Agent liefert. 

Das Nadelöhr ist oft menschlich: Die wenigen Senior-Entwickler:innen müssen noch jede Änderung persönlich freigeben. An diesem Punkt entscheidet sich: Investieren Teams in automatisierte Prüfinfrastruktur? Oder lässt sich die neu gewonnene Geschwindigkeit gar nicht nutzen, weil die Freigabe zum Flaschenhals wird?

Das Ziel ist aber nicht, die Qualitätssicherung vollständig zu automatisieren. In einer gut aufgesetzten Arbeitsumgebung gibt es vielmehr klar benannte Stellen, an denen ausdrücklich ein Mensch entscheidet, nicht der Agent. Diese Zuständigkeiten sollten feststehen, bevor der erste Agent produktiv läuft.

• Was „fertig“ bedeutet, legen vorher Menschen als Test oder Kriterium fest. Bei uns in der HEC übernimmt zum Beispiel ein standardisierter, KI-gestützter Acceptance-Test den fachlichen Teil davon: Er prüft auf Basis vorher vereinbarter Kriterien, damit nicht bei jedem Feature neu festgelegt werden muss, woran dessen korrekte Umsetzung gemessen wird.
• Architekturentscheidungen mit Tragweite bekommen bewusst ein Gate, an dem jemand freigibt, bevor sie umgesetzt werden. Ein Agent kann bei uns zum Beispiel Rückmeldungen aus einer Code-Prüfung bearbeiten und abgestimmte Änderungen umsetzen. Die endgültige Freigabe bleibt beim Menschen. 
• Sicherheitsregeln stehen vorab fest, nicht erst, wenn etwas schiefgeht: welche Tools ein Agent nutzen darf, wie mit Zugangsdaten und internen Daten umgegangen wird, und dass vorgeschlagene Abhängigkeiten geprüft werden, bevor sie installiert werden. Erfundene oder kompromittierte Pakete sind ein reales Risiko, nicht nur ein theoretisches. 
• Fachbereiche, die selbst bauen, bekommen einen Rahmen statt eines Verbots. Wenn zum Beispiel in einem Logistikunternehmen die Disposition oder das Controlling anfängt, eigene Tools zu vibecoden, löst ein Verbot das Problem nicht. Es verlagert es nur aus dem Sichtfeld der IT. Besser ist ein klar abgesteckter Bereich, in dem das erlaubt ist, mit denselben Grundregeln wie oben, nur niedrigschwelliger durchgesetzt. 

Nicht jedes System braucht dieselben Leitplanken. Logistische Kernsysteme wie TMS oder WMS, an denen der laufende Betrieb hängt, bekommen die strengen Gates aus dem vorigen Abschnitt. Schnittstellen und Integrationsarbeit sind oft der größte Hebel, weil hier viel Routinearbeit anfällt, die sich gut gegen feste Verträge prüfen lässt. Interne Tools und Prototypen dürfen lockerer laufen: Wenn ein internes Dashboard einen Fehler hat, kostet das weniger als ein Fehler im Kernsystem. 

Die Annahme, die im Steering-Termin häufig geäußert wird, ist: „Das geht jetzt schneller, also wird es billiger.“ Der erste Teil stimmt oft: Einzelne Implementierungsschritte sind messbar schneller erledigt. Schneller heißt aber nicht automatisch insgesamt billiger, denn die Geschwindigkeit ist nicht kostenlos. Automatisierte Prüfungen, geteilte Skills und klare Verantwortlichkeiten entstehen nicht von selbst. Jemand muss sie aufbauen und pflegen. Das ist eine echte Anfangsinvestition. 

Der Ertrag zeigt sich nicht im ersten Sprint. Erst über viele Personen und Wochen hinweg bleibt die Qualität konsistent und zeigt damit ihren wahren Wert: Fehler fallen früh auf, wenn sie noch billig sind, nicht erst spät, wenn sie teuer werden. 

Eine zugespitzte Version desselben Arguments lautet: weniger Aufwand, also weniger Personal. Genauso plausibel ist die Gegenthese: Die Arbeit verschiebt sich. Statt zu verschwinden, bewegt sie sich weg von reiner Implementierung, hin zu Verifikation und fachlicher Klärung.

Wer eine Anfangsinvestition gegenüber der Geschäftsleitung vertreten muss, kann also so argumentieren: Es sollte nicht die Investition in Prüfinfrastruktur gegen den schnellen Gewinn aufgewogen werden. Schwerer wiegt das Risiko der Nicht-Entscheidung. Wer jetzt nicht in Prüfbarkeit investiert, baut die Geschwindigkeit trotzdem auf, nur ungeprüft. Das ist das Risiko, das CEO oder CFO eigentlich bewerten sollten. 

Wenn sich Arbeit von Implementierung zu Verifikation verschiebt, ändert sich auch, was eine erfahrene Entwicklerin von einem Berufseinsteiger unterscheidet. Seniorität zeigt sich zunehmend daran, Risiken in einem Vorschlag zu erkennen, den man nicht selbst geschrieben hat. Diese Fähigkeit lässt sich schwerer trainieren als reines Programmieren. 

Für Juniors heißt das: Sie brauchen früher Übung im Lesen und Beurteilen von Code, nicht nur im Schreiben. Wer das nicht aktiv einplant, bekommt auf Dauer ein Team, das gut darin ist, Agenten etwas bauen zu lassen, aber schwach darin, zu erkennen, wann das falsch ist. 

Wenn ihr eine Prüfinfrastruktur für das Vibe-Coding im eigenen Haus angehen wollt, lohnt es sich nach unserer Erfahrung, gleich von Anfang an auf Folgendes zu achten: 

1. Mit einem Pilotteam starten: Führt den Ansatz zunächst in einem klar abgegrenzten Team ein. Ziel des Piloten ist nicht nur zu zeigen, dass KI die Entwicklung beschleunigt, sondern dass die vorgesehenen Prüfmechanismen im Alltag tatsächlich funktionieren.
2. Prüfmechanismen verbindlich machen: Automatisierte Tests, Reviews und andere Kontrollpunkte dürfen nicht davon abhängen, wie viel Zeit gerade verfügbar ist. Was für eine Anwendung verpflichtend geprüft werden muss, sollte deshalb vorab festgelegt und technisch so weit wie möglich erzwungen werden.
3. Klare Verantwortlichkeit von Anfang an benennen: Wer entscheidet, was „fertig“ bedeutet? Wer gibt Architekturentscheidungen frei? Das sollte feststehen, bevor der erste Agent produktiv eingesetzt wird. 
4. Vor dem Piloten Vergleichswerte festhalten: Messt vorab zumindest Durchlaufzeit und Nacharbeitsaufwand vergleichbarer Aufgaben. Nur so lässt sich später belastbar beurteilen, ob der Einsatz von KI tatsächlich schneller, günstiger oder qualitativ besser geworden ist.
5. Fachbereiche von Anfang an einbeziehen: Legt früh fest, welche Arten von Anwendungen Fachbereiche selbst mit KI bauen dürfen, welche Daten sie dabei verwenden dürfen und ab wann die IT eingebunden werden muss.