Engineering Your Own AI Assistant | Paul Iusztin

The transcripts are edited for clarity, sometimes with AI. If you notice any incorrect information, let us know.

Digital life organization using the PARA method and lightweight data pipelines

Alexey: Usually I do the introduction, but I am very excited and impatient to start talking to you Paul, so I will skip the intro. Just like the video, subscribe to our channel. There is a link about Data Talks Club in the description. Click on this and today we will talk about creating our AI systems. Today we have Paul as our guest. It is always a big pleasure to have Paul. (0:00)

Paul: Yes, same here. I love our talks and it is amazing. It is great to be here again. (0:23)

Alexey: Paul is a frequent guest. First I think we hosted you and your coauthor in our book of the week channel where we talked about your LLM handbook, is that correct? That is the title. (0:30)

Paul: Yes. That is how we LM engineering math I think. (0:49)

Alexey: When I reached out to you about that. Before that I saw your face constantly on my LinkedIn feed. I keep seeing it on LinkedIn, Twitter, and Substack. You are everywhere. For me it is always nice to say here. (0:55)

Alexey: I noticed that you have a course about creating a second brain where you talk about automating yourself and the things you do. (1:13)

Paul: I actually also within my book started shifting my attention towards the second brain thing a long way back. Even when we have not used AI for this, I have been into productivity to some extent for five or six years. It has been a hobby of mine. I never went extreme into this like all these productivity gurus, but I always liked organizing my digital life and trying to be more productive around it. I do this as long as it does not get toxic. (1:25)

Paul: I have been into this second brain type of thing a long way back. Actually it is a term coined by Thiago Forte and I read his book. He basically describes how to organize. I think it is this one. I have zero affiliate stuff but I really like it. (2:08)

Paul: It is Building a Second Brain. I really like it. He is basically the second brain guy. He talks about how to organize your digital life without any fancy engineering. This is very beautiful because it nicely fits organically into your workflow. (2:32)

Paul: We as engineers usually directly ask what database we can use, what pipelines we can integrate, and how we can scale this. All these thoughts are good and productive. Usually I found that they introduce a lot of friction in actually using these systems in your daily life. You also have to put a lot of effort into actually creating them, maintaining them, and making them actually useful. That is why I tried to find ways in how you can just use tools that you have like Obsidian, Notion, or whatever you actually have. (2:52)

Paul: How can you actually introduce organically some layers and some pipelines? (3:30)

Alexey: I was taking notes. My last thing I took notes of was second brain, wiki, Obsidian, notes, and layers. The reason I put wiki there is because I wanted to ask you if you call your second brain your personal wiki. Is it like a Wikipedia where you can put things that are relevant for you and they have this linked structure? This allows you to easily go from something abstract to something concrete quite fast. (3:38)

Paul: Yes. To be honest, I do not use links or references that much. Probably you can, but I find it really complicated. Long story short, I think this is not about tooling at all, but is about the processes that you want to integrate in your life. My data pipeline is a very light data pipeline that does not use any engineering, any code, or any AI. (4:09)

Paul: It is very basic and is based on this PARA principle. Basically you just divide all your digital life between projects, areas, resources, and an archive. I think that the most interesting part is how you structure your resources. For example, the resources are where you just pipe data into your digital life. This can be your own notes or data from the outer world whenever you find a nice article. (4:39)

Alexey: If I go on Twitter and I see something interesting while I am on a bus, I cannot read it right now. I would put it in the resources so I can read it later. (5:14)

Seamless resource capture with Obsidian and Readwise

Paul: Exactly. It is a very simple strategy. For this I also use Obsidian and Readwise. Readwise is a very nice tool that allows you just to click save. It works for PDFs, papers, videos, or whatever. (5:21)

Paul: You click save, it goes into that system, it gets ingested, and you can use it whenever it makes sense. Basically this is the data pipeline where you just get everything aggregated very easily and very smoothly. You just do your own thing. You click a button, you capture it, and you move on. It is very light. (5:39)

Paul: Then you have these areas and projects. Basically this is where you get your resources and you scope them down to something concrete. Areas are things that are not bounded in time. For my company they are things like my content creation funnel or my distribution. These are core pillars of my business but they are not necessarily anchored in time. (5:58)

Paul: I will always need them. In my personal life they are things such as my car, health stuff, and financial stuff. These are areas in my life that most probably will never end. Then on the project side they are just projects scoped in time that have a clear goal and I need to tackle them. On the AI side, I think the most interesting part is how you can map those resources to something concrete like a project. (6:31)

Paul: I think that is the trickiest part. Before in a pre AI era if we started saving resources, YouTube videos, and articles, they piled up really fast. I save around two hundred fifty per month. It is impossible to browse them when you need them. That is the actual problem. (7:04)

