Context Engineering für Coding Agents

Context Engineering für Coding Agents

0:00 Stellen Sie sich vor, eine neue Kollegin fängt bei Ihnen an. Was sagen Sie ihr am ersten Tag? Vermutlich nicht, wie eine Schleife funktioniert — sondern welcher Testbefehl der richtige ist, welche Verzeichnisse man besser nicht anfasst und welche Eigenheit im Code aus gutem Grund so aussieht. Genau dieses Wissen braucht auch ein Coding Agent, und zwar in jeder neuen Sitzung erneut.

0:22 Context Engineering ist die Disziplin, dieses Wissen einmal aufzuschreiben, statt es in jedem Prompt zu wiederholen. Es ist der unspektakulärste Teil dieses Seminars — und der mit dem besten Verhältnis von Aufwand zu Wirkung.

Context Engineering für Coding Agents

0:35 Vier Fragen führen durch dieses Modul. Was gehört überhaupt in eine Regeldatei — und was ausdrücklich nicht? Wie werden mehrere solcher Dateien zusammengesetzt, wenn es global, im Projekt und im Unterverzeichnis welche gibt? Wie lässt man sich so einen Regelblock werkzeuggestützt vorschlagen, ohne ihn ungeprüft zu übernehmen?

0:54 Und zuletzt die Frage, die im Alltag entscheidet: Wie hält man das Ganze aktuell? Am Ende prüfen Sie die Wirksamkeit Ihrer eigenen Regeln in einem echten Lauf.

Welche Informationen ein Agent braucht

1:04 Fangen wir mit der Auswahl an, denn hier wird der meiste Aufwand verschwendet. Die Versuchung ist groß, alles aufzuschreiben, was über ein Projekt wahr ist. Nützlich ist aber nur ein kleiner Teil davon — und der Rest kostet nicht nur Schreibzeit, sondern auch Platz im Kontext, der dann für den Code fehlt. Sehen wir uns an, wo die Grenze verläuft.

1:25 Das Auswahlkriterium ist überraschend scharf: Hinein gehört, was der Agent zum Schreiben korrekten Codes braucht und nicht aus dem Repository ablesen kann. Moderne Agenten lesen Code sehr gut — deutlich besser, als sie Prosa über Code verstehen. Eine Beschreibung der Architektur ist deshalb meistens verschwendeter Platz.

1:43 Wörtliche Befehle dagegen kann niemand erraten, Konventionen ohne Werkzeugzwang stehen nirgends, und gesperrte Bereiche sieht man dem Code nicht an. Dazu kommt das Kriterium, wann etwas als fertig gilt — die vielleicht wichtigste einzelne Zeile in so einer Datei. Die linke Spalte hat eine Gemeinsamkeit: Sie enthält nur Dinge, die man nicht sehen kann.

2:04 Die rechte Spalte auch — nämlich Dinge, die man sehr wohl sehen kann, wenn man ins Repository schaut. Verzeichnisbäume, Tech-Stack-Listen, Prosa über die Architektur: All das beschreibt, was ohnehin dasteht. Es fühlt sich beim Schreiben gründlich an und ist trotzdem verschenkte Mühe. Die Fußzeile bringt es auf den Punkt: Wer beschreibt, was im Code steht, verbraucht Kontext ohne Gegenwert.

2:28 Und Kontext ist eine begrenzte Ressource, auch wenn die Zahlen groß klingen. Diese vier Punkte sind keine Theorie, sondern die häufigsten Beobachtungen aus der Praxis. Der Agent wählt einen plausiblen Testbefehl — plausibel deshalb, weil er in tausend anderen Projekten stimmt, nur in Ihrem eben nicht. Er modernisiert ein Muster, das aus gutem Grund alt aussieht, weil ihm niemand den Grund gesagt hat. Er ändert generierte Dateien, die beim nächsten Lauf überschrieben werden.

2:56 Und er hält sich für fertig, weil kein Kriterium hinterlegt war. Jeder dieser Fälle ist eine Zeile in der Regeldatei — wirklich nur eine Zeile. Achten Sie beim Lesen weniger auf den Inhalt als auf den Ton. Da steht nicht „wir verwenden üblicherweise npm", sondern der Befehl selbst. Nicht „Migrationen sollten möglichst nicht geändert werden", sondern die klare Ansage. Das ist der Unterschied zwischen einer Absichtserklärung und einer Regel.

3:22 Anweisend formulieren fühlt sich beim Schreiben unhöflich an — für den Agenten ist es der Unterschied zwischen einer Information und einer Anweisung. Beachten Sie auch die letzte Zeile: Das Fertig-Kriterium steht in derselben Datei wie die Befehle, denn beides braucht er in derselben Sekunde.

