Why Use GitHub as the Knowledge Collaboration Foundation for the AI-Native Era

I want to gradually migrate the knowledge that our company needs to preserve long-term—especially my own work logs, documents, and articles—from traditional document systems like Confluence and Feishu to GitHub. This choice may seem counterintuitive: GitHub isn’t user-friendly for non-technical people, and Git itself has a steep learning curve. Even among developers, not many truly master Git collaboration workflows in a fluid and natural way.

But that’s precisely why I believe it becomes more valuable in the age of AI agents.

In the past, the barrier to Git was that humans had to personally understand concepts like branch, commit, PR, review, and merge, and follow a whole set of conventions for writing commits, opening PRs, handling conflicts, and maintaining history. Most people—myself included—don’t find these easy. So in the past, GitHub was more of a specialized tool for a minority of technical people, and it was hard to make it a company-wide universal knowledge collaboration system.

Now things have changed. Those hard-to-understand concepts can be delegated to AI; those hard-to-follow rules can be entrusted to AI. People don’t need to learn Git themselves, nor do they need to deal with GitHub’s complex workflows. People only need to express ideas and requirements in natural language, and agents can handle organizing, saving, committing, reviewing, syncing, and presenting.

So I choose GitHub not because it’s a better document editor, but because it’s a better knowledge infrastructure for AI agents to operate on.

1. Knowledge is a Shared Asset, Not Private Documents

We’ve always hoped to foster a more open and transparent way of knowledge collaboration within the company. Knowledge should be a shared asset for everyone, not locked behind permission walls and owned only by the few with editing rights. This doesn’t mean all information has no boundaries, nor that anyone can casually modify formal content. Rather, within appropriate permission scopes, information is visible by default, issues can be pointed out, improvements can be proposed, and final conclusions are confirmed through clear processes.

In traditional document systems, collaboration often revolves around “who has edit permissions.” A document is private by default—not viewable, not editable—requiring permission to view and inclusion in an edit group to change. Those without permission can only comment, request access, or start a new document. Knowledge thus inherently carries a “private” attribute, making it hard for others with better ideas to directly contribute.

GitHub’s default stance is the opposite: content placed in a repository is public by default and editable by default. Anyone can clone the repository locally, freely modify, organize, and extend content. How you read, index, or use it with your own AI agent is entirely up to you. But Git’s version control makes this “default editable” state controlled—whether something enters the company’s jointly maintained official version is determined by owners, reviews, and rules. Upstream maintainers actually have stronger control over the main branch than in traditional document systems. This is “open contribution, controlled merge”: the barrier to contribution is lowered, while the responsibility for merging remains clear.

Under this mechanism, knowledge is no longer someone’s private document, but a shared asset in a repository. Everyone can propose improvements around it, while formal content still has clear accountability boundaries. This is far better for long-term collaboration than simply granting edit permissions to some people: it encourages broader participation while preventing formal knowledge from being randomly messed up.

2. GitHub is a Collaboration Language AI Models Know Naturally

GitHub has an advantage that many third-party document systems lack: AI models themselves are very familiar with it.

GitHub hosts the world’s best open-source projects and has accumulated a wealth of mature collaboration patterns. This content has naturally entered the training data of large language models. That means AI not only knows what GitHub is, but has already learned from countless real projects how to organize content, propose changes, discuss issues, reach consensus, and what collaboration styles are clearer and more efficient.

In other words, many of GitHub’s rules, norms, and collaboration etiquette are not a new system that AI needs to learn from scratch, but a working style that’s already internalized in the model’s capabilities. We don’t need to write a manual first on “how to collaborate using GitHub”; it can usually work naturally within this paradigm.

This is completely different from many third-party document systems. For example, if you ask AI to use Feishu documents, it often needs to first connect tools, link MCPs, consult documentation, reference manuals, and then understand Feishu’s page structure, knowledge base structure, permission limitations, commenting methods, update methods, and API response formats. For AI, these systems are more like external black boxes. It has to explore bit by bit through tool calls, and in daily use it’s more prone to errors due to permissions, formats, interfaces, and insufficient context, resulting in lower efficiency.

