LLM Meets You for the First Time Every Session — That’s Why Documentation Is Strategy
When background explanations started piling up like a tax, I started writing CLAUDE.md
When I first learned about LLMs, someone told me “they have no memory.” I just nodded and moved on. But once I actually started using Claude Code on a real coding project, I felt what that really meant in my gut.
It was a day I was building my stock app. I opened a new session, sent the first message, and got back: “Can you explain what this project is?” We’d spent two hours the day before nailing down the architecture together — the reasons behind the DB schema choices, the directions we’d abandoned, the notes on what went wrong — all gone. At first I just copy-pasted my way through it. “This project does X, here’s what we’ve done so far, and yesterday we decided Y.” But as this kept repeating, the frustration slowly built. The background explanations were piling up like a tax.
What I expected: just a minor annoyance. What it actually was: a fundamental design of LLMs
I thought of this as a simple inconvenience at first. But it turns out this is how LLMs fundamentally work. When a session ends, the LLM doesn’t carry any memory. The Claude in the next session isn’t the same Claude from before. It starts from a completely different context.
If you treat this as “an unavoidable constraint,” you stop there. But look at it differently and it becomes a question: “What if I could make things work even though LLM meets me fresh every time?”
That answer was CLAUDE.md.
Documentation becomes the LLM’s memory
Claude Code has a feature where if you put a CLAUDE.md in the project root, it’s automatically read when a session starts. In the 4-lever method, this CLAUDE.md is treated as the first lever for controlling the agent. At first I only put in things like coding conventions. But at some point I started adding other things too. “This project is currently in this state.” “This decision was made for this reason.” “I tried this and gave it up because of that.”
And then the LLM suddenly became someone who knew things. I could open a new session and pick up right where I left off, no background recap needed. That felt surprisingly powerful.
But there was a painful lesson too. I figured more was better and kept adding stuff, and at some point I started noticing the LLM was following the beginning carefully but glossing over the later parts. It was overloaded. So I trimmed it back down. That’s when I learned something: documentation is about density, not length. Only what the LLM can actually read right now has value.
The minimal pattern that survived
After trying a lot of things, the structure that survived was simple. index.md (what’s the current state), log.md (what’s been done), todo.md (what’s next) — just three files. I turned this minimal pattern into a Claude Code skill to automate it, and that’s covered in /docs-init skill.
Of those, index.md is the core. It’s the handoff note you give to the LLM in a new session. “This project is at this stage, there was a recent decision about this, and this is what we’re currently working on.” Enough to get up to speed in under a minute.
And what’s interesting is that this isn’t only useful for LLMs. When I came back to a project after six months and needed to figure out “wait, what was I doing here?” — it worked exactly the same way. Ultimately, passing context to the next session’s LLM was the redefinition of documentation. Not writing for some future reference, but infrastructure to keep the work continuous.
I ran into the same problem outside of coding
While planning myWiki, something came up in a conversation: “Having to lay down all the background again in every new chat is genuinely painful.” This was item four on the list of requirements for the coding project. Written down as a problem to solve.
That’s when I saw that what I’d solved in the coding project was actually a much broader problem. Interests, ideas, planning conversations — those were all fragmented the same way, and I had to re-explain the background every new session too. I tried using GPT Projects, but even with projects separated and sessions separated, it would sometimes pull in context from other projects. That’s when I first used the phrase “context contamination.”
The journey through 나만의-세컨드브레인-설계-결정 and into 에이전트-컨텍스트-끊김-second-브레인-통합 was really the process of taking the problem I first ran into in coding and expanding it to knowledge in general.
In the LLM era, documentation has a different audience
The old concept of documentation was about “referring back later” or “handing off to teammates.” That’s why it always felt like a tedious chore.
In the LLM era, documentation has a different audience. It’s about supplying context so the AI doesn’t make mistakes from missing background right now. When this framing shifts, so does the motivation. It’s not “someday in the future” — it’s “if I don’t write this, the AI is wasting my time right now,” and that’s what actually gets you to write.
The Atlas concept had an expression that captured this perfectly: “The pain is context evaporating at the seams.” Between sessions, between tools — that’s where context disappears, and that’s the real problem. Documentation is what fills those seams.
The simplest place to start is a single index.md. “What state is this project in right now?” — one paragraph, three to five lines. It becomes the first briefing you hand the LLM the next time you open this project.
Background: Second brain design decisions · Method: /docs-init skill · CLAUDE.md 4-lever · Deep dive: Agent context loss problem · Context spine idea · See also: myWiki origin story · Second brain as content engine