Paul: It is even more impossible to actually read all of them. The problem is that now you actually want to put in the work to code, to start a new project, to build a feature, or to write an audio. The friction to find the relevant resources that you saved and apply them into that is huge. To be honest, I never did that. That is why I call it your second brain is a graveyard. (7:30)

Paul: If you do not have a way to link these two, everything that you save is just useless. Basically you just pile it up and you never use it. (8:01)

Alexey: I had a personal wiki. For me the most time consuming part was the creation of this. (8:12)

Paul: Exactly. (8:18)

Alexey: I have a pile of things and a pile of ideas. Sitting down and actually putting them in order, creating links, and creating summaries was taking a lot of time. (8:18)

Paul: Yes. I dropped all of them. I do not care about them because maintenance for all these things is hell. You want to reduce maintenance as much as possible. Ideally, you want a system with zero maintenance and curation. (8:30)

Paul: That is ideal but you want to reduce it as much as possible. Basically I have a system that is like a data pipe or a DAG. You can see it like a DAG. You have your outer world. Then you have this resources layer where you are just piping things. (8:42)

Paul: This data is immutable and you do not care that much about curating it. By saving it, it is already a curation. It means it is something that drove your attention and captured your attention. It means it is valuable for you already. Especially if you want to write a note manually, I like to write notes because it helps me think. (9:02)

Resource retrieval optimization using a deep research algorithm

Paul: That is even a higher level creation. It is already something written by you. Whenever you want to use it in a project to actually put it into work, I wrote a simple deep research algorithm. This is based on something that I want. For example I have a spec for a project or for an article. (9:26)

Paul: I do a quick brain dump on what I actually want to write in that article. I put that as context for the deep research algorithm. Then it scans all those resources automatically. Basically it mostly uses text search with some vector search. It is pretty simple because if you use deep research where you just create all kinds of questions and keywords, it is pretty effective with just keyword search to look through your Obsidian and Readwise. (9:44)

Paul: This way you can capture twenty or thirty resources already relevant to you. Why is this beautiful? Remember that huge pile of resources that most probably you never read. Then you can read them only when you need them. (10:13)

Alexey: Whenever you want personalization or that kind of thing. (10:37)

Paul: Exactly. You just capture things and think this might be useful somewhere in the future. It is like a lazy need. You put them in there and then you read them only when you actually need them. It is like a very organic filter basically. (10:42)

Paul: You never need to anticipate what you might need. You go the other way around. You read it only when you actually need it, which can save you a lot of time. It also reduces a lot of friction of you thinking that you need to learn and read so much. (10:54)

Alexey: Most often you do not need that and it is a lot of pressure. At least for me it was. You have a newsletter on Substack. Do you publish every week there? (11:15)

Paul: Yes. (11:25)

Alexey: I guess this is the pipeline you have. Are you saving all these resources and then having another pipeline with ideas? You decide what you are working on this week. Then you look at the resources you have in order to see what you can write about. (11:25)

Paul: Exactly, that is how I started thinking about it. Now I am expanding it to multiple areas. That was the seed and my core problem basically. Why is this powerful? You can use deep research on Gemini, Perplexity, NotebookLM, or whatever tool you use. (11:43)

Paul: To be honest I never like the resources that they find. It is useful but it requires a lot of curation. It gives you a big dump. (12:01)

Alexey: Maybe a third or a fourth of this dump is useful but you still have to go through this super long document. (12:12)

Paul: Exactly. This way you already create your little slice of the internet that you need. You know it is already highly curated and you know it is high quality. What I also do on top of this is subscribe to some RSS feeds and newsletters. This also gets dumped into this second brain because the probability that I save everything that I need is low. (12:19)

High-quality internet curation versus heavy RAG pipelines

Paul: I thought about myself and decided to curate some people or companies that I trust. Basically I just dump everything that they write into this pool. Whenever I want to start writing something I just query this little slice of the internet that I already know is high quality. What I retrieve from there has a very high probability of being something good. I do not have to spend too much time curating as you said. (12:44)

Alexey: That is pretty cool. Is the course creating your second brain about what you described? (13:18)

Paul: No, the course on how to create a second brain was actually done two years ago. It was at the inception of something like this. (13:29)

Alexey: I think one of the first things I got to know about you was this course. Maybe many listeners also found you this way. (13:40)

Paul: You could see my excitement in the course probably. It is something that I really liked, but basically I am not doing what I was doing two years ago. We already had models that were good enough to have a good enough RAG. That is what I tried to do. That was my initial thought that you need to do RAG. (13:46)

Paul: I was thinking how you can index all this data. That is not really realistic at least for personal use if you do not want to put a ton of money and effort into it. As I said earlier, I am just subscribed to two tools, Readwise and Obsidian, which is about two hundred bucks per year. It is a system that works, plus my agent subscription and that is all. I do not need to invest into RAG pipelines, databases, and all that fancy infrastructure. (14:14)

