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

問題#

使用 AI 工具有哪些觀點？軟體工程師角色的未來又是什麼？

重點摘要#

本 wiki 中的資料來源大致可歸類為四種不同立場——看好的內部人士、務實的實踐者、懷疑的治理派、架構論述派——它們在軟體工程師角色的方向上大致達成共識，即使在速度和風險上存在分歧：寫程式的能力成為基本門檻，差異化因素轉向決定要建造什麼、設計 agent 的運作環境，以及驗證產出。領域知識和人類判斷力升值；純粹的程式碼產出速度貶值。誠實的保留意見：大部分證據來自 Anthropic 內部加上一位獨立實踐者，最強烈的預測（「100 行程式碼」）是自稱的誇飾法，而這組資料中唯一嚴謹的實證研究（HBR / Kropp et al.）是一個警告，而非背書。

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

立場 A——看好的內部人士：「寫程式已被解決，harness 會縮小，loops 是未來」#

主要聲音：Boris Cherny（Claude Code 創造者）、Cat Wu（Claude Code & Cowork 產品負責人）。

「寫程式已被解決（對我而言）。」 Boris 100% 透過 Claude Code 寫程式碼，曾有單日 150 個 PR 的紀錄，以手機為主要工作介面，白天運行數百個 agents、夜間運行數千個（Boris Cherny）。明確的保留意見：對於非常大型的程式碼庫或冷門語言尚未成立。
harness 應該縮小，而非膨脹。 Harness Shrinkage as Models Improve：每次模型更新都讓團隊刪除 prompt 段落；Boris 預測 Claude Code「一年後可能只有 100 行程式碼」（他將此定位為帶有真實方向的誇飾法）。Cat Wu 的紀律：每次啟動時閱讀整個 system prompt，並刪除新模型已能原生處理的部分。
能力向內遷移。 /loop 原語（見 Agent Loop Pattern）從 harness 功能變成了 Opus 4.7 的模型原生行為——「我注意到資料在變化，我會啟動一個 loop 並每 30 分鐘回報。」Boris：「Loops 是目前的未來。」
為下一個模型而建，而非當前模型。 Anthropic 在 2024 年底推出 Claude Code 時就知道它約 6 個月內缺乏 PMF——賭的是下一個模型會補上差距（Harness Shrinkage as Models Improve）。
軟體被民主化。 Printing Press Software Democratization：如同 Gutenberg 之後的識字率普及，軟體撰寫能力擴散；「寫會計軟體最好的人是一位優秀的會計師，而非工程師——寫程式是簡單的部分。」Boris 預測未來十年將出現約 10 倍以上具顛覆性的新創公司。

立場 B——務實的實踐者：「AI 工具很強大，但軟體工程基本功才是天花板」#

主要聲音：Matt Pocock（獨立 AI 程式教育者，打造了 Sandcastle）。

基本功仍然適用。 「我們忘了軟體工程基本功——那些對與人協作至關重要的東西——對 AI 同樣非常有效」（Matt Pocock）。引用 Brooks、Pragmatic Programmer、Ousterhout、Fowler。
「爛的程式碼庫造就爛的 agents。」 Harness Shrinkage as Models Improve 的反面觀點：「如果你的程式碼庫沒有回饋迴路，你永遠不可能從 AI 得到像樣的產出。你的回饋迴路品質決定了 AI 寫程式的天花板。」測試、型別、linters、隔離的 review 環境是不會遷移進模型的基礎設施。
管理 context 預算。 Context Window Smart Zone：LLM 隨著 context 增加呈二次方退化（無論宣傳的視窗大小，約 100K token 的「聰明區」）；1M token 的視窗「只是多了很多笨區」。偏好 /clear 而非壓縮。
從規格到程式碼就是「換個名字的 vibe coding」。 程式碼才是戰場，而非規格；在寫計畫之前先與模型達成共同的設計概念（Design Concept Grilling）。
Review 是 2026 年尚未解決的問題。 當 agents 產出更多程式碼時，人類需要 review 更多程式碼——這是 loops 無法取代的持久瓶頸。
這與官方工具指南一致：Claude Code Best Practices 和 Agent Harness Engineering 都將 AI 生產力視為受環境設計所限（CLAUDE.md/AGENTS.md 作為目錄、驗證驅動的 loops、探索→計畫→寫程式）。

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