AGENTS.md und Repository-Kontext

3:39 Im zweiten Kapitel geht es um die Mechanik. Regeln gibt es selten nur an einer Stelle: etwas im Benutzerverzeichnis, etwas in der Projektwurzel, vielleicht noch etwas in einem Unterverzeichnis. Wie diese Ebenen zusammenkommen und welche im Konflikt gewinnt, entscheidet darüber, ob Ihre Regeln überhaupt wirken. Das ist weniger offensichtlich, als es klingt.

4:01 AGENTS.md ist bewusst schlicht gehalten: gewöhnliches Markdown, keine Pflichtfelder, kein Schema. Interessant ist das Einsammeln. Die Dateien werden vom Wurzelverzeichnis abwärts bis zum aktuellen Arbeitsverzeichnis aneinandergehängt. Was näher an der Arbeit liegt, steht am Ende — und wiegt damit schwerer. Das entspricht der Intuition aus dem Alltag: Die Hausordnung gilt für das Gebäude, der Zettel an der Kellertür für den Keller.

4:27 Wenn beide etwas Widersprüchliches sagen, gilt der Zettel. Nur merkt man den Widerspruch bei Regeldateien meist nicht. Die spannende Zeile ist die vierte. Alles, was Sie in Dateien schreiben, wird von einem ausdrücklichen Auftrag im Chat überstimmt — und zwar zu Recht. Regeln sind Voreinstellungen, keine Sperren. Wer eine echte Grenze braucht, bekommt sie nicht über Text, sondern über Rechte und Sandbox; darüber sprechen wir in einem eigenen Modul.

4:54 Die Fußzeile erwähnt außerdem eine Override-Datei: Sie ist der saubere Weg, eine globale Gewohnheit vorübergehend auszuschalten, ohne die eigentliche Datei zu verstümmeln und danach zu vergessen. Hier kommt der Punkt, an dem sich Ehrgeiz rächt. Die eingelesene Menge ist begrenzt — standardmäßig 32 Kilobyte. Wichtiger als diese Zahl ist aber die Ökonomie dahinter: Jede Zeile in der Regeldatei ist Kontext, der für den Code nicht mehr da ist.

5:22 Lange Referenztexte gehören deshalb verlinkt, nicht eingefügt. Als Startpunkt haben sich zwanzig bis dreißig Zeilen bewährt. Was darüber hinauswächst, sollte aus einem echten Reibungspunkt entstanden sein — nicht aus dem Wunsch, vollständig zu sein. Der erste Punkt ist der, den man nicht kommen sieht: Widersprüche zwischen zwei Ebenen fallen niemandem auf, weil nichts kaputtgeht — das Ergebnis ist nur anders als erwartet.

5:48 Der zweite ist die wichtigste Erkenntnis dieses Moduls: Eine veraltete Regel ist schlimmer als keine Regel, weil sie aktiv in die falsche Richtung führt. Der dritte ist Platzverschwendung, der vierte eine grundsätzliche Warnung: Regeln sind Text, keine technische Zusicherung. Sie können missachtet werden, und ohne Blick in den Diff merken Sie es nicht.

Projektkontext werkzeuggestützt aufbauen

6:08 Nun die praktische Frage: Muss man so eine Datei von Hand schreiben? Nein — es gibt Abläufe, die das Repository untersuchen und einen Regelblock vorschlagen. Interessant an ihnen ist weniger, dass sie schreiben können, als wie sie mit Ihnen umgehen, bevor sie schreiben. Der Ablauf untersucht das Projekt, fragt nach Regeln, die er nicht sehen kann, und schlägt dann einen kurzen Block vor. Zwei Details sind dabei bemerkenswert.

6:34 Erstens schreibt er zwischen eigene Marker — der erzeugte Teil bleibt damit abgrenzbar, und was Sie selbst ergänzt haben, bleibt unberührt. Zweitens zeigt er den Block vollständig an und wartet auf Ihre Bestätigung, bevor er ihn schreibt. Und er committet nicht. Das ist keine Zurückhaltung aus Höflichkeit, sondern die Anerkennung eines einfachen Umstands: Diese Datei wirkt in jeder künftigen Sitzung.

6:57 Der wichtigste Schritt ist der dritte, und er lautet: streichen. Alles, was im Code steht oder von einem Werkzeug erzwungen wird, fliegt raus. Vorschläge beschreiben gern, was sie im Repository gesehen haben — das ist der häufigste Befund. Danach erst schreiben lassen, den Diff prüfen und die Datei wie jede andere Quelldatei reviewen.