Paul: That sounds good but if you do not want to create a product and just want it for yourself, it is okay to be a bit more hackerish. (14:47)

Alexey: This second brain that we talked about fits perfectly because today the topic is personal assistance. What is the relationship between the second brain and having personal assistance? (15:05)

Paul: I see the second brain as your context layer. That is actually ninety percent of the problem. LLM agents are amazing. If you want to actually put them to work, the context is ninety percent of the problem. You can very easily now switch from Fable to some GPT 5.6 cell model or K3 or whatever powerful model you have now. (15:17)

Paul: We can see there is a huge competition over there and they start to get better and cheaper. Basically you have zero advantage over there. You can just pick one and use it. The context is actually what makes you unique and what makes you actually ship things that are yours. That is basically the relationship. (15:51)

Paul: How can you take all these resources from your context layer and put it into an agent? The second problem is how you can grow this context layer organically without spending too much on creating and maintaining it. You do this without it starting to be a burden basically. (16:15)

Second brain setup as a context layer for personal AI assistants

Alexey: When I think about personal AI assistance I am thinking about tools like Open Interpreter or Hermes. Is this also what you think about when you think about assistance? What is your experience with these tools? (16:31)

Paul: I think that is the future for sure. At the moment I do not think they are there yet to be honest. If I started using them, it would feel for me that they just add more friction than they should. I think the future is no screens, just an agent that you talk to and somewhere somehow it will deliver what you need. We are really early. (16:50)

Paul: I need this system to actually be productive and to actually ship. That is why I am not using that. (17:23)

Alexey: I agree. I have Open Interpreter. It is running on my remote server and I have it in my Telegram. It is for super ad hoc stuff like creating an issue in this GitHub repo. This is a server I rent, a remote machine. (17:30)

Alexey: Once I was attacked by hackers who overloaded my SSH so I could not SSH to my server. When I tried to SSH into the server it would refuse the connection. Because I had Open Interpreter running I asked it to check what was happening. It said my connections were overloaded. I asked if it could do something and it installed some blacklist. (17:43)

Alexey: It fixed my server so I could SSH into it. (18:07)

Paul: That is cool. (18:13)

Alexey: I thought it was nice to have this backdoor into my server. If things like that start happening I actually kind of have an agent on the inside which I can use through Telegram to do some things. That was probably a single use case where Open Interpreter was very helpful. The rest is just playing with it. I have not really integrated it into my workflow. (18:19)

Paul: Where do you run this and how much does it cost? (18:49)

Alexey: I run it on Hetzner. Think of EC2 instances. You actually rent a physical server. This is kind of bare metal except you do not manage it. It is not under your desk, it is somewhere on a data server. (18:55)

Alexey: This is an actual server. That is why it is cheaper. I pay forty per month. (19:08)

Paul: Okay. You basically host it yourself or they take care of hosting it? (19:16)

Alexey: They put it in a data center. They actually take the server and put it into the data center. (19:23)

Paul: Yes. I meant Open Interpreter like the software. (19:28)

Alexey: Open Interpreter. I just installed it there on the server. (19:28)

Paul: Makes sense. Hetzner just gives you a Linux machine? (19:37)

Alexey: Exactly. It is cheaper than Amazon or GCP. You can do whatever you want there. (19:42)

Paul: How much does it cost you per month to run the AI usage and all of that? (19:48)

Alexey: I just use a subscription. I use that AI. (19:59)

Paul: Okay. (20:04)

Alexey: I use it for many things. Since what I get is just a key that I can use for Codex, Claude, and Open Interpreter, it does not really cost anything extra. (20:04)

Paul: Makes sense. You just use the GLM 5.2 from them? (20:21)

Alexey: Yes, and that one. (20:27)

Paul: Okay. That actually makes sense. I am really curious about your assistant. These general purpose assistants are kind of cool. A lot of people were talking about them, but now if I open Twitter, I do not really see much about them. (20:34)

Paul: There was big excitement, but then people started using them. They realized they are not there yet. It feels like they are more in the way of what you want to do. I think they are trying to do everything and be a new operating system basically. That is a nice idea but hard to tackle. (20:52)

Paul: I never install them. I just talked to people and most of them told me what you told me. (21:15)

Alexey: It is very simple but I would not run it on my computer. I would only run it in an isolated sandbox environment. What can it do on my computer? I do not want it to run twenty four seven. It is scary. (21:29)

AI workflow simplification with Anthropic APIs and CLI tools

Paul: Personally I kept it super simple. I just used Claude code with an Anthropic subscription. That is it. I know there are big discussions now that a certain model is better. To be honest, most of the time everyone tries to hack into using Anthropic models for coding and writing. (21:40)

Paul: At least that is what interests me. I decided not to bother with all that nonsense. Just stick to their subscription. I think what you do is a really good option. Sticking to one subscription avoids wasting too much time hacking around so you can just build value, build features, and ship something. (22:07)

