Context Engineering für Coding Agents: Warum Kontext die Codequalität bestimmt

Zwei Senior-Entwickler, derselbe Coding Agent, dasselbe Ticket, derselbe 15 Jahre alte Monolith. Der eine liefert am Nachmittag einen sauberen Pull Request. Der andere kämpft zwei Tage und wirft am Ende alles weg. Am Prompt liegt es nicht, beide formulieren sauber. Entscheidend ist, was der Agent sah: welche Dateien, welche Regeln und welcher Ausschnitt der Codebasis im Kontextfenster landete.

Ab einem bestimmten Punkt bringt besseres Prompten keine Verbesserung mehr. Sie können denselben Satz zehnmal umformulieren, die Ergebnisse werden nicht besser. Was die Codequalität im Team prägt, ist der Kontext, den der Agent erhält. Das ist der Schritt vom Prompten zum Orchestrieren. Wie dieser Wechsel mit Rollout, Tooling, Messung und Compliance zusammenhängt, ordnet der Coding-Agents-Leitfaden als Gesamtbild ein.

Der Wechsel von Prompt Engineering zu Context Engineering ist keine Mode. Der Begriff ist nützlich, weil er ein Problem benennt, das Teams beim zweiten oder dritten Agenten-Rollout selbst spüren: Nicht der perfekte Satz entscheidet, sondern welche Informationen, Regeln und Grenzen der Agent kennt.

Context Engineering beschreibt, wie Teams den Kontext eines Modells systematisch steuern: Regeln, Gedächtnis, Retrieval und das aktive Kontextfenster (englisch Context Window). Prompt Engineering (den Wortlaut einer Anweisung optimieren) und RAG (eine Retrieval-Technik) sind Teilbereiche davon, keine Konkurrenz. Anthropic nennt es "die natürliche Weiterentwicklung des Prompt Engineering".

Kurz gefasst: Ab einem Punkt bringt besseres Prompten nichts mehr, weil nicht der Wortlaut über die Qualität entscheidet, sondern der Kontext, den der Agent sieht. Context Engineering ist der Oberbegriff für das systematische Zusammenstellen von Regeln, Gedächtnis, Retrieval und Kontextfenster. Prompt Engineering und RAG sind Teilbereiche davon. Sie stehen nicht in Konkurrenz dazu.

Ich nutze Claude Code im Folgenden als durchgehendes Beispiel, weil sich die Mechanik von Context Engineering daran besonders gut zeigen lässt, bis zu versionierten Regeln und gesperrten Pfaden. Die Prinzipien gelten genauso für Cursor, Codex, Copilot und Aider; nur die Dateinamen und Konfigurationsoptionen heißen anders.

Context Engineering vs. Prompt Engineering: Der Prompt ist die Frage, der Kontext ist das Wissen

Prompt Engineering optimiert den Wortlaut einer einzelnen Anweisung. Context Engineering entscheidet, welche Informationen das Modell bei jedem Schritt insgesamt sieht. Das eine ist ein Satz, das andere ein System.

Dazu kommt ein zweiter Wandel, der oft übersehen wird: Die Modelle selbst haben sich verändert. Bei klassischen Chatmodellen musste der Prompt den Denkweg meist mitliefern, also die Rolle setzen, Zwischenschritte erzwingen, Beispiele vorgeben, das Antwortformat festnageln. Reasoning-Modelle übernehmen einen Teil dieser Planung intern. OpenAI rät für sie zu einfachen, direkten Prompts und warnt, dass alte Kniffe wie "think step by step" nicht unbedingt helfen und teils sogar stören. Prompt Engineering verschwindet damit nicht, es wird nüchterner: Ziel, Grenzen, Format und Erfolgskriterien klar benennen. Die eigentliche Hebelwirkung liegt aber immer öfter darin, welchen Kontext das Modell bekommt und welchen nicht.

Das macht Context Engineering bei Coding Agents nicht kleiner, sondern größer. Reasoning-Modelle brauchen nicht nur Eingabe-Token, sie erzeugen zusätzlich Reasoning-Token, die als Output abgerechnet werden und ebenfalls Platz im Kontextfenster belegen. Wer das Fenster mit Logs, alten Dateien und widersprüchlichen Regeln füllt, nimmt dem Modell Aufmerksamkeit und den Raum zum Nachdenken.

