GitHub 工程師在 2026 年 11 月 5 日的文章中說明，公司重新設計了 Git 儲存架構，原因是 AI 代理同時並行寫入程式碼的規模遠超傳統協作。舊架構每秒只能處理數十次寫入，難以應付單一儲存庫需要支援數千個代理、每秒上千次推送的情境。
這套新架構內部代號 Project Rubicon，把運算與儲存拆成四層：無狀態的虛擬副本節點負責讀寫請求；Ref-CAS 服務把每次參考更新變成獨立的比較交換操作，由多數節點仲裁提交；Git 封包與索引存放在 Azure Blob Storage；另外還有獨立運作的壓縮節點持續在背景合併封包。
GitHub 提供的數據顯示，某個熱門儲存庫每日請求量從 3 月的 4,400 萬次成長到 5 月的 1 億 8,100 萬次，等於四倍成長，單一儲存庫最高要扛住每秒 7,200 次推送。新架構讓寫入延遲隨寫入量增加仍維持平穩，這點被視為因應 AI 代理大量平行開發的關鍵。
這篇文章偏向 GitHub 內部工程團隊的基礎設施紀錄，說明的是大型平台如何支撐數千個 AI 代理同時改程式碼，對正在學寫程式的孩子來說比較抽象，沒有可以直接練習的工具或教材；不過它示範了軟體系統在規模變大時必須重新設計架構，是觀察「工程師如何解決大問題」的好例子。
AI開發工具軟體架構