Who builds the next GitHub? Code, AI and platform power

GitHub is a platform where people store, develop and publish software together. Underneath it sits Git, a version control tool: it records changes to files, supports parallel branches of development and helps bring different versions of work back together. Git provides the technical foundation. GitHub adds collaboration through issue reports, discussions, pull requests and automated workflows.

Git emerged from Linux kernel development in 2005. GitHub was founded in 2008 and launched publicly on April 10, 2008. Ten years later, Microsoft bought the company for $7.5 billion, announcing the completion of the acquisition on October 26, 2018. What started as a home for developers became central infrastructure for the software world. Git history, GitHub launch, Microsoft acquisition

In 2026, it suddenly feels as though every other person outside traditional software development has a GitHub account too. A small app here, a personal dashboard there, an AI tool asking to connect a repository. That is my deliberately exaggerated impression, not a statistic about people without development backgrounds. The change behind it still matters: building software is becoming more accessible, while the infrastructure underneath has more work to do.

That is why the question of who builds the next GitHub interests me. Anthropic has rebuilt its internal source control. Cloudflare is providing building blocks for new Git platforms. Meanwhile, GitHub’s reliability is being questioned publicly. This involves much more than a nicer merge button. It concerns who controls the place where software is created, reviewed and moved into production.

When users become software builders

This started before the current year. GitHub’s 2025 Octoverse report already counted more than 180 million developers and over 36 million new users in a year. According to GitHub, nearly 80 percent of new developers used Copilot within their first week. These are vendor figures, not proof that AI caused all that growth. They do show how closely joining GitHub has become connected with AI tools.

Previously, building a small utility often meant learning enough programming to get a useful starting point. Today, someone can describe an idea and develop it step by step with a coding agent. Expertise remains necessary, especially where data, permissions and production systems are involved. Nevertheless, the distance between an idea and a first working program has become considerably shorter.

I see enormous potential for open source: clearer documentation, additional tests, help investigating bugs, more accessible interfaces and renewed attention to abandoned ideas. These are practical ways AI can accelerate development. They do not establish that every project has improved in quality. Another repository does not automatically become maintained software, and another pull request can mean more work for a maintainer.

I am therefore less interested in how many lines an agent produces than in how much of its output can be understood, checked and maintained. As code arrives faster, the bottleneck moves towards the people and systems deciding which changes deserve to stay.

The Christmas tree on the status page

The header image shows The Missing GitHub Status Page by Marek Šuppa. The screenshot is dated October 15, 2026 and lists 65 incidents and 93.70 percent platform uptime over a 90-day window. Git Operations, by comparison, shows 99.55 percent. Those figures belong to that capture; they are not fresh availability measurements I have made.

The unofficial page reconstructs time windows from published status reports and merges overlapping disruptions. A platform figure aggregates different services. It does not mean Git clones, pull requests and Actions were simultaneously unavailable to every user during every recorded incident. Consequently, 93.70 percent does not simply mean “GitHub was completely offline 6.30 percent of the time.” Interpretation depends on the aggregation and the incidents included.

Nevertheless, the image touches a sensitive point. A source hosting platform is now part of the production chain. An inaccessible review, blocked build or disrupted API can delay a release even when the source code is fully available locally. For the affected workflow, what matters is whether the whole chain works.

The status chart also does not establish that AI caused these incidents. It helps explain why alternatives attract attention. Assessing the causes of individual disruptions requires their respective incident reports.

Why Git and GitHub need separate consideration

A GitHub outage does not by itself expose a flaw in Git’s data model. With a complete local Git copy, I can keep recording changes, comparing older versions and working on branches. That work does not require a permanently reachable hosting provider. This independence is one of Git’s most valuable properties to me.

The services a team builds around its repository are a different matter. If approvals, tests, artifacts and deployment depend on a platform, a local copy is insufficient to continue the entire process. The code is distributed, while the workflow may be highly centralized.

That creates two separate requirements: a platform must operate reliably, and a version control system must fit its users’ workload and data volume. Changing hosting providers does not automatically fix every scaling problem. Conversely, a difficult period for a platform does not by itself justify replacing Git altogether.