Die Quellen, die den Begriff geprägt haben, sind sich in diesem Punkt ungewöhnlich einig. Anthropic beschreibt Context Engineering im Leitfaden "Effective context engineering for AI agents" (September 2025) als "the natural progression of prompt engineering": Wo Prompt Engineering einen einzelnen Prompt schreibt, wählt Context Engineering bei jedem Schritt neu aus, welche Informationen das Modell erhält: Systemanweisungen, Tools, MCP-Verbindungen, externe Daten, der bisherige Verlauf. Für LangChain ist Prompt Engineering entsprechend "a subset of context engineering". Andrej Karpathy nannte es im Juni 2025 "the delicate art and science of filling the context window with just the right information for the next step" und zählte RAG, Tools und Memory als Zutaten auf. RAG ist demnach ein Baustein, nicht dasselbe wie Context Engineering.

Warum diese neue Einordnung in der Praxis wichtig ist, bringt Philipp Schmid von Google DeepMind auf den Punkt: "Die meisten Agent-Fehler sind heute keine Modellfehler mehr, sondern Kontextfehler." Oft fehlt dem Modell nicht die Fähigkeit, sondern der passende Kontext. Es scheitert nicht am Denken, sondern am Blickfeld.

In der Codebasis wird das konkret. Birgitta Böckeler von Thoughtworks beschreibt auf martinfowler.com Context Engineering für Coding Agents (Februar 2026) als "curating what the model sees so that you get a better result", und sie ordnet Claude Code als eines der Werkzeuge ein, an denen diese Entwicklung besonders sichtbar wird. Es geht nicht mehr darum, einen Prompt zu schleifen, sondern darum, die Informationsumgebung zu gestalten, in die jeder Prompt eingebettet ist.

Welche konkreten Muster für Kontextdateien in gewachsenen Codebasen daraus folgen, ist eine Ebene tiefer angesiedelt. Hier geht es um das System darüber. Und dieses System speist sich aus vier klar benennbaren Quellen.

Die vier Kontextquellen eines Coding Agents

Der Kontext, mit dem ein Coding Agent arbeitet, kommt aus vier Quellen: den Regeln, die Sie ihm mitgeben, seinem Gedächtnis über Sitzungen hinweg, dem Retrieval, also der gezielten Suche in der Codebasis, und dem aktiven Kontextfenster. Wer Context Engineering betreibt, steuert diese vier gezielt, statt sie dem Zufall zu überlassen. Erst wenn diese vier Quellen getrennt sichtbar sind, können Teams an den richtigen Stellschrauben drehen.

Regeln: CLAUDE.md und AGENTS.md als versioniertes Team-Artefakt

Regeln sind der einzige Kontext, den das Team bewusst schreibt und gemeinsam versioniert. Alles andere passiert automatisch oder zur Laufzeit. Hier greifen Sie direkt ein.

Bei Claude Code steckt dieser Kontext in der CLAUDE.md, die bei jeder Sitzung geladen wird. Das heißt: Jede Zeile darin verbraucht Token, neben der eigentlichen Konversation. Anthropics eigene Vorgabe empfiehlt deshalb weniger als 200 Zeilen pro Datei; längere Dateien, so die Doku wörtlich, "consume more context and reduce adherence". Das ist der doppelte Hebel, den viele übersehen: Größe kostet nicht nur Token. Sie senkt auch die Wahrscheinlichkeit, dass der Agent die Regeln beachtet. Eine CLAUDE.md mit 600 Zeilen kostet mehr und wird vom Agenten schlechter beachtet als eine knappe Datei.

Nur die Projekt-CLAUDE.md im Repository ist das versionierte Team-Artefakt, das über die Versionskontrolle geteilt wird. Die User-Datei ist persönlich, und die CLAUDE.local.md gehört in die .gitignore. Claude Code lädt mehrere Geltungsbereiche nacheinander, vom Allgemeinen zum Spezifischen, von der Enterprise- oder Managed-Policy bis zur lokalen Datei. Wichtig: Claude Code hängt alle gefundenen Dateien aneinander. Sie überschreiben einander nicht. Was weiter oben geladen wurde, verschwindet nicht. Es summiert sich.

