5 月 4 日，Sequoia Capital 主辦的 AI Ascent 2026 大會上，Anthropic 的 Claude Code 創始人 Boris Cherny 在主場對談中丟下一句話：
「對我來說，coding 已經解完了。」
他接著指出，2026 年到現在，他幾乎沒有親手打過一行程式碼，所有程式都是模型代寫，每天手機會推送幾十個 PR 通知，「上週有一天，我推了 150 個 PR，那是個人紀錄。」
這句話來自 Sequoia Capital 公開的對談影片。對台下那屋子工程師、創業者、創投合夥人來說，衝擊並不在「AI 會寫程式」——那件事早在兩年前 Sonnet 3.5 推出 type-ahead 自動補全時，就已經實際發生。
真正的衝擊在於：「寫 code」這件事本身的工作型態，已經被推到一個多數工程師還沒心理準備好的階段。
反共識的不是「AI 寫 code」，是「人不再坐在 IDE 前」
外界談 AI 編程，直覺都是以 IDE 為中心：模型在 VS Code、Cursor、JetBrains 裡幫你 autocomplete，你還是坐在螢幕前敲鍵盤的那個人，只是多了一個「很會補完的輸入法」。
Cherny 在現場舉手調查觀眾使用 Claude Code 的方式，結果顛覆了這個想像：CLI（指令列介面）用戶遠比 IDE 用戶多很多。
「我自己最近主要是用 iOS 在跑，」他說。
也就是說，工程師正在從「親手打字寫程式的人」，變成「對一群 AI 下指令、分派任務的調度者」。
Cherny 在訪談裡拆解自己的日常作業流：打開 Claude app，左側的 code 分頁同時開著 5 到 10 個 session（可以想像成不同專案的聊天室），每個 session 底下掛著幾十個 agent（各自負責一小塊工作的 AI 小助手）；白天通常有「幾百個 agent 在跑」，晚上則是「幾千個 agent 在做更深的工作」。
換個更簡單的說法：他每天的工作畫面，不是盯著一個 IDE，慢慢敲一支服務，而是同時指揮一整個 AI 工程師大隊。
更關鍵的工具，是他口中的「最酷的東西」：/loop。
這個指令本質很簡單，就是讓 Claude 幫你排程——有點像更聰明的 cron job，可以設定每分鐘、每 5 分鐘、每天等頻率，重複跑一段任務。
Cherny 自己同時掛著幾十個 loop：
有一個在「照顧」他的 PR（Pull Request，程式碼修改請求），幫他修 CI（自動化測試流程）、自動 rebase；
另一個盯著 CI 健康度，一遇到 flaky test（有時過、有時不過的「不穩定測試」）就自動排查、修復；
還有一個每 30 分鐘從 Twitter 抓用戶回饋，自動分群整理成可讀的資訊。
他總結說道：
「我現在覺得 loop 就是未來。如果你還沒玩過，強烈建議。」
如果把這段再濃縮成一句話，就是：工程師不再一個一個功能手刻，而是掛著一整排 loop，讓 AI 24 小時幫你維修系統、追蹤健康、收集用戶聲音。
解掉 coding 後，下一個被解的是「團隊組成」
Cherny 不只把自己的 coding 形態翻過一遍，連對未來軟體團隊的長相，他也直接給出一個相當具體的預測。
他承認，預測未來本來就很困難，但仍然押了一個明確方向：未來會有遠比現在更多的「跨領域通才」。
傳統軟體圈講「通才」，多半指「iOS 也能寫、web 也能寫、後端 server 也能搞」的工程師，本質上還是在同一個專業領域裡橫向展開。
Cherny 看到的下一波，則是跨「學科」的通才：例如一個人同時有產品 sense、工程能力，又具備設計或資料科學的判斷力；或者產品 + 資料科學 + 工程都能自己拉得動。
他拿自己的團隊當例子：Claude Code 團隊裡，工程經理、產品經理、設計師、資料科學家、財務、使用者研究員，每一個人都會寫程式。
「他們仍各有自己的專業，但現在所有人也都在寫 code。」
當寫程式的入場成本被 AI 壓到夠低，「我不會 code」不再是其他職能可以拿來當免責理由的盾牌，反而會變成勞動市場上的折舊風險。
亦即，未來的財務、設計、PM、研究員，如果只懂本行、不會動手讓 AI 幫自己做工具，很容易被貼上「上一世代人才」的標籤。
這對企業組織意味著什麼？
Cherny 的說法有點反直覺：Anthropic 內部與外界最大的差距，他認為反而不在模型本身。
「我們內部用的就是大家用的同一個模型，少量 Mythos、大量 Opus 4.7，」他說，「真正大的差距，在組織流程。」
他描述 Anthropic 內部的現況：已經沒有任何「純手寫」的程式碼，所有 SQL 都是模型產生；員工各自的 Claude 整天在 Slack 上彼此通訊、互相補位處理未知狀況，形成一個由人＋模型共同運作的 agent 網路。
SaaS 末日論？比較像是「七種護城河」被重新洗牌
論壇上最常被丟出來的問題之一，是：「當 AI 把寫程式成本壓到幾乎歸零，SaaS 會不會整個崩盤？」
Cherny 的回答相當冷靜。他引用投資人 Hamilton Helmer 在《七力》（Seven Powers）裡的框架，來解釋這一波 AI 對商業壁壘的實際影響。
這本書把公司「為什麼可以長期賺錢、不容易被抄襲」的原因，拆成七種不同的結構性優勢——也就是俗稱的護城河。
在這七種裡，Cherny 認為會被 AI 明顯削弱的，主要有兩種：
第一是 switching costs（轉換成本）。
過去 SaaS 靠「你搬家很痛」留住客戶；未來模型可以直接幫你從 A 工具導出資料、轉格式、搬到 B 工具，轉換成本被 AI 大幅壓低，黏著力自然被稀釋。
第二是 process power（流程力）。
有些公司靠自己設計的一整套 workflow、SOP 與內部工具，把效率拉到別人追不上的程度。問題是，當 Claude 4.7 這類模型已經非常擅長理解流程、拆解步驟、迭代到完成，「靠流程本身」築起來的護城河，就會被穿透。
「給它一個目標、要它迭代到完成，它就會自己做，」他說。
但他也提醒，其他幾種商業壁壘並不會因為 AI 就自動蒸發，像是：
- 網路效應（network effects）：用戶越多、價值越高的雙邊或多邊平台；
- 規模經濟（scale economies）：規模越大，單位成本越低的生意；
- 獨占資源（cornered resources）：別人拿不到、只有你掌握的關鍵資源。
換句話說，AI 不是平均壓平所有 SaaS，而是有選擇地拆特定幾種護城河：靠流程與高轉換成本活下來的玩家會被衝擊最大，靠網路效應與規模經濟吃飯的玩家，反而可能因為 AI 更快放大。
對新創來說，他反而是樂觀派。Cherny 認為，未來十年內出現那種「顛覆一切」級別的新創數量，會比過去十年多出 10 倍。
理由不是「AI 讓做產品變得很簡單」，而是：大公司被自己的內部慣性卡住——要改流程、要重訓員工、要對抗組織內抗拒，處處牽一髮動全身。
反觀新創沒有這些歷史包袱，可以從第一天就以 AI 為原生前提來設計產品與組織結構，自然有機會在新賽局裡跟大公司正面對打。
印刷術 2.0：寫程式從「專業技能」退位成「基本素養」
整場對談裡，最有歷史縱深的一段，是 Cherny 如何類比軟體業的未來。
他說自己平常看的書主要兩種：科幻與科技史。如果從科技史的長鏡頭來看，他覺得現在發生的事，最像 1400 年代歐洲的印刷術。
在印刷術問世之前，歐洲識字率只有約 10%。會讀寫的人，大多受僱於不識字的國王與貴族——識字是一種少數人的專業。
印刷術出現後 50 年，歐洲出版的書本數量超過前一千年累積的總和；書的成本掉了大約百倍。再經過幾百年的公共教育與制度變化，全球識字率才一路爬到今天大約 70%。
「我覺得接下來會發生的事，而且會比 50 年快得多，是寫程式徹底民主化，變成任何人都會的事。」
Cherny 預測，未來最會做會計軟體的人，不會是工程師，而會是真正懂會計的會計師——因為「寫 code 是簡單的部分，懂 domain 才是難的部分」。
這其實是在說一個「軟體版的印刷術故事」：把「能 code」從專業壁壘退成基本素養，真正留下來的競爭力，會回到你對問題本身與產業脈絡的理解深度。
被淡化的兩個張力：安全外殼與「條件式的 coding solved」
Cherny 的論述強而有力，但裡面有兩個他輕描淡寫帶過、卻值得企業導入者多想兩遍的張力。
第一個張力，出現在他談到 harness（外殼框架）時。
現在很多所謂的「AI agent 系統」，外面都還包了一層 harness，用來處理模型還不夠穩、還沒完全對齊的地方，包括：
- prompt injection（提示詞攻擊）；
- 靜態指令驗證；
- 權限控管；
- human in the loop（關鍵步驟要有人類審核）。
這些聽起來有點抽象，白話來說，就是在模型外面再裝一圈安全殼，用規則與人工干預去補齊模型目前的「不可靠」。
Cherny 的看法是：一年後模型的對齊會好很多，這些安全機制會變得沒那麼重要。
這是一個相當樂觀、也相當集中的賭注——賭模型的進步會比 harness 更快，賭未來不會出現那種光靠 prompting 很難攔下的新型攻擊。
對企業導入者來說，這個賭局的風險是明顯不對稱的。如果模型對齊沒如預期那麼快，整個 agent fleet（大批自動化代理人）很可能會把同一個錯誤「工業化放大」，在錯的方向上跑得更快。
第二個張力，是他那句「對我來說，coding 已經解決了」背後，其實有相當多隱含條件。
Cherny 自己也坦白：Claude Code 的 codebase 刻意選擇 TypeScript + React，這兩者都是當前模型最熟悉、資料分布最密集的語言與框架。
面對複雜龐大的既有系統、冷門語言、或高度客製的產業內部平台時，他的答案其實保守許多：
「這些地方現在仍未解，通常答案是：等下一個模型。」
也就是說，「Coding solved」目前仍是一個有條件的命題，條件包括：
- 你的 codebase 長在模型熟悉的語言與框架上；
- 你的系統結構沒有太偏離主流設計模式；
- 你願意把一部分舊有負債，重構到模型「看得懂」的形狀。
也就是說，只有當你的系統足夠「主流」、足夠貼近模型的訓練分布時，Cherny 口中的「coding solved」才真正成立。
對想直接把工程組織拉到「全員 Claude Code」模式的團隊來說，這兩道裂縫都值得繼續觀察：
- 模型對齊真的會跑得比 harness 更快嗎？
- 這種條件式的「coding solved」，要再過幾代模型，才有機會覆蓋到各行各業那些雜亂、老舊、又帶有一堆例外條款的 codebase？
這些問題，他沒有給出答案——也暫時不會有標準答案。
但可以確定的是：在他已經身處的那個未來裡，工程師的工作敘事，已經從「我寫了什麼程式」變成「我指揮了多少 AI 去完成什麼任務」。
資料來源：Sequoia Capital
本文初稿為AI編撰，整理．編輯/ 李先泰