Anthropic builds Scion for an unusual scale

Anthropic reports roughly 2,500 merged changes per day in May 2026, rising to more than 30,000 in September. Its main branch history approaches 100 GB, with a compressed working copy exceeding 25 GB. CI alone performs around 25 million checkouts daily. The cited figure of over 600 PB of daily transfers is an extrapolation for naive full fetching, not a measured daily traffic total.

Its response is Scion. Anthropic describes a five-month migration, alongside the Antique review tool and other internal infrastructure. Scion assumes continuously connected clients and moves version control operations to the server. Files load as needed, and APIs answer many queries directly. Jobs consequently do not need a local repository copy for every question.

The boundary Anthropic draws is essential: Scion is neither a general Git replacement nor an announced public GitHub for everyone. It targets enormous monorepositories and Anthropic’s own agent workload. Anthropic also wants to share lessons with the existing Git ecosystem. “Anthropic is building the next GitHub” therefore captures, at most, a technical shift rather than an already available competing product.

Why a smaller client can make a large difference

The architectural idea is understandable without operating at Anthropic’s scale. Imagine an automated task checking whether a particular configuration file changed between two versions. It needs an answer to a narrow question. Preparing a substantial local working environment could cost considerably more effort than the check itself.

For one task, that overhead may barely register. Across many short-lived environments, repeated setup, data transfer and cleanup can consume a considerable share of resources. A service that delivers precisely the necessary data changes that calculation. This is an architectural tradeoff, not proof that every small repository needs a centralized version server.

The price is a stronger dependency on that service being reachable. Moving more work onto a server makes its failure handling, permissions, recovery and capacity limits correspondingly important. Keeping less data locally is convenient until the remote service stops responding.

I like seeing a familiar assumption challenged. I would still avoid turning it into a universal recommendation. For a modest project, a complete local Git history may offer exactly the right balance of simplicity, speed and independence.

Cloudflare keeps Git and makes repositories programmable

Cloudflare takes a different route with Artifacts. Introduced in April, the service provides versioned storage with a Git-compatible interface. APIs can create, import and fork repositories, while ordinary Git clients can use them. Cloudflare describes separate repositories for projects, tasks or agent sessions, storing versioned code and context. The underlying infrastructure can be provisioned programmatically instead of treating every repository as a manually configured permanent workspace.

That makes Git compatibility strategically useful. Existing tools and familiar workflows reduce the effort of getting started. A new product can initially concentrate on collaboration without simultaneously introducing an entirely new version control protocol.

In October, Cloudflare announced an open beta for customers on a paid Workers plan. Newer integrations connect Artifacts to Workers Builds and preview environments. Events can trigger automated reviews, while repository-specific tokens constrain access. Cloudflare explicitly invites others to build the next Git platform on Workers and Artifacts. This is infrastructure with platform ambitions, not yet a complete GitHub with an equivalent social and organizational ecosystem.

The interesting distinction is where each company draws the boundary. Anthropic is optimizing its own enormous development system. Cloudflare offers a foundation for other companies to build products. The actual interface for people, agents and shared decisions remains a separate product challenge.

Why these companies want to be there

Anthropic’s directly documented reason is its own bottleneck. Research and product development waiting for version control operations cost time and computing capacity. Better internal infrastructure has value even if Scion never becomes a public product.

Beyond that, I see a strategic interest in making coding agents useful throughout longer workflows. A model that writes a function is valuable. An agent that navigates a project, prepares reviewable changes and works with existing infrastructure can become much more deeply embedded in daily work. That is my economic interpretation, not an Anthropic-confirmed commercialization plan for Scion.

For Cloudflare, the connection to its infrastructure business is more direct. Running applications on Workers and holding their development data in Artifacts brings more of the workflow onto the same platform. Cloudflare describes Artifacts billing based on operations and stored data. More agents can mean more repositories, accesses and computing work. Whether a particular workflow is economical depends on its actual usage.

