我最近看到一則 Threads 在聊一個很有趣的現象：AI coding 變快之後，開發團隊的新瓶頸不再是「寫得出來」，而是「看得懂、審得完、追得回」。

貼文提到 GitHub 執行長 Thomas Dohmke 參與的新創（文中稱 Entire），在種子輪就募到 6,000 萬美元、估值 3 億美元，主打要處理 AI 生成程式碼帶來的版本管理與可追溯性問題。數字我沒有去逐一核對，但它點到的痛點很真實。

Threads 原文連結

AI 讓「版本控制」這件事變得不夠用

過去十幾年，Git 幾乎定義了軟體開發的協作方式：

• 我們用 commit 把改動打包
• 用 diff 讓人類審閱
• 用 branch/PR 來管理風險
• 用 blame/commit history 追責與追溯

這套機制背後有個隱含前提：變更的速度大致跟人類能理解的速度同一個量級。

但當你把 AI Agent 放進來，變更速度會直接跳一個維度：

• 一個 agent 可以在幾分鐘內嘗試數十種改法
• 一個 workflow 可以在多個 repo 同步改動
• PR 像連續噴射一樣進來，審閱者的注意力被快速耗盡

真正的災難不是「AI 會寫錯」，而是「AI 會寫很多、而且看起來都像對」。

最後結果常見兩種：

1. 團隊被大量低品質變更淹沒，乾脆把 gate 開得更嚴，速度又掉回去
2. gate 來不及守，品質往下滑，維運成本用另一種方式爆炸

關鍵不是多一個工具，是多一層「可理解的脈絡」

貼文提到一個產品方向：把 AI 寫程式的「提示詞」與「思考脈絡」跟程式碼綁在一起，像是把每次生成都做成可追溯的 checkpoint。

我覺得這個方向的價值不只是 debug。

它在解決一個更根本的問題：當變更源頭不再是人類鍵盤，而是模型與 agent 的連鎖決策時，我們需要新的可解釋層。

在企業落地內部 AI 助理時，我最怕的是這種狀況：

• repo 裡多了一段 code，但沒人知道為什麼要這樣寫
• PR 描述很漂亮，但它其實是 LLM 自動補上的敘事
• 出問題時，只能靠人把上下文「猜回來」

如果能把「這次改動是因為什麼需求／哪些限制／參考了哪些文件／做過哪些嘗試」以機器可讀、也讓人類可快速掃過的格式保存下來，審閱效率會差很多。

我會怎麼把它落到工程流程裡

假設你真的要在團隊裡導入 agentic coding，我會優先做的不是「讓 agent 寫更多」，而是把可追溯性當成系統的一部分：

• 每次 agent 變更都要附上 provenance：輸入（prompt、規格、資料源）、輸出（改動）、以及驗證（測試結果、lint、benchmark）
• 把「意圖」變成可檢索的資料：不要只留在 PR 描述，把它存成結構化 metadata（例如 JSON sidecar、commit note、或專用的 checkpoint store）
• 把審閱從逐行 diff 轉成「分層審閱」：先看意圖與驗證摘要，再決定哪些檔案需要深讀
• 建立降級路徑：一旦信心不足，就讓系統自動縮小改動範圍、回到保守策略，或把人叫進來做決策

這些做完，你才有資格談規模化。

「又一個抽象層」其實是必然

我看到留言有人吐槽：「又是新的抽象層嗎……」這句我很有感。

答案是：會，而且很可能是必要的。

當開發從「人寫程式」走向「人設計工作流、機器產生改動」，版本控制要管理的對象就不只是 code，還包含：

• 生成策略（prompt、tool policy、agent 設定）
• 決策過程（思考脈絡、嘗試紀錄）
• 驗證證據（測試、對照、觀測）

你如果只管 code，本質上是在管最後一張輸出紙；問題是 AI 時代的關鍵常常藏在「輸出之前」。

我預期接下來一年，開發工具會出現一波很大的分水嶺：能把 agent 的產出變成可被審閱、可被追溯、可被治理的，才會真的進到企業主流程。

AgenticWorkflow #AICoding #DeveloperTools #人機協作 #AI落地實務