Die Agenten lesen Ihr Repository. Das deckt den größten Teil dessen ab, was sie benötigen – doch nicht die Entscheidungen, die sich im Kopf von Mitarbeitern, in Wikis oder in Gesprächen von vor zwei Jahren befinden.
Projektkontext Dort fügen Sie den Rest ein.
Was Coroid eigenständig ermittelt
Allein aus dem Repository können die Agenten Folgendes erkennen:
- die verwendeten Programmiersprachen, Frameworks und Bibliotheken
- wie das Projekt gebaut, getestet und ausgeführt wird
- bestehende Muster – wie Fehler behandelt, Module strukturiert und Dinge benannt werden
- welche Abhängigkeiten bestehen
Sie müssen nichts davon dokumentieren. Die Wiederholung ist verschwendete Arbeit und birgt das Risiko, dass die Angaben gegenüber dem Code veraltet werden – der ohnehin die autoritative Quelle darstellt.
Was die Agenten nicht ableiten können
Der Code zeigt was Sie getan haben, niemals warum:
- eine Bibliothek wurde statt einer offensichtlicheren Alternative gewählt – aus einem Grund, der nach wie vor gilt
- ein Muster, das wie eine Dopplung aussieht, aber eine bewusste Trennung darstellt
- ein Modul, das niemand ohne Rücksprache mit einem bestimmten Team bearbeiten sollte
- Vereinbarungen, auf die Sie sich geeinigt haben, die jedoch noch nirgends umgesetzt wurden
- Einschränkungen außerhalb des Quellcodes – Compliance-Vorgaben, Verträge, ein laufender Migrationsprozess
Das gehört in den Projektkontext. Der Test ist einfach: Könnte jemand, der nur das Repository liest, das herausfinden? Wenn ja, lassen Sie es weg. Wenn nein, notieren Sie es.
Kontext hinzufügen
Hängen Sie Dokumente, Richtlinien und Referenzen unter den Kontext Abschnitt Ihres Projekts. Architekturhinweise, Entscheidungsprotokolle, Stilrichtlinien und API-Verträge eignen sich gleichermaßen.
Guter Kontext ist kurz und präzise. Ein 40-seitiger Onboarding-Leitfaden für Menschen besteht größtenteils aus Erzählungen; die drei Absätze darin, die echte Einschränkungen beschreiben, sind entscheidend. Extrahieren Sie diese.
Aufgabenspezifischer Kontext
Der dem Projekt zugeordnete Kontext gilt für alles. Für Informationen, die nur für einen bestimmten Arbeitsbereich relevant sind – ein Ticket, ein Entwurfsdokument, ein Kundenbericht –, ordnen Sie sie der Aufgabe zu.
Bewahren Sie den Projektkontext für dauerhaft gültige Informationen auf. Eine aufgabenspezifische Notiz im Projektkontext wird zu Störung bei jeder zukünftigen Aufgabe.
Aktualität gewährleisten
Ein veralteter Kontext ist schlimmer als gar kein Kontext, weil die Agenten ihn als autoritativ betrachten. Wenn sich eine Vereinbarung ändert, aktualisieren Sie den Kontext in derselben Änderung wie den Code.
Falls Sie wiederholt dieselbe Korrektur in Kommentaren zur Nachbesserung vornehmen müssen, ist das ein Zeichen dafür, dass etwas im Kontext fehlt – oder dass etwas darin falsch ist.