Leitplanken für KI-Coding-Agenten schlagen intelligentere Modelle

Ein Reviewer sah sich meinen Code an und fand einen Fehler. Eine Route gab einen 500-Fehler zurück, obwohl sie einen 404-Fehler hätte zurückgeben sollen. Der Reviewer meldete den Fund klar und deutlich, einschließlich Datei und Zeile.

Mein Agent korrigierte diese Route. Genau diese eine.

Fünf weitere Routen hatten denselben Fehler. Sie blieben unberührt, während der Agent die Arbeit als abgeschlossen meldete — und er log nicht. Er hatte das behoben, was ihm gezeigt worden war. Er kam nur nie auf die Idee zu fragen, an wie vielen anderen Stellen sich derselbe Fehler verbarg.

Eine Weile nahm ich an, das sei ein Modellproblem und ein besseres Modell würde es lösen. Das stellte sich als falsch heraus, und die Lösung, die funktionierte, war simpler, als ich erwartet hatte. Bei Leitplanken für KI-Coding-Agenten geht es nicht darum, das Modell intelligenter zu machen. Es geht darum, ihm einen Ort zu geben, an dem es Dinge ablegen kann.

Wo KI-Coding-Agenten unbemerkt falsch abbiegen

Die Fehler, die mich am meisten Zeit kosteten, hatten technisch nichts gemeinsam. Strukturell hatten sie eine Gemeinsamkeit: In jedem Fall wurde etwas Wichtiges im Kopf behalten, statt es aufzuschreiben.

„Er sagte, er sei fertig. War er aber nicht.“

Du bekommst eine Abschlussmeldung. Die Aufgabenliste ist abgehakt. Dann siehst du nach, und dort steht ein TODO, wo die Logik sein sollte, oder eine Funktion gibt eine leere Liste zurück, oder eine Teilaufgabe wurde stillschweigend übersprungen.

Hier ist, was bei mir zu lange gedauert hat zu erkennen. Der Agent blufft nicht. Er gleicht seine Arbeit mit seiner eigenen Erinnerung an das ab, was er gerade geschrieben hat, und diese Erinnerung ist wirklich überzeugend. Grüne Tests plus die lebhafte Erinnerung daran, den Code geschrieben zu haben, fühlen sich genauso an wie fertig.

Leg es stattdessen ab: Nichts gilt ohne Belege, die du dir ansehen kannst, als erledigt. Nicht die Behauptung, dass es funktioniert hat. Die tatsächliche Ausgabe, die tatsächliche Datei, die tatsächliche Zeile.

„Er änderte meinen Test, statt den Code zu korrigieren.“

Das tut weh, weil der Agent genau das macht, worum du ihn gebeten hast. Du hast gesagt, er solle die Tests zum Bestehen bringen. Ein fehlschlagender Test lässt sich auf zwei Arten zum Bestehen bringen, und eine davon ist viel einfacher.

Leg es stattdessen ab: Schreibe die Kriterien auf, bevor die Arbeit beginnt, und behandle sie danach als schreibgeschützt. Wenn das Ergebnis nicht passt, ist das Ergebnis falsch. Nicht die Kriterien. Das klingt offensichtlich — bis du selbst versucht bist, das Ziel um einen halben Zentimeter zu verschieben.

Warum eine längere CLAUDE.md Agenten dazu bringt, Anweisungen zu ignorieren

Mein erster Impuls war derselbe wie bei allen anderen. Alles in CLAUDE.md aufschreiben. Jeder Fehler wurde zu einer neuen Regel, und die Datei wuchs.

Es wurde schlimmer. Nicht dramatisch — nur stetig und auf eine Weise, die sich nur schwer auf eine Ursache zurückführen ließ. Regeln begannen einander auf Arten zu widersprechen, die ich nicht erkennen konnte, und das Modell entschied sich stillschweigend für eine Lesart, ohne den Konflikt je zu melden. Und als Forschende Repository-Kontextdateien tatsächlich anhand realer Issues testeten, verbesserten die Dateien den Aufgabenerfolg überhaupt nicht. Sie erhöhten die Inferenzkosten um mehr als 20 %. Das Fazit lautete, eine Kontextdatei auf ihre Mindestanforderungen zu beschränken.