Daneben steht AGENTS.md, der offene, werkzeugunabhängige Standard, ein README für Agenten. Er entstand 2025 aus einer herstellerübergreifenden Initiative, wird heute von der Agentic AI Foundation der Linux Foundation betreut, von über 60.000 Open-Source-Projekten genutzt und von zahlreichen Agenten unterstützt: Codex, Cursor, Aider, Copilot und weiteren. Nur eben nicht automatisch von Claude Code. Die Brücke ist ein @AGENTS.md-Import in der CLAUDE.md oder ein Symlink. Ein Repository mit nur einer AGENTS.md gibt Claude Code keine automatisch geladene Projektanweisung. Das fällt oft erst auf, wenn der Agent zum dritten Mal eine Konvention verletzt, die in der Datei längst beschrieben ist.

Dass eine solche Regel am Ende ein Ratschlag bleibt, den der Agent lesen, aber ignorieren kann, wird später im Governance-Abschnitt wichtig.

Gedächtnis: Was der Agent zwischen Sitzungen behält

Außerdem gibt es ein eigenes Auto-Memory. Es speichert pro Repository Notizen, die der Agent aus Ihren Korrekturen und Präferenzen ableitet. Beim Start jeder Sitzung werden die ersten rund 200 Zeilen der Indexdatei MEMORY.md geladen; die dahinterliegenden Themendateien holt der Agent nur bei Bedarf. Der Unterschied auf den Punkt gebracht: Die CLAUDE.md schreibt das Team, das Auto-Memory schreibt der Agent.

Technisch dahinter steht Anthropics Ansatz für lange Aufgaben, das strukturierte Notieren ("structured note-taking"). Der Agent legt Notizen außerhalb des Kontextfensters ab, etwa in einer NOTES.md oder einer To-do-Liste, und holt sie später wieder herein. So entsteht ein dauerhaftes Gedächtnis mit wenig Zusatzaufwand, auch über Dutzende Werkzeugaufrufe hinweg, ohne dass der gesamte Verlauf dauerhaft im Fenster mitgeschleppt werden muss.

Retrieval: Wie der Agent die Codebasis durchsucht

Claude Code arbeitet sich durch die Codebasis wie ein Entwickler: grep, Dateien öffnen, Referenzen verfolgen, ohne vorab einen Index zu bauen oder etwas hochzuladen. Das nennt sich agentic search oder Just-in-Time-Retrieval. Die CLAUDE.md liegt vorab im Kontext, die Dateien selbst holt der Agent zur Laufzeit mit seinen Werkzeugen.

Dass das kein Zufall ist, hat Boris Cherny, der Claude-Code-Lead bei Anthropic, im Februar 2026 beschrieben: "Early versions of Claude Code used RAG + a local vector db, but we found pretty quickly that agentic search generally works better. It is also simpler and doesn't have the same issues around security, privacy, staleness, and reliability." Kurz gesagt: Frühere Versionen nutzten RAG. Anthropic hat es wieder entfernt.

Warum das zählt, sieht man am typischen Fehler des Gegenmodells. Ein Embedding-Index liefert gern eine Funktion, die das Team vor zwei Wochen umbenannt hat, oder ein Modul, das letzten Sprint gelöscht wurde. Cursor wählt bewusst den anderen Weg, einen persistenten, server-gestützten Embeddings-Index mit inkrementellem Sync. Beides kann sinnvoll sein. Es ist ein Architektur-Trade-off, kein Qualitätsurteil. Aider zeigt einen dritten Weg mit seiner repository map: tree-sitter parst die Symbole, ein Graph-Ranking wählt die wichtigsten Symbole für ein festes Token-Budget aus. Drei Werkzeuge, drei Antworten auf dieselbe Frage, wie ein Agent an das relevante Stück Code kommt.

