Drei Ebenen — warum ich meine AI-Tools nach Kontext trenne, nicht nach Modell

Als ich angefangen habe, AI-Assistenten produktiv einzusetzen, hatte ich eine simple Strategie: ein Tool, bestes Modell, alles reinwerfen. Strategie, Coding, Recherche, Content — alles in einer Session. Wenn die Antwort mal daneben lag, lag es bestimmt am Modell. Also das nächstteuere geholt. Das war naiv.

Die Qualität der Antworten blieb unberechenbar. Mal präzise, mal total daneben. Ich habe eine Weile gebraucht, bis ich gemerkt habe, dass das Problem nicht an den Modellen lag. Das Problem war der Kontext.

Der Kontext macht den Unterschied, nicht das Modell

Ein AI-Assistent ist nur so gut wie das, was er sehen darf. Strategische Fragen brauchen strategischen Kontext — laufende Projekte, Entscheidungen, offene Punkte. Debugging-Fragen brauchen Code-Kontext — echte Dateien, echte Logs, echte Fehlermeldungen. Implementations-Aufgaben brauchen möglichst wenig Ballast — eine klare Spec, fokussiert.

Drei grundlegend verschiedene Kontext-Domänen. Ein Tool, das versucht, in allen drei gleichzeitig zu arbeiten, bekommt einen Matsch aus Projektnotizen, Code-Fragmenten und Spec-Resten. Daraus wird dann freundlich etwas zurechthalluziniert, was plausibel klingt und manchmal sogar stimmt.

Aus der Erkenntnis ist ein Modell geworden, das bei mir seit Monaten stabil läuft. Ich nenne es für mich die drei Ebenen.

Ebene 1 — Strategie

Die Frage, die hier gestellt wird: „Was ist der richtige nächste Schritt?“

Der Kontext, der dafür gebraucht wird: meine Projekte, meine Entscheidungen, mein Wissen, meine Ziele, mein Schreibstil.

Das Werkzeug: Obsidian-Vault mit integriertem Claude-Plugin. Der Assistent sieht alles, was ich je dokumentiert habe — Projekte, Bereiche, Ressourcen, Tagesnotizen, Kontext-Profile, Knowledge Base. Perfekt für Fragen wie „wo war ich letzte Woche stehengeblieben“, „passt diese Idee zu meinen laufenden Projekten“, „schreib mir einen Entwurf in meinem Ton“.

Nicht geeignet für: Coding mit mehr als zwanzig Zeilen, Debugging gegen echten Code, Architekturfragen, bei denen die Codebase die Wahrheit ist. Der Vault weiß, was ich will. Er weiß nicht, was im Code tatsächlich steht.

Ebene 2 — Architektur

Die Frage: „Wie baue ich das technisch?“

Der Kontext: die Codebase, die Git-History, die Log-Dateien, die Datenbankstruktur, der Laufzeitzustand.

Das Werkzeug: VS Code mit Claude Code als Pair-Programmer. Hier sieht der Assistent die echten Dateien, kann Tests laufen lassen, Logs lesen, direkt am Debugger mitlesen. Wenn die Frage lautet „warum schlägt dieser Workflow fehl“, dann braucht die Antwort den echten Zustand, nicht meine Erzählung davon. Remote SSH macht das Gleiche auf entfernten Servern — wo der Code läuft, dort editiere ich ihn.

Nicht geeignet für: „Was war nochmal mein Ziel?“ Das kann VS Code nicht beantworten, weil der Vault nicht dabei ist.

Ebene 3 — Implementation

Die Frage: „Schreib mir das jetzt runter.“

Der Kontext: möglichst wenig. Nur eine klare Spec.

Das Werkzeug: Kilo Code, eine VS Code Extension, die auf hohen Token-Durchsatz optimiert ist. Wenn der Plan steht und nur noch getippt werden muss — zehn ähnliche Komponenten nach Muster, Boilerplate, Test-Varianten — dann generiert Kilo schnell, ich prüfe, korrigiere, weiter. Iterations-freundlich, ohne strategischen Overhead.

Der Haken: Kilo fragt nicht „warum“, es macht einfach. Bei unklarer Spec produziert es selbstbewussten Unsinn. Erst mit Ebene 1 und 2 klären, was gebaut wird. Dann Kilo drauflassen.

Das sieht in der Praxis so aus

Ein konkretes Beispiel, wie ein typischer Workflow durch die Ebenen läuft — Bau einer neuen Automatisierung mit n8n:

