Mit Claude Code über zwei Monate hinweg hat sich aus einer Konfigurationsdatei ein Betriebssystem entwickelt.

Der schmerzhafteste Fehler: Dateien im Verzeichnis rules/ werden bei jedem Gespräch vollständig geladen. Ich habe dort 17 KB Regeln reingeschoben, was den Kontextfenster direkt sprengte — 125.996 / 125.999 Tokens, Claude kam nicht mehr zum Schreiben. Erst als ich es auf 6.6 KB reduzierte, funktionierte es wieder normal.
Diese Erfahrung hat mir ein Designprinzip gelehrt: Jeder Byte hat Kosten, bedarfsorientiertes Laden ist die richtige Lösung.
Derzeit ist meine Struktur dreistufig:
(Immer geladen, <200 Zeilen, nur Zeiger)
→ rules/ (automatisches Laden, Verhaltensregeln, Debugging-Prozesse, Fangregeln)
→ docs/ (bedarfsgesteuertes Laden, schwere Dokumente, nur bei Bedarf gelesen)
Darüber laufen vier Mechanismen:
Hot Data Layer —
Speichert den Fortschritt des Tages, schreibt automatisch vor dem Schließen des Fensters, wartet nicht auf dein "Speichern". Beim nächsten Gespräch kann Claude an der Stelle weiter machen.
Aufgabenrouting — Sonnet verarbeitet den Alltag, bei Geld/Strategie-Updates automatisch zu Opus, bei Bedarf Cross-Validation durch Outsourcing an Codex oder Gemini. Vier Schichten Scheduling, jede mit klaren Trigger-Bedingungen.
Erfahrungsspeicherung — Bei Bugs zuerst die Wissensdatenbank prüfen, ohne Prüfung ist Debugging-Verstoß. Korrigierte Fehler werden sofort eingetragen.
Abschlussprüfung — Bevor man behauptet "es ist fertig", müssen Tests laufen, Ausgaben gelesen und bestätigt werden. "Es sollte kein Problem sein" ist verboten.
Nach zwei Monaten ist mein größtes Gefühl: Es ist keine einmal konfigurierte Datei, sondern ein lebendiges System. Wenn du es korrigierst, merkt es sich; wenn du Fehler machst, sammelt es Erfahrung; wenn du das Fenster schließt, speichert es automatisch. Je mehr du es benutzt, desto intuitiver wird es, weil es mit dir zusammen wächst.
Wie sieht dein aus?