Paul: Basically I have this context layer and I have two pools of skills and code. I start to combine them. I do not like using only skills. I try to combine them by building Python packages that are used within skills. I find this to be a very powerful combination. (22:30)

Paul: Skills interface directly with Python packages. I write a Python package, a CLI on top of it, and I pass it to a skill to use it. I have one for coding and one for content creation and productivity stuff. They all interface with this context layer and I use this through Claude code basically through the CLI directly. (22:52)

Alexey: You run Claude minus C and then your prompt? Then that is it? (23:24)

Paul: No. I just open Claude directly. (23:30)

Alexey: You do not automate it directly? (23:35)

Paul: No, not that much to be honest. I do not have automations to be honest. I see people keep talking about them, but I do not see that much value into automating things. For example, if I get a brief of my emails, I do not have hundreds of emails. I do not see the value in that. (23:35)

Paul: For my calendar, I do not have thousands of meetings. I get the point for some people that are in these scenarios and I am sure they exist. I get the value of that. For me, I just open my computer and interact with Claude code with everything. I do not do clicks that much anymore. (24:00)

Alexey: What happens when you run out of limits? (24:26)

Paul: I do not. (24:26)

Alexey: You do not? (24:33)

Paul: Seriously, I think in the past seven months I ran out of tokens only once when they introduced Fable. I had not realized how fast it eats tokens. I just started doing my own thing with Fable and in two days I was maxed out. Otherwise I do not know what people do to max out their tokens. I run agents all day long and I do not. (24:33)

Alexey: Maybe you are doing something different. For me I have this problem all the time. I have two or three subscriptions and I constantly hit the limits. Tell me more about this context layer because maybe this is the secret sauce that makes it possible to actually not run out of tokens. How do you connect all these things? (25:03)

Ad-hoc wiki generation from markdown brain dumps for content creation

Alexey: Maybe we can walk through your assistant using a use case. Maybe we can take a use case of preparing a new article and you can walk us through the entire thing. How do you start and what interfaces do you use? (25:26)

Paul: Basically let us say that I am writing a new article on how to build a coding agent from scratch. My process is that first I dump into an outline all the core topics that I want to approach there. I do this as much as possible in the right order. (25:47)

Alexey: You create an outline by typing or speaking to open a file. Do you use dictation? (26:10)

Paul: Yes, dictation. It is a normal markdown file where usually through dictation I just do a breakdown of what I want to explore in that article. (26:16)

Alexey: This is a markdown document. Let us say coding agent from scratch dot md where that lives maybe inside the articles folder. You just create a brain dump there. That is the first step. (26:28)

Paul: Exactly. That is the seed of everything that happens afterward. Then I run a skill called wiki research that has multiple steps. The first step runs this deep research algorithm on top of my second brain using this outline as a seed. It basically starts creating all kinds of queries for text and semantic search on top of my second brain. (26:34)

Paul: It grabs thirtyish resources. I found that thirty is a good middle ground and balanced for an article. It also searches my notes, resources, and basically everything that I have. It is a mix of my personal thoughts, personal experiences, and other resources from other people. Based on that I create a wiki. (27:08)

Paul: Just based out of those resources I create a wiki like the wiki memory that is now popular on the internet. I already started using it for the past three or four months. I started having a simpler version even before it got popular. (27:40)

Alexey: You mean the one from Andrew Karpathy? (27:59)

Paul: Exactly. I was already starting to use something. After that it got more concrete. (28:06)

Alexey: He has a gist in GitHub. He describes the structure and the approach. (28:12)

Paul: Yes. My missing piece was how you can actually create a mini knowledge graph out of that wiki, which was a big revelation for me. Anyway, it is a very powerful tool where you can keep your context and research. Basically I never pass all my documents to an agent. I always pass this wiki where it can progress its disclosure. (28:19)

Paul: It gets what it needs. This way I can keep my context very thin whenever I want to write something. Sometimes before doing the deep research and wiki I know that I have a couple of resources that I really want to use. Sometimes you already know that you have these two or three links that you use as inspiration. Sometimes that happens. (28:48)

Codebase ingestion and web scraping proxy tool workarounds

Alexey: Does it help load source code? (29:18)

Paul: Exactly. That is another step inside this wiki. I also index code bases. I have a sub agent that creates some architecture diagrams and basically creates an ad hoc documentation for that codebase. The beautiful part is that most often you do not have all your topics cleared when you start doing this. (29:21)

Paul: Then you can start asking questions on top of that wiki and start learning more about the topic. You basically refine your initial outline and find gaps in your knowledge in what you thought you learned. Maybe you just want to fact check what you thought you knew. It is more like an exploration phase. Based on each question you start generating new notes on top of it. (29:47)

