Transcription
Hello everyone, this is my Second Brain. Almost 2000 notes, over 4000 files, and I find relevant information within seconds. Many of you asked in the last video, how do you need something like this? That's exactly what I'm going to show you today, the complete path step-by-step with all the references and all the mistakes I made. But first things first, this visual appearance is only for later, and that's intentional, because the beautiful galaxy or the other structured views of the entire existing system, that was actually the easiest part, and at the same time, the part where I lost hours. And why, and what mistake I made, you will see then. And the advantage for you, of course, is that you simply don't have to make this mistake and can save yourself hours of potential despair. But first, we'll build what really counts, namely a system you can trust, and let's start where each of us stands. You collect notes in Obsidian, in Notion, wherever, and collecting, that's totally easy. Every article, every idea, every meeting, just put it in. And this here is my Vault. That's what the folder with all the notes is called in Obsidian. And this is what it looks like after a few months. It looks quite cool and impressive, but it's not, because it's just a mess. And I'll show you now what this image really means. Firstly, I can't find what I've collected again. The standard search works with words, not with meaning. This means that if I no longer know which terms I used back then, the correct note becomes virtually invisible. Secondly, and this is much worse, I can't trust what I find at all. And I'll show this with an example from my Vault. In one strategy document, there's a goal for my videos. But in another note, there are the actual evaluations, and they say something completely different. Both lay peacefully next to each other for months, and I didn't notice. And now the crucial point. In the standard version, I can't even check this. Obsidian gives me links and a search, but it doesn't tell me where my notes contradict each other, what is duplicated, and what might be outdated. I would have to keep all of that in my head. And with 2000 notes, that's simply impossible. But there are solutions for this now, and I'll explain exactly those in this video. How many such conflicts are really in my Vault in the end, I'll show you later with the actual numbers. And collecting knowledge is easy. Finding knowledge again and being able to trust it, that's the real problem. That's why at the beginning of this project, there was no technical decision, but a question, namely this one. How does collected knowledge become a system I can trust, instead of a growing trash heap? And this question has two halves. Firstly, findability. I want to be able to find any information again, even if I only vaguely remember what it was about. And secondly, trust. Duplicates, contradictions, and outdated versions should be noticeable and not just lie around silently. And now look at this question. There's nothing about a graph, nothing about a nice view. It has nothing to do with the visual appearance at first. And if you take away only one thing from this video, then it's this: first build the system that answers this question. The visual appearance is just a window, and a window, you can build that at the end. And if the question is clear, comes the next step: write down what the system needs to be able to do to answer it. This here is the complete overview, which I'll go through step-by-step. I'll explain the approach, I'll explain the function behind it, so that you understand the whole system. And if you watch this video completely and understand all the information I'm sharing, you can then completely rebuild this system. I also have a goodie for everyone who sticks around later in the video. It will be very technical in parts, and the video will be very long, but with it, you'll have everything you need. So, first of all, what it actually needs to be able to do. At this point, most people, and I used to, make the exact same mistake. They jump directly to the tool. That is, which tool, which plugin, which app. We did it the other way around. And when I say "we," I mean Claude and me. Before even a single line of code was created, we wrote down what the system needs to be able to do to answer the initial question, what it needs so that I can find every piece of information again, and so that I can trust the inventory. No features, no tools, but capabilities. For me, there are exactly four, and remember them well, because each of these four capabilities will find its home in the architecture later. Firstly, find relevant information in seconds, even if I no longer know the exact word. I want to be able to ask, what was our subtitle style again, and get the right note without knowing the file name. This means the search must understand meaning, not just compare letters. Secondly, read. When I've found something, I want to be able to open and read it directly. In the same system, without switching apps. Sounds trivial, but it's the difference between a tool and a springboard back into chaos. Thirdly, and this is the answer to the trust half of our question, stay clean. The system should itself recognize where my knowledge contradicts itself, where there are duplicates, where versions are outdated, and it should condense knowledge instead of just stacking it. And no search engine in the world can do that. For that, a separate mechanism will be needed later. And fourthly, overview, the entire system at a glance. Yes, and at this point, the graph comes into play at some point, but just look at it closely. It's listed here as a capability, as one of four, and not in the first place. In addition, there's a constraint that shapes several technical decisions. My knowledge base, the index, the graph, and the search are all located and run completely locally on my computer. There is no additional cloud database and no external search services. My notes are my life, projects, finances, personal, and so on. Only when Claude analyzes content or maintains the wiki will the selected excerpts be transferred to the model. And here's the first point you can directly adopt. Before you install any tool, take 10 minutes and write your own list. What does your system need to be able to do for you to trust it? Three to five points, and each one so concrete that you can check at the end whether it's fulfilled. Capabilities first, tools later. And now we have a question and a list of capabilities. And now, of course, the question is, how do you get from such a list to a finished system without getting completely lost? And for that, there is a process. The process has six steps, and this is the process by which the question became a finished system. These six steps, and I'll say it right away, the actual building work, what you imagine when you think of building a system with AI, is only step 5 of six. Four of the six steps happen before the first line of code is created. And that's exactly why it worked in the end. And I'll tell you one thing right away. I didn't come up with this process myself. Steps 2 to 5 come from a ready-made skill package for Claude Code. It's called Superpowers. A skill is nothing more than an instruction that you give to Claude once, and that then applies to every project. At its core, Superpowers does exactly one thing. It forces the AI into an engineering process. Claude is not allowed to just start and write code. It must first ask questions, one after another. It must write down the decisions in a document. It must make a plan with small, testable tasks, and only then will it build. And at each of these transitions, you are the control point. Without your approval, it simply doesn't move forward. If you want to learn more about skills, where to get them, and how to install them, I'll link a suitable video in the description. Why is the process valuable? The biggest risk in AI projects is not bad code. It's that the AI builds the wrong thing at full speed, convincingly for hours, and completely misses the target. And this structure protects you from exactly that. You don't need to know project management or have led a software team. The skill brings this discipline, and you bring the decisions. You will see what I mean in the next few minutes. Step 1 has nothing to do with AI yet, and it's still the most important: organize the data basis. Before anything was built, I completely reorganized my Vault. A clear cluster structure, workflow folders for Inbox, Daily Notes, and Templates, and topic clusters for Content, Business, Community, Personal, and Knowledge. Every note has had a unique place since then. And why this first? Quite simple. The best search in the world will only find your chaos faster in a mess. And if a topic is in five places, no system in the world can build trust from that. Order in the data is not a side step. It's the foundation on which everything else stands. And you can also do this step today. Just use Claude Code, have it search your workspace, and reorganize everything together with it. Claude will suggest clusters. You decide what belongs where. Step number 2: Brainstorming. And here the role distribution is reversed from what most people might expect from AI. I didn't tell Claude, "Build me a Second Brain." Instead, Claude asks me questions, one after another. What is the purpose? What is the data basis? What does it need to be able to do? What should it explicitly not do? These, for example, are the actual questions from back then, and in the end, Claude suggests two or three approaches with pros and cons, and I decide. The most important decision back then: the system works on my entire workspace, as it is. No migration, no new format, no moving everything first. And important here: in this entire step, no code is created, not a single plugin. Step 3: Everything that was decided is written down in a design document. The specification, section by section, approved by me, and this is the original from back then. And this specification is essentially the contract. If a dispute arises later during building, what applies then? Not my memory, not the AI's interpretation. What applies is what is written in the specification. And this may sound bureaucratic, but it saves exactly the discussions that otherwise cost hours. And to give you a sense of the pace, from the first brainstorming question to the start of building, it took about 30 minutes. And this process is not a bureaucratic brake. It's actually the turbo for your project because everything runs more smoothly. Step 4: The specification becomes a plan. Claude breaks the whole thing down into small tasks. For me, there were a total of 14 core tasks, and each task has two things: a test and a very clear completion criterion. Not "build the search," but "the search delivers this file for this example query." Before that, the task is not finished. Step 5: Build, and do it step-by-step. For each task, a fresh sub-agent is used, a separate Claude instance, which receives exactly that one task and the necessary context, and nothing else. After that, the result is checked. Only then does the next task come, and my role in it. I don't read code. I look at results, does the test run, does it do what the criterion says, and the AI writes every single line, and I approve the whole thing. Step 6: Test. What you don't test, you can easily talk yourself into liking. And how the test looked and how it turned out, that comes in Chapter 6 with actual numbers. And if you want to replicate this, the complete process you've just seen, brainstorming, specification, plan, task by task, that was Superpowers from start to finish. A skill package installed once, and Claude Code works like this on every project. Again, the link is in the description, and even if you use a different tool, the pattern is transferable. First decide, then record in writing, and then let it be built in small steps. One thing I haven't mentioned yet: how did Claude know what looked good and what worked technically during brainstorming? And the answer is the most important part of this entire video, namely references. And not in the way most people use them. I assigned three roles to them. And what does that mean? References. Collecting references doesn't necessarily mean copying links and saying, "Build me this." That would just be a copy template, and the results are almost always bad because foreign solutions solve foreign problems, not your own. And for me, each reference had a clearly defined role. There are exactly three of them. And these three roles are the most transferable part of the entire video. No matter what you build with AI, you can always ask these three questions. Role 1: The Building Block. Something that already exists and can be directly incorporated without reinventing it. For me, this is QMD, a local hybrid search by Tobi Lütke, the Shopify founder. QMD combines classic keyword search with semantic search and runs entirely on my computer. Remember capability number 1: finding without the exact word. QMD delivers exactly that as a plugin, installed, integrated, ready to use. And how this search works in detail, I'll show you in the architecture section. But the lesson behind it: don't build anything yourself that already exists as a maintained, finished component. Every hour you don't spend on your own search, you spend on what makes your system special. Role 2: The Pattern. Here you don't adopt software, but an idea and implement it yourself, tailored to your system. And my pattern comes from Andrej Karpathy, one of the most famous AI researchers ever, and he described how an AI can maintain its own knowledge wiki. The AI writes and updates Markdown pages, there's a small index that is read first, and there are validation rules against contradictions and broken links. And the remarkable thing about this: this reference is not a program or a finished tool. It's just a short text in which Karpathy describes how he works. A few paragraphs, nothing more. But the idea within it, the AI maintains the knowledge itself according to fixed rules, is a one-to-one answer to our capability number 3: staying clean. We built the implementation completely ourselves, tailored to my Vault. How that looks in practice, you'll see in Chapter 6 with actual results. Role 3: The Benchmark. A reference from which you adopt neither code nor concept, but which defines how good the result must look. And my benchmark was not a foreign product, but images, mockups of my target visual style generated with AI. Separate knowledge worlds, each with its own color, that don't mix. Clear hierarchy, clarity. Connections appear only when you select a node. These images, not vague words, were given to Claude Code as a visual goal, not written in the prompt, "Make it beautiful," but "This is what it looks like when finished." And how I arrived at these images and what very expensive mistake preceded it, I'll tell you in the Optics chapter. And just this much about it: keep these mockups in mind. They play the main role in the end. And then there's a line at the bottom that's almost more important than the three cards. I also looked at two other projects, namely Gbrain and Graphify. I didn't adopt any code from either, but their pattern: Markdown as the sole truth. The graph, only a derived intermediate state, secured one of the most important architectural decisions. And where exactly you'll see it in the architecture. Knowing what you don't need also gives you the confidence to stick to your own approach when things get difficult later. Discarding something is also a research result. So, your three questions for every own project: What do I adopt ready-made? Which patterns do I adapt? And by what do I measure whether the result is good enough? Building block, pattern, benchmark. With that, you have all four points that flowed into the system: the central question, the four capabilities, the process, the references. Now I'll show you what resulted from that and how the system is built, the architecture. And don't worry, there are only five building blocks, and I've actually already mentioned them all. So, and here is the complete architecture. And before you think it's too technical, there are exactly five building blocks, and each of the four capabilities from before finds its home here. But the most important thing about this image isn't the boxes, it's the colors. Orange means your data, green means normal code, deterministic, always runs the same, costs nothing. And purple means AI. And now look at how little purple there is in this image. This is one of the most important design decisions in the entire system. AI is only used where understanding is truly necessary. Everything that a machine can do reliably and consistently is done by normal code. That saves money, is faster, and is traceable. Building block 1, far left, your workspace. That's the Vault we organized in step 1. In my case, almost 2000 notes, a total of over 4000 files plus the surrounding folders. Code projects, the skills, Claude instructions, the memory, what Claude has remembered about me and my projects, and the connectors, i.e., the connections to other programs. And here you might see the most important sentence of the entire board: Markdown is the sole truth. All knowledge is stored as simple text files on my drive. No database, no proprietary format, no system that can lock me in. Every other part of the architecture is simply a derived view of these files and can be discarded and rebuilt at any time without a single piece of knowledge being lost. Remember the folder 09 Wiki, it plays a very special role shortly. Building block number 2, the Indexer. Sounds technical, but it's the simplest idea in the entire system. Imagine a librarian who walks through the shelves once. He doesn't read the books, he just registers them. What's there? Where is it, and which books refer to each other? And that's exactly what the Indexer does with my workspace. A small program runs through all folders and notes three things for each file. What is it? Title, location, size. How is it connected? Which note links to which? Which text does it have? And to which knowledge cluster does it belong? And from that, it writes two files. Firstly, a map file. Every point, every connection, ready to display. That later feeds the graph view. And secondly, the index.md file. A catalog, one line per area and important file. Not for every single note, otherwise the catalog itself would become a book again. Claude reads this first when I ask something. And most importantly, there's no AI in it. And why is that good? Every run is exactly the same. Every run takes seconds. Every run costs nothing. If an AI had done this, every run would be more expensive, slower, and slightly different each time. Deterministic code before the model. And how do you get exactly such an Indexer? You do it in three steps, and you can adopt them for your own system in the same way. Step 1, define the pattern. Mine comes from the two reference projects Gbrain and Graphify and consists of three rules. Rule number 1: The Markdown files are the sole truth. Rule number 2: The map file is only a derived intermediate state, generated anew with each run, never maintained manually. And Rule number 3: Reading is strictly separated from displaying. Step 2: Write the specification. It contains exactly these three rules, and in addition, specifically which folders are scanned, which are ignored, and what the two output files should look like. All of this was decided before building. And Step 3: Let it be built. Claude Code built the Indexer from the specification in four small tasks, each with a test. That means for you, you only need to tell the AI the pattern. Write me a script without AI that goes through all my notes, collects titles, links, and tags, and writes a map and a catalog from it. The rest is exactly the process from Chapter 3. Building block number 3, the search, our ready-made building block QMD. And as promised, here is the functional principle. QMD combines two search maps that complement each other perfectly. The first is the classic keyword search. Fast, precise, finds every word that is actually in the text. Its weakness, of course, you know. If you simply no longer know the exact word you're looking for, then you won't find anything. That's why there's the second one, the semantic search. I'll explain it with an image. Imagine a huge map. But instead of cities, there are meanings on it. A small AI model reads every note and places it on this map. The content determines the position. Notes that are about the same thing end up close together, even if they use completely different words. And now the question, how does the model know what belongs together? It has read huge amounts of text during training and learned which terms appear in the same contexts. And now comes the real trick. When I search, my query is placed on exactly the same map. It also gets a position. And this turns the difficult question, "Which note fits my query?" into a very simple one: "Which notes are closest to my query on the map?" And these nearest neighbors are the results, and for that, not a single word needs to match. I ask for subtitles and get the note where perhaps only "captions" is written. Different words, same meaning, right next to each other on the map. And this map is built by three small AI models that QMD automatically downloaded during setup and that run completely locally on my computer. Together, no more than 3 GB. One understands my query and adds related terms. One places the notes and queries on the map. And another one looks at the results at the end and puts the best ones forward. And these are not chat giants, they are small specialists for a single task. And on my Mac, these models run completely smoothly locally. And here's a small example. I'm searching for something intentionally vague, and there's the direct correct file within seconds, without anything leaving my computer. And where can you use this search in everyday life? You can do it in three places. Firstly, you can do it directly in the terminal. Secondly, much more often, not me myself. Claude uses it for me as one level of its search ladder, more on that shortly. And thirdly, directly in my Graph Web App. How that works, I'll show you in detail in the Optics chapter. Building block number 4, the only big purple in the image, Claude itself. And here's the point that almost everyone underestimates. The crucial thing is not the AI, it's its rule set. So the Claude MDE, a text file that Claude reads at every startup and that defines how it works with my knowledge. The core of it is the search ladder. I call this rule set Brain First. When I ask Claude something, it's not allowed to just search wildly or, worse, read half the Vault. It must descend the ladder. Level 1, read the Index.md. The small catalog, a few hundred lines. Level 2, check the wiki to see if the knowledge is already condensed there. And Level 3, the QMD search. Level 4, open exactly one file, namely the best one. And then there's Level 5, Answer. This also answers a question that came up under the last video: How do you get the whole Vault into the context window? And in short, the context window is the AI's short-term memory, and tokens are the chunks in which it reads text. And the more tokens, the fuller, slower, and more expensive. And the answer to this question: not at all. The size of the Vault doesn't automatically determine how much of it ends up in the context. Claude loads only the catalog and the few relevant files per query, a few thousand tokens perhaps. The trick is not a larger context window. The trick is a system that doesn't need one at all. And do you see the arrow here, going back from Claude to the Vault? That's the feedback loop. Claude doesn't just read, it also writes, it maintains your wiki folder in the Vault according to the pattern. And how exactly that works and what resulted from it is the next chapter. Building block number 5, the Web App. And does anything strike you? It's hanging on the edge of this diagram. That's no coincidence, because it does exactly three things. Firstly, it reads the map file from the Indexer and draws the graph from it. Secondly, it opens any note I click on, right next to it. This is where capability number 2, reading, finds its home. And thirdly, it contains the search box, the third place from just now, where the QMD search works. Nothing more. It never writes, it never decides, and no other part of the system actually needs it. And this is the most important realization for everyone who wants to build along. Building blocks 1 to 4: Vault, Indexer, Search, Rule Set. That's the system. And for that, you don't need to be able to program. The Vault is organizing, QMD is installing. The rule set is a text file, and the only real code, the Indexer, Claude writes for you. The app is just the window, and the system must first prove that it deserves the window. A system can look great on paper, but the question is, does it hold up in real operation? And now let's look at the whole thing in a practical test. And in doing so, a number comes to light that made me doubt my own Vault for a moment. My old Vault, and up to this point, everything sounds good, but "sounds good" is exactly the state in which most systems simply die. You build them, are proud, and three weeks later you don't use them anymore because they don't bring anything in everyday life. Therefore, the system had to prove itself in a practical comparison from the start. Step six in the process, and twofold. Firstly, is it really faster, and that's clarified by a measurement test. And secondly, which is more important to me, can I really trust the knowledge in it, and that's clarified by the wiki layer. And let's start with that, because that's the core. Remember the Karpathy pattern from the references? The AI maintains the knowledge itself. Here it's implemented. In my Vault, there's a folder 09 Wiki, and for it, there's a strict rule: I don't touch it. Not a single text in it is from me. It's maintained exclusively by Claude. And that runs according to fixed rules. They are in a schema file, a normal text file that lies in the Wiki folder itself. It's Claude's work instruction for the wiki. Before any wiki work, Claude reads this file exactly and adheres to what's in it. For example, what page types exist: summarization of sources, topic pages, pages about people and projects, and synthesis pages that condense knowledge from multiple sources. Everything is cross-linked, and the effect of this is that no matter which Claude session is currently working, exactly the same rules apply in the wiki. And the most important process for this is called ingest. I give Claude a new source, a transcript, an article, a note. Claude reads the source and determines, using the wiki's page directory, which pages already touch on the topic. Only these are opened, not the entire wiki. Then it's ingested: affected pages are updated, missing ones are created, links are set, and the most crucial thing happens exactly during this process: on each of these pages, Claude checks whether this information, i.e., the new information, contradicts what is already there. And the most important thing for everyone who still has full concentration: this wiki doesn't need any special technology. They are normal Markdown files in my Vault. One folder, one rule file, and the maintenance is done by Claude Code. Anyone can open it with a text editor. I read them, for example, in Obsidian or directly in my Graph App. Both turn cross-links into clickable links and warning messages into colored boxes. The text editor is essentially the shelf, and Claude is the librarian. And you can call this librarian in three places. In the terminal, in the Claude Code app, or directly in Obsidian with a plugin like Claudian, for example, which embeds Claude Code as a sidebar. Then everything happens in one window. Only one thing the ingest never does: it doesn't run in my Web App. And why? That's a conscious decision. You'll see that in the next chapter. And now, perhaps a quick question for you: would it bring you added value if Claude were directly in the Web App as a chat window that answers your questions, and you could fly directly to the source in the graph? Please write it in the comments, and if enough interest arises, I'll look into how extensive the whole thing is, i.e., the implementation, and make a separate video about it. So much for the principle, but you don't have to believe me. However, I've prepared a trap, and this is a completely normal note that could land in my inbox every day. A few bullet points about the Second Brain setup. It looks very harmless, but I've hidden various errors in it. Three statements that contradict what you've already learned today. Perhaps you've already discovered them while reading along. Now I'll ingest this note into the wiki as usual. Let's see how many errors the system catches. And here's the result. All three caught and marked, some on multiple pages, because a contradiction is marked wherever it appears. The statement, "semantic search, send my notes to a cloud service," is marked on the QMD page with a reference to the documented local architecture. The statement, "the measurement test yielded nothing," is marked with the numbers from my practical comparison as counter-evidence. And the recommendation, "maintain the wiki manually," is marked on two pages because it violates the fundamental rule of the entire wiki pattern. And one detail shows that the system doesn't just flag everything. The note also contained a fourth statement: "more source work," completely harmless. It wasn't marked, but was incorporated as confirmation of an open point on the relevant page. So the system distinguishes: what fits is incorporated, what contradicts is marked. And now look very closely, because this is the most important, or the most important property of the entire system. It hasn't overwritten anything. It hasn't simply decided who is right. Both statements are there, each with its source, and below it the sentence, "Patrick decides." The AI finds the conflicts, but which version applies, that's up to me. And this was a prepared trap. But the crazy thing is, when the wiki ingested my actual inventory, my notes, my strategy documents, my project files, it marked 52 conflict points, statements that didn't clearly fit together, 52 in my own knowledge, including actual contradictions, outdated versions, and cases like this one, where "should" and "is" were not clearly separated. And you already know one example, the two files from the beginning of the video. Exactly, the system found them. In my channel strategy, there was a goal: viewers should watch at least half of each video on average. That sounds excellent, I wrote that down at some point. But in another note, there were the actual evaluations, and the actual values were there, and both statements existed peacefully next to each other for weeks in two files that I never had open simultaneously. I also mentioned it briefly at the beginning, but didn't explain it. The system marked it automatically, and that's exactly the point. These ambiguities and conflicts were there the whole time. They only became visible when a machine read and condensed everything simultaneously. And now the question, what do I do with such a finding? The box is not an end state. It's a task for me. In this case, the decision is: the goal remains. 50% is my ambition. The actual numbers don't tell me the goal is wrong, but in this case, they simply tell me that I need to get better, or rather, you need to watch my videos longer. So I'll clarify the source. In the strategy document, it now clearly states: this is the target value, and next to it, the current status.
The order is important here. I am repairing the source, not the warning. If I were to simply delete the box, the next run would immediately find the exact same conflict again, and the files would still contradict each other. Only when the source is clear do I tell Cloud "decided." So it goes. The wiki is updated, the box disappears, the decision is recorded in the log, and the hidden contradiction has become a visible work order. In addition, every single run is logged. When did the run happen? Which source came in? Which pages were changed? This sounds unspectacular, but it is the difference between a system you have to believe in and a system you can verify. The second test remains, speed. The test was run twice with the same five real questions from my daily work. Once without my system and the next morning again with Brain. In between, there was only the installation of the search and the rules. Measured were tokens, time, and whether the answer was correct. And the result in this comparison with five questions, the Brain variant needed about 50% fewer tokens and about 40% less time with five out of five correct answers in both runs. And this is not a scientific study, of course, but a practical comparison with my own work questions. And for my workflow, the difference was simply significant. And the most expensive question shows why a single line about a fix in my project cost over half a million tokens without Brain. And understand me correctly here, the token consumption does not come from the question, it comes from the search. Each search step re-reads the entire previous history. Without a system, Cloud searches for a long time, and each round becomes more expensive than the last. And with the system, the search was over after two steps, and therefore the question only costs a third. If you want to understand deeper how tokens and the tokenizer work, I also have a separate video for that, which I will link here, and the link is in the description. For simple questions, things that are already in the loaded context anyway, the normal session wins just as well. There is nothing where you can save tokens somehow. And the Brain wins where it is really relevant. For knowledge that is deeply buried and for questions whose answers are in multiple files. And the test that really counts in the end is everyday life. I work with it every day, not because I built it, but because it is faster than searching myself. And that is the benchmark on which every system hangs. Do you still use it when the enthusiasm is gone? And with that, the system is complete. It finds in seconds, it reads, it keeps itself clean, and it has proven itself in my test and in everyday life. Now the time has come for the last step, the optics, and for the biggest mistake of the entire project. I am fulfilling the promise from the intro. The mistake that cost us hours. I will tell you directly what you should not do, because that is exactly what I did, and that was the mistake. I described in text what I wanted and let the AI build it. Make it denser, 3D, more depth, less glow, and Cloud delivered, but something. And then I was just like, no, do it this way and that way. again something else, until I was really annoyed at some point and couldn't get any further. The problem was, of course, not the AI, but my descriptions, they were simply not good. It's a guessing game for the AI. And then came the realization that turned everything around. Cloud is extremely good at dealing with references, at recreating something very concrete, but it cannot guess what it looks like in my head. So I needed something very concrete, namely images. Hence the change. I opened ChatGPT. There is a really good build engine, and I had it generate the target state of the optics there first. And I will show you the complete real process with my prompts now. My starting prompt. You see it completely in the picture here, and it was essentially: I need a graph view for my Second Brain. Up to ten main clusters, each with its own color. Clearly separated and visually higher quality than the Obsidian graph. ChatGPT first delivered a concept, and from that, I directly adopted various ideas. First, the clusters remain spatially separated so that the content does not mix. Second, connections are not permanently visible but only appear when you hover over them with the mouse, otherwise the graph becomes restless. And that's exactly where the hover effect from my app comes from. And the more knowledge is in my folder, the bigger the sphere. Then came target image number 1, the globe with separated knowledge worlds. Target image number 2, the cluster view. One prompt, one result. As an addition, I also said, place the code mascot as a central element in the middle. And you see, the direction was right immediately. And target image number 3, I didn't just want to see my notes, but my complete AI system, Cloud MD as the central control element, plus Memories, active Skills, Plugins, and Connectors. ChatGPT suggested a ring structure for this. Inside the system core, around it the knowledge and project structure. on the very outside the external services, visually clearly separated, and from the same suggestion comes another idea that it knows from my app, namely the detail window that quietly opens on the side when you click on an element. After one or two more rounds, the result was ready. A few days ago, I added another representation, the layer view. A single prompt, and the basic idea was right immediately. These images became the visual specification for Cloud Code, and thus the views were created within minutes. And the crazy thing is, these exact views are what impress people the most. Yet, it is actually the part that goes the fastest once you know the right way. And another tip on the side: If you are looking for visual inspiration, it is also worth taking a look at Pinterest. Search terms like knowledge graph or Big Data Cloud provide really cool reference images. Do you still remember the promise from the reference chapter? Keep the mockups in mind. They play the main role in the end. That's exactly where it is now. The images went from the benchmark to the construction blueprint. I gave them to Cloud Code as a reference, and it was built according to a single rule. Cloud implements one step. I check in the browser whether the result matches the target image, and only after my approval does the next step come. And the best example is the layer view. The image from the ChatGPT history as a reference, one implementation step, a look in the browser, approval, done. And here is the result, my knowledge as a graph in different versions. I said the system must first prove that it deserves the window, and it has. Now it can also be beautiful. And now, of course, the legitimate question, if search, wiki, and reading also work in Obsidian with Cloud Code, why have a separate app at all? And for that, I have three answers. First, Obsidian only shows my notes. My system is larger. Cloud projects, skills, memory, connectors, Obsidian does not display these layers. The app is the only window that shows everything. Second, the health check. Which clusters are growing? What is lying around unused? I see this at a glance, instead of guessing somewhere in a haystack where something is. And third, I can read and click further in the graph. Each file opens directly here, even those outside the vault. And that is the test of whether a visualization is a tool or just a poster. If Obsidian is sufficient for that, perfect, you save the app. It is the icing on the cake and actually looks quite cool, and you can also just experiment with it. And with such projects, you learn a lot about working with AI. And one thing has been added that answers this question even better. The search box of the app can now also do semantic search. So I type in a question. What was our style for the subtitles? Press Enter, and the app delivers the corresponding note, even though the word is not present anywhere. One click, and the graph flies to exactly that file and opens it. And now the point that will surprise many, namely what this actually means for AI and for tokens. When you press Enter, the following happens. The app forwards the question to QMD, specifically to the fast variant of the search. The question understanders expand the query with related terms. The embedding model places it on the meaning map and compares two of the three local models. So, the fine-tuning sorter remains outside. Only the complete hybrid search, with which Cloud Code works via the search ladder, uses that. All of this runs completely on my Mac. Nothing is sent to any provider, not a single API token is consumed, nothing from my Cloud quota is touched. The costs are pure computing time, about 2 seconds of processor work per search, nothing else. I can search 100 times a day without API costs per search, and it also works offline. The app thus uses local AI, but not Cloud AI, and it does not incur usage-dependent API costs. It borrows the local specialists from QMD for the search, but remains a pure read interface. It finds and shows, but it never writes. I only consume tokens in this entire system in one single place, when Cloud really thinks for me. Finally, I switch back to the view, the layer view. It is proof that the optics are interchangeable. The system underneath, index, search, wiki, rules, that remains exactly the same, no matter which window you put in front of it. The window is simply a matter of taste. The foundation is mandatory. The lesson from this chapter in one sentence: Do not describe to the AI in words what it should look like. First, have images of the target state generated, and then use those as a reference. Two, AI is clear division of labor. For example, ChatGPT creates the target image. Cloud Code recreates it. Since I've been working this way, it's no longer a guessing game. It's simply an order with a template. And now the question remains, actually the most important in the whole video: What of this will you now rebuild, and what will you start with today? Let's come to your entry and summarize what we have learned in this project and what the project has learned. Seven lessons, and you have seen each of them in action today. One: References always beat descriptions in technology as well as in optics. Two, small steps with approval, never everything at once. That built the foundation and saved the optics. Step number 3: Decide before building. The specification is the contract. Whoever builds first and then decides, builds twice. Point number 4: Deterministic where possible. Use AI only where understanding is really necessary. That's why my indexer costs nothing and runs in seconds. Five. Markdown remains the only truth. No database, no format prison. Everything else is just a view of your files and is replaceable at any time. Six. Every claim needs a check. Without the benchmark, I wouldn't know to this day if all of this is even worth it. I would just believe it. And seven, the most important, the human decides, the AI delivers. For every brainstorming question, for every contradiction in the wiki, for every optics step in this entire project, the AI has not made a single decision. It has only made them possible. And now to you. You don't have to rebuild the entire system to benefit from it. The core of finding and trusting can be done completely without you having to write code yourself. Four steps together, about an hour, and in my opinion, you already have the biggest part of the practical benefit. Step 1: Organize your notes into topic clusters. Take Cloud Code with you, let it search your inventory, and re-sort together with it. That is the foundation. It costs nothing, except perhaps the hour. Step number 2: Create an index file, a catalog, one line per topic, what it is, where it is. Cloud Code types this for you too. Tell it to go through your folders and write the catalog. It is the first step of the ladder. Step 3: Install and initialize QMD. After a few terminal commands, you have a local hybrid search across all your notes. The link is in the description. Step 4: Write the Brain First rules into your Cloud MD. First catalog, then the search, then exactly one file. You can find the rules to copy in my PDF giveaway for download in my free school community, where everything revolves around AI and where many other AI enthusiasts are already present and exchange ideas on various topics. That's all. No graph, no app, no wiki. That is the icing on the cake, which comes when the foundation proves itself. And if you remember only one sentence from this entire video, then it is this one under the board. The AI writes the code: "You curate the references, and you decide, and you approve every step." Because I own the interface myself, I can further develop and expand it later. For example, here my own video editing, which I created, automatic cutting of my long videos, and from the finished video in a few seconds, I can directly export shorts. All local, no subscription, no costs. But that is a separate chapter. For the Second Brain, it remains crucial. The system underneath works independently of this interface. All links can be found in the description. My free starter document is also linked there. And now, of course, I am interested in one question. What should I show next? Cloud directly in the app, or perhaps a Cloud variant? Just write Chat or Cloud in the comments, or maybe something else that interests you. And if this deep dive, even if it was extremely long and perhaps very technical, has helped you and delivered added value, and if this format is good for you, I look forward to a subscription and a comment. And now build your foundation, and we'll see you in the next video.