Ich bin Ralf Enderle und kümmere mich bei eXXcellent solutions um die Rolle von KI in unserem Engineering. Wir stecken gerade mitten in einem Entwicklungsschub, bei dem die Wahrheit von heute übermorgen schon wieder anders aussehen kann. Was ich hier aufschreibe, ist deshalb kein abgeschlossenes Fazit, sondern eine Art Tagebuch: Themen, die mir in unserer Projektpraxis begegnen, und die Gedanken, die ich mir dabei mache. Den Anfang macht ein Thema, das uns in den letzten Monaten immer wieder eingeholt hat.
Wer sich derzeit mit Coding-Agents beschäftigt, kommt an Berichten über Agenten nicht vorbei, die in Produktivumgebungen mehr angerichtet haben als geplant war: gelöschte Datenbestände, Änderungen an Systemen, die niemand autorisiert hatte, Aktionen mitten in Phasen, die ausdrücklich dafür vorgesehen waren, genau das zu verhindern. Solche Fälle sind inzwischen gut dokumentiert und werden in der Branche breit diskutiert, meist unter der Frage, wie sehr man einem Agenten trauen darf.
Uns interessiert daran etwas anderes. In den Fällen, die wir uns angesehen haben, existierte die Regel, die den Vorfall hätte verhindern sollen, meistens bereits. Sie war klar formuliert. Sie stand im Kontext. Und sie hatte keinerlei Wirkung, weil nichts sie durchgesetzt hat. Das ist der Unterschied, um den es in diesem Beitrag geht: Eine Guardrail ohne Durchsetzung ist eine Bitte.
Der übliche Einstieg in Agentic Engineering führt über eine Datei mit Regeln. CLAUDE.md, AGENTS.md, Cursor Rules: Der Name wechselt, das Prinzip ist dasselbe. Konventionen, Architekturvorgaben und Verbote werden aufgeschrieben und dem Agenten in den Kontext gelegt. Das ist sinnvoll und der richtige erste Schritt.
Es ist aber kein Durchsetzungsmechanismus, sondern ein Wahrscheinlichkeitsmechanismus.
Der Grund liegt in der Arbeitsweise eines Agenten. Er führt in einem einzigen Lauf zwanzig bis zweihundert Tool-Calls aus. Mit jedem Schritt wächst der Kontext um Dateiinhalte, Kommandoausgaben und Zwischenergebnisse. Die Regeldatei von Minute eins steht dann irgendwo in der Mitte eines sehr langen Verlaufs, umgeben von Material, das für den aktuellen Schritt viel relevanter aussieht. Nach einer Kompaktierung des Kontexts ist sie womöglich gar nicht mehr da.
Dass die Regeltreue unter diesen Bedingungen nachlässt, ist keine Eigenart eines bestimmten Modells und geht auch nicht mit der nächsten Generation weg. Es folgt daraus, wie Sprachmodelle Kontext gewichten. Ein Modell entscheidet nicht zwischen Regel und Aufgabe, es verarbeitet beides als Text im selben Fenster.
Für unsere Projekte hat das eine praktische Konsequenz. Wir schreiben Regeln weiterhin auf. Wir verlassen uns aber nicht darauf, dass sie befolgt werden, sondern nur darauf, dass sie das Verhalten in die richtige Richtung verschieben. Alles, was verbindlich sein muss, braucht eine zweite Ebene.
In unseren Projekten hat sich eine Ordnung bewährt, die nicht nach Themen sortiert, sondern nach der Frage: Was passiert, wenn der Agent sich nicht daran hält?
Die Reihenfolge ist bewusst umgekehrt zur üblichen Einführungsreihenfolge. Die meisten Teams beginnen unten und bleiben dort.
Die wirksamste Guardrail ist die, die vor der ersten Entscheidung des Agenten greift. Der Gedanke dahinter ist einfach: Statt zu beaufsichtigen, was ein Agent tut, legen wir fest, was er überhaupt tun kann.
Praktisch heißt das: Ein Agent arbeitet in einer Umgebung, in der die Produktionsdatenbank technisch nicht erreichbar ist. Nicht, weil es ihm untersagt wurde, sondern weil keine Credentials existieren, mit denen er sie erreichen könnte. Netzzugriff läuft über eine Allowlist. Das Arbeitsverzeichnis ist begrenzt, Schreibrechte darüber hinaus gibt es nicht.
Diese Ebene ist die einzige, die auch gegen Prompt Injection trägt. Ein Agent liest Issues, Pull-Request-Kommentare, Log-Ausgaben, Webseiten und die Antworten angebundener Systeme. Alles davon kann Anweisungen enthalten, die dort nicht hingehören, teilweise in Zeichen, die im Editor unsichtbar sind. Für das Modell ist dieser Text nicht von Ihrer Aufgabenstellung zu unterscheiden. Beides ist Kontext.
Daraus folgt eine Grenze, die sich nicht wegprompten lässt: Gegen eine Anweisung, die von außen in den Kontext gelangt, hilft keine Regel im Kontext. Nur eine Grenze außerhalb davon. Wenn ein Agent keine Zugangsdaten hat, kann er auch keine ausleiten, egal wer ihn dazu auffordert. Der Aufwand dafür ist überschaubar und einmalig. Er gehört an den Anfang eines Projekts.
Zwischen der Umgebung und der Pipeline liegt eine Ebene, die viele Teams übersehen: die Prüfung im Moment des Tool-Aufrufs. Der Agent will einen Befehl ausführen, ein externes Programm entscheidet vorher, ob das zulässig ist.
Technisch sieht das je nach Werkzeug unterschiedlich aus. In Claude Code sind es Hooks, die vor einem Tool-Aufruf (PreToolUse) ein eigenes Skript ausführen und drei Entscheidungen zurückgeben können: erlauben, nachfragen, blockieren. Entscheidend ist die Eigenschaft dahinter: Der Hook ist ein externer Prozess. Das Modell kann ihn nicht überstimmen, nicht umdeuten und nicht vergessen.
Ein Detail, das in der Praxis den Unterschied macht: Ein blockierter Aufruf sollte dem Agenten eine Begründung zurückgeben. Ein stiller Abbruch führt dazu, dass er einen anderen Weg zum selben Ziel sucht. Eine Begründung führt dazu, dass er die Grenze berücksichtigt. Guardrails, die erklären, funktionieren besser als solche, die nur verweigern.
Die Falle bei „ask“: Nachfragen ist die bequemste Option und die verführerischste. Anthropic hat für Claude Code ausgewertet, wie Nutzer mit Freigabedialogen umgehen: Rund dreiundneunzig Prozent wurden bestätigt. Das ist keine Nachlässigkeit einzelner Entwickler, sondern die vorhersehbare Reaktion auf zu viele Fragen. Wer bei jeder Kleinigkeit fragt, erzieht Menschen zum Wegklicken. Die Freigabe wird dann zum Ritual und nicht zur Entscheidung.
Wir gehen deshalb sparsam mit „ask" um. Was oft und harmlos ist, wird erlaubt. Was selten und gefährlich ist, wird blockiert. Nachgefragt wird nur dort, wo ein Mensch wirklich urteilen muss.
Die dritte Ebene ist die vertrauteste, weil sie älter ist als jeder Agent: Tests, statische Analyse, Architekturregeln, Security-Scanning, Policy-Checks in der Pipeline. Mit KI werden diese Verfahren nicht überflüssig. Sie werden wichtiger.
Der Grund ist einfach. Ein Agent, der prüfen kann, ob er richtig liegt, korrigiert sich selbst. Einer, der es nicht kann, produziert überzeugend aussehende Ergebnisse. Eine Architekturregel, die als ausführbarer Test formuliert ist (etwa mit ArchUnit), wirkt in beide Richtungen: Der Agent bekommt sie als Feedback, bevor er den Pull Request stellt, und der Mensch bekommt sie als Gate, bevor gemergt wird. Dieselbe Grenze, zweimal wirksam.
Was wir in Reviews sehen, macht diese Ebene wichtiger als früher. Das typische Muster ist nicht der falsche Code, sondern der doppelte. Ein Agent, der eine Funktion braucht, schreibt sie eher neu, als dass er die vorhandene sucht. Für seinen einzelnen Auftrag ist das die effizientere Lösung. Für die Codebasis ist es die teurere. Erkennen lässt sich das früh und automatisch, im Review dagegen erst dann, wenn jemand beide Stellen kennt.
Ein Hinweis aus eigener Erfahrung, weil er uns Zeit gekostet hat: Prüfregeln, die von einem Agenten geschrieben wurden, müssen selbst getestet werden. Eine Policy-Regel, die syntaktisch korrekt ist und niemals greift, ist schlimmer als gar keine – sie erzeugt das Gefühl von Absicherung. Wir hinterlegen deshalb zu jeder Regel einen Fall, der sie auslösen muss.
Bleibt die Ebene, mit der die meisten anfangen. Sie ist nicht wertlos, sie ist nur falsch eingeordnet. Regeln im Kontext beeinflussen, wie ein Agent arbeitet, wenn nichts dagegensteht. Sie entscheiden über Benennungskonventionen, Bibliotheksauswahl, Codestil, bevorzugte Muster. Das ist viel wert, weil es die Menge der Fälle reduziert, in denen die härteren Ebenen überhaupt greifen müssen.
Was sich bei uns bewährt hat: kurz halten und dorthin schreiben, wo es gebraucht wird. Eine Regeldatei mit achthundert Zeilen konkurriert mit dem eigentlichen Arbeitskontext um denselben knappen Platz. Regeln, die nur für ein Modul gelten, gehören zu diesem Modul und nicht in eine zentrale Datei.
Zudem: Regeln sollten nicht nur das beinhalten, was ein Agent machen soll und wie er sich verhalten soll. Es muss auch dokumentiert sein, wo seine Grenzen sind und was er nicht machen soll!
Die Zuordnung folgt bei uns einer einzigen Frage: Was kostet der Fehler, und ist er umkehrbar? Reversibilität ist dabei der eigentliche Hebel. Wo jeder Schritt günstig rückgängig zu machen ist, kann ein Agent mehr Freiheit bekommen. Wo das nicht gilt, sinkt die zulässige Autonomie. Das ist keine Vorsichtsmaßnahme obendrauf, sondern die Voraussetzung dafür, dass Autonomie überhaupt vertretbar ist.
Drei Dinge, die uns Aufwand gekostet haben, bevor sie funktioniert haben:
Erstens: Wir haben zu lange auf der falschen Ebene gearbeitet. Als ein Agent etwas tat, was er nicht sollte, war unsere erste Reaktion, die Regel deutlicher zu formulieren. Danach nachdrücklicher. Danach in Großbuchstaben. Es half jedes Mal ein bisschen und nie zuverlässig. Die richtige Frage ist nicht, wie man eine Regel besser formuliert, sondern auf welcher Ebene sie hingehört.
Zweitens: Zu viele Nachfragen sind schlechter als wenige harte Grenzen. Unsere erste Hook-Konfiguration fragte bei fast allem nach. Nach zwei Wochen klickte niemand mehr bewusst. Wir haben die Zahl der Nachfragen anschließend deutlich reduziert und dafür mehr Fälle hart blockiert. Seitdem wird wieder gelesen, was auf dem Bildschirm steht.
Drittens: Guardrails brauchen Pflege wie Code. Eine Regel, die niemand mehr auslöst, ist entweder überflüssig oder kaputt. Wir schauen uns die Trefferstatistik der Hooks regelmäßig an. Was nie greift, kommt auf den Prüfstand.
Vier Ebenen, eine Logik: Je teurer und je weniger umkehrbar ein Fehler ist, desto härter muss die Grenze sein, die ihn verhindert. Und je härter die Grenze sein soll, desto weiter außerhalb des Modells muss sie liegen. Eine klare Anweisung reicht nicht, wenn nichts sie durchsetzt. Was es braucht, ist eine Umgebung, in der die verbotene Aktion gar nicht erst möglich ist. Guardrails sind deshalb kein Misstrauensvotum gegen die Technik. Sie sind die Bedingung dafür, einem Agenten mehr Spielraum geben zu können, ohne mehr zu riskieren.
Über uns
eXXcellent solutions steht für individuelle Software, die mitdenkt, statt begrenzt. Seit 25 Jahren verbinden wir technologische Exzellenz mit Innovationskraft – für Lösungen, die wirken und Unternehmen, die über den Standard hinaus wollen. Dabei decken wir das gesamte Spektrum der Softwareentwicklung ab.