Die Datei, die alle anlegen, und der Hebel, der woanders liegt

Es gibt einen Handgriff, der in fast jedem Team zum Standard geworden ist, das mit KI-Coding-Agenten arbeitet: Man legt eine Datei ins Repository, die dem Agenten erklärt, wo er ist. AGENTS.md heißt sie meistens, bei Anthropics Claude Code CLAUDE.md, bei anderen Werkzeugen .cursorrules. Darin steht, wie das Projekt aufgebaut ist, welche Befehle die Tests starten, welche Konventionen gelten. Die Anbieter empfehlen das ausdrücklich. Viele Werkzeuge erzeugen die Datei auf Knopfdruck.

Die naheliegende Annahme dahinter ist, dass mehr Kontext zu besseren Ergebnissen führt. Eine Untersuchung der ETH Zürich hat das erstmals sauber nachgemessen — und findet die Annahme nicht bestätigt.

Was gemessen wurde

Die Arbeit trägt den Titel „Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?“ und stammt von Thibaud Gloaguen, Niels Mündler und Martin Vechev von der ETH Zürich, gemeinsam mit Mark Müller und Veselin Raychev vom ETH-Spin-off LogicStar.ai. Ein Hinweis zur Aktualität gehört vorweg: Die Arbeit erschien am 12. Februar 2026 und wurde am 23. Juni überarbeitet. Sie wird im deutschsprachigen Raum gerade erst breit diskutiert, neu ist sie nicht.

Die Methodik ist bewusst zweigleisig. Zum einen nahmen die Autoren etablierte Aufgaben aus dem verbreiteten SWE-bench-Korpus — echte Fehlerberichte aus populären Python-Projekten — und legten maschinell erzeugte Kontextdateien dazu. Zum anderen stellten sie eine eigene Sammlung von Aufgaben aus Projekten zusammen, in denen Entwickler bereits von Hand geschriebene Kontextdateien hinterlegt hatten. Getestet wurden mehrere Agenten mit mehreren Modellen, darunter Claude Code, Codex und ein Agent auf Basis eines Qwen-Modells. Erfolg bedeutete: Der erzeugte Patch besteht alle Tests.

Das Ergebnis steht so im Abstract: „we find that providing context files does not generally improve task success rates, while increasing inference cost by over 20% on average. This observation holds across different LLMs, coding agents, and for both LLM-generated and developer-committed context files.“ Keine messbare Verbesserung der Erfolgsquote, aber über 20 Prozent höhere Kosten pro Aufgabe. Und zwar stabil über verschiedene Modelle, verschiedene Agenten und beide Arten von Kontextdateien.

Der Befund hinter dem Befund

Der eigentlich nützliche Teil ist nicht das Gesamturteil, sondern die Aufschlüsselung. Denn die Studie findet nicht, dass Kontextdateien wirkungslos sind. Sie findet, dass ein bestimmter Inhalt wirkungslos ist: „while instructions in the context files are well followed by coding agents, repository overviews, although popular and recommended by model providers, are not helpful.“

Anweisungen werden also befolgt. Was nicht hilft, ist die Repository-Übersicht — die Beschreibung der Architektur, die Aufzählung der Verzeichnisse, die Erklärung, was das Projekt tut. Genau das ist aber der Inhalt, den automatische Generatoren produzieren, wenn man sie auf ein Projekt richtet.

Der Grund dafür ist plausibel, wenn man sich klarmacht, was ein Agent tatsächlich tut: Er liest den Code. Eine Beschreibung der Ordnerstruktur ist eine Zusammenfassung von Informationen, die er ohnehin abrufen kann — und sie kostet Platz im Kontextfenster, den sie mit der eigentlichen Aufgabe teilen muss. Die Autoren selbst formulieren die Konsequenz vorsichtig: Kontextdateien seien nützlich, um „non-standard coding practices“ festzuhalten, aber „any attempts to improve performance should be rigorously evaluated before deployment.“

Dazu gehört eine Einschränkung, die die Autoren selbst benennen: Getestet wurde fast ausschließlich Python — eine Sprache, die in Trainingsdaten massiv vertreten ist. Bei einem hauseigenen Framework in einer Nischensprache könnte derselbe Text deutlich mehr wert sein.

Wo die Datenlage uneinheitlich ist

Hier wird es unbequem, und wer die Studie als Beweis zitieren will, sollte das wissen. Eine zweite, unabhängige Arbeit untersuchte dieselbe Frage an echten, bereits zusammengeführten Pull Requests aus zehn Projekten — und kam bei den Kosten zum umgekehrten Ergebnis: niedrigere Laufzeit und geringerer Token-Verbrauch bei vorhandener AGENTS.md. Beide Untersuchungen betrachten von Menschen geschriebene Dateien, kommen aber zu entgegengesetzten Kostenrichtungen. Die Erklärung liegt vermutlich im Aufgabentyp: ein konstruierter Fehlerbehebungs-Benchmark ist nicht dasselbe wie die Arbeit, die ein Team tatsächlich durch seinen Review schiebt.

Eine Praktikerin der Agentic AI Foundation hat denselben Effekt noch kleiner vorgeführt: Ihr erster Einzeldurchlauf zeigte die Kontextdatei als deutlich langsamer und teurer; der Median aus fünf Durchläufen kehrte das Bild um. Ihr Fazit ist die methodische Lehre dieses ganzen Themas: Ein Durchlauf pro Bedingung „told me the wrong thing“. Agentenläufe sind verrauscht. Wer seine Konfiguration an einem Versuch bewertet, misst Zufall.