Integration also creates a reason to stay. A Git repository is often relatively straightforward to move elsewhere. A system of application-specific APIs, agent workflows, events, permissions, previews and deployment is harder to relocate. The more conveniently these pieces work together, the more practical effort switching providers requires.

These incentives do not contradict the technical benefits. A service can solve a real problem while strengthening its provider’s position. That is precisely why I want to consider both sides before a convenient integration becomes a dependency nobody questions.

Code contains more than program text

And yes, training data belongs in this discussion. It deserves attention as a possible strategic interest. Treating it as the universal explanation for every new Git platform would be too easy.

A repository often holds much more than the current solution. Its history can reveal which approach was attempted first, which test failed, why a review rejected a change and which correction was finally accepted. That relationship could be particularly valuable when developing coding systems: a task, an attempt, feedback and a verifiable result are connected.

Consider a fictional example. An agent must fix a date calculation bug. Its first proposal passes the existing tests but fails a newly added year-boundary test. A reviewer explains the mistaken assumption, and the next change corrects it. The learning value would extend beyond the final code to the path from a plausible mistake to a reasoned solution. Whether a provider actually uses such data, and has permission to do so, is a separate question.

The value of code therefore does not simply disappear as generating it becomes cheaper. Reliable requirements, documented decisions, useful tests, maintenance experience and demonstrated interoperability still take work. A mountain of generated files cannot replace them. When proposals can be produced in enormous quantities, credible evidence that one actually solves a problem becomes especially valuable.

This is my assessment of the economic and technical potential. The announcements discussed here establish neither that Anthropic collects other organizations’ private repositories through Scion nor that Cloudflare operates Artifacts to train its own coding model.

What actually needs distinguishing in model training

Interest in development data for AI is not purely hypothetical. In March 2026, GitHub said that from April 24 it would use interaction data from certain personal Copilot plans for model training unless users opted out. GitHub explicitly distinguishes active Copilot interaction data from repository contents at rest: it says it does not broadly read stored private repositories for this purpose. Different protections apply to Copilot Business and Enterprise. GitHub’s explanation of data usage

Anthropic, meanwhile, says inputs and outputs from its commercial products are not used for model training by default. Voluntarily submitted feedback and explicit participation in relevant programs may receive separate treatment. That statement is not a general promise covering every consumer plan and setting. Anthropic’s explanation for commercial products

For a new service, I would therefore want to understand which content is only stored, which is processed to answer a request and which is used for product improvement or training. These are different activities. An agent needs to process code to work on it; that does not automatically grant permission to incorporate it into a model.

Likewise, calling something open source does not settle every question about its use. Publicly visible code, its license, confidential material and a service’s terms need separate consideration. To me, an understandable data usage policy belongs in the product just as much as a useful API.

The next GitHub needs to enable better decisions

The most convenient vision would be a platform where unlimited agents generate unlimited code and other agents approve everything automatically. I am unconvinced. Several systems sharing the same mistaken assumption do not produce independent evidence merely by agreeing with one another.

A useful platform would make clear which task a change addresses, which baseline it uses, which checks ran and who takes responsibility for accepting it. Changes developed in parallel can each appear correct while breaking something together. Faster merging does not remove that problem.

Agent context also needs boundaries. Task descriptions, logs and configuration files can contain information that does not belong in every repository or external execution environment. Persisting agent sessions creates a new data collection alongside the development aid. Its access controls and lifetime deserve deliberate design.

For open source, the human side remains essential too: trust in maintainers, understandable discussions and a willingness to look after a project for years. Faster hosting can support that work. More automated activity alone cannot replace it.

GitHub faces a challenge, but succession remains open

I think it is healthy to question even foundational tools again. AI can give more people the ability to build their own software. We should be able to ask whether existing platforms still fit the work that follows.

Anthropic demonstrates a specialized internal rebuild. Cloudflare opens infrastructure for new products. GitHub still has an established ecosystem that an alternative would need to replace or usefully complement. A new storage architecture alone will not decide this competition.

The question that matters to me is who can help more people and agents work together productively while preserving traceability, independence and control over their data. That is the standard I would apply to the next GitHub. It is probably also where a substantial part of the business lies.

Until next time,
Joe