Und Retrieval endet nicht am Code. Über einen MCP-Server als weitere Kontextquelle zieht der Agent auch Jira-Tickets, Datenbankabfragen oder Runbooks in seinen Kontext.

Das aktive Kontextfenster: Was gerade im Arbeitsspeicher liegt

Andrej Karpathys Analogie trifft es am besten: Das LLM ist die CPU, das Kontextfenster ist der Arbeitsspeicher. Alles, was der Agent gerade im Kopf hat, konkurriert um denselben begrenzten Platz: die Systemanweisungen, die geladenen Dateien, die Tool-Ausgaben, der bisherige Gesprächsverlauf. Nichts davon ist gratis. Jeder Eintrag belegt Platz und kann einen anderen verdrängen.

Und genau hier beginnt das Missverständnis, dass mehr Platz automatisch mehr Signal bedeutet.

Warum mehr Kontext nicht besser ist

Mehr Kontext hilft nur, solange er relevante Information enthält; Rauschen senkt die Trefferquote und treibt die Kosten nach oben. Ab einer gewissen Kontextlänge sinkt die Trefferquote eines Modells messbar, egal wie groß das Fenster laut Datenblatt ist.

Anthropic formuliert es im eigenen Leitfaden nüchtern: Kontext ist "a finite resource with diminishing marginal returns". Jedes Modell hat ein begrenztes Aufmerksamkeitsbudget ("attention budget"), und jeder zusätzliche Token zehrt daran. Der Grund liegt in der Architektur: In einem Transformer bezieht sich jeder Token auf jeden anderen, das sind bei n Token in der Größenordnung von n² Beziehungen. Wächst der Kontext, verteilt sich dieselbe Aufmerksamkeit auf immer mehr Paare, und das Signal verdünnt sich. Gutes Context Engineering heißt deshalb nicht, das Fenster zu füllen, sondern "the smallest possible set of high-signal tokens" zu finden.

Die Belege dafür sind inzwischen zahlreich. NoLiMa (Modarressi et al., ICML 2025) testet Modelle mit versteckten Frage-Antwort-Paaren, die bewusst keine Wortüberlappung haben, das Modell kann also nicht über Stichwort-Matching abkürzen. Bei 32.000 Token fielen 11 von 13 getesteten Modellen unter die Hälfte ihrer Kurzkontext-Basisleistung. Selbst GPT-4o, in NoLiMa einer der stärkeren Werte, rutschte von 99,3 % auf 69,7 %. Wichtiger als dieser eine Wert ist der Breitenbefund: Es trifft die Modellgruppe, nicht ein einzelnes Modell. RULER (Hsieh et al., NVIDIA) prüft 17 Modelle über 13 Aufgaben, und obwohl alle ein Kontextfenster von mindestens 32.000 Token unterstützen, hält nur die Hälfte bei 32K überhaupt noch brauchbare Leistung. Und "Lost in the Middle" (Liu et al., TACL) zeigt eine U-förmige Kurve: Die Trefferquote ist am höchsten, wenn die relevante Information am Anfang oder am Ende des Kontexts steht, und sie fällt deutlich ab, sobald das Modell auf die Mitte eines langen Kontexts zugreifen muss. Die Datenblattgröße sagt also wenig darüber, was das Modell in der Mitte einer 400-Zeilen-Datei noch findet.

Für dieses Verhalten gibt es einen Namen: context rot. Der Begriff stammt aus einer Untersuchung von Chroma (Juli 2025, 18 untersuchte LLMs), und Anthropic übernimmt ihn in der eigenen Dokumentation: "more context isn't automatically better. As token count grows, accuracy and recall degrade, a phenomenon known as context rot." Wer jetzt auf das nächste, noch größere Fenster hofft, wird enttäuscht. Anthropic widerspricht dieser Hoffnung ausdrücklich: "context windows of all sizes will be subject to context pollution." Auf ein größeres Fenster zu warten ist keine Lösung, sondern ein Aufschub.