Alexey: The questions are coming from the skill. You say you have this wiki research skill and the skill fetches thirty plus resources which includes resources you bookmarked and personal thoughts. It uses this knowledge graph from the wiki. Based on that because you have this graph and you fetch some articles, you can create follow up questions. (30:15)

Paul: Exactly. I always interact with the wiki through this skill. When you just want to read, you can just pass the index to the wiki and it is enough. The LLM knows how to move around through the links basically. When you want to ingest, I have this skill that explains basically how my structure looks. (30:46)

Paul: It explains what I want for a particular GitHub repository or another link from my Obsidian or Readwise. It is glued to my context layer basically and knows how to take data and put it into the wiki. (31:05)

Alexey: Ingest is when you want to add something to the wiki to the graph. (31:29)

Paul: Yes. I use that just through Claude code in my use case, but it probably works with any harness. (31:29)

Alexey: You have this Readwise. I guess you can open Claude code and ask it to please pull the latest articles from Readwise and ingest them into the wiki. (31:42)

Paul: Yes. Readwise also has a CLI so you can do whatever you want basically. Another nice piece that I added into this is a tool like Bright Data or Firecrawl. This allows you flexibility if you find something randomly on the internet. You just paste a link and tell it to grab that and put it into the wiki. (31:49)

Alexey: Bright Data is a platform for proxies and web scraping. (32:18)

Paul: Yes, it basically web scrapes whatever public data you want from whatever you need. It knows how to scrape from LinkedIn and X. It does all that dirty work where it bypasses proxies, blocked IPs, or bot detection and all that mess. It is pretty cheap. I have used it for two months already and I think I used ten bucks in credits. (32:23)

Alexey: You do not have a scale. You probably pay for gigabytes. It is so cheap that I did not even explore their cost proxies because I have the same problem with YouTube. I want to get a transcript, but since my agents live in a data center, YouTube blocks them. What I do is I use a different proxy. (32:50)

Alexey: There you pay per gigabyte. One gigabyte of traffic that goes through the proxy costs eight dollars or something like this. In order to get one gigabyte of transcripts, you actually have to get a lot of videos. (33:15)

Paul: Exactly. It makes sense because I scrape hundreds of links and I spend just a few bucks. (33:33)

Alexey: Firecrawl is something on top of that or what is it? (33:44)

Paul: It is a competitor. It is the same similar thing. (33:50)

Alexey: What are you using? (33:55)

Paul: I do not really use anything like that. I do not even remember the proxy. I just asked GPT which proxy I should use and it was the first one. I configured it once and forgot. I will remember when I run out of credits. (33:55)

Alexey: Exactly. These are probably a layer on top. They are not just a proxy. Bright Data gives you an NCP server and I think they also have a CLI and a skill. You just put that into the harness and you can start scraping whatever you want them to take care of. (34:11)

Resource reranking and context window management for large texts

Alexey: They also curate your data, clean it, and just give you a nice markdown ready to be parsed by the agent. So that is your ingest skill. The first one is the wiki research skill and then the ingest skill. (34:43)

Paul: I have just this research wiki skill basically that has some sub agents. I have other skills that know how to interact with Readwise, Obsidian, and Bright Data. They explain how to use these tools and otherwise it is just very ad hoc basically just getting links. What I also did was add a reranking step. This is really powerful because you get these thirty links or sometimes even more. (34:52)

Paul: You want to rerank them relative to your initial query to sort them a bit and prioritize their importance. (35:24)

Alexey: Let us again think about the use case we have. You are writing an article about creating a coding agent from scratch. You already have some resources. Maybe it is the source code that was leaked from code. Maybe it is something else like Codex. (35:37)

Alexey: Something relevant is there in your wiki. You do your brain dump into this markdown document and then you launch this wiki research skill that uses a deep research algorithm and comes up with thirty plus resources. Then these resources are reranked. You said there is this rerank. (35:54)

Paul: Yes, ranking stuff. They are reranked and all of them are put into the wiki. Reranking is mostly during queries for me to understand their importance. During creation I create the wiki out of all of them. (36:12)

Paul: Then I start querying and talking with this wiki and it basically grows. Sometimes I realize that I need more resources so I can ingest more into it. Basically I start refilling this knowledge base used just for this article. (36:38)

Alexey: For this article you create a kind of mini wiki. It contains a lot of stuff but most of these things are not needed. What you do is you create a mini wiki just for this project for this article. (36:52)

Paul: Exactly. They become linked and from this link you can start asking questions. In my opinion I have around twenty thousand nodes. If you want to create a wiki out of that it will not work. That is already at one hundred plus nodes. (37:04)

Alexey: When you ask me how I burn all these tokens, I decided to use Codex on all the podcast episodes. I wanted to build a wiki. In Codex you get these resets. I did it three times. Imagine in one day it would burn all the weekly limit. (37:31)

