使用 AI 工具的觀點與軟體工程師角色的未來

問題#

人們對使用 AI 工具有哪些看法？軟體工程師角色的未來又會如何？

摘要#

這個 wiki 中的來源可歸納為四種截然不同的立場：看好者內部人士、務實派實作者、懷疑派治理觀點，以及架構論點。儘管對發展速度和風險看法不同，他們對 SWE 角色的走向大致看法一致：編碼能力會成為基本門檻，差異化優勢則轉向決定要打造什麼、設計代理程式的工作環境，以及驗證輸出。領域知識與人類判斷力的價值上升；純粹的編碼產出速度則貶值。坦誠地說，這些證據大多來自 Anthropic 內部，另有一位獨立實作者；最鮮明的預測（「100 行程式碼」）是當事人自己說的誇飾，而這組材料中唯一嚴謹的實證研究（HBR / Kropp et al.）提出的是警訊，並非背書。

第一部分 — 使用 AI 工具的觀點（四種立場）#

立場 A — 看好者內部人士：「編碼已經解決，harness 正在縮小，迴圈才是未來」#

主要發言者：Boris Cherny（Claude Code 的創作者）、Cat Wu（Claude Code 與 Cowork 的產品主管）。

「對我來說，編碼已經解決了。」 Boris 表示自己 100% 的程式碼都透過 Claude Code 撰寫，曾有一天提交 150 個 PR，並以手機為主，每天運行數百個代理程式、夜間運行數千個（Boris Cherny）。明確的但書：對非常大型的程式碼庫或分布外語言，這還不成立。
harness 應該縮小，而不是擴大。 模型進步，harness 隨之縮減：每次模型發布，團隊都能刪掉一些提示詞段落；Boris 預測 Claude Code「一年後可能只剩 100 行程式碼」（他說明這是誇飾，但方向確實如此）。Cat Wu 的做法是：每次啟動都讀完系統提示詞，並刪除新模型已能原生處理的內容。
能力會往模型內部遷移。 /loop 原語（參見代理程式迴圈模式）從 harness 功能轉變為模型原生行為，在 Opus 4.7 中已經如此——「我注意到資料正在變動，就會啟動一個迴圈，每 30 分鐘回報一次。」Boris 說：「到了現在，迴圈就是未來。」
為下一個模型打造，而不是為眼前這個。 Anthropic 在 2024 年底推出 Claude Code 時，明知它還有約 6 個月才會達到 PMF，仍押注下一個模型能補上差距（模型進步，harness 隨之縮減）。
軟體開發將普及化。 印刷術帶來的軟體民主化：就像 Gutenberg 發明印刷術後識字能力普及，軟體撰寫也會擴散；「最適合寫會計軟體的人，是很優秀的會計師，而不是工程師——編碼才是簡單的部分。」Boris 預測，未來十年，足以造成顛覆的初創公司將增加約 10 倍。

立場 B — 務實派實作者：「AI 工具很強大，但軟體工程基本功決定上限」#

主要發言者：Matt Pocock（獨立 AI 編碼教育者，打造了 Sandcastle）。

基本功依然適用。「我們忘了，軟體工程基本功——那些和人合作時至關重要的東西——用在 AI 上也一樣非常有效」（Matt Pocock）。他引用 Brooks、Pragmatic Programmer、Ousterhout、Fowler。
「糟糕的程式碼庫會造就糟糕的代理程式。」 模型進步，harness 隨之縮減提出另一種看法：「如果你的程式碼庫沒有回饋迴圈，你永遠、永遠、永遠都無法從 AI 得到像樣的輸出。回饋迴圈的品質會影響 AI 編碼的能力。這就是上限。」測試、型別、linter、獨立的審查環境都是不會遷移到模型裡的基礎設施。
管理上下文預算。 上下文視窗的智慧區：無論宣稱的視窗多大，LLM 的表現都會隨著上下文增加而呈二次方退化，約有 100K token 的「智慧區」；100 萬 token 的視窗「只是增加了很多愚蠢區」。與其壓縮上下文，不如優先使用 /clear。
從規格到程式碼只是「換個名字的氛圍編碼」。 戰場在程式碼，而非規格；動手規劃前，先和模型達成一致的設計概念（設計概念深度提問）。
審查是 2026 年尚未解決的問題。 代理程式交付更多程式碼時，人類也得審查更多程式碼——這個持久瓶頸無法靠迴圈取代。
這與官方工具指引一致：Claude Code 最佳實務和代理程式 harness 工程都指出，AI 生產力取決於環境設計（把 CLAUDE.md/AGENTS.md 當作目錄、以驗證為主導的迴圈，以及探索→規劃→編碼）。

