Warum der Test wichtig ist

KI-gesteuerte Code-Assistenten erlauben es Teams oft, eine „Rules“-Datei in das Repository zu legen und erwarten, dass das Modell bei jeder Anfrage deren Anweisungen befolgt. In der Praxis sieht das Modell die Datei möglicherweise nie, oder es sieht sie, ignoriert jedoch den Inhalt. Ein aktuelles Experiment mit Claude Code zeigte beide Probleme auf. Das Tool übersprang stillschweigend eine 72 KB große AGENTS.md-Datei; als dieselbe Datei in CLAUDE.md umbenannt wurde, lud der Assistent sie und erhöhte die Token-Anzahl für jede Anfrage. Dieses zusätzliche Token-Budget bläht Latenz und Kosten auf und kann dazu führen, dass eine Anfrage das Limit eines Modells überschreitet.

Entwickler, die davon ausgehen, dass „die Datei existiert“ gleichbedeutend mit „das Modell befolgt die Regeln“ ist, riskieren versteckte Ineffizienzen und unvorhersehbare Ergebnisse. Der dreistufige Test erzwingt konkrete Belege in jeder Phase: Konfiguration, Laden und Nützlichkeit.

Die drei Fragen, die man stellen sollte

  1. Konfiguriert – Befindet sich die Datei dort, wo der Assistent nach ihr sucht? Verschiedene Tools verwenden fest codierte Pfade oder Dateinamenkonventionen; eine Abweichung bedeutet, dass die Datei nie in die Prompt-Pipeline gelangt.
  2. Geladen – Liefert der Assistent einen Beweis dafür, dass er die Datei erhalten hat? Ein Hash kann die Identität der Datei auf der Festplatte bestätigen, aber nur ein Übertragungsnachweis (z. B. eine Log-Zeile oder die Token-Anzahl) beweist, dass das Modell sie tatsächlich wahrgenommen hat.
  3. Nützlich – Verbessert die Anwesenheit der Datei das Ergebnis der Aufgabe? Eine geladene Datei, die zwar Token verbraucht, aber das Ergebnis unverändert lässt, ist ein Nettoverlust.

Durchführung des Tests

Das Verfahren ist bewusst minimal gehalten, damit es auf jeder Plattform wiederholt werden kann.

  1. Erstellen Sie eine sichtbare Regel – Schreiben Sie eine einfache, beobachtbare Anweisung. Zum Beispiel: „Listen Sie vor der Bearbeitung genau zwei Dateien auf.“ Die Wirkung der Regel kann in der Antwort des Assistenten überprüft werden.

  2. Prüfen Sie Tool-Version und Modell – Öffnen Sie eine neue Sitzung und notieren Sie den Versionsstring sowie die Modell-ID. Verschiedene Versionen können die von ihnen erkannten Dateinamen ändern.

  3. Führen Sie zwei Durchläufe aus Durchlauf A: Verwenden Sie einen Dateinamen, den das Tool nicht erkennt (z. B. AGENTS.md). Durchlauf B: Verwenden Sie den nativen Dateinamen des Tools (z. B. CLAUDE.md).

    Notieren Sie:

    • Den Quell-Hash der Datei (um zu beweisen, dass sich der Inhalt auf der Festplatte nicht geändert hat).
    • Den exakten verwendeten Pfad.
    • Jegliche Belege, die der Assistent über das Laden der Datei protokolliert hat (Erhöhung der Token-Anzahl, explizite Meldung „loaded X.md“ usw.).
    • Die Token-Anzahl für jede Anfrage.
    • Das Ergebnis der Aufgabe (hat der Assistent genau zwei Dateien aufgelistet?).

Wenn Durchlauf B zeigt, dass die Regel befolgt wird und die Token-Anzahl um den erwarteten Betrag steigt, ist die Datei sowohl geladen als auch nützlich. Wenn die Regel trotz der Token-Erhöhung ignoriert wird, wird die Datei zwar gelesen, aber das Prompt-Parsing des Modells verwirft die Anweisung. In diesem Fall hilft es nicht, mehr Text zur Datei hinzuzufügen; verschieben Sie die Regel stattdessen in ein fest codiertes Policy-Gate oder ein Test-Framework.

Was die Daten offenbaren

Der Fall Claude Code zeigte eine deutliche Lücke zwischen Konfiguration und Laden auf. Die 72 KB große Datei existierte, hatte den korrekten Hash und war mit dem Repository synchronisiert, dennoch griff der Assistent nie darauf zu. Die Umbenennung der Datei in das native CLAUDE.md löste das Laden aus, verursachte aber auch einen erheblichen Token-Overhead. Jedes zusätzliche Token verbraucht Rechenzyklen und kann dazu führen, dass die Anfrage die Rate-Limits überschreitet.

Der dreistufige Test macht solche versteckten Kosten sichtbar, bevor sie zu Blockern in der Produktion werden. Durch die Erfassung der Token-Differenz können Teams entscheiden, ob der Nutzen der Regel ihren Preis rechtfertigt.

Fazit

Gehen Sie niemals davon aus, dass eine Regel-Datei eine Funktion erfüllt, nur weil sie im Repository liegt. Nutzen Sie den dreistufigen Test – konfigurieren, laden, Nützlichkeit beweisen –, um diese Annahme in messbare Belege zu verwandeln. Wenn der Beweis zeigt, dass eine Datei lediglich ein Token-Fresser ist, verlagern Sie die Logik aus dem Prompt in ein deterministisches Gate. Das Ergebnis ist ein schlankerer, schnellerer und vorhersehbarerer KI-Coding-Workflow.