Alexey: These resets were going to expire anyway, so I thought I was going to reset them. Another day reset, another day reset, and then there were a few resets just along the way that happened because of some Codex stuff. It took an insane amount of time. It is five years of conversation. (37:58)

Paul: It is heavy. I think that could be valuable. It is not a dynamic thing. It is more like having an archive that you look around and want to cluster or do some data mining. That can be valuable for sure, but personally I would do it a bit differently. (38:17)

Paul: Content styling optimization by lowering LLM reasoning capabilities (38:17)

Paul: In that case I would actually run a knowledge graph extraction algorithm model and some smarter algorithms rather than just dumping everything into Opus and letting it do its own thing. Going back to our example, I have this brain dump and this wiki which we assume has everything that I need. My brain dump explains a very rough idea of how my article wants to look and has some personal thoughts in it. Then I have the wiki with other personal thoughts, experiences, and all the resources. I take this and I compile it into a plan which I call a guideline in this use case. (39:06)

Paul: That plan usually follows a particular structure that I want to convey into an article. This could work for anything else like video scripts or posts. You take it and you map it into a structure of something that you want to express. That plan already contains all the research baked into it. You just take what you need from the wiki and put it into that plan. (39:34)

Paul: This is really important because this is the last step that the wiki exists for your agent. You need to take everything that you need and put it into this plan. After one step I also do reflection on top of it to ensure that the agent took everything that it needs and follows the rules that I put into the skills for structure and other details. This can be automated. I also do some grilling on top of it for more open questions. (40:07)

Alexey: That is another skill, the agree with me skill? (40:40)

Paul: Exactly. For content creation in this use case, I took that actually and adapted it for creating content. (40:47)

Alexey: It helps you identify gaps in the article. (40:52)

Paul: It is more for open ended questions. I usually use reflection for more yes and no questions. For instance, is this structure followed? This is where we can actually pin a right or wrong answer. I use grilling for more subjective answers such as storytelling. (40:58)

Paul: Is this personal experience in the right place? Is the transformation the right thing? For more subjective creation type of things I stay and chat with them and I need to be in the loop. Sometimes it just talks so I do not want to take it that way. I need to be there in that process. (41:17)

Paul: I do this a couple of times. Basically I go through this grilling process. Now I have a plan for what I want to write. Then I take this plan and apply a styling layer on top of it to create basically the final piece. That plan is meant just for the LLM. (41:41)

Paul: I do not care about what words it uses. I mostly care about reasoning everything to be in the right place. For example, similar to coding, ultimately when you do the plan you use Opus Fable. When you apply the styling layer, I found out that if you use models with high reasoning it is worse. Because they reason while they try to write, it increases the probability of bad wording, going off the track, or putting in weird sentences. (42:06)

Paul: You should try this. It is not perfect and still does that, but it is a lot better if you put reasoning low when you write. Sometimes I do not know why it still happens. It includes these meta comments saying it does not need to include reasoning in the article. Reasoning that should be internal becomes a part of the article. (42:42)

Paul: Exactly, if you put the reasoning low it never happens. What I also did for the styling layer is optimize just for how it sounds. All the reasoning is already baked into the plan. The agent does not really need to think, it just needs to map that plan into something that sounds right. I found that using older models for this is better because Anthropic optimizes their models for coding. (43:08)

Paul: They start using these loadbearing verdict type of words. I think the previous Opus models were better at writing than now. (43:46)

Alexey: Exactly. I noticed that it is actually going down. With each new Opus it becomes worse and worse. (43:58)

Paul: Exactly. For writing I use Opus 4.6 or something like that. I think I use a combination of older Opus models and Sonnet for writing. The structure also gives me in the long run the possibility to fine tune my styling layer. Because it is completely decoupled, during planning I can use the best of the best where they just make these beautiful connections between all my resources. (44:10)

Paul: At the styling layer I can own that layer and do something custom. I will probably need to do that because even what I told you is not perfect yet. I still need to edit it usually twice and refine it. Anyway it speeds up the process a lot. (44:39)

Alexey: Especially if you need to write one article per week. (45:01)

Paul: Exactly. This way I can also create better content because it makes all these interesting connections between so many units of knowledge that are scattered around. You can create very interesting connections that otherwise you would not have the time to do. (45:08)

Alexey: How much time does it take for you to write an article end to end right now from the idea to publishing? (45:26)

Paul: Around one day give or take with diagrams and everything. (45:33)

Alexey: So before it would take two or three days. (45:38)

Paul: It depends a lot on the topic. Even now I am working on this bigger series on how to build a coding agent from scratch which is more important to me. Even with this system I spent two days on creating the first article because I want it to be super polished. Without this system probably for this one I would have spent the whole week. (45:44)

Alexey: Okay. You said you have two pools of skills. One is for writing, another is for coding. Writing and productivity type of things. Basically coding and everything else. (46:02)