立場 C — 懷疑派／治理觀點：「風險不在能力，而在組織如何定位並監督 AI」#

主要發言者：Kropp、Bedard、Wiles、Hsu、Krayer（HBR，2026 年 5 月，以及 2026/03 的「brain fry」論文）——這是本 wiki 中唯一有隨機實驗證據的一組研究。

把 AI 擬人化會削弱問責。 AI 員工定位（n=1,261；效果集中在約 23% 已把 AI 代理程式列入組織架構的組織）：其他條件都相同時，把代理程式定位成「員工」而非「工具」，會使個人問責下降 9 個百分點、歸因於 AI 的比例增加 8 個百分點、不必要的升級處理增加 44%，並讓被發現的錯誤減少 18%——採用意願沒有提升。
「腦力耗竭」真實存在，而且可以測量。 AI 腦力耗竭：超出認知能力的監督所造成的精神疲勞，與輕微錯誤頻率增加 11%、重大錯誤頻率增加 39% 有關。工具定位會增加審查者的負擔；員工定位則以投入不足取代這種負擔。兩種定位都有代價。
真正促進採用的是管理者以身作則，而非組織架構圖上的象徵——AI 成熟的公司中，管理者在日常工作中明顯使用 AI 的可能性是其他公司的 3.5 倍（AI 員工定位）。
解方是從結構上重新設計，而不是「擴大管理幅度」：以抽樣稽核取代每項輸出都審查；將審查集中在高風險決策點；讓人類從逐項輸出審查轉為系統層級監督；調整績效管理，獎勵協調與編排（人類與 AI 的問責機制重設、AI 腦力耗竭）。

立場 D — 架構論點：「harness 會融入模型，互動也不例外」#

主要發言者：Thinking Machines Lab（互動模型，2026 年 5 月）；Sutton 的觀點見苦澀的教訓。

苦澀的教訓再次應驗。 苦澀的教訓：擴展通用方法勝過手工打造的結構。在整個 wiki 中，這是支持 harness 融入模型的關鍵理由——但有個但書：機械式驗證與性格或許不會遷移到模型內部。
不只程式碼，還包括介面。 互動模型／Turn-Based Interface Bottleneck：今天的輪流對話介面本身就是頻寬瓶頸；VAD／輪次偵測／對話管理的 harness 應融入模型。「只有當互動性在模型裡，互動性才能隨智慧提升而擴展。」這是在互動層面採取同樣的 harness 縮減做法。

各立場的真正衝突之處#

問題	看好者內部人士 (A)	務實派 (B)	懷疑派 (C)	架構論點 (D)
編碼是否「已經解決」？	是，對我來說，現在就是	否——受程式碼庫品質限制	問題問錯了；問題在監督	趨勢上是，從結構來看
harness 長期來說重要嗎？	會縮減到近乎不存在	驗證的部分仍是承重結構	—	融入模型
最大風險	為錯誤的（當前）模型打造	糟糕的回饋迴圈 → 糟糕的代理程式	問責責任分散、腦力耗竭	手工打造的支架被超越
證據基礎	內部軼事、創辦人說法	實作者經驗	隨機實驗，n=1,261	新研究實驗室的架構與基準測試

A 和 B 的共識比表面看起來更多：Boris 承認 harness 的驗證層會持續存在；Pocock 則承認實作可以完全交由代理程式自行處理。C 是另一個面向——談的是組織設計，而非模型能力。D 最具推測性（單一研究實驗室在 2026 年 5 月提出的論點）。

第二部分 — 軟體工程師角色的未來#

2.1 核心轉變：從「撰寫程式碼」到「決定要打造什麼＋驗證是否運作」#

