By 听雨, from 凹非寺
量子位 | Official account QbitAI
GitHub, why did you break down again……
On November 3, the official status page recorded two outages in a single day, one of which affected Git operations.
On November 4, services like pull requests malfunctioned again, with some requests failing or delayed.
Your code is fixed and you want a colleague to see whether it can be merged into the main project—only to get stuck at exactly this step.
One netizen joked about it:
Perfect time to go grab a coffee.
Just as GitHub was scrambling to make repairs, Axios broke an exclusive:
OpenAI plans to acquire Pierre, a maker of code hosting tools, with the deal still pending closing.
The two pieces of news colliding like this—the timing is a bit coincidental.
And it has to be said: quite a few companies building AI coding tools have started managing their own code.
Musk's旗下... wait—no—Cursor, under Musk's orbit, already allows developers to store entire projects directly in Cursor.
Anthropic has gone one step further, moving the main codebase its engineers use every day into its own in-house system.
Why have all these companies started working on this?
Because AI is writing code faster and faster, and the infrastructure is gradually failing to keep up……
OpenAI built its own and is preparing to buy another
OpenAI itself has tasted what it's like when a code system can't keep up.
Back in March, The Information reported that OpenAI engineers repeatedly encountered GitHub service disruptions, and the company was developing an internal alternative tool.
Then on November 2—just a few days ago—it unveiled its own Git backend,Pando, which handles internal code storage and retrieval operations.
According to the engineering team, previously an engineer would advance one change at a time. With Codex, one person can prepare several at once.
And every code push triggers multiple automated tasks to fetch the code and run checks.
The number of people writing code hasn't suddenly multiplied several-fold, yet the work the system must handle has increased.
The original system gradually strained: pulls and pushes slowed down, and merges started failing.
Pando has been handling real development traffic since April (month 4). According to OpenAI's statistics, after switching over, the median time for a single push dropped by nearly 80%.
With its own engineers' problem solved, OpenAI is now preparing, for Codex users, to acquirePierre, bringing capabilities like code storage into the product.
Come to think of it, you may have already used Pierre's stuff~
Suppose you ask Codex to fix a bug, and it changes five files in one go.
You open the file list, find one of them, and then compare line by line what it deleted and what it added.
The former action uses Trees, built by Pierre; the latter uses Diffs, also built by Pierre. Both of these toolsets were integrated into Codex long ago.
Pierre also runs another business calledCode Storage, and among its customers is the AI app development platform Lovable.
By typing a few sentences into Lovable, users can build a website. Behind the scenes, each project needs one or more Git repositories to store the code and its modification history.
According to data Pierre disclosed in August this year, at that time Lovablecreating more than 8 million new repositories per week, with a peak of 250 per second.
OpenAI plans to bring Code Storage's capabilities into Codex once the acquisition is completed.
From then on, having AI write code, checking what it changed, and saving that version could all be done inside Codex.
For now, the deal still has to satisfy closing conditions such as regulatory approval.
The day Cursor opened code hosting, GitHub also went down
You may remember that on August 14, Musk's SpaceX completed its acquisition of Cursor.
Three days later, Cursor's code hosting service Origin opened early testing.
And as it happened, on August 17, GitHub suffered an outage lasting7 hours 47 minutes.
Cursor employee Matt Palmer even cracked a joke at the time, to the effect that they had wanted to launch earlier, but GitHub, it— it went down again!!
Origin gave developers two options: for new projects, they could create repositories directly in Origin, and pushing code to Cursor, requesting reviews from colleagues, receiving change feedback, and merging branches could all bypass GitHub.
For older projects already on GitHub, you could also just sync a copy to Cursor.
Comments you left in Cursor could be seen by teammates back on GitHub, and the code on GitHub still remained the authoritative version.
So here comes the question:
if writing code, reviewing code, and merging can all be done in Cursor, why would I specifically open GitHub?
Even for older projects whose repositories remain on GitHub, code reviewers no longer need to go there.
Claude wrote code so fast that Anthropic had to build its own system
OpenAI and Cursor have connected more development operations into their own products, while inside Anthropic, the workload had grown so large that the code management system needed to be redone.
Mainly because Claude writes code just too fast…
According to Anthropic's disclosure, in May — the 5th month of this year — the company was merging an average of about 2500 code changes per day. By September, the 9th month, a single day had already exceeded 30,000.
That means more than 30,000 modifications were being merged into the team's shared code version every day.
Just for continuous integration tasks used for automated testing and similar work, code was being fetched about 25 million times a day.
At peak, the company maintained hundreds of Git mirrors, using these repository copies to share the load. But the faster the main repository updated, the harder these copies became to maintain.
Engineers found that most of those fetching the code were always-on Agents and automated tasks.
For some tasks that only need to know which lines of a file changed, why prepare a full local copy of the repository first? Just have the server compute the result and send it over.
Following this line of thinking, Anthropic builtScion。
The client fetches whichever file it needs, while querying history, creating commits, and merging changes are handled by the server.
7 engineers, using Claude, spent 5 months building this internal version control system, along with the accompanying code review tool Antique and more, and migrated the company's entire main codebase over to it.
However, Scion primarily serves large-scale internal codebases with frequent changes, like Anthropic's.
Community resources such as the public repository of Claude Code remain on GitHub.
Thirty thousand changes a day — who checks them?
Once code can be obtained faster and stored more smoothly, there is a trickier problem:
How do you decide whether these modifications can be accepted?
In a recent conversation, Anthropic'sAddy Osmanidescribed their approach:
First have Claude do a round of review, and also give it the conditions to run the features like a real user.
For example, if the change is to a web page, have it open a browser, check the page, exercise the features, and then run the necessary tests.
Engineers then examine the verification evidence it submits, including operation recordings, page screenshots, and test results. Every change still has a person responsible for it, and if something goes wrong, the responsible person has to deal with it.
△ The code-change inspection and release process published by the Claude Code team
Anthropic's engineering blog also mentions an even more troublesome scenario:
During a round of test runs, hundreds or thousands of changes may have been merged into the codebase again.
At that scale, the team found that the approach of using a repository-wide global lock to coordinate the merge queue was hard to run effectively, so they shifted their focus to automated testing after merge and before deployment.
The company also admits that concurrent modifications can still conflict.
They claim that Claude can usually complete conflict fixes faster than humans, but did not disclose the corresponding quantitative results.
One More Thing
Reading this far, you might think:What about GitHub then?
GitHub, in fact, has not been idle either; it is redoing its underlying layer itself.
On October 28, it disclosed that this year it has added 4 million CPU cores and 160PB of high-speed storage, and continues migrating its services to Azure.
Beyond adding resources, the original queuing approach also had to change.
In the past, even if several Agents submitted changes on different branches, they could still wait on each other at the write stage of the same repository. GitHub is making these updates processable in parallel, reducing unnecessary queuing.
△ On the left, queuing by the entire repository; on the right, updates to different branches and other references are allowed to proceed in parallel
After code is stored, a large number of automated test tasks will come to access it.
GitHub is also separating the resources used for reads and writes. When more tasks come to fetch code, it scales up the services responsible for reading separately, reducing resource contention between the two sides.
These renovations are still being rolled out step by step.
OpenAI and Cursor have started providing code hosting themselves; Anthropic is redoing its internal systems; and GitHub is also transforming its own infrastructure.
So everyone is coping with the development workload brought by AI.
As for us users, our demands are actually quite simple:
When the code is written and everything that should be checked has been checked, don't mess things up again when it's time to merge it in...
Reference links:
[1]https://x.com/FrenchBoulou/status/2117919227147640978
[2]https://x.com/pierrecomputer/status/2117999036175188183
[3]https://www.axios.com/2026/11/04/openai-pierre-computer-github
[4]https://www.anthropic.com/research/redesigning-source-control
[5]https://www.youtube.com/watch?v=AnsXWH2_EBU