There’s another harder advantage: Git’s interface itself is extremely stable. The semantics of command line, file tree, diff, and blame haven’t changed in decades. Rich UI document systems change their interfaces and APIs ten times a year, with external tools and MCPs constantly patching to keep up; Git doesn’t need to keep up. For AI agents that rely on long-term reliable operation of tools, this stability is an infrastructure-level advantage.

So Git/GitHub isn’t the only tool AI can use, but it’s one of the collaboration paradigms that AI models are most familiar with, most standardized, and most easily understood. Putting company knowledge into this structure is like letting AI manage knowledge in a way it already knows well, rather than forcing it to constantly adapt to various proprietary document systems.

3. Local Repositories Give AI Complete Context

Another key advantage of GitHub/Git: repositories can be fully synced locally.

This is very important for AI agents. If knowledge lives in cloud document systems like Feishu or Confluence, AI can often only get content piecemeal through search interfaces, MCP tools, paginated APIs, HTML or rich text parsing. What it sees are query results, not the complete knowledge base. Every search, read, and edit depends on tool calls, and is easily limited by permissions, interfaces, and search quality.

Current AI agent programming is a great example. When doing AI programming, we definitely want the codebase locally. Even for large projects, as long as the local index, structure organization, and context orchestration are done well, the AI agent can have a very high grasp of the project content. It’s hard to imagine a large program project’s code and files scattered across Feishu documents: every query requires calling Feishu’s API, every read relies on search results, every modification has to cross document system permissions and format limitations. That would be terribly inefficient.

What’s true for code is also true for company knowledge.

If future AI agents are to truly understand and maintain company work logs, project retrospectives, product thinking, technical proposals, and decision records, they also need to face a complete, local, well-structured knowledge base. Git repositories allow agents to browse directory structures, search all files, build indexes, view history, compare diffs, detect duplicates and conflicts, and directly propose changes.

This is not just “searching documents”; it’s enabling AI to understand the entire knowledge space.

Localization also brings a commonly overlooked benefit: all AI agents can simultaneously use the same knowledge without conflicts. Today Claude Code organizes a log, tomorrow Codex runs an analysis, while Cursor directly edits the same repository—all agents read the same local files, without issues of who occupies the API or who needs to reconnect MCP. Multiple agents can work in parallel without interfering. This isn’t about “migrating from one agent to another”; it’s about “all agents sharing the same knowledge simultaneously.” Content locked inside Feishu or Notion can’t do this.

4. GitHub is the Raw Information Layer, Not the Final Presentation Layer

I don’t think GitHub should become the best document editor, nor that everyone should directly open GitHub to read documents.

A more reasonable understanding is: GitHub is responsible for preserving the rawest, cleanest, most tool-readable, and most traceable information. What tools people use to edit, read, and present that information doesn’t need to be unified.

This is also why knowledge in GitHub is usually structured text like Markdown, YAML, JSON, MDX. These may not be the most comfortable final reading form for humans, but they are very suitable as underlying information sources—compared to complex rich text, HTML, page blocks, and editor states, they are easier to search, slice, reference, compress, summarize, reorganize, and transform. For AI, the cleaner the underlying information, the higher the understanding and usage efficiency, and the less token waste. People don’t necessarily have to write Markdown themselves; agents can help them organize into appropriate formats.

Some people can read and organize with Obsidian, some can have agents like Codex or Claude Code make modifications, distribute updates via Slack bots, use AI agents to generate summaries, PPTs, interactive demos, or even final products.

GitHub is not about replacing all tools; it’s about enabling all tools to collaborate around the same trusted raw data. As long as the underlying information is accurate, clear, and traceable, the presentation layer can be flexibly generated for different people, scenarios, and needs.