Cat Wu：「隨著寫程式碼變得便宜得多，變得更有價值的事情就是決定要寫什麼」（工程師與 PM 角色融合）。
Boris Cherny：瓶頸會從編碼轉移到領域知識——會計師／醫生／律師／教師為自己的領域撰寫工具（印刷術帶來的軟體民主化）。
這個角色大致分成三種持久工作：(1) 產品判斷——挑對事情；(2) harness／環境工程——設計代理程式工作的支架；(3) 驗證與審查——負責機械式回饋迴圈，以及在全新上下文中進行審查（學會與 AI 協作：軟體工程師實用指南）。

2.2 角色融合，團隊縮小#

工程師與 PM 角色融合：在 Anthropic，Claude Code 團隊裡的每個職能角色都會寫程式碼（EM、PM、設計師、資料科學家、財務人員、使用者研究員）；工程師「幾乎不需要產品團隊介入，就能在週末前從 Twitter 回饋做到產品上線」。招聘偏好：「產品品味出色的工程師。」影響包括：不論職稱都看重品味、大力推動跨職能訓練、更小而且端到端負責的團隊、更精簡的 PRD、職涯階梯逐漸分化。仍待解答的問題：這種模式能否擴展到約 50 人以上的團隊？Boris 保留態度——「幾年後才知道」。相較之下，Anthropic 內部另一種看法（成長部門主管）認為，快速交付的工程師需要更多 PM／設計支援，而不是更少——也就是說，團隊形態取決於組織職能。

2.3 哪些工作仍由人類負責（價值上升的技能）#

熟練程式碼審查——代理程式交付更快後的新瓶頸（Matt Pocock、AI 原生產品節奏）。
跨職能 EQ／默會判斷——知道應該在哪裡討論、感受發布時機是否成熟，以及怎樣才算公平的取捨；Cat Wu 明確指出，這些不會融入模型（工程師與 PM 角色融合）。
領域深度——能開始打造工具的會計師，勝過不了解領域的工程師（印刷術帶來的軟體民主化）。
以使命／價值觀清晰作為決勝點——降低協調成本（AI 原生產品節奏）。
系統層級監督——協調品質、決策權限控管、升級處理設計——這明確是重新設計後的人類邊界角色（人類與 AI 的問責機制重設）。
harness／驗證基礎設施——Pocock 所說的「這就是上限」；這部分支架不會遷移到模型內部（模型進步，harness 隨之縮減）。

2.4 策略定位：哪些護城河（以及哪些職涯）能存續#

七大力量套用於 AI：在 AI 影響下，轉換成本與流程力量會減弱（代理程式能移植整合並逐步改良流程）；網路效應、規模經濟、稀缺資源仍能存續；錯位競爭會加劇（AI 原生初創公司選擇現有企業在結構上無法跟進的模型）。套用到個人職涯：「累積 15 年、無人能取代的流程知識」屬於 AI 現在能逐步改良的流程力量；「在這個利基領域建立的可信賴人脈」則是 AI 無法複製的網路效應。從頭培養 AI 原生習慣，而不是把 AI 硬套到 AI 出現前的工作流程。

2.5 誠實面對不確定性#

高度確信：編碼技能會成為基本門檻；驗證／審查會持續重要；harness 提示詞支架會隨每次發布縮減；上下文有智慧區限制。多個來源相互印證。
中度確信：「100 行程式碼」（Boris 自己說是誇飾）；印刷術式的發展時間表（「比 50 年快」，但確切速度未知）；產品品味成為瓶頸（在 Anthropic 這類小型團隊中成立，能否擴大規模尚不清楚）。
值得納入考量的反面證據：這裡唯一嚴謹的實證研究（AI 員工定位）提出的是警訊——把 AI 擬人化並列入組織架構會分散問責、降低審查品質，卻沒有提升採用意願。看好的論述很大程度仰賴 Anthropic 自身的說法和一位獨立實作者；對個人工作流程的指引有充分根據，但在組織規模上的實證較少。
總結：「軟體工程師將消失」並不是這些來源的主張。他們認為日常主要工作會改變——少花時間敲程式碼，多花時間決策、設計、驗證與監督；失去優勢的是價值只來自編碼產出速度或純粹流程知識的人，受益的則是具備領域深度、判斷力，以及嚴謹設計代理程式良好回饋迴圈能力的人。

另請參閱#

學會與 AI 協作：軟體工程師實用指南 — 提供實作建議的配套文章：6 個技能群組、日常做法、反模式、90 天計畫。本頁是各種立場的描述性地圖；該頁則是行動計畫。