What If Your Entire Software Team Worked From the Same LLM Wiki?

Software projects have always had a documentation problem.

Not because we don't document things.

We document too many things in too many places.

The PM writes a product spec in Google Docs or Notion. Someone converts it into Jira tickets. The developer reads both and asks questions on Slack. Architecture decisions end up in another document. QA reads the original requirement and creates test cases somewhere else. Analytics gets another requirement document explaining what events need to be tracked.

Three months later, somebody asks:

What happens if a user deletes a video that has already been added to a playlist?

And suddenly five people are searching Jira, Slack, documentation and code trying to reconstruct the answer.

LLM Wiki suggests a different way of thinking about project knowledge. Instead of treating documentation as documents, treat the repository as a continuously compiled knowledge base about the product.

Let's build a feature this way from beginning to end.

01The PM starts with a feature spec

Suppose we are building a video application and the PM wants to introduce Continue Watching.

Normally the PM might create something like Continue Watching - Product Requirement.docx. Instead, we create:

/docs/raw/product/continue-watching.md

The PM can still use an LLM to draft it:

Feature: Continue Watching

Goal:
Allow users to resume partially watched videos.

Requirements:

1. A video enters Continue Watching after the user watches
   at least 10 seconds.

2. Completed videos should not appear.

3. Continue Watching should show a maximum of 20 videos.

4. The most recently watched video should appear first.

5. Progress should sync across devices.

6. If the video is deleted or unpublished, it should disappear
   from Continue Watching.

But this file is not the final documentation. It is source material. We ingest it into LLM Wiki, and the wiki compiles that information into the existing knowledge base — instead of creating another isolated document, it updates or creates the relevant concepts:

/wiki/features/continue-watching.md
/wiki/video/playback-progress.md
/wiki/user/watch-history.md
/wiki/content/content-availability.md

Now Continue Watching is connected to the rest of the product. That distinction is important: we aren't asking an LLM to answer questions from a pile of documents every time. We are asking it to continuously compile those documents into an organized representation of the product.

02The developer doesn't start from a Jira ticket

Now the backend developer gets the task. Instead of reading a Jira description and trying to reconstruct the system, the coding agent has access to the project wiki through MCP. The developer can ask:

Implement Continue Watching.

Read the relevant product requirements and existing architecture
before proposing an implementation.

The coding agent queries the knowledge base and discovers:

It can also inspect the actual repository. Now the agent has two types of context: what the system is supposed to do, from the wiki, and what the system currently does, from the code.

That combination is considerably more useful than giving an agent a Jira ticket saying "Implement Continue Watching API." The agent can propose something like:

POST /watch-progress
GET  /continue-watching

and identify the existing services and database tables that should be modified. The developer reviews the plan and implements it.

03Implementation becomes new knowledge

Here is where the workflow gets interesting. During implementation we discover something: writing progress to Postgres every few seconds creates unnecessary writes. So we decide:

Playback progress will first be stored in Redis. Progress will periodically be persisted to Postgres. Redis is the low-latency operational store. Postgres remains the durable source of truth.

Normally this decision might live in a PR comment, someone's head, Slack, or an architecture document that nobody updates. Instead we add the implementation decision as another source:

/docs/raw/decisions/continue-watching-storage.md

Then compile again. The wiki can now update concepts around Playback Progress, Redis Usage, Persistence Strategy, and Continue Watching. The knowledge base has evolved together with the implementation.

04QA doesn't start from zero either

The feature reaches QA. Usually QA reads the Jira ticket and manually derives test cases. But QA now has access to exactly the same knowledge base. They can ask:

Generate test cases for Continue Watching.

Include functional, boundary, failure and cross-device cases.

Use the actual documented product behaviour.

The result might include:

TC01
Watch video for 5 seconds.
Expected: Video does not appear.

TC02
Watch video for 11 seconds.
Expected: Video appears.

TC03
Complete the video.
Expected: Video disappears.

TC04
Watch videos on Device A.
Open Device B.
Expected: Progress is synchronized.

TC05
Unpublish a partially watched video.
Expected: Video disappears.

TC06
Watch 25 different videos.
Expected: Only the latest 20 appear.

Notice what happened: QA did not receive a second interpretation of the requirement. Developer and QA are reasoning from the same knowledge source. That can remove an entire class of communication problems.

