多數挑戰 GitHub 的對手，承諾的是同一套流程的更好版本。Zed 的主張則是這套流程本身已經過期，並把 Delta 推入公開測試來證明——那是一個以開發者與程式代理共用一條即時討論串、取代 pull request 的環境。這個說法比多數同類主張更有分量，因為 Zed 已經自己付過代價：Delta 自家的儲存庫關掉了 pull request，33 名員工在沒有 PR 的情況下把 570 項變更送進 main。
重點摘要
- Delta 跑在 DeltaDB 上。DeltaDB 會保留 Git 兩次提交之間發生的編輯，以及人與代理之間的對話——這些正是 Git 平常會丟掉的素材——而提交本身仍是團隊推送與建置的檢查點。
- 審查者不再讀 diff，而是加入討論串，直接繼承原代理的脈絡，並取得上層工作樹的獨立副本，可以在不干擾作者的情況下執行與修改程式。
- 測試版免費，可在 macOS、Linux、Windows 與網頁上使用，也能從行動瀏覽器存取討論串；付費方案已預告，但尚未定價。
診斷：審查流失的是脈絡，不是規模
Pull request 問世約 15 年，內建了一個正在悄悄失效的假設：寫出那份 diff 的人有辦法解釋它。一旦大部分程式碼由 AI 代理產出，量會一直長，但推理過程卻鎖在審查者從未看過的那段工作階段裡。
對於常見的緩解做法，Zed 講得很直白。把一大筆變更拆成堆疊分支，確實比較好一頁頁翻，卻不會還原任何思考；把 diff 貼給第二個代理，等於要它重新推導作者早就拍板的決定。這兩種做法都把「看不看得懂」當成排版問題。Zed 的問法——為什麼同事的代理得去猜你是怎麼走到這一步的——則把病灶放在另一處：工具在提交那一刻丟掉的東西。
實際上會改變什麼
最實際的轉變是，協作不必再等推送。同事被邀請進一場與代理仍在進行中的對話，看到同一批工作樹，各自在自己的機器上動手；由於代理的脈絡跟著討論串走，審查者可以直接問它，作者當初為什麼選 Mutex 而不是 RwLock。作者登出後工作仍然存續，審查也能拆成子討論串——獨立的工作樹副本讓審查者不只是標記問題，而是直接動手修，再把結果在變更落地前折回主線。
最後這項能力才是真正新穎之處，未解的問題也集中在這裡。審查者親手改程式的審查，模糊了讓審查之所以是獨立把關的那條界線；有稽核或法遵義務的團隊，會想知道討論串內部如何歸屬作者身分與核准。Zed 目前還沒有說明這一塊。
導入刻意只做一半
這裡沒有任何環節要求全有或全無的遷移，Zed 自己就示範了那個中間狀態：zed-industries/zed 仍留在 GitHub，社群照樣在那裡開 issue，同時鼓勵貢獻者把 Delta 討論串與 pull request 並陳。由於 DeltaDB 是延伸 Git 而非取而代之，從未安裝 Delta 的同事看到的仍是一個普通儲存庫——這讓試用隨時可以放棄，成本極低，也很可能是這項產品最重要的設計決定。
路線圖比測試版野心得多。Zed 把目標流程稱為「持續工程」，理由是整合與交付早已走向持續化，工程的其餘部分卻還停在批次模式。該公司計畫把 Git 儲存搬進 DeltaDB，最終透過以內容為基礎的建置，把 CI 等級的驗證也拉進討論串。目前代理能做的，只是觸發既有的 CI 供應商，並在變更落地前讀取結果。
展望
把代理寫的程式碼當成重建開發平台的理由，並非 Zed 獨有的立場——Cursor 也以相近的前提，用 Origin 瞄準 GitHub 的核心流程。Zed 不同之處在底下那個賭注：對手仍把分支、提交與 diff 留作基本單位，Zed 則預期討論串會成為軟體開發的單位，而差異（delta）才是描述其狀態的正確方式。這個主張能走多遠，要由商業條件決定，而除了「會保留某種免費版」的承諾之外，那些條件還沒公布。
FAQ — 常見問題
Delta 會取代 Git 嗎？
不會。DeltaDB 是在 Git 以內容為基礎的版本管理之上，疊加以差異為單位的增量版本，而推送、拉取與建置的對象仍然是提交。新增的是兩次提交之間的工作，那是 Git 不會保留的部分。
Delta 可以免費使用嗎？
公開測試期間免費。Zed 表示正在準備給個人與團隊的付費方案，並承諾免費版會一直存在，但尚未公布價格，也沒有說明免費方案會包含哪些功能。
團隊可以不離開 GitHub 就導入 Delta 嗎？
可以，而 Zed 在自家開源儲存庫上跑的正是這種安排。貢獻者把 Delta 討論串放在 pull request 旁邊一起分享，而從不打開 Delta 的人，仍然對著一個標準 Git 儲存庫工作。