Im Alltag von Claude Code sehen Sie das indirekt. Das effektiv nutzbare Fenster liegt spürbar unter der 1M-Token-Angabe aus dem Datenblatt, und Auto-Compact fasst die Sitzung zusammen und startet sie neu, lange bevor die Grenze aus dem Datenblatt erreicht ist. Eine harte Zahl dafür kursiert in der Community, aber sie ist versionsabhängiges Reverse-Engineering, kein zugesicherter Wert. Verlassen sollten Sie sich nicht darauf, dass ein weiteres Modul, das Sie in den Kontext werfen, noch gelesen wird.

Der zweite Grund, das Fenster nicht zu fluten, steht auf der Rechnung. In der Agentenschleife wird der Kontext bei jedem Schritt erneut bezahlt, "token costs scale with context size". Ein stabiles Präfix, eine selten geänderte CLAUDE.md und ein fester System-Prompt werden durch Prompt Caching deutlich günstiger, rund 90 % Rabatt auf den gecachten Teil. Ein Kontext, der sich bei jedem Aufruf ändert, ist es nicht. Als greifbarer Anker (Preise Stand Juli 2026): Opus 4.8 kostet 5 USD pro Million Input-Token, Sonnet 5 liegt bei 2 USD Input (Einführungspreis bis 31.08.2026, danach 3 USD). Über Enterprise-Deployments nennt Anthropic im Schnitt rund 13 USD pro Entwickler und aktivem Tag, 150 bis 250 USD pro Monat. Die alte Regel, wonach über 200K Token der doppelte Preis fällig wird, gilt für die aktuellen Modelle übrigens nicht mehr, sie wurde im März 2026 aufgehoben, das volle 1M-Fenster ist zum Standardpreis enthalten. Die vollständige Preis-Mechanik gehört in eine eigene Rechnung, die steht in Token-Kosten und Break-even der Coding-Tools. Hier zählt nur das Prinzip: Ein übervoller Kontext ist doppelt teuer: Er kostet Qualität und Geld.

Context Engineering im 15 Jahre alten Monolithen

In einer gewachsenen Codebasis entscheidet sich erfolgreiches Context Engineering an einer einzigen Frage: Weiß der Agent, wo er suchen soll? Agentic search skaliert nur, wenn die Codebasis ihm genug Ausgangskontext gibt, um überhaupt am richtigen Ort anzufangen.

Anthropic ist an dieser Stelle deutlich. Agentic search "works best when Claude has enough starting context to know where to look". Diesen Ausgangskontext liefern CLAUDE.md-Dateien und Skills. Die Kehrseite beschreibt Anthropic ebenfalls: "If you ask it to find all instances of a vague pattern across a billion-line codebase, you'll hit context-window limits before the work begins." Der Agent läuft gegen das Kontextlimit, bevor die eigentliche Arbeit anfängt. Teams, die in das Setup der Codebasis investieren, sehen bessere Ergebnisse, und das ist keine Frage des besseren Modells. Lesbarkeit für den Agenten, also Struktur, Regeln, Skills, ist Voraussetzung, nicht Kür.

Im Monorepo wird das konkret. Legen Sie die CLAUDE.md auf der Ebene des relevanten Unterverzeichnisses an, nicht im Repo-Root: Claude durchläuft den Verzeichnisbaum ohnehin nach oben und lädt jede CLAUDE.md, die es unterwegs findet. Die Root-Datei bleibt schlank und enthält nur Verweise und kritische Stolperfallen, nicht die Regeln jedes einzelnen Moduls. Legen Sie Test-, Lint- und Build-Kommandos pro Unterverzeichnis fest, damit der Agent im billing-Modul nicht die Kommandos aus payments verwendet. Und pflegen Sie .ignore-Dateien für generierte Dateien, Build-Artefakte und Third-Party-Code, sonst füllt der Agent seinen ohnehin knappen Kontext mit Rauschen, das niemand lesen wollte.

Der Umbau selbst, also wie Sie einen alten Monolithen mit Charakterisierungstests absichern und Schritt für Schritt in kleinen Pull Requests verändern, ist ein eigenes Thema. Das steht im Weg durch den Legacy-Monolithen. Hier geht es um die Vorarbeit: welchen Ausschnitt der Codebasis der Agent überhaupt sehen soll, damit er im richtigen Verzeichnis landet.

