Engineering
KI-Agenten in der Softwareentwicklung: Code schreiben lassen, ohne die Kontrolle abzugeben
Ein KI-Agent, der Server löschen kann, ist ein Risiko. Einer, der es nicht kann, ist ein Werkzeug. So ziehen wir die Grenze.
Ein Agent, der nachts um drei Uhr eine Datenbank löscht, ist der Albtraum jeder IT-Leitung. Deshalb lassen viele Firmen KI-Agenten gar nicht erst zu. Wir setzen sie in der Softwareentwicklung täglich ein. In den letzten 30 Tagen sind so 432 Pull Requests in unserem Haupt-Repository gelandet. Möglich ist das, weil der Agent an Regeln gebunden ist, die er nicht umgehen kann.
Kontrolle über KI-Agenten in der Softwareentwicklung braucht mehr als einen Prompt
Die naheliegende Lösung lautet: dem Agenten in einer Anweisung sagen, was er nicht tun soll. Das reicht nicht. Eine Anweisung ist ein Text. Der Agent liest sie falsch oder vergisst sie. Eine Webseite, die er gerade zusammenfasst, kann sie überschreiben.
Wir setzen die Grenze deshalb dort, wo der Agent sie nicht mehr verhandeln kann: in Hooks. Ein Hook ist ein kleines Skript, das vor jedem Befehl läuft und ihn erlaubt oder blockiert. Der Agent sieht nur das Ergebnis. Bei uns sind es gut zwei Dutzend, jeder für genau eine Sorte Fehler.
Vier Stufen, vier Zuständigkeiten
Nicht jede Regel gehört an denselben Ort. Wir trennen vier Ebenen, und die Trennung ist der eigentliche Kern.
Verwaltete Einstellungen gelten auf jedem Rechner und gewinnen gegen alles darunter. Hier steht die Verbotsliste: Server herunterfahren, Cluster-Knoten löschen, Infrastruktur zerstören. Diese Befehle lassen sich nicht wegklicken.
Plugin-Hooks prüfen die Form eines Befehls. Sie laufen auch in unbeaufsichtigten Arbeitsbereichen, in denen niemand eine Rückfrage beantworten könnte. Ein Hook liest zum Beispiel einen SSH-Aufruf, zerlegt den Befehl auf der Gegenseite und blockiert systemctl stop k3s, selbst wenn es in Anführungszeichen steckt.
Repo-Einstellungen enthalten, was nur zu diesem Projekt gehört, etwa dessen Deploy-Befehle.
Benutzer-Einstellungen gelten nur auf einer Maschine und enthalten nie eine Regel, auf die andere sich verlassen.
Steht eine Sicherheitsregel in der falschen Stufe, erreicht sie die anderen Rechner nie.
Was ein Mensch freigeben muss
Die Liste ist bewusst kurz. Nachfragen gibt es nur bei Dingen, die nach außen wirken oder sich nicht per Revert zurückholen lassen: Software veröffentlichen, ein Passwort per Link teilen, tofu apply gegen echte Infrastruktur, Ressourcen im Cluster löschen oder skalieren.
Alles andere läuft durch. Früher gab es mehr Rückfragen, und das war schlechter. Wer bei jedem zweiten Befehl bestätigen muss, klickt irgendwann blind. Ein Gate, das niemand mehr liest, ist keins.
Der Merge als Zustandsentscheidung
Ob ein Pull Request gemerged werden darf, entscheidet ein Hook anhand seines Zustands. CI grün: erlaubt. CI rot oder unlesbar: Rückfrage. CI läuft noch: erlaubt mit --auto, dann merged GitHub selbst, sobald die Checks durch sind.
Eine Ausnahme gibt es. Änderungen an den Verzeichnissen .claude und .github/workflows brauchen eine Freigabe, denn dort steht, was der Agent darf und was die CI prüft. Wer diese Dateien ändert, ändert das Gate selbst.
Dazu ein Befund, den wir gern zeigen. Wir haben 80 zurückliegende Merges ausgewertet: 41 berührten diese geschützten Pfade, 5 trugen eine Freigabe, und alle 80 stammten vom selben Autor. Bei 36 der 80 Merges bedeutete die vorgeschriebene Prüfung nur, dass der Agent anhielt, damit derselbe Mensch, der den Auftrag gegeben hatte, ihn durchklickte. Das ist keine Kontrolle, das ist Theater. Wir haben die Regel deshalb enger gefasst und schreiben in die Dokumentation, unter welcher Bedingung sie wieder weiter wird: sobald ein Zweiter regelmäßig mitmergt.
Was das für Sie bedeutet
Wenn wir für Ihre Firma Software oder Infrastruktur betreiben, gelten dieselben Regeln, auf Kundensystemen noch strenger: Rollouts in die Produktion und Schreibzugriffe brauchen dort immer eine ausdrückliche Freigabe. Sie bekommen die Geschwindigkeit paralleler Agenten und wissen zugleich, dass jede Änderung in einem Pull Request mit grüner Prüfung endet, den ein Mensch verantwortet.
Wie das im Alltag aussieht, steht auf der Seite Arbeitsweise. Wenn Sie wissen wollen, was davon für Ihren Betrieb passt, buchen Sie ein Erstgespräch.