7:17 Die Fußzeile weist auf die Marker hin: Sie sind der Grund, warum ein zweiter Lauf Ihre Handarbeit nicht überschreibt. Insgesamt dauert der ganze Ablauf keine halbe Stunde, wirkt aber in jeder Sitzung danach. Warum diese Umständlichkeit mit der Bestätigung? Weil der Preis eines Fehlers hier asymmetrisch ist. Eine falsche Zeile im Code fällt beim nächsten Test auf.

7:39 Eine falsche Regel im Kontext wirkt still, in jeder Sitzung, und niemand sucht dort. Dazu kommt: Der Block konkurriert mit Anweisungen, die schon im Projekt stehen. Und ein sehr praktischer Grund zum Schluss — was Sie selbst nicht gelesen haben, können Sie im Review nicht vertreten. Wenn eine Kollegin fragt, warum diese Regel dort steht, sollte es eine Antwort geben.

8:02 Der erste Punkt fasst zusammen, was wir gerade besprochen haben. Der zweite ist eine Grenzziehung, die im Seminar oft diskutiert wird: Architekturentscheidungen gehören nicht in die Regeldatei, sondern in die Spezifikation. Die Regeldatei sagt, wie hier gearbeitet wird — nicht, warum das System so aufgebaut ist. Der dritte Punkt betrifft die Pflege: Wer den Block bei jedem Lauf neu erzeugt, verliert die Erfahrung, die drinsteckte.

8:27 Und der vierte ist ein Klassiker: zwei Regeldateien parallel, keine davon als führend erklärt.

Kontext prüfen und pflegen

8:34 Bleibt das Kapitel, das über den langfristigen Nutzen entscheidet. Eine Regeldatei ist kein Dokument, das man einmal schreibt und dann besitzt — sie veraltet genau wie Code, nur unauffälliger. Sehen wir uns die drei Anlässe an, bei denen man sie anfasst, und wie man ihre Wirkung überhaupt misst. Drei Anlässe, und der zweite ist der wertvollste. Nach größeren Umbauten prüfen, ob die Regeln noch stimmen — das leuchtet ein.

9:00 Bei Verdacht auf Veralterung durchgehen und kürzen — auch. Aber der mittlere Anlass ist der, den die meisten verpassen: Wenn der Agent denselben Fehler zum zweiten Mal macht, ist das kein Ärgernis, sondern ein Signal. Es fehlt eine Regel, und Sie wissen in diesem Moment genau, welche. Wer diese Gelegenheit nutzt, hat nach ein paar Wochen eine Datei, die aus echter Erfahrung besteht.

9:23 Achten Sie auf die Fußzeile, denn sie enthält die eigentliche Botschaft: Gestrichen wird häufiger als ergänzt. Das widerspricht dem Reflex — Regeln sammeln sich an, weil jede einzelne mal einen Grund hatte. Aber eine Datei, die nur wächst, wächst irgendwann aus ihrem Nutzen heraus: Sie kostet Kontext, niemand liest sie mehr ganz, und Widersprüche schleichen sich ein.

9:45 Nehmen Sie sich vor, bei jeder Ergänzung eine Zeile zu suchen, die weg kann. Meistens finden Sie eine. Ihre Aufgabe ist ungewöhnlich, weil sie nichts baut: Sie messen, ob Ihre Regeln überhaupt wirken. Dafür formulieren Sie Kontrollfragen so, dass eine Regel im Weg steht — bitten Sie den Agenten also ausdrücklich um etwas, das die Regel verbietet.

10:06 Nur dann zeigt sich ihre Wirkung. Fragen Sie nach dem Testbefehl, nach einem gesperrten Pfad, nach der Stelle für eine Rechteprüfung, nach dem Fertig-Kriterium. Was der Agent falsch beantwortet, ist Ihr nächster Eintrag — oder ein Hinweis darauf, dass die Regel auf der falschen Ebene steht. Vier Sätze zum Mitnehmen. In die Regeldatei gehört, was im Code nicht steht — sonst nichts.

10:29 Regeln schichten sich von global bis zum Arbeitsverzeichnis, und ein ausdrücklicher Auftrag schlägt sie alle. Ein erzeugter Block wird gelesen und gekürzt, bevor er geschrieben wird. Und wiederholte Agentenfehler sind kein Ärgernis, sondern eine fehlende Regel. Damit haben wir den dauerhaften Kontext beisammen. Im nächsten Modul geht es um den einmaligen: die Spezifikation für ein konkretes Vorhaben.