05QA findings go back into the wiki

Suppose QA discovers an undefined case:

What happens when someone watches exactly 10 seconds? Is the condition progress > 10 or progress >= 10?

Instead of resolving this only inside a Jira comment, the PM clarifies: "A video qualifies when watch duration >= 10 seconds." That clarification gets ingested, and the knowledge base changes. The product specification, developer context and QA understanding converge again.

This is the important loop:

The wiki isn't documentation created after development. It participates in development.

06Stakeholders can ask the product questions

Now imagine the product head asks "How exactly does Continue Watching work?" They don't need to ask the PM. They ask the project knowledge base. Or: "Why are completed videos removed?" Or: "Where is playback progress stored?" Or: "Does Continue Watching work across devices?" Or: "What happens when content gets unpublished?"

Some are product questions. Some are engineering questions. But they can be answered from the same interconnected knowledge base, with the underlying sources available for verification.

This starts reducing something every engineering organization spends a surprising amount of time doing: humans acting as APIs for information stored in their heads.

07Analytics can use the same context

Analytics is another place where requirements frequently diverge. Suppose the PM asks "Are users actually using Continue Watching?" An analytics agent can inspect the feature definition and determine which events matter:

continue_watching_impression
continue_watching_click
video_resume
video_completed

It can propose a funnel:

If the warehouse is also exposed to the analytics agent, the stakeholder can eventually ask "What percentage of users who see Continue Watching actually resume a video?" or "Compare completion rates between videos resumed through Continue Watching and videos started normally."

The interesting part is that the agent already understands what Continue Watching means. The analytics system doesn't exist in isolation from the product specification.

The repository starts looking different

Eventually I can imagine repositories looking something like this:

project/
│
├── src/
│
├── tests/
│
├── migrations/
│
│
├── docs/
│   └── raw/
│       ├── product/
│       ├── engineering/
│       ├── qa/
│       ├── analytics/
│       └── decisions/
│
└── wiki/
    ├── features/
    ├── architecture/
    ├── services/
    ├── data/
    ├── analytics/
    └── concepts/

docs/raw contains the evidence. wiki contains the compiled understanding. And src contains the implementation. Put all three together and a coding agent gets a surprisingly complete picture of the project.

Why not just put everything into RAG?

You could. But there is a subtle difference. With conventional RAG we tend to do:

The organization of knowledge happens primarily at query time. The LLM Wiki pattern introduces another step:

Instead of repeatedly reconstructing the product from fragments, we maintain an organized representation of it. This doesn't necessarily replace RAG — for a sufficiently large project you will probably still want retrieval. The difference is what you're retrieving. Rather than only retrieving random chunks of historical documents, the agent can retrieve deliberately organized concepts while still going back to the raw source when necessary.

Git makes this even more interesting

Because the wiki can be Markdown, it can live beside the code. That gives us something normal enterprise wikis don't naturally have: git blame, git diff, pull requests, branches, code review, version history.

A PR could contain:

Code changes
+
Database migration
+
Tests
+
Wiki changes

Reviewing a feature then means reviewing not just "Did we implement this correctly?" but also "Did our understanding of the system change?" If yes, the knowledge change ships with the code change.

There is still one important rule

I would not treat the generated wiki as unquestionable truth. The source documents and code remain authoritative. LLMs can misunderstand requirements, merge concepts incorrectly, or preserve outdated assumptions.

So the model should really be:

RAW SOURCES = evidence

CODE = implementation

LLM WIKI = compiled understanding

The bigger idea

For years we have treated project documentation as something humans write for other humans. AI coding changes that assumption. Documentation now has another extremely important consumer: agents. And agents can also maintain part of that documentation.

That creates a different software-development loop:

Everyone is no longer maintaining their own partial interpretation of the project. They are contributing evidence to a shared knowledge system.

The PM doesn't need to understand the implementation. The developer doesn't need to remember every product discussion. QA doesn't need to reverse-engineer requirements. Stakeholders don't need to find the right person to ask. And every new AI agent doesn't have to rediscover the project from scratch.

We have spent the last few years making LLMs better at generating code. The next problem might be much less glamorous: giving every person and every agent working on a project the same understanding of what they are building.

That is where I think the LLM Wiki pattern becomes much more interesting than simply being another way to organize notes.