@Stefan Klink Ich glaube, ich würde das etwas anders aufteilen. - Ein „Second Brain“ für dein Fach- und Domänenwissen (wie du Dinge tust, Entscheidungen, Learnings oder wiederkehrende Fragen von Kunden) – das profitiert genau von dem Ansatz aus dem Video. - Kundenprojekte, Angebote und Rechnungen gehören für mich in ein eigenes System (CRM, Buchhaltungstool oder ein separates, klar abgegrenztes Obsidian-Vault pro Kunde) – nicht in ein gemeinsames Wiki. - Coding-Projekte: Der Code selbst bleibt in Git, wo er hingehört. Das Wissen über den Code (warum Pattern X statt Y gewählt wurde, Benchmark-Ergebnisse, Architekturentscheidungen oder Lessons Learned) gehört dagegen durchaus ins Second Brain. Kurz gesagt würde ich das Second-Brain-Prinzip nicht auf „Wissen, das sich klärt und stabilisiert“ beschränken, sondern eher so definieren: Ein Second Brain ist für Wissen, dessen Zweck Verstehen statt Operieren ist – nicht für Daten, die laufend operativ genutzt und verändert werden. Denn manches ändert sich ständig (z. B. welches Modell sich für welche Aufgabe eignet oder aktuelle Cloud-Preise) und gehört trotzdem ins Second Brain, weil es Wissensmanagement ist und keine operativen Geschäftsdaten. Gerade deshalb finde ich den im Video gezeigten Ansatz spannend: Ein LLM kann Verbindungen zwischen Notizen herstellen, Widersprüche oder veraltete Informationen erkennen und Wissen leichter auffindbar machen. Diesen Mehrwert sehe ich vor allem bei langfristigem Wissen – deutlich weniger bei operativen Daten oder dem eigentlichen Quellcode, die bereits ihre eigenen Systeme der Wahrheit haben.