Ist geklärt, welchen Ausschnitt der Agent sehen soll, folgt die härtere Frage: welchen er sehen darf.

Governance: Welchen Kontext darf der Agent sehen?

Standardmäßig sieht ein Coding Agent mehr, als die meisten Teams annehmen. Der Lesezugriff ist breit, viele Grenzen sind eher Schutzmechanismen als harte Prozessgrenzen, und wer harte Grenzen braucht, muss sie auf Betriebssystemebene ziehen.

Das Standardverhalten wird oft falsch eingeschätzt. Claude Code arbeitet ab Werk schreibgeschützt, verlangt also für jede Schreiboperation eine Freigabe. Der Lesezugriff ist damit aber nicht auf das Arbeitsverzeichnis beschränkt. Der Agent kann Dateien außerhalb des Projektordners lesen, was für Systembibliotheken und Abhängigkeiten nützlich ist. Die Verzeichnisgrenze ist eine Schreibgrenze, keine Lesegrenze. Für die Frage, was der Agent tatsächlich sieht, ist genau das der springende Punkt.

Der dokumentierte Schutzmechanismus dafür sind versionierte Deny-Regeln. In .claude/settings.json sperrt permissions.deny gezielt Pfade, etwa Read(./.env) oder Read(./secrets/**). Diese Datei kann ins Repository übernommen und gemeinsam versioniert werden. Sie gilt damit fürs ganze Team, nicht nur auf der lokalen Maschine. Einen .claudeignore-Mechanismus als offiziellen Ausschlussweg dokumentiert Claude Code nicht; der dokumentierte Weg läuft über diese Deny-Regeln.

Hier endet allerdings die Garantie. Das sollte man klar sagen. Deny-Regeln sind ein wichtiger erster Filter, aber keine harte Prozessgrenze. Sie greifen bei den eingebauten Dateiwerkzeugen und bei erkannten Bash-Kommandos wie cat, head, tail und sed, aber nicht zuverlässig bei beliebigen Subprozessen. Ein Python- oder Node-Skript, das eine Datei selbst öffnet, umgeht die Deny-Schicht vollständig. Für harte, prozessübergreifende Sperren brauchen Sie die Sandbox auf Betriebssystemebene mit denyRead, die für alle Kindprozesse erzwungen wird.

Dass Prosa hier kein Schutz ist, lässt sich an einem dokumentierten Muster zeigen. In zwei unabhängigen Bug-Reports von Mai 2026 (#59094, #58173) lasen Agenten .env-Dateien, die korrekt in der .gitignore standen und nie versioniert wurden, und schrieben produktive Zugangsdaten in das Transkript, das anschließend an das Modell gesendet wird, trotz einer expliziten Memory-Regel dagegen. Beide Reports schließen mit dem Befund, dass Prosa-Regeln für die Behandlung von Secrets nicht verlässlich sind. Das ist die harte Version des Governance-Grundsatzes: Die CLAUDE.md ist nicht verbindlich. Sie formt, was der Agent versucht; nur technische Zugriffskontrollen wie Berechtigungsregeln und PreToolUse-Hooks bestimmen, was er darf. Anthropic formuliert es selbst so: "Instructions in your prompt or CLAUDE.md shape what Claude tries to do, but they don't change what Claude Code allows."

Weil der Agent weitreichenden Lesezugriff hat und weil der Kontext für die Modellanfrage an den Anbieter gesendet wird, lautet die operative Frage für Teams im DACH-Raum, welchen Code und welche Daten der Agent aufnehmen darf: proprietärer Code unter NDA, Secrets, und personenbezogene Daten in Testfixtures, Seed-Daten und Logs. Die technischen Schutzmechanismen halten den Agenten von diesen Dateien fern; die rechtliche Einordnung, wann die DSGVO beim Agenten wirklich greift, ist ein eigenes Thema.

Woran ein Team merkt, dass Context Engineering wirkt

Context Engineering ist kein Dokumentationsprojekt. Es muss die Arbeit des Agenten messbar verbessern, sonst hat das Team nur eine schön gepflegte CLAUDE.md und sonst nichts. Der Unterschied zeigt sich nicht in der Datei, sondern im Verhalten des Agenten.

Brauchbare Frühindikatoren sind greifbar: Der Agent bricht seltener mitten im Lauf ab. Pro Pull Request braucht es weniger Korrekturschleifen. Er greift seltener zum falschen Test- oder Build-Kommando. Hinweise wie "lies erst Datei X" werden überflüssig. Die Eingabe-Token pro erfolgreich erledigter Aufgabe sinken. Mehr Pull Requests bestehen Tests und Review schon im ersten Durchlauf. Und permissions.deny, PreToolUse-Hooks oder Sandbox-Regeln greifen sichtbar, statt still im Hintergrund zu verstauben.

Bleiben diese Werte gleich, hat das Team Kontext dokumentiert. Bewegen sie sich, steuert es ihn.

Ebenso oft scheitert Context Engineering nicht am Wissen, sondern an der Zuständigkeit. Niemand weiß, wem die CLAUDE.md gehört, also pflegt sie keiner.

Verantwortung: Die Projekt-CLAUDE.md gehört dem Team oder Tech Lead, das im jeweiligen Verzeichnis arbeitet. Die Root-Regeln im Monorepo gehören dem Platform-Team. permissions.deny, Hooks und Sandbox-Regeln verantworten Security und Platform gemeinsam. Datenschutz und Recht liefern die Liste der regulierten Pfade, schreiben aber nicht die Regeln des Agenten.

Vom Prompten zum Orchestrieren

Der entscheidende Wechsel betrifft nicht das Werkzeug, sondern die Haltung: weg vom einzelnen Prompt, hin zum bewussten Aufbau des Kontexts, mit dem der Agent arbeitet.

Die vier Quellen dieses Kontexts sind nicht vorgegeben. Regeln, Gedächtnis, Retrieval und das aktive Fenster sind Stellschrauben, an denen Sie drehen. Wer sie für unveränderlich hält, überlässt dem Zufall, was der Agent im entscheidenden Moment sieht. Und weil die Kontextarchitektur oft stärker wirkt als die Modellwahl, entscheidet dieses Gerüst öfter über den Ausgang als die Frage, ob Claude oder Cursor unter der Haube läuft.

Was heißt das für die Entscheidung diese Woche? Kürzen Sie zuerst die Projekt-CLAUDE.md auf weniger als 200 Zeilen und behalten Sie nur, was das Team weiß und das Modell nicht aus dem Code ableiten kann. Setzen Sie dann eine versionierte permissions.deny-Regel für .env, Secrets und regulierte Pfade, bevor der erste Agent an produktionsnahem Code arbeitet. Und für kritische Bereiche wie Authentifizierung und Zahlung ersetzen Sie die Textregel durch einen PreToolUse-Hook. Nur dieser Mechanismus wird technisch durchgesetzt. Alles andere ist eine Bitte, die der Agent im ungünstigen Moment überliest.

Checkliste: Context Engineering vor dem ersten Team-Rollout

• Projekt-CLAUDE.md unter 200 Zeilen halten und nur aufnehmen, was das Team weiß und das Modell nicht aus dem Code ableiten kann.
• AGENTS.md per @AGENTS.md-Import oder Symlink für Claude Code sichtbar machen.
• Im Monorepo eigene CLAUDE.md-Dateien für relevante Unterverzeichnisse anlegen und die Root-Datei schlank halten.
• Generierte Dateien, Build-Artefakte und Third-Party-Code über .ignore-Dateien aus dem Suchraum halten.
• .env, Secrets, Logs und regulierte Testdaten über eine versionierte permissions.deny-Regel sperren.
• Für kritische Bereiche wie Authentifizierung und Zahlung einen PreToolUse-Hook oder die OS-Sandbox einsetzen, nicht nur eine Textregel in der CLAUDE.md.
• Kontextgröße und Kosten messen, nicht schätzen.

Im Workshop Coding Agents meistern nutzen wir diese Kontext-Architektur am Code der Teilnehmenden.