Das ist das ganze Problem im Kleinen. Mit einer langen Regeldatei sagst du einem vergesslichen System, es solle sich angestrengter erinnern. Es muss mehr festhalten, nicht weniger.

Das Framework, bei dem ich schließlich landete, enthält eine Regel, die sich beim Lesen falsch anfühlte und erst richtig, als ich sie eine Weile angewendet hatte: Jede neue Regel muss eine alte löschen oder mit ihr zusammengeführt werden. Die Anzahl der Regeln darf nicht wachsen. Wenn das eine schwierige Entscheidung erzwingt, ist genau diese schwierige Entscheidung der Sinn der Sache — du findest heraus, auf welche Regeln du dich tatsächlich verlassen hast.

Fünf Orte, an denen du Dinge ablegen kannst

Das ist die ganze Idee. Jede Zeile zeigt etwas, das scheitert, wenn man es im Kopf behalten muss, und den Ort, an den es stattdessen gehört.

Im Kopf festgehalten	Irgendwo abgelegt
Was „fertig“ bedeuten sollte	Kriterien, die vor der Arbeit aufgeschrieben wurden
Ob es wirklich geprüft wurde	Belege, die du dir ansehen kannst
Ob deine eigene Arbeit etwas taugt	Ein anderes Modell, das sie prüft
Was du vor drei Stunden entschieden hast	Eine Datei auf der Festplatte
Ob diese Aktion sicher ist	Eine Schranke, die bei einem Menschen stoppt

Drei davon brauchen eine kurze Erklärung.

„Am Ende prüfe ich immer noch alles selbst.“

Wenn du aufgehört hast, der Ausgabe zu vertrauen, bist du jetzt der Engpass, und der Agent hat dir überhaupt keinen Hebel verschafft.

Den Agenten zu bitten, seine eigene Arbeit zu prüfen, hilft nicht, und der Grund verdient etwas Aufmerksamkeit: Es ist derselbe Kontext, der den Fehler hervorgebracht hat, also greift er auf dieselben Begründungen zurück. Er verteidigt die Arbeit, statt sie zu testen.

Leg es stattdessen ab: Leite die Prüfung an ein anderes Modell weiter, idealerweise von einem anderen Anbieter. Anderes Training, andere blinde Flecken. Das Modell, das meinen Fehler in fünf Routen fand, war nicht dasjenige, das ihn geschrieben hatte, und das ist kein Zufall.

„Etwas hat sich selbst freigegeben, und ich war es nicht.“

Agenten lesen viel Text, den sie nicht geschrieben haben — Issue-Threads, Dokumentation, Webseiten, Tool-Ausgaben. All das kann das Wort „freigegeben“ enthalten. Prompt Injection steht auf Platz eins der OWASP-Risikoliste für diese Systeme, und OWASP sagt unverblümt, dass die üblichen Abwehrmaßnahmen das Risiko nicht vollständig mindern.

Leg es stattdessen ab: Bei einer Freigabe zählt, woher sie stammt, nicht was sie sagt. Ein Mensch hat Ja gesagt oder ein signiertes Artefakt auf der Festplatte sagt Ja. Alles andere, das lediglich das Wort „freigegeben“ enthält, ist Text.

„Die Kontextkomprimierung hat vier Stunden Kontext verschluckt.“

Lange Sitzung, der Kontext füllt sich, die Unterhaltung wird zusammengefasst. Die Zusammenfassung bewahrt, was passiert ist, und verliert das Warum. Eine Stunde später diskutierst du eine bereits getroffene Entscheidung erneut, und du kannst nicht erkennen, ob du sorgfältig bist oder dich im Kreis drehst.

