Ein Agent kann eine Projektregel nicht rekonstruieren, die nur in den Köpfen einzelner Personen existiert. Er füllt die Lücke mit dem häufigsten Muster aus seinen Trainingsdaten, das völlig vernünftig und für dein System trotzdem falsch sein kann.
Besserer Kontext verringert dieses Raten. Mehr Kontext hilft nicht immer. Ein Repository-Dump kann das eine Interface oder die eine Entscheidung begraben, die die Aufgabe bestimmt.
Behandle Kontext als Beleg
Nützlicher Kontext beantwortet fünf Fragen:
- Welches Verhalten soll sich ändern?
- Wo lebt dieses Verhalten?
- Welche Regeln müssen weiterhin gelten?
- Welches bestehende Beispiel zeigt das lokale Muster?
- Welcher Befehl beweist das Ergebnis?
Jede Antwort sollte nach Möglichkeit auf einen Beleg verweisen. Ein Dateipfad schlägt die Beschreibung einer Datei. Ein fehlschlagender Test schlägt einen Absatz über den Bug. Eine akzeptierte Fixture schlägt „folge unserem üblichen Format“.
Angenommen, ein Endpoint liefert den falschen Status. Gib die Route, die Service-Grenze, den relevanten Test, den fehlschlagenden Befehl und die erwartete Antwort an. Füge nicht jeden Controller der Anwendung ein.
Baue einen Kontext-Stack
Ich trenne Kontext danach, wie lange er nützlich bleibt.
Repository-Kontext ändert sich langsam: Architekturgrenzen, Befehle, Namensregeln, Sicherheitsvorgaben und Zuständigkeiten. Halte ihn in versionierten Dateien nahe am Code.
Task-Kontext ist temporär: das aktuelle Ziel, der beobachtete Fehler, der erlaubte Scope, die Akzeptanzkriterien und die Stop-Bedingung. Er gehört in den Prompt oder das Issue.
Laufzeit-Belege entstehen während der Arbeit: Logs, Screenshots, Testausgaben, Datenbankzustand und der finale Diff. Aktualisiere sie, statt dich auf eine alte Chat-Nachricht zu verlassen.
Dieser Stack verhindert zwei häufige Fehler. Der Chat bleibt klein, und stabile Regeln überleben, auch wenn die Unterhaltung verschwindet.
Lege dauerhaftes Wissen im Repo ab
Ein nützliches Repository hat meist:
- einen Einstiegspunkt, der erklärt, wie man baut und testet;
- lokale Anweisungen für Packages mit abweichenden Regeln;
- Architekturentscheidungen für Vorgaben, die man leicht fälschlich „vereinfacht“;
- Beispiele nahe am Code, der ihre Form übernehmen soll;
- Tests, die wichtiges Verhalten festhalten.
Mach aus einer einzigen Anweisungsdatei kein Handbuch für das ganze Unternehmen. Agenten finden, genau wie Menschen, keine Regeln mehr, wenn die Datei zum Haufen wird.
Halte jede Regel nah an dem Bereich, den sie regelt. Lösche veraltete Anweisungen in derselben Änderung, die sie falsch macht.
Achte auf vergifteten Kontext
Falscher Kontext ist oft schlimmer als fehlender Kontext. Ein veralteter Befehl, ein überholtes API-Beispiel oder eine alte Architekturnotiz gibt dem Agenten falsche Sicherheit.
Wenn der Output unerklärlich falsch aussieht, prüfe die Eingaben, bevor du die Prompt-Formulierung änderst. Kontrolliere, welche Anweisungsdateien geladen wurden, ob das Beispiel noch kanonisch ist und ob der fehlschlagende Output vom aktuellen Branch stammt.
Beginne mit einem Context Brief
Vor einer Repository-Aufgabe schreibe ich Folgendes:
Goal:
Observed evidence:
Relevant files:
Rules and examples:
Allowed scope:
Verification:
Unknowns:
Wenn ich ein Feld nicht ausfüllen kann, untersuche ich entweder das Repository oder markiere die Unbekannte. Das ist sicherer, als das Modell stillschweigend eine Antwort wählen zu lassen.
Kontextqualität ist eine Engineering-Eigenschaft. Speichere dauerhafte Fakten, wähle die Belege für diese Aufgabe aus und halte den Nachweis aktuell.