Not because shared context stops mattering, but because documents are becoming the wrong place to maintain it.
I have been living in the personal knowledge management space for quite a few years now.
For my personal life, I first relied on Tana Outliner, and now on Tana. It fits the way I think. It lets me connect things, structure them, and maintain a personal system that is flexible enough to evolve with me.
Professionally, the situation has been different.
In the teams I manage, collaboration matters more than personal elegance. We work inside the Microsoft ecosystem. We collaborate extensively with colleagues. And Tana Outliner, at least at the time, did not really lend itself to that kind of shared, operational environment.
So for parts of my professional work, I relied on Notion. Over time, that Notion setup became more than a place to store notes. It became a system. Multiple databases connected to each other. Templates for campaigns, events, and projects. A way of working that reflected how the team actually operated. At some point, we got into conversations with the global marketing team at HSO about taking that setup beyond my own teams. The idea was that this system could become the system of choice for HSO marketing worldwide. That was flattering, of course. But it also created a very practical problem. If this system was going to be used globally, it needed documentation. And my immediate thought was: well, shit.
Because documenting a system like that is not a small task. You have to explain the structure. The databases. The relationships. The templates. The intended workflows. The edge cases. The “how do I create a project?” questions. The “what is the difference between a campaign and an event?” questions. The things that are obvious to the person who built it, but completely opaque to someone entering it for the first time.
Then, one Friday afternoon, I was sitting at my daughter’s swimming lesson. I had some time to kill, so I opened Claude. Not even a specialized workflow. Just an ordinary Claude chat, connected to my Notion environment through MCP. I asked it a simple question: could it access the Notion environment?
It could.
So I asked the next question: could it go through the system and document it?
And the scary thing is: it worked.
It took some time. But eventually it produced an extensive Notion page that outlined the structure of the system I had built. It described the databases and their relationships. It inferred best practices. It created how-to sections. It even pre-populated frequently asked questions based on what it discovered.
- How do I create a project?
- How do I create an event?
- How do I create a campaign?
It could answer those questions not because I had already written documentation, but because it could reason over the structure and content of the system itself. The databases were there. The templates were there. The examples were there. The relationships were there. Enough campaigns, events, and projects had already been created for the system to reveal its own logic.
And that was the moment the question shifted for me.
Not: how do I document this system? But: why am I documenting this system manually at all?
Documentation was always a workaround
The uncomfortable conclusion is that documentation as a separate manual activity has an expiry date. That does not mean shared context becomes less important. Quite the opposite. Shared context, decisions, examples, and durable memory will probably become more important than ever. But we should not confuse the need for memory with the document as the place where memory must live. For decades, documents were the best container we had. If a process needed to be explained, we wrote a document. If a system needed to be understood, we wrote a document. If a decision needed to survive beyond the meeting where it was made, we wrote a document. If new colleagues needed to learn how work gets done, we wrote a document. The document became the default interface for organizational memory.
But documents were never perfect for this. They drift out of date. They are written from one person’s point of view. They require someone to remember that they exist. They require someone else to trust that they are still accurate. They often describe the intended version of a process, not the messy reality of how work actually happens. Still, documents were useful because systems could not explain themselves.
- The CRM could store customer data, but it could not explain the sales process.
- The project management tool could contain tasks, but it could not explain how the organization thinks about projects.
- The design tool could contain screens, but it could not explain the product decisions behind them.
- The knowledge base could contain answers, but only if someone manually wrote and maintained them.
Documentation filled the gap between software and understanding. It was the layer we placed on top of systems that could store information, but could not yet interpret it.
That is changing.
The system can start explaining itself
Once an AI model can access the underlying system, the interface changes. The user no longer has to ask:
- Where is the documentation for this?
- They can ask:
- How does this work?
That sounds like a small difference, but it is not. The first question assumes that an explanation already exists somewhere as a document. The second assumes that an explanation can be generated from the system itself. That is what happened with my Notion setup. The documentation Claude created was not based on a pre-existing manual. It was based on the structure of the workspace: the databases, the properties, the templates, the relationships, the examples, and the actual content created by the team over time. In other words, the system contained more knowledge than I had consciously documented. It knew, implicitly, what a project was. It knew how a campaign related to an event. It knew which templates existed. It knew which fields mattered. It knew which patterns repeated. It knew enough to explain the system back to me.
That is new.
Not because AI magically understands everything. It does not. It can still misread things. It can still infer too much. It can still produce a confident answer from incomplete evidence. But the direction is clear. When software systems become accessible to reasoning models, documentation no longer has to be the primary source of explanation. It can become an output. A view. A generated layer. A temporary answer to a specific question. The source of truth is no longer necessarily the document. The source of truth is the system where the work happens.
The document becomes an output, not the source
This is the important shift. Documentation may still exist. In my case, Claude produced a Notion page. That page was useful. It gave people something to read, review, and share. But the page was not the most interesting part. The interesting part was that the documentation was generated from the operational system itself. That changes the role of documentation. Traditionally, documentation is treated as source material. Someone writes it. Others consult it. The organization tries to keep it up to date. When the system changes, someone must remember to change the documentation too. This is where documentation work becomes painful. Every meaningful system creates a second system next to itself: the explanation of the system. And now both need maintenance.
- The product changes, so the help center must change.
- The process changes, so the handbook must change.
- The database changes, so the onboarding guide must change.
- The workflow changes, so the training material must change.
The more alive the system is, the more likely the documentation is to decay. But if documentation becomes generated output, that relationship changes. A document can still be created when needed. It can still be reviewed. It can still be shared. But it does not have to be the place where knowledge is manually maintained.
Instead, the durable knowledge lives in the system:
- the structure
- the data
- the relationships
- the templates
- the examples
- the decisions
- the history
- the constraints
- the actual work
The document becomes one possible rendering of that knowledge. Not the source.
This does not mean “no memory”
It would be easy to misunderstand this argument. I am not saying organizations will need less context. I am not saying people can stop being explicit. I am not saying we can throw everything into tools and trust AI to figure it out later. That would be naive. The need for shared memory increases.
As teams become more distributed, more asynchronous, more automated, and more dependent on software, the need to understand context becomes more important, not less.
- People still need to know why decisions were made.
- They still need to know what a field means.
- They still need to know which process to follow.
- They still need examples.
- They still need constraints.
- They still need to understand the difference between what is possible and what is intended.
The question is not whether this memory matters. The question is where it should live. For a long time, the answer was: in documents. I think that answer is becoming less obvious.
Some context belongs in the structure of the software itself. Some belongs in templates. Some belongs in metadata. Some belongs in examples. Some belongs in captured conversations. Some belongs in decision records. Some belongs in code. Some belongs in the relationships between objects. Some belongs in the history of how work actually unfolded.
The future is not undocumented work. It is post-document documentation.
The new work is memory architecture
If documentation as a manual activity becomes obsolete, something else becomes more important. Not “prompting AI to write docs.” That is too shallow. The real work becomes designing systems that are legible to both humans and machines. That means clear structures. Meaningful naming. Consistent templates. Useful examples. Explicit relationships. Captured decisions. Clean metadata. Workflows that leave traces. It means thinking less like a writer of manuals and more like an architect of organizational memory.
This is a different skill.
A traditional documentation mindset asks:
- How do we explain this system in a page?
- A memory architecture mindset asks:
- How do we design the system so its logic can be understood, queried, reconstructed, and explained?
Those are not the same question.
If a campaign, an event, and a project are different things, the system should make that difference visible. If a workflow has stages, the stages should be represented. If decisions matter, they should be captured where they happen. If templates define best practice, they should not only help people create new items; they should also teach the system what good looks like. If examples are the most useful way to learn, the system should contain good examples.
This is where the work moves.
Away from manually writing documentation after the fact. Toward building environments where the documentation can emerge because the system itself is structured enough to be understood.
The expiry date of documentation jobs
This is where the argument becomes uncomfortable. If your job is to manually document software systems, processes, or internal knowledge, that job has an expiry date. Not tomorrow. Not everywhere at once. Not without exceptions. But the direction is hard to ignore. A lot of documentation work exists because systems are unable to explain themselves, and because users need a human-authored bridge between the tool and their task.
AI weakens that assumption.
If a model can inspect the system, understand the user’s question, retrieve relevant examples, reason over the structure, and produce a tailored explanation, then the static manual becomes much less valuable. Especially the generic manual. The “how to create a project” page. The “how to use this template” page. The “where to find X” page. The “what does this database do” page. The “how this workspace is structured” page. These are exactly the kinds of things that should not require manual documentation if the system is well structured and accessible to AI. That does not mean people who work in documentation have no future. But the valuable work changes. The value will be less in writing and maintaining pages, and more in designing the conditions under which reliable explanations can be generated. That includes information architecture, taxonomy, metadata, governance, examples, decision capture, quality control, and trust. The role moves closer to systems thinking.
Less writer. More memory designer.
Documents will not disappear completely
Of course, documents will not vanish. There will still be moments when a document is the right form. A policy may need a stable text. A legal statement may need an approved version. A strategic narrative may need careful wording. A public help article may need editorial control. A decision record may need to be frozen at a point in time. There are also cases where the act of writing is the thinking. A good document can force clarity. It can slow people down in a useful way. It can create alignment precisely because it requires someone to make an argument from beginning to end.
So I am not arguing against writing. I am arguing against the assumption that manual documentation should remain the default way organizations create shared understanding. That assumption made sense when documents were the best interface we had. But if software can increasingly explain itself, the document loses its privileged position. It becomes one interface among many. Sometimes useful. Sometimes necessary. But no longer the center of the system.
The real question
The experience at my daughter’s swimming lesson stayed with me because it felt small and large at the same time. Small, because all I did was ask Claude to look at a Notion workspace and document it. Large, because it exposed a shift in how organizational knowledge might work. I had assumed that the system needed documentation before it could scale. But maybe the more important question was whether the system had been built in a way that made it explainable.
That is a different standard. And it leads to a different future.
Documentation will not disappear because organizations no longer need to remember. It will disappear because memory will move closer to the systems where work actually happens. The document is becoming less important than the system’s ability to explain itself.
