Wie man mit AI arbeitet und durch Zinseszinseffekte wächst

• Ein praxisnaher Leitfaden, der fünf Prinzipien der Zusammenarbeit mit AI systematisch ordnet: Kontext bereitstellen, Vorlieben konfigurieren, Verifikation automatisieren, Delegation ausweiten und Feedback-Schleifen schließen
• Alle Arbeitsergebnisse (Code, Dokumente, Analysen, Entscheidungen) werden als Kontext für die nächste Session akkumuliert, und Korrekturen werden in die Konfiguration übernommen, um künftige Fehler in einer Zinseszins-Struktur zu verringern
• Zeigt konkrete Methoden, um mit CLAUDE.md, Skill-Dateien, Guides usw. das Verhalten des Modells und Workflows wie Code zu verwalten
• Enthält Delegationsstrategien zur Skalierung des Durchsatzes, etwa durch parallele Sessions, gegenseitige Verifikation zwischen Modellen und Remote-Steuerung
• Diese Prinzipien sind nicht nur für AI relevant, sondern ein allgemeines Framework, das sich ebenso auf die Zusammenarbeit in menschlichen Teams anwenden lässt

---

Kontext als Infrastruktur aufbauen

• Wenn man allen Code in ~/src und Wissensarbeit in ~/vault (projects/, notes/, kb/ usw.) organisiert, kann das Modell Kontext leichter mit grep oder glob durchsuchen
• Organisatorischer Kontext (Slack, Drive, Mail usw.) lässt sich über MCP(Model Context Protocol) mit dem Modell verbinden
  • Für jedes Projekt INDEX.md pflegen und bei jedem Eintrag URL, Zuständige und Inhaltsbeschreibung als Kommentar festhalten
  • Eine bloße URL-Liste zwingt das Modell dazu, jeden Link zu öffnen; Kommentare helfen, Kontextverschwendung zu vermeiden
• Da das Modell in jeder neuen Session bei null startet, sollte man projektbezogene CLAUDE.md-Dateien wie Onboarding-Dokumente für neue Mitarbeitende schreiben
  • Einschließlich Glossar für Abkürzungen, Projekt-Codenamen und Unterscheidung gleichnamiger Personen
  • Die Lesereihenfolge vorgeben: INDEX.md → TODOS.md → themenspezifische Notizen
• Zwei getrennte Memory-Layer betreiben
  • ~/vault: Speicherung von Fakteninformationen wie Projektstatus, Artefakten und Domainwissen
  • ~/.claude (CLAUDE.md, skills/, guides/): Speicherung von Konfigurationen wie Präferenzen, Workflows und persönlichen Vorlieben

Vorlieben als Konfiguration kodieren

• Nutzung von ~/.claude/CLAUDE.md

  • Dient als Verhaltensvertrag, den Claude zu Beginn jeder Session liest
  • Enthält Verhaltensregeln wie direkt formulieren, widersprechen wenn man nicht einverstanden ist, Unsicherheit offen benennen, bei Fehlschlägen die Grundursache untersuchen und erneut versuchen, kein Reformatting außerhalb des Aufgabenbereichs usw.
  • Man kann auch einen Teaching-Abschnitt definieren, der bei neuen Kernbegriffen aus einem System oder einer Domäne 1–2 Sätze Erklärung liefert

• Scope nach Verzeichnis trennen

  • Global (~/.claude/CLAUDE.md): Einstellungen, die überall gelten, etwa Verhalten, langfristige Ziele und Lernpräferenzen
  • Repo-Root: repo-spezifische Regeln wie Linting, Naming und PR-Konventionen
  • Projektverzeichnis: projektspezifischer Kontext wie Verzeichnisstruktur und Domainwissen
  • Startet Claude Code in einem Unterverzeichnis, lädt es beim Aufsteigen im Verzeichnisbaum jedes CLAUDE.md

• Strategie zum Aufteilen einer zu langen CLAUDE.md

  • Eine lange CLAUDE.md wird zur Kontext-Steuer, weil sie in jeder Session vollständig geladen wird
  • Statt @import in CLAUDE.md nur Pfade zu Guide-Dateien im Stil „bei Bedarf lesen“ angeben, um Lazy Loading zu realisieren
  • Beispiel: beim Schreiben ~/.claude/guides/writing.md, bei Evaluationsaufgaben ~/.claude/guides/evals.md