• Obsidian: „Brauche ich das überhaupt? Welche bestehenden Projekte würde das entlasten oder erweitern? Wie heißt der nächste konkrete Schritt?“ Ergebnis: eine kurze Entscheidung, ein Eintrag in der Projektdatei, ein next_action.
• VS Code: „Zeig mir die bestehende Datenbankstruktur. Wie läuft ein ähnlicher Workflow bereits? Was muss ich anpassen, damit der neue ohne Konflikte einfügt?“ Ergebnis: ein Architekturvorschlag, ein Plan, der zur echten Codebase passt.
• Kilo Code: „Hier ist die Spec. Bau mir die acht ähnlichen Nodes mit den Varianten A, B, C.“ Ergebnis: Code, den ich noch gegenchecke, aber der schnell entsteht.

Drei Tools, drei Kontexte, ein Ergebnis. Wenn ich versuche, das alles in einem einzigen Tool zu machen, halbiert sich die Qualität bei jedem Schritt.

Die vierte Spur: asynchrone Delegation

Das Drei-Ebenen-Modell hat bei mir eine Ergänzung bekommen, die nicht in die Hierarchie passt, sondern parallel dazu läuft: ein kleines eigenes Agent-Team für asynchrone Arbeit. Aufgaben, die mehrere Stunden dauern — tiefe Recherche, Content nach Research-Pipeline, spezialisierte Rollen — will ich nicht selbst machen und nicht synchron in meiner Session abarbeiten.

Also lege ich ein Briefing in eine Inbox, der Orchestrator delegiert an das passende Team-Mitglied, das Ergebnis kommt zurück, ich mache in der Zwischenzeit etwas anderes. Die Team-Mitglieder haben klare Rollen, dokumentierte Prozesse und schreiben ausschließlich in ihrem eigenen Bereich. Den ganzen Vault dürfen sie lesen, außerhalb ihres Bereichs aber nichts anfassen. Namensschema aus der Bobiverse-Reihe, weil warum nicht.

Wichtig an der Stelle: Das ist kein Ersatz für die drei Ebenen. Es ist eine andere Achse — synchron vs. asynchron, nicht Strategie vs. Code. Für Kleinkram ist der Delegations-Overhead größer als der Nutzen. Ein Zweizeiler delegiert man nicht, man schreibt ihn.

Was ich nicht mehr mache

Ein paar Anti-Pattern, die ich mir über die Zeit abgewöhnt habe:

• Coden im Vault. Die AI kann dort zwar Code schreiben, sieht aber weder Laufzeit noch Tests. Über zwanzig Zeilen wird das eine Rate-Veranstaltung, die sich überzeugt anhört.
• Strategie im Code-Editor. Ohne Vault-Kontext erfindet die AI Projekte, die es nicht gibt, oder vergisst längst entschiedene Prioritäten. „Was mache ich heute“ ist keine Frage an VS Code.
• Alles delegieren. Wenn ich eine Aufgabe in drei Minuten selbst lösen kann, spare ich keine Zeit, indem ich sie ans Team delegiere. Delegation lohnt sich nur bei Arbeit, die Arbeit ist.
• Alles gleichzeitig offen haben. Drei VS-Code-Fenster, Obsidian, Team-Session — alles parallel klingt effizient, ist aber nur Kontext-Chaos. Seriell die richtige Ebene wählen.

Der eigentliche Take-away

Die Qualität von AI-Assistenz hängt weniger vom Modell ab, als ich lange dachte. Sie hängt vom Kontext ab, den das Tool mitbringen darf — und vielleicht noch wichtiger: von dem, was es nicht mitbringen muss.

Das hat eine konkrete Konsequenz für die Tool-Auswahl. Ich frage mich nicht mehr „welches Modell ist das beste für diese Aufgabe“. Ich frage mich „welchen Kontext braucht das eigentlich“. Die Antwort auf die zweite Frage führt automatisch zum richtigen Werkzeug. Strategischer Kontext → Vault-Tool. Code-Kontext → Code-Tool. Nur Spec → Fokus-Tool. Mehrere Stunden Arbeit, die nicht in meiner Session passiert müssen → Delegations-Tool.

Kontext-Verschmutzung ist der eigentliche Qualitätskiller. Tool-Auswahl ist im Kern Kontext-Auswahl.

Sichtbares Nebenprodukt: weniger Frustration mit AI-Antworten, weniger Drang, ständig das Modell zu wechseln, weniger Hyperaktivität beim Ausprobieren neuer Tools. Die drei Ebenen bleiben stabil. Die Werkzeuge dahinter dürfen sich über die Zeit ändern.