寫 code 快 100 倍之後：真正卡住的是整條鏈

Coding agent 讓寫軟體快 10 到 100 倍後，瓶頸從工程移到 PM、行銷、法務與設計。Andrew Ng 的組織答案是高脈絡通才小隊與樂高式建構模塊；企業則要由上而下重畫工作流、先整理資料再堆 agent。

江中喬

15 7月 2026 • 10 min read

當 coding agent 讓「做出軟體」的速度暴漲，組織不會自動變聰明——它會先把原本隱藏的等待面全部暴露出來。Andrew Ng 在一場爐邊對談裡把這件事講得很直白：過去一年，程式開發代理比他預期更快；而當寫軟體快上十倍、甚至百倍，瓶頸不只是產品管理，幾乎每一環都成了瓶頸。

這不是危言聳聽，是產能轉移後的算術。工程若以天為單位交付，法務仍以週為單位簽核，你得到的不是敏捷，而是排隊理論上的災難。本文談的是：瓶頸長什麼樣、團隊怎麼重組，以及企業若只做「百花齊放」為什麼換不到轉型。

工程變快，是整條價值鏈在重新定價

Ng 約莫一年前就寫過「產品管理瓶頸」：界定做什麼、收斂範圍、拿到客戶回饋，跟不上開發速度。這一年，他的觀察是——這個瓶頸更嚴重了，而且是好事，因為代表工程真的加速了。

但好消息到此為止。當產出變便宜，下一個最慢的環節會立刻變成最貴的資源：

環節	典型症狀
產品	功能做得出來，說不清優先序與成功標準
行銷	工程一次丟出一堆能力，對外故事跟不上
法規	開發一天完成，簽核仍要一週
設計	交付節奏快過體驗與一致性治理
決策	會議與對齊本身成為吞吐量上限

換句話說：coding agent 優化的是「建造」；企業競爭力很快取決於「選擇、解釋、合規與分發」。
這和「掌控思想，而非代碼」「實作不再是瓶頸」是同一條曲線——只是場景從個人與產品小組，拉到整個職能鏈。

組織答案：1 到 10 人的高脈絡通才小隊

Ng 說他也不確定「未來軟體團隊標準編制」的最終答案，但他自己越來越常組的是：

規模極小：大約一到十名工程師
高度脈絡：懂領域、懂系統、懂客戶約束
高度授權：在寬鬆規範內可衝刺、可發布、可做決策
通才取向：一人承擔超過一個傳統職能

用鴿籠原理想很清楚：若一條產品線需要工程、產品、一點法務、一點行銷、一點設計，卻只有兩個人——定義上每人就必須兼多角。AI 不會奇蹟似地把工程師變成頂級行銷；但它能讓「不擅長的初稿」變得夠用——例如工程師用 AI 草擬服務條款，律師只做發布前終審；行銷文案同理。

誰比較容易勝任？目前他把球多數仍分給深厚工程背景的人——因為理解 agent、工具鏈與系統邊界有先天優勢。但他也明確鼓勵：產品、行銷、營運背景若願意學寫 code、願意進場，機會是開著的。現實分佈偏工程，不代表編制應該永遠鎖死工程。

這和 Anthropic Labs「一人火花、三人出產品」的精神相容：協調成本壓到最低，循環次數拉到最高。 差異是 Ng 把「跨職能初稿」寫進了常態，而不只是工程內的角色溶解。

開發者的心智模型：樂高積木 × Coding Agent

他把「怎麼變強」收成兩個動作，而不是背下一個永遠正確的框架名。

第一，掌握足夠多的建構模塊。
模塊分兩類：AI 的（RAG、agent 框架、eval、護欄……）與非 AI 的（UI 元件、身分驗證、前後端、資料庫……）。積木只有白色，房子無聊；顏色與異形件一多，可組合物呈組合式成長。DeepLearning.AI 一類短課的價值，正在於把這些模塊補齊。

第二，用 coding agent 快速組裝模塊。
這裡有一個實務痛點：很多 API／SDK 新過模型的知識截止日，agent 會「不知道怎麼用最新磚」。他與合作者推動的方向，是給 agent 一層可更新的文件與回饋管線（談及 Context Hub 這類「給 AI 的 Stack Overflow」）——讓代理載入最新文件再寫呼叫，而不是靠訓練語料裡的過期記憶。

對個人開發者，這意味著：
競爭力 = 積木目錄的廣度 × 組裝的速度 × 對最新介面的可達性。
工具換來換去（Claude Code、Codex、Gemini CLI、開源 agent）是常態；真正要累積的是模塊判斷與組裝節奏。

企業導入：由下而上的點子，必須接上由上而下的工作流

