You shipped the feature. The PR merged. The Figma file got handed off. The PM closed the ticket. Done, right?
No. Not even close.
Here is the uncomfortable truth that most teams are ignoring: if your work cannot be understood, queried, and built upon by an LLM, it is not done. It is abandoned.
The old definition of done was built for humans only
For decades, "done" meant something like this: the design is signed off, the code is deployed, the stakeholders are happy, and the Jira ticket moves to the right. Maybe someone writes a confluence page. Maybe they don't. Either way, the knowledge about why that feature exists, what was tried and rejected, what user research informed the decision, lives in one place: someone's head.
That is tribal knowledge. And tribal knowledge has an expiration date. The person leaves. The Slack thread gets buried. The context evaporates.
We have tolerated this for years because the only consumers of that knowledge were other humans, and humans are pretty good at tapping someone on the shoulder and asking. But the shoulder tap does not scale. And now there is a second consumer of your work that cannot tap anyone on the shoulder.
I built this system live. Watch the full walkthrough here:
The new consumer: your LLM
Every team I work with now uses an LLM somewhere in their workflow. Cursor for code. Claude Code for builds. ChatGPT for research. Copilot for pull requests. The tools vary, the pattern does not: people are pointing AI at their work and expecting it to understand.
But here is the problem. When that LLM tries to understand your project, what does it find? A Figma file with no annotation. A codebase with no architecture decision records. A product spec from six months ago that never got updated after the pivot. A design system with no documented rationale.
The LLM cannot tap anyone on the shoulder. It can only read what you wrote down. And most teams write down almost nothing.
This is why Andrej Karpathy's LLM Wiki concept, which went viral this week, resonated so hard. Karpathy described a system where you feed raw material (articles, research, documents, transcripts) into a folder, and an LLM compiles it into a structured, interlinked wiki. No vector databases. No complex infrastructure. Just markdown files that compound over time.
The concept is simple: stop relying on your memory. Start building a knowledge base that an LLM can actually navigate.
What Karpathy's wiki exposes about how we work
I built this system live on my channel using Claude Code and Obsidian. The setup takes minutes. You create a vault, drop in your raw files, paste Karpathy's gist into Claude Code with a short prompt, and the LLM builds the entire wiki structure: index, log, entity pages, relationships, everything.
But the interesting part is not the tooling. It is what the process reveals about how badly we document our own work.
When I pointed Claude Code at my YouTube channel's transcripts, around 60 of them, it built a knowledge graph that surfaced connections I had never consciously made. Topics I kept returning to. Contradictions between what I said in one video versus another. Gaps where I had strong opinions but zero supporting evidence.
That is what happens when you make your knowledge machine readable. The machine reads it. And it finds the holes.
Now imagine this at a team level. A designer ships a component. A PM ships a feature. An engineer ships an API. Each person's "done" is isolated. The designer's rationale lives in a Figma comment. The PM's reasoning lives in a Google Doc that three people have access to. The engineer's context lives in commit messages that nobody reads.
None of this is queryable. None of it compounds. None of it survives the next reorg.
The new definition of done
Here is my argument, and I know it will be controversial: in 2026, "done" needs to include documentation that is structured for LLM consumption. Not just human consumption. Both.
For designers, that means: your design system documents, component decisions, brand guidelines, user research notes, interview transcripts, UX teardowns, and critique feedback should live in a single, queryable knowledge base. When a new designer joins the team, they should be able to point an LLM at that knowledge base and get onboarded in hours instead of weeks.
For product managers, that means: your PRDs, decision logs, stakeholder interview notes, sprint retros, OKRs, metrics, customer feedback, NPS scores, and competitor teardowns should be in one place. Not scattered across Notion, Google Docs, Confluence, and someone's personal notes app. When the next PM picks up your product area, they should be able to query the LLM and understand not just what was shipped, but why.
Think about what that actually means. It means "done" is not just the artifact you shipped. It is the artifact plus the reasoning, documented in a format that both humans and machines can traverse.
If you shipped the feature but the "why" only exists in your head, you are not done. You are a single point of failure.
Why knowledge graphs change everything
There is a reason Karpathy's system uses interlinked markdown files and not a flat folder of documents. The structure matters. The relationships between pieces of knowledge are often more valuable than the pieces themselves.
When I ran the ingest on my YouTube transcripts, the LLM did not just create 15 isolated summary pages. It created a graph. Concepts linked to other concepts. Entities referenced across multiple sources. Relationships that I, the person who created all of that content, had never explicitly drawn.
This is the fundamental insight behind knowledge graphs: information in isolation is data. Information with relationships is knowledge. And knowledge compounds in ways that data never can.
Think about how a traditional design system works. You have a component library. You have usage guidelines. You have accessibility notes. Maybe you have decision logs explaining why a certain component was built a certain way. In most organizations, these live in separate tools, maintained by separate people, with no explicit connections between them.
Now imagine all of that ingested into a wiki where the LLM has built relationships between the component, the user research that informed it, the accessibility standard it satisfies, the sprint retro where the team debated the interaction pattern, and the customer feedback that triggered the redesign. That is not a design system. That is a design knowledge graph. And when a new designer joins and asks "why does our modal work this way?", the LLM does not just retrieve a usage guideline. It traces the full chain of reasoning.
This is what Obsidian's graph view makes visible. You can literally see clusters of tightly connected knowledge, isolated nodes that should be linked but are not, and structural gaps where your team has strong opinions but weak documentation. The visual representation alone surfaces problems that no amount of Confluence searching would reveal.
The same principle applies to product work. A PM's decision to prioritize feature A over feature B involves competitive analysis, customer interviews, metrics, stakeholder input, and strategic alignment. In most teams, that decision lives as a single line in a roadmap tool. The reasoning behind it is scattered across five tools and three people's memories. In a knowledge graph, all of those inputs are linked to the decision node. The "why" is not just documented. It is structurally connected to everything that informed it.
This is not academic. This is practical. When your LLM has access to a knowledge graph instead of a flat folder, its answers go from generic to specific. It stops saying "best practices suggest..." and starts saying "based on the user research from Q2 and the decision log from sprint 14, this component was designed to..."
That is the difference between an LLM that sounds helpful and an LLM that actually is.
The second brain is not a personal productivity hack
The "second brain" concept has been around for years, popularized by Tiago Forte and the personal knowledge management community. But most people think of it as a note-taking system. A way to organize your Evernote or your Notion. A personal productivity hack.
That framing is too small for what is happening now.
When Karpathy described his system, he was not talking about personal note-taking. He was describing a fundamentally different relationship between a human and their accumulated knowledge. In his setup, the LLM has built and maintains a wiki of over 100 articles and 400,000 words from his research. He rarely edits it directly. The LLM writes, updates, links, and maintains the entire thing. His role is to feed it raw material and ask it questions.
This is not a note-taking app. It is an externalized, queryable, self-maintaining extension of your professional memory.
And the implications for teams are enormous. Consider what happens when every designer, every PM, and every engineer on a team maintains a second brain that feeds into a shared wiki. The team's collective knowledge stops being trapped in individual heads and starts existing as a persistent, queryable artifact.
New hire onboarding goes from "shadow Sarah for two weeks" to "point your LLM at the team wiki and ask it anything." Post-mortem insights stop being a Google Doc that nobody reads and start being connected nodes in a knowledge graph that inform every future decision. Design critique feedback stops evaporating after the meeting and starts compounding into a searchable body of design reasoning.
The second brain concept matters here because it reframes documentation from a chore into an investment. Every raw file you drop into the wiki, every transcript, every research note, every decision log, makes the entire system smarter. The knowledge compounds. The connections multiply. The LLM gets better at answering questions about your work because there is more context for it to draw from.
This is compounding returns applied to organizational knowledge. And like any compounding system, the teams that start early will have an exponential advantage over those that start late.
The gap between how we work and how LLMs work
Here is a problem most teams have not thought about yet. LLMs do not work the way humans work. Humans can hold ambiguity, read between the lines, infer context from a half-finished Slack message, and fill gaps with institutional memory they have absorbed over months of working in the same building. LLMs cannot do any of that.
An LLM reads what you give it. Literally. If your design system documentation says "use the primary button for the main action" but does not define what constitutes a "main action" in your product's specific context, the LLM will give you a generic answer. If your PRD says "we decided to go with option B" but does not explain what option A was or why it was rejected, the LLM cannot reconstruct that reasoning.
Most documentation is written for humans who already have context. It assumes shared understanding. It relies on the reader knowing who "the team" refers to, what "the incident" was, and why "that approach" was rejected. These are invisible references that a human colleague can decode but an LLM cannot.
This is why a wiki with explicit relationships matters so much. When the LLM builds the knowledge graph, it forces implicit knowledge to become explicit. Every entity gets a page. Every relationship gets a link. Every decision gets connected to its inputs. The ambiguity that humans navigate effortlessly becomes structured knowledge that machines can traverse.
Karpathy's gist includes tools for exactly this problem. The health check scans the wiki for unlinked entities, concepts that are mentioned but never defined, references that point nowhere. The lint pass finds inconsistencies, articles that contradict each other, claims that lack supporting sources. These are not just maintenance tools. They are quality controls on your team's collective knowledge.
And here is the part that should make you uncomfortable: if you ran a health check on your team's existing documentation right now, how many gaps would it find? How many undefined concepts? How many decisions with no recorded reasoning? How many references to conversations that happened six months ago and were never written down?
That gap between what your team knows and what your team has documented is the exact gap that makes your LLM useless.
From personal wiki to team knowledge infrastructure
One concern I hear often is: "This is cool for one person, but how does it work for a team?" Karpathy's original system is local. One person, one vault, one LLM.
But the solution is straightforward. Put the wiki in a GitHub repository. Everyone on the team can contribute raw files. When someone has a new research finding, a meeting transcript, a design decision, they drop it into the raw folder and push. Then anyone on the team can run the ingest, and the LLM updates the shared wiki with the new information, linking it to everything that already exists.
This is exactly what I have done with my own YouTube channel wiki. The raw files, the images, the entire compiled wiki lives in a repository. If I had collaborators, they could contribute to the same knowledge base. The LLM handles the compilation. The humans handle the curation.
For teams, this means the wiki becomes a living artifact that grows with every sprint, every research round, every design review. It is not a documentation project that someone has to champion. It is a byproduct of doing the work, as long as you build the habit of capturing the reasoning alongside the output.
The GitHub model also solves the versioning problem. You can see what was added when, by whom, and how the LLM integrated it into the existing structure. You have full history. You have accountability. And you have a knowledge base that no single person's departure can destroy.
"But we already document things"
No, you don't. Not really.
Most teams have documentation the same way most people have a gym membership. It exists. It was set up with good intentions. Nobody uses it consistently.
And even when documentation exists, it is almost never structured for LLM consumption. It is buried in tools with terrible search. It is written in a format that assumes the reader already has context. It is never updated after the initial write.
Karpathy's wiki pattern solves this because the LLM maintains the structure. You do not have to be disciplined about formatting or linking. You drop raw material in, and the LLM does the compilation. It creates the relationships. It maintains the index. It runs health checks to find gaps and inconsistencies.
The discipline you need is simpler: make a habit of capturing your reasoning, not just your output.
The tribal knowledge problem is now an AI problem
Here is where this gets urgent. Teams are already using LLMs to make decisions. Engineers ask Cursor about the codebase. PMs ask Claude to analyze user feedback. Designers ask ChatGPT about accessibility patterns.
But those LLMs are operating with incomplete context. They do not know your company's design principles. They do not know why you chose that specific API architecture. They do not know about the user research that killed the original feature direction.
So the LLM gives generic answers. And people ship generic work. And then everyone wonders why AI is not delivering on its promise.
The problem is not the AI. The problem is that your organizational knowledge is inaccessible to it.
What to do about it
This is not theoretical. You can start today.
Set up an Obsidian vault. Install the Web Clipper extension. Open Claude Code in the vault directory. Paste Karpathy's gist with a simple prompt, and the LLM will build your wiki structure in minutes. Then start feeding it: design specs, meeting notes, research findings, decision logs. Everything you would want a new team member to know.
The repo for the setup I demonstrated is public: github.com/julianoczkowski/karpathy-llm-wiki
Once you have the wiki, you can plug it into anything: Claude projects, Cursor, Windsurf, Copilot. It is just files. That is the beauty of it. No vendor lock-in, no complex infrastructure, no monthly subscription. Just markdown that compounds.
And once you start, the benefits compound fast. Each new source you ingest does not just add one more document. It adds connections to every existing document. A user research transcript from today links to the design decision from three months ago, which links to the competitive analysis from last quarter. The knowledge graph gets denser, richer, and more useful with every addition.
This is why I think about the wiki less as a tool and more as a habit. The same way a developer commits code daily, a designer or PM should commit knowledge daily. Not polished documentation. Not formatted reports. Just raw reasoning, dropped into a folder, compiled by an LLM that never forgets.
The teams that build this habit will have a structural advantage that grows over time. Their LLMs will give better answers because they have better context. Their new hires will onboard faster because the institutional memory is queryable. Their decisions will be more consistent because the reasoning behind past decisions is always accessible.
The teams that do not build this habit will keep losing knowledge every time someone goes on holiday, changes teams, or leaves the company. They will keep asking the same questions, making the same mistakes, and wondering why their AI tools give such generic output.
The uncomfortable question
Next time you close a ticket or hand off a design, ask yourself: could an LLM reconstruct the reasoning behind this decision from what I have documented?
If the answer is no, you are not done.
The definition of done in 2026 is not just "shipped." It is shipped, documented, and queryable. By humans and machines alike.
The teams that figure this out first will compound their knowledge. The teams that don't will keep starting from scratch, every sprint, every hire, every reorg.
Your choice.
Julian Oczkowski is a designer with 29 years of experience, including work with Adobe, IBM, and Danone. He runs AI For Work, a YouTube channel focused on practical AI workflows for designers, PMs, and engineers.
Watch the full LLM Wiki build tutorial: youtu.be/lnsExa1UbnM
Subscribe for weekly AI workflow tests: youtube.com/@aiforwork_app
Tags: AI, Second Brain, Product Management, UX Design, Product Design
Top comments (1)
Julian . "you are a single point of failure" landed harder than expected.
I've been sitting with the same problem from a slightly different angle: not team documentation, but personal AI sessions. I have Claude
conversations that run 8,000–10,000 lines — architectural decisions, debugging dead ends, the reasoning behind choices I'd already forgotten I made. Theoretically captured. Practically useless.
You mention Karpathy's wiki approach, and that's actually what finally pushed me to act on this. I built something small that converts those raw session dumps into structured Obsidian notes: auto-summary, collapsible turns, a full transcript layer underneath. First time I could point a new
Claude session at a specific decision from three months ago, the quality of its output was immediately different. Less re-explaining. Richer answers.
What your article clarifies for me: I was framing this as a retrieval problem. "Compound knowledge returns" reframes it as a compounding problem.
Every session that isn't structured isn't just one lost artifact — it's a missing node in a graph that should have been building.
Where I'm still unsure: your health check question — "could an LLM reconstruct the reasoning?" — how do you handle sessions where the reasoning
was genuinely emergent? Where the conversation was the thinking, not a record of thinking that happened elsewhere?