Die überraschendste Bestätigung kommt vom Hersteller. Anthropics eigene Dokumentation für Claude Code empfiehlt CLAUDE.md weiterhin — warnt aber fast deckungsgleich mit der ETH-Arbeit vor dem Gegenteil von Gründlichkeit: „Keep it concise. For each line, ask: ‚Would removing this cause Claude to make mistakes?‘ If not, cut it. Bloated CLAUDE.md files cause Claude to ignore your actual instructions!“ Der vermeintliche Widerspruch zwischen Forschung und Anbieter ist also kleiner als die Schlagzeilen: Beide sagen, dass kurze, nicht ableitbare Anweisungen wirken und lange Erklärtexte schaden.

Der größere Zusammenhang: die Produktivitätsfrage

Die Kontextdatei ist nur ein Symptom. Dahinter steht die Frage, die in jedem Vorstandsgespräch über KI-Werkzeuge auftaucht — und deren Antwort 2026 schwächer belegt ist, als die Marketingfolien vermuten lassen.

Die Organisation METR hat dazu die sorgfältigste Messung vorgelegt. Ihre Studie von Anfang 2025 fand, dass erfahrene Entwickler mit KI-Werkzeugen 19 Prozent länger brauchten — ein Ergebnis, das damals breit zitiert wurde. Im Februar 2026 hat METR nachgelegt und das Vorzeichen gedreht: Für die ursprüngliche Gruppe schätzt man nun einen Zeitgewinn von 18 Prozent, bei neu angeworbenen Entwicklern 4 Prozent. Entscheidend ist aber, was dahinter steht: Die Konfidenzintervalle reichen von −38 bis +9 Prozent beziehungsweise −15 bis +9 Prozent. Beide schließen die Null ein. Es gibt also auch in der aktuellen Messung keinen statistisch gesicherten Produktivitätsgewinn — bei gleichzeitig deutlich besserem Punktschätzer als ein Jahr zuvor.

METR selbst hält den Wert für eine Untergrenze und nennt den Grund: 30 bis 50 Prozent der Teilnehmer gaben an, bestimmte Aufgaben nicht eingereicht zu haben, weil sie sie ohne KI nicht machen wollten. Das Experiment verliert damit systematisch genau jene Aufgaben, bei denen der Gewinn am größten wäre. Wer also eine klare Zahl sucht, findet sie nicht — auch nicht bei denen, die am ehrlichsten messen.

Zwei weitere Datenpunkte gehören ins Bild, bei beiden ist der Interessenkonflikt zu benennen, weil die Erheber Werkzeuge in diesem Markt verkaufen. Die Codeanalyse-Firma GitClear berichtet aus 623 Millionen untersuchten Codeänderungen über drei Jahre einen Anstieg duplizierter Codeblöcke um 81 Prozent und einen Rückgang verschobenen, also aufgeräumten Codes von 21 auf 3,8 Prozent. Der Anbieter CodeRabbit zählte in 470 Pull Requests bei KI-mitverfasstem Code 10,83 Befunde pro Änderung gegenüber 6,45 bei rein menschlichem, mit einem Schwerpunkt bei Sicherheitsthemen.

Und selbst die Gegenmaßnahme hat eine Kehrseite: Eine Arbeit mit dem Titel „Building to the Test“ zeigt, dass Agenten auf das optimieren, was geprüft wird — bei einer Portierung erreichten Modelle nahezu perfekte Testergebnisse, obwohl zentrale Funktionalität fehlte.

Was daraus für Entscheidungen folgt

Drei Schlüsse lassen sich aus dieser Quellenlage ziehen, ohne sie zu überdehnen.

Erstens: Die Kontextdatei ist kein Hebel, sondern Hygiene. Wer Produktivitätsgewinne erwartet, weil eine AGENTS.md im Repository liegt, erwartet das Falsche — besonders, wenn die Datei automatisch erzeugt wurde. Sinnvoll ist sie für das, was ein Agent nicht aus dem Code ableiten kann: der ungewöhnliche Build-Befehl, die Konvention, die nirgends dokumentiert ist, die Bibliothek, die man bewusst nicht benutzt. Alles andere konkurriert mit der Aufgabe um Aufmerksamkeit.

Zweitens: Der eigentliche Hebel ist die Prüfbarkeit. Anthropics Dokumentation bringt es auf einen Satz, der weniger nach Werkzeug und mehr nach Organisation klingt: „Claude stops when the work looks done. Without a check it can run, ‚looks done‘ is the only signal available.“ Ein Agent ohne ausführbaren Prüfer liefert etwas, das fertig aussieht. Ein Team, dessen Testsuite langsam, lückenhaft oder unzuverlässig ist, wird von Agenten nicht schneller — es wird nur schneller mit unklarem Ergebnis. Das ist die unromantische Nachricht an Tech Leads: Die Investition, die Agenten produktiv macht, ist oft die Testinfrastruktur, die schon vor der KI auf der Liste stand.

Drittens: Konfigurationsentscheidungen brauchen Messung, nicht Meinung. Die Kontextdatei ist das erste Beispiel einer neuen Klasse von Einstellungen — Prompts, Regelwerke, Subagenten-Zuschnitte —, die sich anfühlen wie Konfiguration, aber wirken wie Code. Wer sie ändert, ohne einen wiederholten Messlauf dagegen zu halten, trifft eine Entscheidung auf Basis eines Einzelversuchs. Genau davor warnen in dieser Recherche sowohl die Forschung als auch der Hersteller als auch die Praktikerin.

Über eine andere Seite derselben Datei haben wir in unserer Reportage vom 28. August geschrieben: dort ging es darum, dass eine Konvention für KI-Agenten zur Lieferkette für fremden Code werden kann. Beide Befunde zusammen ergeben ein nüchternes Bild. Die Datei, über die am meisten geredet wird, leistet für die Leistung am wenigsten — und trägt dabei ein Risiko, über das am wenigsten geredet wird.