主要聲音：Kropp、Bedard、Wiles、Hsu、Krayer（HBR，2026 年 5 月 + 2026/03 的「brain fry」論文）——本 wiki 中唯一的隨機實驗證據。

將 AI 擬人化會侵蝕問責制。 AI Employee Framing（n=1,261；效果集中在約 23% 已將 AI agents 放入組織圖的組織中）：在其他條件不變下，將 agent 定位為「員工」而非「工具」——個人問責感下降 9 個百分點、歸因於 AI 上升 8 個百分點、不必要的升級增加 44%、發現的錯誤減少 18%——且採用意願沒有提升。
「Brain fry」是真實且可測量的。 AI Brain Fry：超出認知容量的監督所產生的心理疲勞，與輕微錯誤頻率增加 11% 和重大錯誤頻率增加 39% 相關。工具定位對審查者造成負擔；員工定位則以參與不足取代了這種負擔。兩種定位都有其代價曲面。
真正驅動採用的是管理者的身教，而非組織圖上的象徵意義——AI 成熟的公司有 3.5 倍的可能性讓管理者在日常工作中明顯使用 AI（AI Employee Framing）。
解方是結構性重新設計，而非「擴大管理幅度」：以抽樣稽核取代逐一產出審查、將審查集中在高風險決策點、將人類從逐一產出審查轉向系統層級監督、重設績效管理以獎勵協調能力（Human-AI Accountability Redesign、AI Brain Fry）。

立場 D——架構論述派：「harness 溶解進模型——包括互動層」#

主要聲音：Thinking Machines Lab（Interaction Models，2026 年 5 月）；Sutton 透過 The Bitter Lesson。

苦澀的教訓再次應驗。 The Bitter Lesson：規模化的通用方法勝過手工設計的結構。在本 wiki 中，這是將 harnesses 溶解進模型的核心論據——但附帶一個保留意見：機械式驗證和角色特質可能不會向內遷移。
不只是程式碼，還有介面。 Interaction Models / Turn-Based Interface Bottleneck：今天的輪流對話介面本身就是頻寬瓶頸；VAD／輪次偵測／對話管理的 harness 應該溶解進模型。「互動性只有在存在於模型內部時，才能隨智慧一起擴展。」這是在互動軸上的同一個 harness 縮減動作。

各立場實際衝突之處#

問題	看好的內部人士 (A)	務實派 (B)	懷疑派 (C)	架構論述派 (D)
寫程式「已被解決」了嗎？	是的，對我而言，現在就是	否——受限於程式碼庫品質	問錯問題了；監督才是問題	趨勢上是的，結構性地
harness 長期重要嗎？	縮小到接近零	驗證的那一半仍是承重結構	—	溶解進模型
最大風險	為錯誤的（當前）模型而建	爛的回饋迴路→爛的 agents	問責分散、brain fry	手工搭建的腳手架被超越
證據基礎	內部軼事、創辦人宣稱	實踐者經驗	隨機實驗，n=1,261	新實驗室的架構＋基準測試

A 和 B 的共識比表面看起來更多：Boris 承認 harness 的驗證層會持續存在；Pocock 承認實作可以完全 AFK。C 是正交的——它關注的是組織設計，而非模型能力。D 是最具推測性的（單一實驗室 2026 年 5 月的論述）。

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

2.1 核心轉變：從「寫程式碼」到「決定要建什麼＋驗證它能運作」#

Cat Wu：「當程式碼變得更便宜時，更有價值的是決定要寫什麼」（Engineer PM Convergence）。
Boris Cherny：瓶頸從寫程式轉移到領域知識——會計師／醫生／律師／教師為自己的領域撰寫工具（Printing Press Software Democratization）。
角色大致分為三個持久活動：(1) 產品／判斷力——選對要做的事；(2) harness／環境工程——設計 agent 運作的腳手架；(3) 驗證與 review——掌握機械式回饋迴路和新鮮視角的審查（Learning to Co-Work with AI: A Software Engineer's Field Guide）。