• Wiederkehrende Aufgaben ab mindestens einmal pro Woche in Skills umwandeln

  • Skills sind Markdown-Workflow-Dateien mit Namen, Triggern und Prozeduren
  • /polish: Artefakt-Diff prüfen, bei vorhandenen Metriken Eval ausführen, bei Browser-Rendering in Chrome prüfen, sonst Code ausführen und Output/Fehler kontrollieren → iterieren und PR-Entwurf erstellen
  • /write: Outline-Interview → Research-Subagent erzeugen → Entwurf schreiben → Feedback durch einen adversarialen Kritiker → iterieren
  • /daily: Kalender, Slack, PRs und Log des Vortags lesen und die heutigen Prioritäten formulieren
  • SKILL.md sollte sich auf Workflow und Routing konzentrieren; Wissen wie Templates oder Skripte wird in separate Dateien ausgelagert und nur bei Bedarf geladen

• So bootstrapt man Skills

  • Eine Aufgabe zunächst einmal interaktiv ausführen und das Modell dann bitten, daraus einen Skill zu machen
  • Den Skill für gleiche oder ähnliche Aufgaben ausführen und die Ausgabe innerhalb derselben Session korrigieren
  • Das Modell anhand der Korrekturen und des Feedbacks den Skill aktualisieren lassen
  • Man kann auch Beispiele für gewünschte Ausgaben bereitstellen, damit Muster wie Codestruktur, Dokumentstruktur und Ton extrahiert werden

• Skills über Transkripte verbessern

  • Dass die erste Version auf die Ursprungssession überangepasst (overfit) ist, ist normal
  • SKILL.md nicht direkt editieren, sondern in der Session korrigieren, damit sich Before-and-after-Paare im Transkript ansammeln
  • Wenn die Ausgabe zufriedenstellend ist, das Modell bitten, das Feedback in den Skill zu integrieren → nach einigen Runden konvergiert der Skill

• Nicht jede Aufgabe braucht diesen Kontext

  • Für Brainstorming, Exploration und Entwurfsarbeit den Simple Mode verwenden: CLAUDE_CODE_SIMPLE=1 claude
  • CLAUDE.md wird geladen, aber Agent-Harness (Hooks, Skills, Tool-Loops) ist deaktiviert → näher am Denken des Modells arbeiten

Verifikation für Autonomie

• Verifikation nach links verschieben (shift left)

  • Verifikation als Leiterstruktur aufbauen: unten billig und deterministisch, oben teurer und urteilsabhängig
  • Unterste Stufe: ein Post-Edit-Hook, der auf vom Modell geänderten Dateien ruff format und ruff check --fix ausführt → deterministisch und ohne Token-Kosten
  • Höhere Stufen: Tests, Evals, LLM-Review usw.

• Das System so aufsetzen, dass das Modell seine Arbeit selbst verifizieren kann

  • Wenn das System Metriken produziert, kann das Modell Evals selbst ausführen und darauf optimieren
  • Bei Browser-Rendering-Ausgaben in Claude in Chrome prüfen
  • Beim Bauen eines Docker-Images Fehler lesen, das Dockerfile anpassen und erneut bauen
  • Beim Erstellen eines Dashboards Tooltip-Rendering, Label-Überlappungen und Übereinstimmung von Zahlen und Narrativ in Chrome prüfen

• Bei langen Aufgaben soll ein Modell das andere überwachen

  • In langen Sessions häufen sich Fehler, und es kann zu Drift kommen
  • Lösung: Eine zweite Session mit frischem Kontext starten, die die ursprüngliche Spezifikation mit den letzten Turns der ersten Session vergleicht
  • Zwei tmux-Panels: eines für die primäre Entwicklung, eines für den Pair-Programmer
  • Anfangsanweisungen und Folge-Prompts in eine gemeinsame Datei schreiben, damit der Pair-Programmer regelmäßig prüfen kann
  • Execution Drift: Führt das Modell die Aufgabe korrekt aus? — taktische Checks wie ignorierte Fehler, falsch gemeldete Metriken oder Abweichungen von der Spezifikation → häufig prüfen
  • Direction Drift: Arbeitet das Modell an der richtigen Aufgabe? — strategische Probleme wie Fehlinterpretation der ursprünglichen Absicht und Bau des Falschen → gelegentlich prüfen

Durch Delegation skalieren

• Immer größere Arbeitseinheiten delegieren

  • Das Pair-Programming-Modell mit kurzen Aufgaben und schnellem Feedback eignet sich für schnelle Iteration, explorative Analyse und Prototyping
  • Bei leistungsfähigeren Modellen sollte man Absicht, Constraints und Erfolgskriterien vorab erklären und die End-to-End-Ausführung delegieren
  • Was sich nicht verifizieren lässt, lässt sich nicht delegieren; daher müssen Erfolgskriterien und Metrikdefinitionen zuerst stehen
  • Beispiel: „Isolierte Container pro Eval-Suite bauen und Smoke-Test ausführen → vollständigen Lauf starten → Metriken und Transkripte loggen → Genauigkeit per Subagent prüfen → über n Wiederholungen Konfidenzintervalle berechnen → Report erzeugen und Ergebnis an Slack senden“