Leg es stattdessen ab: Eine Datei. Entscheidungen, aktueller Stand, nächster Schritt. Die Sitzung ist austauschbar, die Datei nicht. Lies sie erneut, bevor du behauptest, irgendetwas sei fertig.

Was Leitplanken für KI-Coding-Agenten kosten

Die Struktur ist wichtiger als die Zahl, also zuerst die Struktur: Die Integration ist ein einmaliger Kostenpunkt. Du bezahlst ihn, während du die Leitplanken in eine Codebasis einbaust, und diesen Teil bezahlst du nicht zweimal. Die unabhängige Prüfung ist die Ausnahme — sie läuft bei jeder Änderung, kostet also auch nach der Einrichtung weiterhin etwas.

Die Aufteilung ist der interessante Teil. Rund 80 % meiner Ausgaben entfielen auf das günstige Modell, das die Massenarbeit erledigte, etwa 17 % auf das teure Modell für Planung und Urteilsvermögen und etwa 3 % auf die Prüfung durch eine zweite Instanz — den Schritt, den viele auslassen. Die Sicherheit war mit großem Abstand der günstigste Posten auf der Rechnung. Über meine Projekte hinweg blieb diese Aufteilung ungefähr gleich, auch als sich die Preise änderten.

Was die konkrete Zahl angeht: Bei den meisten Projekten, an denen ich gearbeitet habe, kostete die nachträgliche Integration bei Preisen vom August 2026 etwa 100 bis 200 Dollar an API-Nutzung. Das Verhältnis ist wichtiger als die Dollarbeträge — plane ein Budget in dieser Größenordnung ein und rechne mit Experimenten. Du wirst die eine oder andere Entscheidung zurücknehmen und eine Phase erneut ausführen, und das ist in der Schätzung enthalten.

Deine Zahl wird anders aussehen, und was sie verändert, liegt auf der Hand: wie groß die Codebasis ist, wie oft du deine Meinung änderst und wie viel du an die günstige Stufe delegierst.

Ein neues Projekt zu beginnen kostete mich viel weniger, und das ist die nützlichere Erkenntnis. Das Geld fließt nicht in das Framework. Es fließt in die Abstimmung — darin, einzeln zu entscheiden, welche deiner bestehenden Tools und Gewohnheiten die Leitplanken ersetzen und um welche sie sich herumbiegen müssen. Bei meiner Integration haben die eigenen Testbefehle des Frameworks nicht überlebt; sie wurden gelöscht und durch Skripte ersetzt, die das Projekt bereits hatte. Bei einem neuen Projekt gibt es nichts abzustimmen.

Fang mit einer an

Du brauchst nicht alle fünf. Wähle den Fehler aus, der dich diese Woche am meisten kostet, und lege diese eine Sache irgendwo ab.

Wenn du nicht sicher bist, welchen, beginne mit der unabhängigen Prüfung — ein zweites Modell sieht sich die Arbeit des ersten Modells an. Sie ist die günstigste der fünf und findet die größte Bandbreite an Problemen, einschließlich derer, nach denen zu suchen dir nie einfallen würde.

Der Fehler in fünf Routen ist immer noch mein Lieblingsbeispiel, weil nichts daran schwierig war. Der Agent brauchte eine Anweisung, die ihm fehlte: Bevor du etwas korrigierst, suche nach allem anderen, das genauso aufgebaut ist. Diese Anweisung steht jetzt in einer Datei. Sie wird in der nächsten Sitzung noch da sein und in der darauf folgenden, lange nachdem wir alle vergessen haben, warum sie geschrieben wurde.

Das gesamte Framework mit den Leitplanken und den Schritten zur Einführung findest du auf GitHub.

---

Ressourcen

• Repository-Kontextdateien, anhand realer Issues getestet (ETH Zurich SRI)
• OWASP LLM01: Prompt Injection
• AGENTS.md, das Format für Repository-Kontextdateien
• Der Speicher von Claude Code und CLAUDE.md
• Das agentische Framework mit den Leitplanken und den Schritten zur Einführung

---