2.2 角色融合；團隊縮小#

Engineer PM Convergence：在 Anthropic，Claude Code 團隊中每個職能角色都寫程式（EM、PM、設計師、資料科學家、財務、使用者研究員）；工程師「從 Twitter 回饋到上線產品，一週內完成，幾乎不需要產品團隊介入。」招聘偏好：「有優秀產品品味的工程師。」影響：不論職稱都以品味為招聘標準、積極跨職能培訓、更小的端到端負責團隊、更輕量的 PRD、碎片化的職涯階梯。開放問題：這能擴展到超過約 50 人的團隊嗎？Boris 保留態度——「這是未來幾年的問題。」一個對比的內部觀點（Anthropic 成長負責人）認為快速交付的工程師需要更多 PM／設計支援，而非更少——即團隊形態取決於組織功能。

2.3 什麼仍屬於人類（升值的技能）#

程式碼審查流暢度——當 agents 交付更快時，這成為新的瓶頸（Matt Pocock、AI Native Product Cadence）。
跨職能情商／隱性判斷力——知道正確的場合、感知何時可以上線、什麼算是公平的取捨；Cat Wu 明確指出這不會融入模型（Engineer PM Convergence）。
領域深度——能寫程式的會計師勝過沒有領域知識的工程師（Printing Press Software Democratization）。
使命／價值觀的清晰度作為決勝因素——降低協調成本（AI Native Product Cadence）。
系統層級監督——協調品質、決策權限把關、升級設計——明確是人類在邊界角色的重新設計形態（Human-AI Accountability Redesign）。
harness／驗證基礎設施——Pocock 所說的「那就是天花板」；腳手架中不會遷移進模型的部分（Harness Shrinkage as Models Improve）。

2.4 策略定位：哪些護城河（和哪些職涯）能存活#

Seven Powers Applied to AI：轉換成本和流程優勢在 AI 下被侵蝕（agents 可移植整合、爬坡優化流程）；網路效應、規模經濟、獨佔資源持續存在；反定位被放大（AI 原生新創選擇既有企業結構上無法跟隨的模式）。應用到個人職涯：「15 年沒有其他人擁有的流程知識」是 AI 現在能爬坡取代的流程優勢；「在這個利基中的可信賴關係網路」是 AI 無法複製的網路效應。從零開始建立 AI 原生習慣，而非將 AI 嫁接到 AI 之前的工作流程上。

2.5 誠實的不確定性#

高度確信：寫程式能力成為基本門檻；驗證／review 作為持久能力；harness-prompt 腳手架隨每次發布而縮小；smart-zone context 限制。多個來源交叉驗證。
中度確信：「100 行程式碼」（Boris 自己定位為誇飾法）；印刷術時間軸（「比 50 年快」，確切速率未知）；產品品味作為瓶頸（在小型 Anthropic 風格團隊中成立，擴展性不明）。
值得重視的反面證據：這組資料中唯一嚴謹的實證研究（AI Employee Framing）是一個警告——被擬人化、放入組織圖的 AI 會分散問責並降低審查品質，卻不會提升採用率。看好的敘事嚴重依賴 Anthropic 自己的說法加上一位獨立實踐者；將其視為個人工作流程指引是有根據的，但在組織規模上尚未經過充分驗證。
總結：「軟體工程師消失」的說法並非這些資料來源所表達的。它們說的是中位數活動改變了——更少的程式碼輸入、更多的決策／設計／驗證／監督——而失去優勢的是那些價值僅在於純粹程式碼產出速度或純粹流程知識的人；獲得優勢的是那些擁有領域深度、判斷力，以及為 agents 建立良好回饋迴路之紀律的人。

另見#

Learning to Co-Work with AI: A Software Engineer's Field Guide——指導性的姊妹篇：6 個技能群組、日常實踐、反模式、90 天計畫。本頁是立場的描述性地圖；那頁是行動計畫。