當工程師一年沒寫一行 code：Boris 談 Claude Code 的工程新秩序
Anthropic Claude Code 負責人 Boris 從 2025 年 11 月起沒有親手寫過一行程式碼，每天仍產出 10–30 個 PR。這不是「工具升級」，而是工程師身份的重寫——稀缺性從雙手的產能移動到腦袋的判斷力。
一個小小的事實，先放在前面
Anthropic 的 Claude Code 負責人 Boris，從 2025 年 11 月開始，沒有親手編輯過任何一行程式碼。
他現在每天照樣產出 10 到 30 個 PR，全部出自 Claude Code，自己做的是審查、決策、把關方向。Anthropic 內部引入 Claude Code 後，工程團隊人數成長了數倍，每人平均產出又額外拉高約 200%。對比他之前在 Meta 負責全公司開發者生產力，一年幾百人努力只能推動幾個百分點，現在是幾百％的跳升。
這件事如果只當成「又一個 AI coding 工具變強了」的新聞，會錯過真正重要的訊號。對我來說，這是一次「工程師這個職業」被重新定義的分水嶺。
Coding 被解決了，稀缺性正在位移
Boris 在訪談裡有一句話我一直想引用：「對我每天要做的工程工作而言，coding 這件事基本已經被解決。」
這句話你可以同意或不同意，但他後半段的觀察更關鍵——真正花腦力的，已經不是怎麼把 code 寫出來，而是：
- 想清楚要做什麼、為什麼要做
- 怎麼定義「對」的標準
- 怎麼驗證它真的是對的
- 怎麼在一堆訊號裡挑出值得動手的那一個
換句話說，稀缺性已經從「會寫程式的人」轉移到「會定義問題、會做取捨、會跟 AI 協作的人」。
這件事對我們這群同時碰工程、產品、顧問案的人特別有感。過去那種「我會寫 code 所以我有價值」的安全感，正在被稀釋得很快。新的護城河不是「雙手的產能」，而是「腦袋的判斷力」。
Claude Code 怎麼被做出來:一個反直覺的產品故事
Claude Code 的誕生過程，比它的功能更值得我們學。
最早的原型叫 Quad CLI，完全是一個 terminal 工具。Boris 只給模型一個 bash tool，結果模型自己學會寫程式、呼叫這個 tool，幫他回答「我現在在聽什麼歌」這種問題。他在公司內部貼文介紹，只拿到兩個 like——大部分人對「終端機 coding 工具」完全沒有直覺的信心。
但他堅持從 CLI 開始，理由非常務實：
模型進步的速度太快，任何重裝甲做法都追不上。 IDE 插件、UI、整合層——這些東西一旦做複雜，就會變成模型進化的絆腳石。CLI 是最薄的一層，能最快把模型能力「透明」地交到使用者手上。
這個思路值得所有想做 AI 產品的人抄下來：
- 先找 product–model fit，再談 product–market fit。模型跑得到什麼程度，產品形態就該配合到什麼程度。
- 起步時刻意用最小形態。 不是因為資源不夠，而是因為最小形態可以讓模型能力直接穿透，沒有中間損耗。
- 熟悉場景的擴張留到後面。 CLI 先跑通之後，再往 iOS、Desktop、IDE 插件延伸。順序反了就會被自己的產品架構綁死。
我看過太多團隊一上來就規劃 roadmap、畫 wireframe、切 sprint，結果模型能力跑在前面，產品架構卻卡在三個月前的假設。Boris 的做法是反過來：讓模型先跑，產品跟著模型進化。
下一個戰場:不是寫 code，是決定寫什麼 code
更讓我有感的是 Boris 描述他們現在怎麼用 Claude。
Anthropic 有一個內部 Slack channel，專門收集 Claude Code 的所有 feedback。早期是 Boris 自己盯著看，看到就衝去改——他刻意在做「回饋立即被處理」的強正回饋循環。但現在，他把整個 channel 指給 Claude 自己處理:讀完回饋、整理問題、分類優先順序、直接開 PR，他只需要 review。
這個轉變的意涵比「coding 被 AI 做掉」更大。它代表:
AI 已經開始吃掉「決定做什麼」這塊工作了。
過去我們覺得 PM 的核心價值是「從雜訊找出下一步」——讀訪談、看資料、整理需求、寫 spec。這塊工作的其中一半，現在 AI 做得又快又好。人類 PM / Lead 的角色正在往更上游走：對問題與願景負責、對風險與取捨負責，而不是逐條整理需求。
這件事在我自己的顧問案、91APP 的 PoC、還有個人寫作流程裡，已經在發生。我現在很多初步的市場掃描、競品分析、使用者回饋分類，都是先讓 AI 跑一輪，我只做最後的判斷與定稿。節省下來的時間，我可以拿去想更難的問題——那些 AI 還答不出來的。
管理心法:刻意欠資源、刻意多燒 token
Boris 講了三個組織原則，我認為所有在做 AI 轉型的團隊都應該釘在牆上。
第一，Underfund everything。 他常常只派一個工程師做一件事，讓他「被迫」把工作丟給 Claude。人力充裕會讓團隊回到舒適圈——用人海解決問題。刻意欠一點資源，才會推動真正的 Claudefy。
第二，速度至上。 Claude Code 早期唯一的競爭優勢就是「快」。能今天做的就不要拖到明天——這在 AI 產品市場裡不是口號，是生存條件。
第三，前期不要省 token。 他跟其他 CTO 的建議很反直覺:不要急著 cost cutting，先讓工程師「用爆模型」，探索最高上限。Anthropic 內部已經有工程師一個月燒掉數十萬美金的 token，但只要產出對得起帳單，這種「AI 成為主要成本中心」的組織型態完全合理。
真正昂貴的從來不是 token，是多人協作的時間成本與機會成本。一個工程師多花 5000 美金 token 換回 200% 產能，比多請一個工程師便宜得多。等到 idea 證明有價值、流量上來，再考慮用更便宜的模型或架構優化降成本——這個順序反了，就會在還沒長出產品力之前，先把團隊綁死在成本焦慮裡。
從工程師到 Builder:身份的重寫
Boris 在訪談末段講了一個我反覆思考的類比:AI 在做的事，像是印刷術之於文字。
過去只有少數人會寫字、抄書，印刷術普及之後，整個社會的知識結構被重寫。現在 AI 做的是把「造軟體」這件事變成普及技能。長期衝擊會比我們想像的大得多——「軟體工程師」這個 title 的重要性會下降，取而代之的是更廣義的「Builder」:能想清楚問題、能跟 AI 協作、能把想法變成可用產品的人。
這對我們這一代工程師是個挑戰，但不是壞消息。反而是機會:
- 如果你原本就卡在「會寫 code 但不會定義問題」，AI 會把這個瓶頸放大到不能再忽略。
- 如果你原本就同時碰工程和產品、同時會寫 code 和寫文章、同時做 PoC 和做顧問——AI 會把你的槓桿放大好幾倍。
工程師和 PM 的界線正在模糊。真正會享受這一波紅利的，是那種「跨職能的通才」——不被單一垂直技能綁住、願意每天把自己的工作重新丟給 AI 問一次「這件事還需要我親自做嗎」的人。
我的收尾
我自己的習慣是，看到這種訪談，會問三個問題:
- 我的日常工作有多少還在用「人力暴力」解決? 有沒有哪些事情其實應該丟給 AI，只是因為我習慣自己做。
- 我花在「寫出東西」和「想清楚要寫什麼」的時間比例是多少? 如果還是前者多，代表我的槓桿還沒打開。
- 我的產出，是不是在往「只有我能做」的方向走? 如果 AI 就能做，那我的價值不在那裡。
Boris 的故事不是要我們恐慌，是要我們換頻率。Coding 被解決了，這對會思考的人是好消息。真正稀缺的東西，從來都不是鍵盤上的手速。
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。