5. The Boundary Between Documentation and Code Will Blur

Another long-term change: as AI agents become more capable, the boundary between code and documentation will become increasingly blurred.

In the past, writing documentation and writing code were two completely different things. Docs are for humans; code is for machines to run. The reason isn’t just different tools—more importantly, human capabilities and division of labor have boundaries: programmers and non-programmers have long been two very different professions. Those who can articulate ideas may not be able to turn ideas into tools; those who can write code may not best understand business and requirements.

But in the AI agent era, this boundary will gradually dissolve. Often, a person doesn’t need to write code themselves; they can use natural language to have an agent modify scripts, adjust tools, generate demos, or even turn an idea in a document directly into a runnable prototype.

For an AI agent, the context needed to complete a task shouldn’t be artificially split into “documents in one place, code in another.” Documentation, code, configuration, prompts, scripts, demos, data structures—these are often different expressions of the same task. If they are placed in the same repository or nearby context, the agent can more easily understand the goal, modify the implementation, update the documentation, and keep content consistent.

This also means that within the company, more and more tools will exist in a way similar to open-source projects. People can not only give feedback, but also directly try to modify these tools in their local environment and submit valuable improvements back.

Behind this is actually a more direct collaboration culture:

Talk is cheap, show me the code.

Here “code” isn’t just traditional program code; it can also be documentation, configuration, prompts, scripts, demos, data structures, or any raw information that agents can understand and execute.

Lizi’s recent work on XD Maker should be an attempt in this direction: enabling more people not just to describe ideas, but to more directly push ideas into something runnable, modifiable, and collaborative.

From this perspective, GitHub is not just a document storage tool, but a collaboration environment that simultaneously holds documentation, code, prompts, demos, and tools. It’s suitable for carrying this new way of working where boundaries gradually blur.

6. Permissions and Security Have Costs, and Need New Governance

This choice isn’t without cost.

Traditional cloud document systems have some centralized management capabilities. For example, documents exist in the cloud, and platforms can record who read which document, how much, and when; some systems can detect a person reading large amounts of content in a short time and trigger security alerts.

If knowledge is localized via Git repositories, these capabilities weaken. Once a repository is cloned locally, the content is already local. How users or local AI agents read it, how much they read, what indexes they build—the centralized platform may not know.

This is a cost we must explicitly acknowledge.

But the value gained is also significant: local AI can access complete knowledge more efficiently, without needing to call query interfaces piece by piece; it can build its own indexes; it can retrieve and organize with lower latency and cost; it can also obtain richer context.

Whether this trade-off is worthwhile depends on how we design governance. My judgment is that the cost is worth it, but only if we design boundaries more clearly: public knowledge, departmental knowledge, project knowledge, highly sensitive knowledge should be managed in separate repositories; highly sensitive content should not enter cloneable repositories; agent writes should be reviewed by risk level; formal company knowledge needs owners; important content should enter the main branch through PR, review, or approval.

The AI agent era will also raise requirements for colleagues’ professionalism and sense of responsibility. People need to be more conscious and professional in taking responsibility for the data they can access.

7. Gradual Evolution, Not Replacement of All Daily Tools

Choosing GitHub as the knowledge foundation doesn’t force everyone to change their daily tools immediately. But when a piece of information begins to have long-term value, needs to be reused, or needs to be understood by AI, it should land in GitHub. GitHub can gradually become the local information retrieval entry point for each person’s own AI agent. The agent starts from here, then connects to various third-party systems and tools like Slack, Feishu, and vice versa.

So this is not a one-time replacement, but a gradual evolution toward an AI-native way of working.

Ultimately, what I hope to build is not another document system, but a new way of company knowledge collaboration: important knowledge no longer scattered, contributions made easier, formal content with clear boundaries, AI agents able to participate efficiently, and the company gradually forming more maintainable and reusable shared knowledge.