這是 GitHub 工程部門公開的下一代 Git 基礎架構規劃，作者是 GitHub 首席軟體工程師 Brian Celenza。文章指出，隨著 AI 代理與開發者一起在同一個儲存庫裡頻繁提交程式碼，傳統 Git 架構面臨前所未有的壓力：過去一年，Git 相關事件量成長超過 2 倍，開發者代理產生的提交次數更成長了 5 倍，逼使 GitHub 重新思考底層架構該如何支撐這種「代理規模」的開發節奏。
GitHub 目前採用的 Spokes 系統讓每個儲存庫在多台檔案伺服器上保留完整副本，但這種設計把「耐久性用的副本」和「擴充用的副本」綁在一起，一旦增加副本反而拖慢寫入速度。新架構改採「儲存與運算分離」：程式碼本體交給 Azure Blob Storage 集中保管，前端再由大量輕量運算節點負責讀取與快取，寫入動作則盡量只保留「更新參考」這一步需要協調，其餘像物件儲存、驗證、秘密掃描都能平行處理。
GitHub 公開的內部測試數字顯示，這套新架構能讓寫入吞吐量提升到原來的 35 倍，讀取容量也能依照需求獨立擴充，不再被寫入效能卡住。GitHub 特別強調，這套設計仍建立在開發者熟悉的分支、審查、合併流程上，即使有大量 AI 代理同時送出提交，程式碼擁有者依然保有審查與核准的控制權，不會因為自動化規模變大而失去把關能力。
對正在學程式的孩子來說，這篇文章比較偏工程基礎架構面，不是能直接上手操作的工具，但它說明了一個重要觀念：當很多人、甚至很多 AI 同時在改同一份程式碼時，背後需要一套機制決定「誰先誰後、怎麼合併」，這正是學習版本控制（像 Git）時會碰到的核心問題，值得作為日後理解團隊協作開發的參考。
GitHub開發工具基礎架構AI