顧問視角裡，幾乎每家公司都對 AI 興奮，也幾乎都投資過「百花齊放」。問題是：bottom-up 常只產生單點方案與漸進效率——很好，但不是董事會以為買到的「轉型」。CEO 於是問：ROI 在哪？

Ng 的建議不是停掉由下而上，而是必須補上由上而下：有人用更寬的視野重畫整條流程。

銀行貸款是他反覆使用的例子。傳統五步大致是：行銷產品 → 收申請 → 審核 → 盡職調查 → 執行。若只把「人工審一小時」換成模型，流程其餘部分不變，你得到的是微幅省工。真有想像力的目標比較像：「十分鐘核貸」產品——行銷怎麼講、資料何時到齊、決策如何即時、後段如何規模化，全部要一起改。

於是兩種 AI 敘事要分清：

省成本	帶成長
有上限	幾乎無上限
常停留在局部自動化	常要求跨部門重設計
好衡量、好立項	更難，但更接近「轉型」

客服中心也一樣：只當省人力是窄用法；若能以更快速度服務更多客戶、拉高滿意度，那是成長槓桿。

點子太多時怎麼辦

企業寄來「三百個 AI 點子」的試算表並不少見。他沒有假裝掃一眼就能點石成金，而是承認要做扎實的：

技術可行性分析
商業影響力分析
收成小投資組合——不全壓一注，但也不會百花齊放到零資源

Coding agent 讓原型變便宜，這很好；把大量預算押在少數全壘打上，仍需要由上而下的資源分配。兩者不互斥：用便宜原型探索，用高層決策集中火力。

先資料，再 Agent（否則 agent 只是更快的猜）

與大企業合作時，極常見的痛點不是「哪個 agent 框架」，而是重新思考資料架構。過去一二十年，產業把力氣花在結構化表與關聯式治理上——這仍然重要。但模型突然能消化 PDF、圖片、音訊、影片等非結構化資產；在對的時間把對的資料送到 agent，價值陡升。

現有架構為什麼常常「餵不動」：

碎片化、治理弱、資料散落（含個人筆電）
schema 不一致
權限為人設計，agent 繼承人的權限——治理與可觀測瞬間失控
合規留下的海量文件，過去無人有空讀，現在整理後可能極有價值

他甚至預見：未來幾年會出現數千萬到數億美元級的資料架構重整專案，只為讓資料「對 AI／agent 就緒」。市場上非結構化方案很多，他坦言還沒看到真正滿意的——這本身也是機會與警告：別以為接一個向量庫就等於資料策略完成。

小而真的工程取捨：迭代速度也會改寫技術選型

對談尾聲有一個很「工程師」的註腳：當 AI 寫 code 極快，一直改關聯式 schema、跑 migration 會變成新摩擦；極低機率的「AI migration 搞砸資料」也夠煩人——幾乎不發生，不代表從不發生。

他的個人做法是：原型期更常把東西丟進 NoSQL，寫入先不鎖死形狀，讀取時再定結構，換迭代速度；超大正式負載仍可能回到可擴的關聯式。重點不是宗教戰 NoSQL，而是：

技術選型要服務 agent 帶來的迭代速度，而不是用舊的變更成本抵銷新的產能。

Coding agent 改變的不只是「誰寫 code」，還有「什麼樣的基礎建設配得上這種寫法」。

你可以帶走的決策清單

個人／小隊

假設產出會再快一個數量級，畫出你組織下一道牆是 PM、法務還是行銷。
組高脈絡小隊；用 AI 做跨職能初稿，用專家做終審與風險簽署。
累積建構模塊目錄；給 agent 可更新的文件層，別只靠模型記憶。

企業

保留 bottom-up，但指定 top-down 主人翁重畫 1～2 條核心工作流（目標像「十分鐘核貸」，不是「審核省 20 分鐘」）。
點子篩選走技術×商業雙分析，組成小投資組合。
Agent 專案前先問資料：非結構化從哪來、權限如何為 agent 設計、如何觀測與撤權。

結語

Coding agent 的誇張之處，不在於它會不會取代所有工程師，而在於它把「建造」的邊際成本壓下去之後，組織必須重新為選擇、合規、敘事、資料與跨職能協作定價。

炒作可以過頭，末日論可以過頭；但「開發代理在最前線、且組合變化極快」這件事，Ng 認為接近真實。對個人，意味著成為能組樂高的高脈絡通才；對企業，意味著停止只收藏三百個試算表點子，開始重畫一條能成長的工作流，並為 agent 準備好資料與權限。

寫 code 可以再快。
整條鏈若不快，你只是更快地排到下一個窗口。