Multi-agent workflows and personal wikis for software engineering tasks

Alexey: I guess everything else is your content and other things like personal productivity. But then also work. (46:18)

Paul: That is more my personal assistant. (46:30)

Alexey: You also work as an AI engineer. I assume you use a similar system for your work too. (46:30)

Paul: Yes, actually I got inspired by one of your articles and then I started doing it on my own. I do not remember the exact name, but you had an article on your multiple agents and shipping code. (46:41)

Alexey: I published it a couple of months ago. I recently discovered that people started calling it graph engineering. I was wondering why. (46:54)

Paul: I mean that is just normal coding. I guess they circle back to how you do programs. (47:02)

Alexey: So you use something like this for coding. (47:10)

Paul: You could put it that way. Basically I have my process and a workflow coupled with agents. You could say it is graph engineering. (47:16)

Alexey: Do you have any sort of context layer there too? (47:30)

Paul: I use wikis for that as well. (47:38)

Alexey: Because for me the problem is, maybe this is another reason I burn through tokens quite fast compared to you, as the codebase grows it takes more time and more tokens for the agent to discover where the change needs to happen. I assume if you have a wiki it helps to find the correct place faster. (47:38)

Paul: I use a wiki more for whenever you want to ship a new feature. I use the wiki to support that new feature. It helps guide what algorithms to pick or functions to guide in how to actually implement something that does not exist yet. It is not necessarily to parse what already exists. For that I use just ADRs and a glossary. (48:03)

Paul: The ADR basically tracks all my design decisions over time and I try to keep them as small as possible. (48:33)

Alexey: Architecture decision record, correct? (48:40)

Paul: Exactly. They are baked naturally into my process. Whenever I ship a new feature, it first creates an ADR coupled with my tickets that need to be shipped. I also keep track of a glossary. It does not need to reason all the time on top of these architectural decisions and the glossary on how to actually parse the whole codebase. (48:40)

Paul: I think that is the trickiest part, but I try to modularize as much as possible to create very targeted actionable modules using some sort of clean architecture. I do not do it too hardcore. I saw people build graphs on top of code bases that speed this up, but I never experimented with this. I do not think that is a good idea to be honest. It is similar to documentation and comments that get unsynced with your code. (49:04)

Paul: Whenever your documentation or your graph on top of your code gets unsynced, you spend more tokens syncing your code with your graph. Ultimately your code is your source of truth and the code itself is a graph, so you need to structure it the right way. (49:41)

Alexey: Do I understand correctly that for coding the steps are similar? You first have some kind of deep research agent that goes through all the nodes you have like ADRs and these kinds of things. Then it ingests them to create a wiki that you can talk to. When you say you want to implement a feature and these are possible options to implement it, they are in the wiki so you can talk to this wiki. (50:00)

Paul: Yes, and refine my plan. Basically that is how I refine the plan that needs to be implemented. I do not put the ADRs and the glossary into the wiki. The wiki contains just external research. Basically the ADR and the glossary are part of the code. (50:37)

Paul: I treat them like part of my current code which the agent knows to look around when it looks around the code. The wiki contains external resources. For example, for this course that I am building, I put in a wiki the code from Claude code, Aider, Open Interpreter, and Pie. I index everything into the wiki plus other notes and videos around this topic. Whenever I wanted to implement a new feature, I just use that wiki to refine my plan. (50:56)

Paul: I ask how each harness implements this particular thing and to explain it to me. Then I did my own thing that made sense for me and refined my plan around that. Whenever I shipped the tasks, they were already really refined. The agent already knew the exact architectural decisions it needed to take, the algorithms, the interfaces, and everything it needed to ship. It is very targeted. (51:29)

Alexey: So the steps are in both cases research, create wiki plan, and then build on top of that. This is for both coding and article creation. (51:51)

Paul: Yes, some implementation details differ. I think the plan and the research now is all the value. How we execute that plan, especially for coding, is a solved problem. Agents are really good at executing these plans as long as the plan itself is good. (52:07)

Personal wiki scaling for enterprise knowledge bases and book writing

Alexey: At the beginning you mentioned that you are building something similar, but instead of having your personal second brain you want to understand how to build it for companies. Can you tell us more? (52:32)

Paul: This idea is very at the beginning so I do not have many details. There is this new concept of a company brain. It is basically what I talked about, but not for one person, it is for the whole team or organization. (52:43)

Alexey: They have a wiki like a Confluence portal with a ton of information. (53:01)

Paul: Exactly. The challenge is how we integrate that with the agent and how we make it context efficient to actually reason on top of it. Very often you do not have everything nicely organized into Confluence. You have Slack messages, emails, Google Drive stuff, code, and a ton of other things. You have this context layer. (53:08)

