所有軟體工程師現在都是 QA

2026 年 6 月初，Anthropic 公布了一項引發爭議的統計數據。大多數 Anthropic 公開發表的言論都會引發大量嘲諷評論，因此請自行判斷。引述與統計數據顯示，Anthropic 80% 的程式碼是由 Claude 產生的。新功能甚至高達 90%。

有趣的是 a) 這真的很瘋狂 b) 它讓我想起可能發生的一件有趣的事。自從 2022 年底這波 AI 熱潮開始以來，我曾經開玩笑說過：所有軟體工程師最終都會變成 AI 生成程式碼的 QA。

信任但需驗證

先來探討 (a)：為什麼這很瘋狂。這是個大膽的說法，但我想指出一些問題。Claude Code 是一個很棒的工具。我是日常使用者，偏好使用「信任但需驗證」的方法透過 Claude Code 進行程式設計。我所有關於軟體和基礎設施的問題都得到了令人滿意的回答，當我不相信時，我會自己驗證答案。如果它寫程式碼，我就檢查。所以，AI 工具所寫程式碼的狀態其實無關緊要。只要最終產品對大多數使用者來說品質良好就行了。這就是第一個問題：它不應該只對大多數使用者品質良好，而應該對所有使用者品質良好。如果你使用 AI 程式設計工具來生成程式碼，我希望你花點時間找出如何正確確保品質，而不是花額外時間編寫有錯誤的程式碼。每個軟體工程團隊都有交付可運作程式碼的優先事項。但如果你使用 AI 程式設計工具將產出 10x，那麼也許可以放慢一點，將產出 7x，並將 3x 用於提升品質。

當人類編寫程式碼時...

2026 年初，我們看到 Claude Code 的原始碼外洩。這些程式碼遠非乾淨。網上普遍的看法是它只是「混亂的生產程式碼」。由於缺乏良好的 QA 流程和寬鬆的標準，遺留程式碼一段時間後會變得混亂。這聞起來像是急著讓東西在 Production 環境運作的味道。而這沒問題...當人類編寫程式碼時。我們都曾經急著將程式碼推送到 Prod 並偷工減料。

這是我對這個論點的第二個問題。當 AI 編寫程式碼時，我期望更高的標準。作為軟體工程師，你有更多時間檢查你的工作。你有更多時間思考如何解決問題。

有報告指出 Claude Code 原始碼中的 main.tsx 長達 4,683 行。它可能從來就不是為了讓人類理解或修復而設計的。這讓我想到，當 tokens 用完且 main.tsx 出現問題時，誰會修復它？原始碼中有 460 個 eslint-disable 註解。如果不強制執行 eslint 規則，那為什麼要有這個規則呢？還有一些經典的註解如 // TODO: figure out why 和 // This fails an e2e test。再一次，我認為如果 80% 的程式碼是由 Claude 編寫的，那麼花費這 80% 的一部分來修復錯誤和找出奇怪的失敗不是更好嗎？

在這個階段有一個重要的事實要記住；Anthropic 製造這些模型，因此很可能能夠為其模型提供大量的 tokens。這意味著他們可以消耗 tokens 來建立稀薄、笨重的 AI 生成程式碼湯。這讓我想到 Claude Code 的程式碼實際上效率有多低，發生了什麼樣的記憶體洩漏，以及這些實際造成了什麼錯誤。

生成程式碼，提升品質

如果我們為人類建立軟體，在軟體開發過程中有人類參與測試至關重要。Anthropic 聲稱 80% 到 90% 的程式碼都是由 Claude 建立的，這有其意義。當 AI 程式設計工具逐漸編寫更多程式碼時，常見的回應是可以在其他任務上花費更多時間。指導 LLMs、設定迴路、偶爾進行程式碼審查、對其輸出進行合理性檢查。其中之一也可能是花時間提升品質。考慮到幾乎不可能分配一些開發時間來修復技術債務，這很難說服。但 AI 編寫的程式碼有品質問題會變得更加明顯，更多人將不得不參與確保品質。總是會有想要建立程式碼的軟體工程師；然而，我可以想像一個世界，大多數從事軟體開發的人將成為機器編寫程式碼的 QA。