Organizations in the AI Era Should Follow a GitHub Model

A few days ago, I saw a Sequoia video saying that companies in the AI era should adopt a GitHub model. Its central judgment was: companies and organizations should collaborate more like GitHub than Feishu.

This is close to what I have experienced using AI in my own work.

What is the Feishu model?

Feishu is a platform for team collaboration. It brings instant messages, groups, cloud documents, Bitable, calendars, meetings, tasks and knowledge management together so a team or organization can communicate about the same work, record information, assign tasks and synchronize progress. Feishu's official explanation of its core modules makes its purpose clear: connect organizational information and collaboration.

The “Feishu-style organization” represents a basic unit of work that remains person-to-person collaboration. A project is divided among roles. People store and pass context through chats, meetings, documents and spreadsheets; managers use OKRs to synchronize information, align goals, divide work and move handoffs forward. These tools are an advanced efficiency layer for traditional human collaboration. They are effective when work depends heavily on frequent cooperation between people.

Imagine this organization as a collaborative office building. Chat is the corridor; groups are project rooms; documents and tables are shared whiteboards and filing cabinets; calendars and meetings are a room-booking system. To move a project forward, people keep entering rooms to clarify background, complete materials, synchronize progress, confirm the next step and hand the baton to the next role. The building's strength is keeping many people connected to the same work: who is doing what, how far it has progressed, who is missing and whom to contact next.

What is the GitHub model?

First distinguish Git from GitHub. Git is a version-control tool, like a change log for code: it records changes, compares versions and can return to an earlier one. GitHub is a code-hosting and collaboration platform: it puts Git-managed repositories online so people can work together. Git manages how code changed; GitHub manages how many people change the same code together.

In plain language, imagine GitHub as a growing tree. The trunk is the foundation the team agrees to maintain. To try a feature or method, someone first grows a branch carrying that change, without directly changing the trunk. A branch is not a person or department; it is a space for change with a clear goal, scope and lifecycle.

Once the branch produces something, the relevant people review what changed, why and what else it might affect. That is the point of a pull request and review. After an owner approves it and required access controls and automated checks pass, the change merges into the main line. If it later proves unsuitable, it can be rolled back or corrected. GitHub does not guarantee no mistakes; it keeps them from quietly entering the shared main line and makes them traceable and manageable.

Why is the GitHub model better suited to the AI era?

Complex work previously required repeated handoffs: research to strategy, strategy to content, content to execution. Feishu-style collaboration is good at making each handoff clear.

AI lets a unit of one person + an AI Agent do more, faster. Local experiments become more numerous and faster, reducing the need for other people to perform every intermediate step. The time it takes to send a request to a domain expert and wait for a handoff may be enough for you and AI to try to produce and improve it yourselves.

The organizational question changes: among these quickly produced local attempts, which are one-off results, and which deserve to become shared, maintained, reusable capabilities—or organizational assets?

That is what the GitHub model manages. Someone builds an idea on a branch without touching the shared trunk, then uses a pull request to explain what changed, why and what evidence supports it. Relevant people review it; only then is it merged. Problems can be rolled back. It does not require publishing every AI conversation. It requires that each change entering the shared system be explainable, traceable and owned.

The distinction between Feishu and GitHub is not simply old versus new. Feishu is an office building that helps people find and synchronize with each other. GitHub is a tree maintained together, concerned with how new branches grow safely and which can join the trunk. AI makes local branch-growing much faster. An organization composed of such people needs a way to grow, review and join branches to the trunk—the collaborative approach of software engineering.

The next step after AI-native individuals is an AI-native organization

In an earlier piece, “What Exactly Is an AI Native Person?”, I compared such a person to a native speaker: AI is no longer an external tool opened occasionally but a “mother tongue” habit in thinking and work.

When a problem arises, their first thought is how AI might help make the solution. They can hand over the problem, context, constraints and acceptance criteria directly. They know what AI can and cannot do, when to let it continue and when they must judge and verify.

But one person's method does not automatically become organizational capability. If an effective work trace exists only on one colleague's computer and in their mind, it remains individual. The organization must make the leap: it does not collect every complete human–AI interaction; it turns verified, reusable parts into jointly maintained capability.

I believe an AI-native organization will grow a shared AI foundation. It is not just a central AI platform to which everyone sends requests; it is a network the organization can call and maintain together: which context and rules are sources of truth, which Agents, Skills and Workflows have been validated, who can change them, how to check them and how to roll back problems.

How does that foundation emerge?

If an AI-native organization is a tree, buying a ready-made trunk and roots is not enough. Without the ability and environment to tend it, the tree will die. This is also why I believe most corporate AI transformations will fail.

A real AI foundation must grow in a suitable environment and be maintained by the organization into a great tree.

First, it needs a seed: the founder's vision and original intention. Whom does the organization want to create value for, and what value? What does it believe? What will it refuse to do even if doing so is more efficient? These explain why the tree grows and provide fundamental criteria for experiments and merges.

Second, it needs soil and environment: real users, business, team and market, plus trust inside the organization. Trust does not mean giving AI all data. It means members are willing to offer effective experience for inspection, correction and reuse, while the organization promises boundaries, permissions, responsibilities and outcomes so sharing does not mean losing control. This trust is not driven by fear or bought with money; it is driven more by the vision and culture in the first point.

Third, it needs roots: infrastructure anyone can connect to. Not another big platform, but a clear account for each reusable Agent, Skill or Workflow: what problem it solves, its inputs and outputs, how it passes, who may use it and which data it must not use. Others can then understand, call and maintain it without repeatedly asking its creator. Without this, an effective attempt remains personal and cannot enter the shared AI foundation.

Fourth, it needs ongoing care: an owner, review and rollback rights. Someone must maintain the capability, determine who can change it and what evidence admits it into the shared layer, and correct or retire it when it fails. The GitHub model lets branches grow locally, join the trunk after review and be pruned when problems emerge.

Each merge should therefore ask more than “does it run?” It should ask whether it makes the tree healthier and whether it still grows in the direction the organization's people have chosen.

That is my understanding of an AI-native organization: people and AI continually grow branches, while the organization knows its seed, where its trunk is and what deserves to join the shared main line.