Are you accumulating “articles to read later” or “technical notes” in Notion or Obsidian? And is the maintenance of that “second brain” stealing precious CPU time from your life?
For engineers, logs that are never read back are not “assets”—they are “technical debt”.
I have worked with various technologies for many years. Once, I too believed that recording everything I learned and organizing it into a searchable state was the right thing to do.
However, with the practical application of AI (LLMs), that premise has collapsed.
The reality is that rather than searching through incomplete notes written by your past self, passing the “current” context to an AI and having it generate the latest optimal solution JIT (Just-In-Time) is overwhelmingly faster and the quality is often better.
In this article, I want to talk about a concept I call “Stateless Engineering”.
This is a technical strategy for “having nothing”—where information is not persisted in the brain or storage, but instantiated only when needed.
If you are drowning in a growing wave of information and feel crushed by the debt known as learning costs, this article might be the git reset --hard you need to put down that burden.
Why Logs Become “Technical Debt”
In software development, “technical debt” refers to the future cost of rework that arises from choosing short-term solutions. Personal notes and logs have the same structure.
1. Information Expiry and Maintenance Costs
Are the notes on “React environment setup procedures” you wrote three years ago still valid today? Likely, library versions have increased, deprecated syntax is included, and they probably won’t work as-is.
Continuing to manage this in a personal knowledge base (like Obsidian or Notion) incurs the following costs:
- Search Cost: Old and new information are mixed, making it time-consuming to find the correct answer.
- Cognitive Cost: The pressure of “I need to organize this” constantly occupies your brain’s memory.
- Fallacy Cost: The risk of implementing something based on old notes and creating bugs.
When you see “unused, commented-out code” in a code review, what do you do? You say, “Let’s delete it”. Life’s logs are the same. “Unmaintained information” is “trash”, just like commented-out legacy code.
2. Applying the YAGNI Principle to Life
There is a principle in agile development called “YAGNI (You Ain’t Gonna Need It)”. It teaches: “Don’t add functionality until it is actually necessary”.
Many engineers think this way when taking logs: “I should record this because it might be useful someday”.
This is “over-engineering”. There is a 99% probability that information will never be read again. If it is truly important information, it will either stay in your brain without recording, or the latest documentation will exist on the web the moment you need it.
A system design that decides “I’ll think about it when it’s necessary” rather than recording out of anxiety is what maximizes brain performance.
3. Why “Generation” Costs Less Than “Searching”
In the past, forgetting was scary. To reach an answer via Google search, you needed appropriate keyword selection and noise filtering. That’s why there was economic rationality in caching (noting) the correct answer once you found it.
However, the arrival of LLMs (ChatGPT, Claude, Gemini) changed the rules of the game.
- Traditional: Search static logs (
SELECT * FROM memories WHERE ...) - Current: Dynamically generate by providing context (
generate(context))
For example, instead of noting how to solve a specific error, if you just throw the “error log” and “code snippet” to an AI, a fix based on the best practices of that moment will be output in 10 seconds.
The time to ask an AI and have it regenerate (computation cost) has become overwhelmingly cheaper than the time to find your own note from three years ago (search cost). This is the technical basis for why I recommend “stateless” management.
Specific Ways to “Discard” and AI Techniques
So, what should you do specifically starting tomorrow? The “Stateless Workflow” I propose is simple:
-
Discard Thinking Logs Immediately: Notes on the process of struggling or trial and error should be
rm -rfthe moment they are resolved. Only the “result (committed code)” should remain. -
Don’t Create Learning Notes: Don’t try to summarize things systematically. Official documentation is always the latest textbook. Implement what you’ve understood as code and leave it on GitHub. As long as you have the code, AI can explain it to you anytime.
-
Journals are for “Freeing RAM”: I recommend journaling, but don’t save it. Write it on paper and throw it away, or use auto-delete settings if digital. The purpose of writing is not “recording” but the “process” of clearing the brain’s cache memory.
Conclusion: Free Your Brain’s Memory
While storage capacity has become cheap, human “attention” remains a finite and expensive resource.
Don’t use your precious CPU to manage past logs.
Discard the past (logs), master external processing units called AI, and always tackle current problem-solving with full power.
I am convinced that this is the survival strategy for engineers living in the coming era.
In this article, I explained the theoretical side of the “strategy for not letting journals and notes become technical debt”.
I have published specific prompts on note (Japanese) that apply this thinking to daily thought organization and use AI to forcibly make your “brain stateless”. If you want to skip manual trial and error and move straight to practice, please check it out.