Paul: It is about how you create your context layer. Companies have started to implement this. I recently tested something from Pinecone, I think it is Nexus, their new tool. Basically they allow you to ingest all of this into their platform and they create a wiki out of it. It is exactly what I presented so far but at an enterprise scale. (53:34)

Alexey: The reason I am asking is I am doing something similar. Data Talks Club has existed for quite some time and all the processes we have internally are documented inside Google documents in Google Drive. It makes it not very easy for an agent to take over. I am thinking how I can automate something and it is just not the right format. Right now I am creating markdown documents because for agents like Claude code it is much easier to go through markdown documents in your file system rather than going to Google Drive. (54:01)

Alexey: The first step of putting everything in markdown documents is done. I like this idea of a wiki because many processes are connected. For a podcast there is a certain process that we follow and they are very connected, so it makes a lot of sense to actually create a wiki from that. (54:49)

Paul: Yes, it is very easy and I started refining it. For example, this idea of knowledge graphs, you can very easily create a knowledge graph within the wiki. You have entities and concepts and you can very easily create relationships between these. Recently I started expanding the idea of a wiki for books. I am writing a book and I try to understand how complicated it is to remember in chapter ten what you have written in chapter three. (55:07)

Alexey: You have the big idea but keeping track of all the details and concepts is hard. Is it a tech book? (55:38)

Paul: Yes, it is on how to build a personal assistant from scratch. (55:50)

Alexey: Where can I sign up? (55:56)

Paul: It is still very early. We are doing it with Manning and hopefully we can ship it in their MEAP program. (55:56)

Alexey: If you need a reviewer, you can let me know. (56:09)

Paul: Awesome, I will let them know. We are just wrapping up chapter two, so we are really early. (56:14)

Alexey: For a technical book it is a problem but maybe less of a problem than something like Game of Thrones. You really need to remember who said what. (56:20)

Paul: Exactly. Actually I started thinking about this because I have a friend who is writing a twist on Game of Thrones just from passion. He asked me how he can use Claude code better for writing because he saw that when he started writing chapter two, Claude code goes off the rails. He is not an engineer and has nothing to do with engineering. I started to explain this idea of how you can create a wiki with your characters and plot twists. (56:34)

Paul: I explained how you can put links in every chapter to understand which characters appear and what plot twists occur. I realized I can actually use this for my book as well. (57:15)

Alexey: I tried it with popular science books where you do not have this character development. You do not need to have this wiki and the usual approach of plan and execute works fine. You plan the outline, then within each chapter you plan exactly what you are going to put in it. A sub agent can work on each individual chapter and then at the end the book makes sense. There is no repetition because there is already this detailed plan. (57:28)

Alexey: This is not a science fiction book where characters and plots are important. This is just popular science. For example, we had a book with my son about metals. Each metal is a chapter so you do not need to overthink this. (58:06)

Paul: You are right. For technical books it is somewhere in the middle. The thing is that it is very easy to create a wiki out of this. It took me two hours or something like that. Because I had all this structure in mind, adapting it was pretty easy. (58:25)

Alexey: Do you write about creating a wiki for books in your book? (58:43)

Paul: I am thinking about it. I did not want it at the beginning, but we have a big chunk on memory. I think using a wiki as memory is really something I will introduce. I will talk about how I use this to write this particular sentence. (58:43)

Alexey: I am checking the questions that we plan to cover. I think we managed to nail some of them. For me I was asking you completely off the script because I really liked how our discussion started and it just naturally flowed into this. Thanks a lot for joining me. I did not even notice how one hour passed by because it was super quick. (59:08)

Alexey: I think it always happens when we talk. (59:31)

Paul: Same here. This is a topic that I am really passionate about so I can talk for another two hours without a problem. (59:31)

Alexey: Thanks Paul. Thanks everyone for dropping by. At the beginning I forgot to mention that there is this Slido link where people could ask questions. Nobody asked questions, but it is a good thing because I could ask you all the questions I had. If I missed your question somehow I apologize. (59:44)

Alexey: I hope everyone knows how to find you, Paul. (1:00:05)

Paul: Yes, I have a video on this topic that I submitted and got accepted as a keynote at the AI Engineer World Fair. I also have an article and open source GitHub repositories around this wiki idea. I think I have this article on Decoding AI. I have this "Your Second Brain is a Graveyard, Make it Agent Memory" article that contains links to everything else. (1:00:05)

Alexey: Please send us this link. I will include this link in the description and if anyone is interested you can just find this in the description too. If we just google what you mentioned the title it should be your article. (1:00:46)

Alexey: Thanks a lot, Paul. (1:01:04)

Paul: Thank you Alex for inviting me. I had a great time. (1:01:04)

Alexey: I think we soon will have a workshop next month. Not on wikis unfortunately. Why unfortunately? Maybe we can change it. (1:01:09)

Paul: We can actually if you want. We can talk offline. That is a good idea. (1:01:22)

Alexey: Okay. (1:01:28)