It’s Tuesday, February 24th, 2026. I’m not entirely sure what to title this post yet, but it revolves around learning, building tools, and the sometimes uncomfortable reality that understanding a problem often requires wasting a lot of AI credits.
As I get older, I’ve started noticing something about myself: my memory isn’t what it used to be. It’s harder to remember the context of things I learned a few weeks ago, and sometimes even harder to reconstruct how I solved a particular problem. Another challenge I deal with is organization, especially when it comes to personal projects. Some people would say I’m organized, but I tend to disagree. I always feel like I’m trying to improve my system, trying to find a better way to track what I’m learning and what I’m building.
A big part of my learning process comes from watching YouTube videos. Most of the content I watch is educational, or at least that’s what I tell myself. While watching these videos, I often take notes. Sometimes those notes end up in random text files, sometimes they go into sticky notes on my computer, and occasionally they land in some kind of structured document. The problem is that everything is scattered. What I really want is a simple workflow: watch an educational video, take notes, and have those notes automatically stored somewhere searchable and organized.
That idea led me to experiment with building a Chrome extension. There are already tools that do something similar. For example, the OneNote browser extension lets you capture content and store notes while browsing. It works well enough, but I wanted something tailored specifically to how I think and how I learn.
The extension worked pretty well at first, but I ran into an interesting problem with YouTube. The way YouTube loads pages—especially when navigating between videos or scrolling through Shorts—doesn’t always fully re-render the page the way you might expect. In technical terms, you end up with differences between the virtual DOM and the real DOM. What you see on the screen might be updated, but the stored page data still reflects the previous video. So if a script tries to grab the title of the video after you scroll to a new one, it might still return the title from the previous video.
I could have spent time digging deeply into that problem, but honestly, it wasn’t worth it. The easier solution was simply to refresh the page and then grab the content again. The URL always updates correctly, so forcing a refresh ensures you’re pulling the correct information. It’s not elegant, but it works, and sometimes that’s good enough.
Once I got that working, it sparked another idea. If I can capture browser activity, could I capture other things I do on my computer as well? For example, could I record browser history, terminal commands, or file events so I can reconstruct how I solved problems later?
That idea immediately raises privacy concerns. You don’t want to accidentally store secrets, API keys, or other sensitive information. But from a purely technical perspective, collecting this data isn’t that difficult. Browsers typically store history in SQLite databases on the system. Terminal command history is also accessible. File events can be tracked with existing system tools.
The tricky part is that not everything is straightforward. Commands run inside IDE terminals, like those in VS Code, are often sandboxed in ways that make them harder to capture. Sometimes the system will only show that you launched the IDE itself rather than the commands executed within it. There are ways around that, but they add complexity.
Even so, I built a simple internal tool that collects basic activity data: browser history, command history, and some file events. Nothing fancy—just enough to get a rough picture of what I’m doing on my machine.
That’s when I ran into an interesting realization. I had always assumed that about half of my YouTube viewing time was educational. Looking at the data, that assumption was completely wrong. It turns out that educational content probably makes up something closer to five percent of what I watch, maybe a little more on good days. The rest is mostly short videos and random entertainment. Even though I still watch more educational content than the average person, the ratio wasn’t even close to what I imagined.
That realization changed how I think about note-taking systems. If most of the content you watch isn’t worth saving notes for, then automatically generating notes for every video doesn’t make much sense. Instead, the system should be more selective. Maybe it should capture metadata for everything, but only generate notes for videos I explicitly mark as important.
This also ties back to the cost of using AI models. Building these tools required a lot of tokens. Some people might say that’s wasteful. But in my experience, sometimes you have to spend credits just to understand the problem properly. Before I built the system, I thought I needed to capture everything. After building it, I realized that capturing everything creates too much noise. The real value comes from filtering and focusing on the signals that matter.
There are already tools that try to capture everything you do on a computer, indexing activity every few seconds. But storing everything isn’t necessarily useful. Most of the time, you don’t need your entire browsing history or every command you’ve ever typed. What you really want is a tailored system that captures the specific kinds of information that help you learn and remember.
I’ve started to think about this as two different approaches. One approach is to automatically capture and summarize everything, letting AI decide what matters. The other approach is more intentional: capture basic metadata in the background, then review it later and choose what deserves a deeper summary. Right now, I think the hybrid approach is probably the most practical.
What this experiment reminded me of is something that’s easy to forget in the age of AI tools. We spend a lot of time thinking about systems and architectures, but real understanding usually comes from building something and seeing what actually happens. The act of writing the code, pulling the data, and dealing with the edge cases forces you to confront reality.
Sometimes the biggest lesson isn’t the tool you built. It’s the fact that the assumptions you started with were wrong.