• Parallele Sessions betreiben und Engpässe erkennen

  • Durch Delegation großer Aufgaben lassen sich 3–6 Sessions parallel ausführen
  • Der Engpass verschiebt sich von „Arbeit ausführen“ zu „klare Spezifikationen schreiben und Output schnell reviewen“ — die Zwischenschicht leert sich
  • Wenn parallele Sessions dasselbe Repo teilen, mit git worktrees für jede Session einen unabhängigen Checkout bereitstellen

• Gute Beobachtbarkeit von Sessions sicherstellen

  • Stop-Hook: Ton abspielen, wenn eine Session abgeschlossen ist (unter macOS z. B. Glass.aiff mit afplay)
  • tmux-Fenstertitel: Identifikation jedes Panels mit Status-Emoji (⏳ in Arbeit, 🟢 abgeschlossen) und einem kurzen, von Haiku erzeugten Label
  • Claude Code-Statusleiste: zeigt Kontextnutzung und aktuellen Modus an

• Auch unterwegs einchecken können

  • Mit der /remote-control-Funktion von Claude Code kann man unterwegs im Code-Tab der Claude-App den Ausführungsstatus prüfen und blockierten Sessions zusätzlichen Kontext oder neue Anweisungen geben
  • So verhindert man, dass Sessions stundenlang untätig bleiben, sollte es aber nur in dringenden Fällen nutzen

Feedback-Schleifen schließen

• Öffentlich arbeiten, um den Kontext reichhaltig zu halten

  • Wenn man in geteilten Dokumenten, Repos und Kanälen arbeitet, können alle Teammitglieder einschließlich des Modells den Kontext nutzen
  • Einfacher Test: „Kann ein neues Teammitglied allein mit dem geteilten Kontext die Arbeit der letzten Woche reproduzieren?“ — falls nicht, steckt wichtiger Kontext nur im Kopf
  • In CLAUDE.md anweisen, bei substanziell abgeschlossener Arbeit automatisch ein kurzes Update und Artefakt-Links in einen Worklog-Kanal zu posten

• Transkripte auswerten, um Konfigurationen zu aktualisieren

  • Lässt man das Modell vergangene Session-Transkripte lesen, kann es Lücken entdecken
  • Beim Scannen von etwa 2.500 vergangenen User-Turns enthielt ein erheblicher Anteil Formulierungen wie „can you also…“, „did you check…“, „still wrong“
  • Das deutet darauf hin, dass das Modell Aufgaben eigentlich proaktiv hätte erledigen sollen oder dass ein Verifikationsschritt fehlte bzw. nicht funktionierte
  • Korrekturen innerhalb der Session vornehmen, damit das Transkript als Eingabedaten für spätere Updates von CLAUDE.md oder Skills dient

• Regelmäßig refaktorieren und aufräumen

  • Mit wachsender Konfiguration können sich Regeln überlappen oder widersprechen
  • Wenn das Modell Regeln ignoriert, kann das an Widersprüchen mit anderen Regeln liegen; daher sollte jede Regel oder Präferenz genau an einer Stelle existieren (wichtige Anweisungen dürfen in der Haupt-CLAUDE.md wiederholt werden)
  • Verstreute verzeichnisbezogene settings.json-Dateien in ~/.claude zusammenführen und konsolidieren

Fazit

• Konkrete Einstellungen können sich mit dem Fortschritt der Modelle ändern, aber die Prinzipien guten Kontext bereitzustellen, Vorlieben zu kodieren, kostengünstig zu verifizieren, mehr zu delegieren und Feedback-Schleifen zu schließen bleiben gültig
• Letztlich ist dieser Prozess nichts anderes, als einen Kollaborateur jeweils mit einem Feedbackschritt zu trainieren, und er lässt sich genauso auf die Zusammenarbeit mit menschlichen Teams anwenden
• Die gleichen Prinzipien gelten nicht nur für persönliche Tools, sondern auch für das Design von Agent-Harnesses, das Festlegen von Teamnormen und den Aufbau organisatorischer Infrastruktur

[xguru]

Der Werdegang dieser Person ist interessant:
Von einem Psychologiestudium zum Lernen mit dem Coursera-Kurs in Data Science
Früh bei Lazada eingestiegen, dem damaligen Amazon Südostasiens, und bis zum VP aufgestiegen.
Lazada wurde von Alibaba übernommen.
Danach zu Amazon gewechselt und dort Principal Scientist für Empfehlungen/LLMs.
Derzeit Mitglied des technischen Stabs bei Anthropic