Thorsten Ball 的軟體開發未來論:Code Review、Unit Test、Terminal 真的會消失嗎? | Allen 知識庫 | Allen 知識庫Thorsten Ball 的軟體開發未來論:Code Review、Unit Test、Terminal 真的會消失嗎?
摘要
Threads 帳號 @dapper_penguin_style 翻譯並整理一組歸因於 Thorsten Ball 的激進預測:AI Agent 將讓逐行 Code Review、Unit Tests、手寫程式、Terminal、PM/Design/Engineering 分工甚至現有開源模式失去意義;真正重要的能力會轉向定義問題、架構系統、驗證成果與取得足夠 Token 運算資源。
這組論點最值得保留的不是「哪些工具必死」,而是核心轉向:
軟體生產的稀缺資源,正在從輸入程式碼,轉向提出正確需求、設計驗證機制、組合系統與承擔結果。
但多個「消失」式主張仍屬預測而非已證實結論。尤其把「模型曾一次產出 900 行可運作 Arduino C」推論成 Unit Tests 不再需要,缺乏可重現資料與跨場景證據。
來源與身分查核
Thorsten Ball 的官方個人網站確認:
- 他是 Amp 的共同創辦人/共同創作者;
- 曾任職 Sourcegraph 與 Zed;
- 著有並自行出版《Writing an Interpreter in Go》與《Writing a Compiler in Go》。
因此人物背景正確;但在沒有原始英文來源的情況下,本文只能確認 Threads 串文完整內容與人物身分,不能獨立證明每句中文都是逐字、完整、無脈絡偏移的翻譯。
14 項預測完整整理
- 逐行 Code Review 會消失:模型產生的程式量將超過人類合理審查能力;人類改為審查整體系統與組成方式。
- Unit Tests 可能消失:若模型幾乎不跌倒,就不需要「輔助輪」。例子是一段 900 行 Arduino C 一次編譯並正常運作。
- 「寫程式碼」的手藝會消失:像手工鞋匠仍存在,但不再是主流生產方式。
- 「打造軟體」反而更重要:商業問題、歷史解法、失敗原因、上市時機與使用者回饋成為主戰場。
- 多數 bug 變成需求 bug:不是 coding bug,而是「一開始要求了錯的東西」。
- 現行開源軟體模式不再合理:Linus's Law 仍成立,但「足夠多雙眼睛」將包含 AI 眼睛。
- 人類手動效能優化仍是少數 edge case:大部分軟體的首要問題不是演算法極致,而是有沒有使用者;真正需要時模型會優化。
- Terminal 對人類會死去:Shell、文字編輯器、CLI flags、jq 等工具將被 Token 介面包覆。
- :軟體將重建在概率式 Token 系統之上,進入所謂「後二進位時代」。
Token 是新的運算典範
PM/Design/Engineering 三角與 Agile/Scrum 會消失:只負責把 ticket 轉交 Agent 再回報的人類 proxy 沒有價值。大公司與小公司工程方式會分化:新創照搬 Google 流程會更荒謬,因為可以更快、約束更少地造產品。Good Code 的既有標準可能失效:很多規範是為降低人類維護成本;若主要維護者是 Agent,80 字元、換行等規則意義下降。Token 取得能力造成新數位落差:沒有足夠運算資源的人會落入二級聯賽;更強模型因少犯錯、少互動,可能比便宜模型更划算。UI 會即時生成,但轉型需要一個世代:選單、設定、Dashboard、篩選器是「人類操作笨機器的 API」;聰明機器可依意圖即時產生介面,但舊系統與舊職缺仍會存續多年。評論區的高訊號反方觀點
1. 商業效率與程式工藝的拉扯
@akiwu40000 將分歧整理成兩派:一派認為架構與結果正確即可,不必逐行看 AI code;另一派堅持人類必須看過、修正,以維持 codebase 品質。其判斷是資本效率會推動前者大量發生,但後者代表可維護性與工程工藝的風險意識。
2. Unit Test 在 AGI 前仍是 Agent 的護欄
@jacky_inga_gunnar 的反駁最關鍵:即使真正 AGI 出現後測試角色可能改變,在那之前 Unit Tests 仍可防止能力較弱、上下文缺失或接手修改的 Agent 破壞既有行為。
3. Code Review 會由「逐行」轉成「意圖與驗證」
@i_0a0_j 認為 AI 讓 codebase 快速增長,逐行 review 確實不現實;但意圖清晰的 Good Code 對人和 AI 仍有意義。這比「Code Review 死亡」更精準:審查單位改變,而非驗證責任消失。
4. 模型之外仍需 Harness 與 Orchestrator
@jelly.fish.fish.jelly 指出 AI coding 的可靠度不只來自模型,還來自工程師逐案打造的 harness 與 orchestrator。換言之,測試、權限、回滾、觀測、eval 與工作流並沒有消失,而是往 Agent 系統層上移。
5. Token 經濟的誘因
@lanporuoji 質疑按 Token 收費的供應商未必有讓第一次輸出完美的商業誘因。這個評論無法直接證明供應商刻意降低品質,但提醒企業必須同時衡量單次 Token 價格、重試輪數、錯誤成本、延遲與 vendor lock-in。
哪些論點可信度較高
高可信的方向
- 手寫程式碼比例下降:Thorsten Ball 官方文章與 Amp 定位都直接反映 Agent 代做大量實作工作。
- 工程價值上移到需求、架構與驗證:當生成成本下降,決定「做什麼、為何做、如何證明正確」自然變得更稀缺。
- 逐行 PR review 難以跟上生成量:審查會朝風險分級、架構邊界、行為驗證、可觀測證據與自動化 review 轉移。
- 新創不應照搬超大型企業流程:流程應依風險、法規、團隊與失敗成本設計,而非按公司聲望複製。
中度可信、需限定語境
- Terminal/固定 UI 淡出:人類可能更少直接操作 CLI,但 Agent 仍大量透過 CLI、API、結構化工具與 deterministic systems 執行工作。比較像「介面隱藏」而不是「底層消失」。
- Good Code 標準重寫:純格式規範的重要性可能下降,但模組邊界、型別、契約、資料流、權限、可觀測性與可恢復性,對 Agent 反而更重要。
- Token 成為生產資本:算力與高階模型會造成差距,但小模型、快取、工具化與開源模型也可能降低集中化風險。
目前證據不足或過度強化
- Unit Tests 消失:一次成功的 900 行案例不能證明跨需求、跨環境、跨版本與惡意輸入仍正確。測試也不只是防止第一次生成錯誤,更是可執行規格與未來回歸護欄。
- Code Review 完全死亡:人類逐行審查可能減少,但安全、隱私、授權、資金移轉、資料刪除、基礎設施和法規領域仍需要可追溯 review 與責任人。
- 開源現行形式不再合理:AI 可以新增「眼睛」,也能大量產生低品質 issue、PR、套件與供應鏈攻擊;治理、信任、maintainer 與 provenance 反而更重要。
- 模型會自行修正所有效能問題:沒有 benchmark、profiling、SLO、真實流量和成本目標,模型同樣不知道何謂「足夠快」。
給 BigIntTech 的可執行解讀
不要押注「測試和審查消失」,應押注它們的抽象層級上移:
- 需求改寫為可驗證 acceptance criteria 與 failure budget;
- Agent 產碼同時產生測試、執行證據、截圖、效能數據與安全掃描;
- Review 從逐行掃 diff,轉成風險分級:資金、權限、個資、不可逆操作必須人工核准;
- 使用 ephemeral sandbox/branch/worktree,主環境不作為 Agent 的試驗場;
- 保留 deterministic verifier:型別、lint、單元/整合/E2E、schema、policy、contract、回歸資料集;
- 用模型複核模型,但不要讓同一個生成脈絡同時當唯一裁判;
- 衡量「完成任務的總成本」,不是只看 Token 單價:包含重試、人工救援、事故與維護成本。
最終判斷
這不是一份可直接採信的 10 年預測,而是一個很有價值的壓力測試:如果程式碼本身接近免費、生成量遠超人類閱讀量,公司的流程、職能與品質系統是否還成立?
工程師從製造每一行,轉成設計能讓 Agent 安全、可驗證、可回滾地製造軟體的系統。
來源
查核限制:Threads 串文沒有附原始英文來源。本文確認人物背景、Amp 關係、Threads 全串與評論,但未將中文翻譯標示為 Thorsten Ball 的逐字引文。