„Lies das ganze Repository” klingt nach der naheliegenden Lösung und ist fast immer die teuerste. Ein mittelgroßes Projekt füllt das Kontextfenster, bevor die eigentliche Frage gestellt ist – und die Antwortqualität sinkt, je voller es wird.
Was am Ende läuft
Ein Ablauf, mit dem du in einer halben Stunde weißt, wie ein fremdes Projekt aufgebaut ist, wo die Arbeit hingehört und was dich beißen wird – bei einem Bruchteil der Token, die das naive Vorgehen kostet.
Schritt 1 – Erst fragen, was es überhaupt ist
Bevor irgendetwas gelesen wird: Build-Datei, README und Ordnerstruktur. Das sind drei Dateien und beantwortet die Hälfte der Fragen – welche Sprache, welche Abhängigkeiten, wie wird getestet.
Schritt 2 – Plan Mode statt Volltext
Mit Shift+Tab in den Plan Mode wechseln und fragen:
Verschaffe mir einen Überblick, ohne etwas zu ändern:
1. Einstiegspunkte und wie eine Anfrage durchs System läuft
2. Build-, Test- und Lint-Befehle
3. Die drei Stellen, an denen Änderungen erfahrungsgemäß wehtun
4. Was dir unklar geblieben ist
Nenne zu jedem Punkt die Dateien, auf die du dich stützt.Claude liest gezielt, statt alles einzusaugen. Punkt 4 ist der wichtigste: Er gibt dem Modell einen erlaubten Weg, Unsicherheit zu benennen, statt sie zu überspielen.
Schritt 3 – Suchen auslagern
Fragen wie „Wo wird diese Funktion überall aufgerufen?” öffnen viele Dateien. Genau dafür sind Subagents da: Die Suche läuft in einem eigenen Kontext, zurück kommt nur das Ergebnis. Dein Hauptkontext bleibt für die eigentliche Arbeit frei.
Schritt 4 – Das Gelernte festschreiben
Was du gerade herausgefunden hast, gehört in die CLAUDE.md des Projekts: Testbefehl, Konventionen, Fallstricke. Beim nächsten Mal steht es da – und muss nicht noch einmal erarbeitet werden.
Kurz halten. Was in der CLAUDE.md steht, wird in jeder Sitzung mitgelesen und kostet jedes Mal Kontext. Zwanzig gute Zeilen schlagen zweihundert vollständige.
Woran es meistens scheitert
- Alles auf einmal lesen lassen. Das Kontextfenster ist voll, bevor die Frage kommt – und Antworten werden mit der Füllung schlechter.
- Kontext nicht verdichten. Wenn Antworten unvermittelt nachlassen, ist meist der Kontext voll, nicht das Modell schwach.
- Erkenntnisse nicht sichern. Wer dieselbe Codebasis dreimal erklärt bekommt, hat zweimal umsonst bezahlt.
