Die spannende Frage bei KI-Agenten im Unternehmen ist längst nicht mehr, ob ein Modell brauchbaren Code schreibt. Sie lautet: Wie kommt diese Änderung kontrolliert in Produktion – nachvollziehbar, überprüfbar und rückholbar?
Die Antwort darauf gibt es in der IT schon länger, sie heißt GitOps: Der gewünschte Zustand steht in Git, jede Änderung läuft über einen Pull Request, ein Automatismus bringt den Stand in den Cluster. Wer das hat, muss für Agenten fast nichts Neues bauen. Ein Agent ist dann einfach ein weiterer Beitragender – einer ohne Sonderrechte.
Der folgende Durchlauf ist ein echter Vorgang aus einem unserer Projekte: eine Formulierung im Footer einer mehrsprachigen Website soll geändert werden. Klein, langweilig, perfekt geeignet – genau die Art Aufgabe, die im Alltag liegen bleibt.
Die Spielregeln
Vier Regeln entscheiden darüber, ob so ein Aufbau trägt:
- Der Agent arbeitet nur auf einem eigenen Branch und liefert einen Pull Request. Er merged nie selbst.
- Ein Mensch gibt den Lauf frei – über ein Label am Issue, bevor überhaupt etwas startet.
- Das Merge-Gate ist technisch erzwungen, nicht bloß vereinbart: Branch Protection, grüne Checks, mindestens eine Freigabe.
- Das Deployment macht GitOps, nicht der Agent. Er hat keinen Zugang zum Cluster und braucht auch keinen.
Schritt 1: Der Auftrag entsteht als Issue
Alles beginnt dort, wo Arbeit im Team ohnehin beginnt – im Issue-Tracker des Repositorys.
Für Agenten-Aufträge gibt es eine eigene Vorlage. Das ist kein Kosmetik-Detail: Die Vorlage erzwingt die Angaben, ohne die ein Lauf regelmäßig schiefgeht.
Ausgefüllt sieht ein guter Auftrag unspektakulär aus: eine Beschreibung, was sich ändern soll, und überprüfbare Akzeptanzkriterien – eines pro Zeile.
Die Akzeptanzkriterien sind der wichtigste Teil des Formulars. Sie sind später der Maßstab, an dem der Pull Request gemessen wird – und sie zwingen den Auftraggeber, vorher zu Ende zu denken. „Fußzeile ist entsprechend geändert“ und „alle drei Sprachen sind berücksichtigt“ ist prüfbar. „Footer überarbeiten“ ist es nicht.
Schritt 2: Die Freigabe ist ein Label
Das Issue allein löst nichts aus. Der Lauf startet erst, wenn ein Maintainer das Label freigegeben setzt.
Diese Trennung von Auftrag schreiben und Auftrag freigeben ist billig zu haben und verhindert die naheliegendste Panne: dass jeder, der ein Issue anlegen darf, damit automatisch Rechenzeit und Codeänderungen auslöst.
Schritt 3: Der Lauf
Ab hier übernimmt die Pipeline. Sie setzt Labels (agent:running, dazu den verwendeten Agenten), kommentiert den Start und verlinkt das Log – live und als Artefakt.
Dass Agent und Modell im Klartext im Issue stehen, klingt nach einer Kleinigkeit. Es ist der Unterschied zwischen „die KI hat das gemacht“ und einer Änderung, die man Monate später noch einordnen kann.
Nach gut zwanzig Sekunden ist der Lauf fertig und hat das getan, was er tun soll: einen Pull Request geöffnet.
Schritt 4: Pull Request und KI-Vorab-Review
Der Pull Request ist der eigentliche Übergabepunkt. Hier läuft automatisch ein zweites Modell über den Diff – als Vorfilter, nicht als Ersatz für das menschliche Review.
In diesem Fall meldet der Vorfilter eine berechtigte Kleinigkeit: In der englischen Sprachdatei ist „Provider“ mitten im Satz großgeschrieben – kein Eigenname, also ein Tippfehler, der auf einer englischsprachigen Seite unangenehm auffällt. Ein Fehler, der aus dem Auftrag selbst stammt und den ein Mensch beim schnellen Durchsehen genauso übersieht.
Wichtiger als der Befund ist, was das Gate daraus macht: Die Checks sind grün, gemerged werden kann trotzdem nicht.
„Merging is blocked – at least 1 approving review is required.“ Genau so soll es sein. Der Agent kann Code liefern, aber die Entscheidung, dass dieser Code in Produktion geht, bleibt bei einem Menschen mit Schreibrechten.
Schritt 5: Nacharbeit ohne Kontextwechsel
Der Befund lässt sich direkt im Pull Request abarbeiten – per Kommentar, ohne die Werkzeuge zu wechseln.
Der Kommentar startet einen zweiten Lauf auf demselben Branch – dieselbe Mechanik wie vorher, inklusive Labels und Log.
Danach zieht die Pipeline ein frisches Review nach, das den Tippfehler nicht mehr findet und die Änderung als unkritisch einstuft. Übrig bleibt ein sprachlicher Hinweis zur Diskussion – kein Blocker.
Dass Auftrag, Lauf, Befund, Nacharbeit und Bewertung als eine zusammenhängende Spur im Pull Request stehen, ist der praktische Gewinn: Das Protokoll entsteht nebenbei, niemand muss es hinterher schreiben.
Schritt 6: Merge ist der Rollout
Nach der Freigabe durch einen Menschen wird gemerged – und damit ist die Änderung ausgeliefert.
Was danach passiert, ist reine Mechanik und für alle Änderungen gleich, ob von Mensch oder Agent: Die Pipeline baut die Container-Images, schreibt den neuen Tag in das GitOps-Repository, und der Cluster zieht sich diesen Stand. Kein kubectl von Hand, kein Sonderweg für „schnelle Textänderungen“.
Vorher:
Nachher:
Was das GitOps-Muster hier leistet
Der Agent ist in diesem Aufbau der am wenigsten interessante Teil. Getragen wird das Ganze von Eigenschaften, die auch ohne KI Sinn ergeben:
- Ein Weg in Produktion. Wenn Änderungen nur über Pull Request und
mainlaufen, gibt es keinen Sonderpfad, den man für Agenten absichern müsste. - Nachvollziehbarkeit ohne Zusatzaufwand. Issue → Pull Request → Commit → Deployment ist eine geschlossene Kette. Wer im nächsten Jahr fragt, warum in der Fußzeile „solution provider“ steht, findet den Auftrag, den Diff und die Freigabe.
- Rückabwicklung als Normalfall. Ein Revert ist ein Commit. Für eine Agenten-Änderung gilt derselbe Knopf wie für jede andere.
- Rechte bleiben klein. Der Agent braucht Schreibrechte auf einen Branch – nicht auf
main, nicht auf den Cluster, nicht auf die Registry.
Wo die Grenzen liegen
Ehrlich bleiben gehört dazu. Drei Punkte, die wir in der Praxis gelernt haben:
Der Zuschnitt entscheidet. Ein Thema, ein Pull Request, überprüfbare Kriterien. Aufträge, die mehrere Module gleichzeitig anfassen oder eine Architekturentscheidung enthalten, gehen regelmäßig schief – nicht weil das Modell zu schwach wäre, sondern weil der Auftrag es ist.
Das KI-Review ist ein Vorfilter, kein Reviewer. Es findet zuverlässig Inkonsistenzen, vergessene Stellen, Stil- und Sprachfehler. Es beurteilt nicht, ob die Änderung fachlich gewollt ist. Wer das Gate deshalb aufweicht („Checks sind grün, reicht doch“), hat den Sinn der Übung verfehlt.
Der Nutzen liegt im Kleinteiligen. Texte, Übersetzungen, Konfiguration, Dokumentation, kleine Refactorings: Hier spart der Agent echte Durchlaufzeit, weil der Aufwand für Kontextwechsel entfällt. Bei der schwierigen Hälfte der Arbeit ändert er wenig – außer dass die Zeit dafür jetzt da ist.
Genau das ist unsere Empfehlung an Unternehmen, die mit Agenten anfangen wollen: nicht mit dem Modell beginnen, sondern mit dem Weg in Produktion. Wer Pull Requests, Review-Gate und GitOps sauber hat, kann Agenten in einem Nachmittag anschließen. Wer sie nicht hat, sollte den Nachmittag lieber dafür verwenden.
Die Screenshots stammen aus einem realen Durchlauf in einem Projekt. Organisations-, Repository- und Benutzernamen sowie Marken-, Kontakt- und Produktangaben wurden für die Veröffentlichung durch Platzhalter ersetzt.