Second Brain fuer Claude Code: Warum simple Notizdateien KI-Arbeit verbessern
KI vergisst, sieht nicht, was in eigenen Notizen steht, und antwortet trotzdem voller Selbstsicherheit. Ein Second Brain aus einfachen Dateien mit je einem Eintrag pro Projekt und Kunde schafft Abhilfe, das alle Tools vor der Arbeit einlesen koennen.
Veröffentlicht am 23. Oktober • Zuerst erschienen auf codemeetai.substack.com
KI vergisst, kann nicht sehen, was in deinen Notizen und Anrufen steckt, und antwortet trotzdem mit voller Überzeugung.
Die Lösung ist ein Second Brain: schlichte Dateien, ein Datensatz pro Projekt und einer pro Kunde, den jedes Werkzeug und jede Person liest, bevor die Arbeit beginnt. Der kostenlose Second Brain Starter ist der richtige Einstieg.
Ich schreibe Code Meet AI, den Newsletter, in dem ich dokumentiere, wie ich KI tatsächlich einsetze, um echte Produkte zu bauen, mit Belegen. Neue Anleitungen erscheinen dort zuerst.
Ich benutze jeden Tag einen Second Brain: schlichte Dateien, die Claude Code und meine anderen KI-Werkzeuge lesen, bevor sie mit der Arbeit beginnen. Am 22. Oktober 2026 gezählt, umfasst er 645 Speicherdateien, 119 Skills, 41 Befehle und 640 Sitzungsberichte. Deshalb habe ich einen, und deshalb denke ich, dass du auch einen haben solltest: sechs Stellen, an denen KI bei Projekten schiefgeht, und die Datei, die jeweils Abhilfe schafft.
KI begann als Prompting. Man tippte eine Frage ein, sie tippte zurück, und die ganze Kunst lag darin, wie man fragte.
Dann wurde daraus Context Engineering. Gleiches Modell, aber jetzt entscheidest du, was es liest, bevor es antwortet: deine Dateien, deine Regeln, deine Beispiele.
Dann kamen die Werkzeuge. Mit MCP hörte das Modell auf, nur zu reden. Es konnte dein Postfach öffnen, deinen Kalender lesen, einen Befehl ausführen und auf das reagieren, was zurückkam.
Das ist ein guter Zustand. KI ist besser als je zuvor, und jede Woche tut ein neues Werkzeug etwas, das letztes Jahr unmöglich aussah.
Warum läuft es also trotzdem schief, wenn du mehr als ein Projekt hast?
Eine Sache kam mit dem Upgrade nicht mit: ein Ort, an dem das Projekt lebt. Das Modell kann alles lesen, worauf du es hinweist, aber es weiß nicht, worauf es zeigen soll. Bei drei oder vier Projekten vergisst es, was du ihm letzte Woche gesagt hast, es findet die Datei nicht, die die Antwort enthält, und es füllt die Lücke mit etwas, das richtig klingt.
Wenn ein Team vergisst, warum ein Projekt so funktioniert, wie es funktioniert, nennen wir es ein Kommunikationsproblem. Bei KI passiert dasselbe auf drei Arten.
Es vergisst. Jeder neue Chat beginnt bei null, also ist die Arbeit der letzten Woche weg.
Es hat keinen Zugriff. Die Antwort liegt in einer Notiz, einem Anruf oder in jemandes Kopf, und das Modell sieht sie nie.
Es ist trotzdem überzeugt. Das ist die Variante, die wehtut.
Eine Person, die es nicht weiß, sagt „Ich weiß es nicht“. Die KI sagt das Falsche in derselben ruhigen Stimme, die sie nutzt, wenn sie recht hat. Du liest eine saubere Antwort, hältst sie für hundertprozentig wahr und hast keine Möglichkeit zu prüfen. Schlimmer noch: Der falsche Teil landet im Chat und wird zum Kontext, sodass die nächste Antwort darauf aufbaut. Eine dumme Aussage, einmal getätigt, wird wiederholt, als wäre sie geklärt.
Sag, es ist Montag. Du öffnest einen Chat, um Hilfe bei deiner App zu bekommen, und verbringst zwanzig Minuten damit zu erklären, was das Produkt ist, für wen es gedacht ist, was du letzte Woche gebaut hast und was unangetastet bleiben muss. Die Antworten sind gut.
Am Mittwoch wechselst du zu einem anderen Werkzeug für eine andere Aufgabe, und es weiß nichts. Du tippst alles wieder aus dem Gedächtnis ein, und das Detail, das am wichtigsten war, dasjenige, das den Bug verhindert hätte, ist genau das, das du vergisst.
Die einfache Lösung ist ein Projektdatensatz. Eine einzige Datei im Stammverzeichnis des Projekts, die sagt, was es ist, für wen es ist, den aktuellen Stand und die nächste Aktion. Jedes Werkzeug liest sie, bevor es irgendetwas tut. Du schreibst die Erklärung einmal, und jeder Chat beginnt dort, wo der letzte aufhörte.
Angenommen, du entscheidest dich für A statt B. A ist der Zahlungsanbieter mit den Gebühren, mit denen du leben kannst, und B ist der, den dein Partner mochte. Ihr einigen euch in einem Anruf, legt auf, und niemand schreibt es auf.
Drei Wochen später schlägt die KI höflich und mit guten Gründen B vor. Dein Partner sagt „siehste?“, und du verbringst eine Stunde mit einer Entscheidung, die du bereits getroffen hattest.
Führe also eine Entscheidungsdatei. Eine Zeile pro Entscheidung: was du gewählt hast, was du abgelehnt hast, warum, wer entschieden hat und das Datum. Schreibe sie direkt nach dem Anruf, in die Datei, die die nächste Sitzung liest.
Der Grund ist der Teil, den die Leute zuerst weglassen, und er ist der Teil, der verhindert, dass die Diskussion zurückkommt.
Nimm die andere Seite. Du hast die Entscheidung tatsächlich notiert, in einer Notiz-App, in einem Dokument, in einem Chat vom letzten Monat. Die KI hat sie nie gesehen, also behandelt sie die Frage als offen und plädiert wieder für B.
Aufschreiben ist die halbe Miete. Die andere Hälfte ist, dem Modell zu sagen, dass die Sache entschieden ist. Führe eine kurze Liste abgeschlossener Entscheidungen im Projektdatensatz, jede mit ihrem Grund, an der Stelle, die zuerst gelesen wird. Eine Entscheidung mit beigefügtem Grund lässt sich viel schwerer versehentlich wieder öffnen.
Diese Variante kostet Geld. Nimm ein Kundekonto. Der Account Lead weiß, dass dem Kunden im letzten Frühjahr eine schnellere Bearbeitungszeit zugesagt wurde. Er weiß, dass der Kunde ein Format abgelehnt hat und dass Freigaben freitags über eine bestimmte Person laufen. Nichts davon steht im CRM, das Auftragswerte, Daten und Aktivitäten speichert, aber kein Feld für das Versprechen oder den Grund dahinter hat.
Dann geht der Account Lead in Urlaub oder kündigt. Die nächste Person trifft den Kunden ohne die Historie, und die KI hilft ihr nicht mehr als jedem anderen, weil sie nicht lesen kann, was nie geschrieben wurde.
Die Lösung ist ein Kundendatensatz pro Konto. Er enthält das Briefing, die datierten Entscheidungen mit Gründen, was der Kunde abgelehnt hat, die gemachten Versprechen und die nächste Aktion. Wer auch immer das Konto betreut, Person oder KI, liest ihn zuerst. Der Datensatz überlebt die Person.
Claude, Cursor, Codex und Gemini wollen jeweils ihre eigene Regeldatei. Du änderst am Dienstag eine Regel in einer davon. Einen Monat später widersprechen sich zwei von vier, und die KI folgt der alten, ohne es dir zu sagen.
Halte eine Regeldatei als Quelle. Gib jedem Werkzeug eine Einzeiler-Datei, die darauf verweist, und verlinke einen gemeinsamen Skills-Ordner in den jeweiligen Pfad jedes Werkzeugs. Die Kopien existieren nicht mehr, also können sie nicht auseinanderdriften.
Letzten Monat hast du das Projekt von Firebase zu Supabase migriert. Der Datensatz nennt noch Firebase. Die KI liest ihn, schreibt für die alte Datenbank, mit voller Überzeugung, und das Ergebnis bricht auf eine Weise, die wie ein Bug im eigenen Werk aussieht.
Eine falsche Datei ist schlimmer als keine Datei, weil niemand daran zweifelt. Setze ein zuletzt-geprüft-Datum an jeden Abschnitt und prüfe den Datensatz, wann immer sich das Projekt ändert: du tauschst ein Werkzeug, ein Kunde geht, eine Entscheidung wird zurückgenommen. Eine Regel, die ein Skript testen kann, wird zu einem Hook, der an einem festen Punkt läuft, ob das Modell zustimmt oder nicht. Eine Regel, die Urteil braucht, bleibt im Datensatz, als Bitte.
Ein Second Brain ist eine Sammlung schlichter Dateien, ein Datensatz pro Projekt und einer pro Kunde, den jedes KI-Werkzeug und jede Person liest, bevor die Arbeit beginnt, und der nach jeder Entscheidung zurückgeschrieben wird. Es ist ein Ordner mit einer angehängten Disziplin.
Das Layout folgt ICM, der Interpretable Context Methodology: eine kleine Routing-Datei verweist die KI auf die eine Datei, die sie braucht, sodass sie nicht alles laden muss.
Das ist meiner, als Graph dargestellt. Jeder Punkt ist eine Notiz, die Linien sind die Verbindungen zwischen ihnen. Wenn die KI eine Sitzung startet, kann sie hierdurch gehen, statt bei null anzufangen.
Zähle die Wiederholungen. Notiere an fünf Arbeitstagen jedes Mal, wenn du einem KI-Werkzeug dasselbe erklärst, und welches Werkzeug es war. Die Zahl zeigt dir, welchen Datensatz du zuerst anlegen solltest.
Schreibe die Entscheidungszeile. Füge nach jedem Anruf oder Chat, in dem etwas entschieden wird, eine datierte Zeile zur Projektdatei hinzu: die Entscheidung, der Grund, der Verantwortliche.
Mache den Urlaubstest für ein Konto. Wähle einen Kunden. Frage, ob die nächste Person eine Datei öffnen und die Versprechen, die Ablehnungen und die nächste Aktion finden könnte. Wenn nicht, ist diese Datei dein erster Kundendatensatz.
Einen schlichten Markdown-Ausgangspunkt für all das findest du im kostenlosen Second Brain Starter. Wie du die Ordner sortierst, sobald du einige Datensätze hast, erfährst du in „How to organise your files for AI“, Episode 11 von Using AI, properly.
Dieser Beitrag stammt aus Code Meet AI, dem Newsletter, in dem ich die Setups aufschreibe, die ich tatsächlich in meinen eigenen Projekten einsetze.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 23 • Originally published at codemeetai.substack.com
AI forgets, cannot see what lives in your notes and calls, and answers with full confidence anyway.
The fix is a Second Brain: plain files, one record per project and one per client, that every tool and person reads before work starts. The free Second Brain Starter is where to begin.
I write Code Meet AI, the newsletter where I document how I actually use AI to ship real products, receipts included. New guides land there first.
I use a Second Brain every day: plain files that Claude Code and my other AI tools read before they start work. Counted on 22 October 2026, it holds 645 memory files, 119 skills, 41 commands and 640 session reports. This is why I have one, and why I think you should too: six places AI goes wrong across projects, and the file that fixes each.
AI started as prompting. You typed a question, it typed back, and the whole skill was in how you asked.
Then it became context engineering. Same model, but now you decide what it reads before it answers: your files, your rules, your examples.
Then came tools. With MCP the model stopped only talking. It could open your inbox, read your calendar, run a command, and react to what came back.
That is a good place to be. AI is better than it has ever been, and every week a new tool does something that looked impossible last year.
So why does it still go wrong when you have more than one project?
One thing did not come with the upgrade: a place where the project lives. The model can read whatever you point it at, but it does not know what to point at. With three or four projects it forgets what you told it last week, it cannot find the file that holds the answer, and it fills the gap with something that sounds right.
When a team forgets why a project works the way it does, we call it a communication problem. With AI the same thing happens in three ways.
It forgets. Every new chat starts from zero, so last week's work is gone.
It has no access. The answer sits in a note, a call or someone's head, and the model never sees it.
It is confident anyway. This is the one that hurts.
A person who does not know says "I do not know". The AI says the wrong thing in the same calm voice it uses when it is right. You read a clean answer, you think it is 100% true, and you have no way to check. Worse, the wrong part goes into the chat and becomes context, so the next answer builds on it. One dumb thing, said once, gets repeated as if it was settled.
Say it is Monday. You open a chat to get help with your app, and you spend twenty minutes saying what the product is, who it is for, what you built last week and what must be left alone. The answers are good.
On Wednesday you switch to another tool for another job, and it knows nothing. You type the whole thing again from memory, and the detail that mattered most, the one that would have stopped the bug, is the one you forget.
The easy fix is one project record. A single file at the root of the project that says what it is, who it is for, the current state and the next action. Every tool reads it before it does anything. You write the explanation once, and each chat starts where the last one stopped.
Suppose you decide to use A instead of B. A is the payment provider with the fees you can live with, and B is the one your partner liked. You agree on a call, you hang up, and nobody writes it down.
Three weeks later the AI suggests B, politely, with good reasons. Your partner says "see?", and you spend an hour on a decision you already made.
So keep a decision file. One line per decision: what you chose, what you turned down, why, who decided and the date. Write it right after the call, in the file the next session reads.
The reason is the part people drop first, and it is the part that stops the argument from coming back.
Take the other side. You did write the decision down, in a notes app, in a doc, in a chat from last month. The AI never saw it, so it treats the question as open and argues for B again.
Writing it down is half the job. The other half is telling the model it is settled. Keep a short list of closed decisions inside the project record, each with its reason, in the part that is read first. A decision with a reason attached is much harder to reopen by accident.
This version costs money. Take one client account. The account lead knows the client was promised a faster turnaround last spring. They know the client said no to one format, and that approvals go through one person on Fridays. None of it is in the CRM, which keeps deal values, dates and activity but has no field for the promise or the reason behind it.
Then the account lead goes on holiday, or leaves. The next person meets the client without the history, and the AI helps them no more than it helps anyone else, because it cannot read what was never written.
The fix is one client record per account. It holds the brief, the dated decisions with reasons, what the client said no to, the promises made and the next action. Whoever covers the account, person or AI, reads it first. The record outlives the person.
Claude, Cursor, Codex and Gemini each want their own rules file. You change a rule in one of them on Tuesday. A month later two of the four disagree, and the AI follows the old one without telling you.
Keep one rules file as the source. Give each tool a one-line file that points to it, and link one shared skills folder into each tool's own path. The copies stop existing, so they cannot drift.
Last month you moved the project from Firebase to Supabase. The record still says Firebase. The AI reads it, writes for the old database with full confidence, and the result breaks in a way that looks like a bug in your own work.
A wrong file is worse than no file, because nobody doubts it. Put a last-checked date on each section, and check the record whenever the project changes: you swap a tool, a client leaves, a decision is reversed. A rule that a script can test becomes a hook, which runs at a fixed point whether the model agrees or not. A rule that needs judgement stays in the record, as a request.
A Second Brain is a set of plain files, one record per project and one per client, that every AI tool and every person reads before work starts, and that gets written back after each decision. It is a folder with a discipline attached.
The layout follows ICM, the Interpretable Context Methodology: a small routing file points the AI to the one file it needs, so it does not have to load everything.
This is mine, drawn as a graph. Every dot is a note, and the lines are the links between them. When the AI starts a session, this is what it can walk through instead of starting from zero.
Count the repeats. For five working days, note each time you explain the same thing to an AI tool, and which tool it was. The count tells you which record to build first.
Write the decision line. After each call or chat where something gets decided, add one dated line to the project file: the decision, the reason, the owner.
Run the leave test on one account. Pick one client. Ask whether the next person could open one file and find the promises, the no's and the next action. If not, that file is your first client record.
A plain Markdown starting point for all of it is in the free Second Brain Starter. For how to sort the folders once you have a few records, see how to organise your files for AI, Episode 11 of Using AI, properly.
This one came from Code Meet AI, the newsletter where I write up the setups I actually run on my own projects.