AI 寫程式，那工程師還剩什麼？——專訪 Arize AI 的 Laurie Voss

Arize AI 開發者關係負責人、npm Inc. 共同創辦人 Laurie Voss 主張，AI 代理（AI agent）已讓寫程式的成本趨近於零，而這創造出的瓶頸會不斷往下游移動，最後落在一個他稱為「產品工程師」（product engineer）的職位上——這種人負責找出人們真正需要什麼、定義什麼叫「好」，然後讓代理代勞打字、把東西做出來。這場 18 分鐘的演講大部分時間都在談這個論點及其後果：程式碼審查的瓶頸、限制理論（theory of constraints）、初階工程師招募的崩盤，以及如何為這個新職位培育人才。標題的框架合理但偏窄——「工程師還剩下什麼」是貫穿全場的主線，不過最具體的材料其實是審查工具、勞動統計與人才培育管道，而非 AI 寫程式本身。

Voss 很有資格談這個題目：他是 JavaScript 套件註冊中心 npm 的共同創辦人，目前任職於一家 AI 可觀測性公司，而且他明確表示這場演講是 Swyx 2023 年文章〈The Rise of the AI Engineer〉的延伸——他認為 Swyx 走得還不夠遠，被新職位取代的不只是 AI 工程師，而是每一種工程師。讀者讀完應該能帶走幾個具體東西：「程式碼免費、審查不免費」這個說法背後的具體數字、已經在自動化審查的具名工具與公司、初階工程師的勞動市場資料，以及 Voss 給團隊的具體處方。

寫程式快了 8 倍，交付只快 30%，癥結在審查

Voss 的核心資料：啟用自主編碼代理的開發者，寫出的程式碼多了 741%——大約是 8 倍——但交付速度只快 30%。他說 30%「不是沒差」，甚至「很驚人」，但他認為程式碼產量變 8 倍、交付卻只多三分之一，代表整個系統卡在某個地方。那個地方就是程式碼審查。

原因出在人的極限，不是工具的極限。Voss 引用 Cisco 約 20 年前（大約 2000 年代中期）的研究：人類每小時能準確判讀的程式碼超過約 450 行之後，正確率就會急遽下滑。因此代理產出的 10,000 行 diff，要好好審查大約得花一週——而他說，實際上根本沒人在這樣做。他對這個問題的總結是：

「產出看似合理程式碼的成本已經崩跌，但判斷這段程式碼值不值得信任的成本，卻原封不動。」

他提到自己先前在另一場 AI Engineer 大會上以〈The Death of the Code Review〉為題，完整談過這個現象。

機器審查員已上線，但彼此意見不合

最直覺的解法——讓機器來審——已經大規模發生，但 Voss 提出的證據顯示，機器還不夠可靠到能獨任審查。

Voss 的實務結論：跑一個 AI 審查員值得，但認真的人會同時跑好幾個，因為單一審查員都不可靠。他對賦予核准權明視訊記憶體疑：「我不知道是誰會開啟那個選項，但你想開就開吧。」

通過測試，不等於維護者願意合併 PR

演講中最犀利的證據來自一組基準測試對照。Claude Fable 5 在標準程式碼基準上通過 80% 的測試。Devin 的開發商 Cognition 另建了一套基準，問的不是「測試過不過」，而是「你身為這個 repo 的維護者，會不會合併這個 PR？」在這個問題下，通過率從 87% 掉到 54%。

Voss 對這 33 個百分點落差的解釋，就是整場演講的骨幹：合併與否，取決於程式風格、副作用、外部系統，以及那些不存在於程式碼庫、而存在於維護者腦中的歷史脈絡。維護者補上的正是「對『好』的判斷」——而這正是代理目前還沒有的東西。

瓶頸會移動；清不掉的那一關，就是人的工作

Voss 的預測建立在 Eliyahu Goldratt 的限制理論上，出自 1984 年的管理小說《目標》：每個系統只有一個瓶頸，加速非瓶頸環節毫無幫助；而當你解決了瓶頸，它不會消失——它會移動，並在下一個瓶頸前堆積。

flowchart TD
    A["寫程式——已經崩解"] --> B["程式碼審查——現在卡住，正被自動化"]
    B --> C["營運與擴充——下一關，5 到 10 年後"]
    C --> D["資安——下一關，5 到 10 年後"]
    D --> E["決定要做什麼"]
    E --> F["定義什麼叫好"]
    F --> G["做到讓人驚豔"]
    G --> H["人的瓶頸——Voss 對下一個十年的押注"]

他的時間表刻意放得很慢：他預期程式碼審查在 12 個月內會有實質進展，但營運、擴充與資安要花 5 到 10 年——並明確駁斥「2027 年就 AGI」的說法。他認為後面這些瓶頸終究會被攻破的理由是：只要某件事能被便宜地驗證，模型開發商就能針對它訓練到模型贏過它。他舉 Cognition 試圖把「可合併性」寫成可訓練的基準，以及 Cursor 的審查工具 BugBot 為例——後者把團隊每一次按倒讚都轉成一條規則，如今已累積約 44,000 條規則。一旦維護者的知識被寫下來、變成模型能訓練的素材，瓶頸就會再次移動。

他的論點還需要第二個前提：軟體需求實質上無窮無盡。他的說法是：你在美髮店、政府機關或銀行遇到的每個爛網站，之所以爛，不是因為沒人知道怎麼做好，而是因為做好很貴，而做得好的人都很忙——大概正在交付 AI 代理。需求無窮，供給又近乎無窮，瓶頸依然存在，而 Voss 押它會留在人這一側。

「什麼叫好」無法轉移，所以只能靠人

Voss 把軟體開發拆成幾個環節，按代理多快能接手來分類：寫程式已經沒了；審查與維護快要沒了；上線到生產環境與擴充是下一關，目前資料還很少；決定要做什麼、定義什麼叫好、做到讓人驚豔，大概還安全。

論點的核心在於：客戶說「我需要能追蹤我的訂單」，這不是規格。市面上有 10,000 種訂單追蹤產品；對某家特定的烘焙坊、汽車零件行或製造業者來說，運氣好的話只有一種合用。這種知識不在訓練資料裡，也不在模型權重裡——它在經營者腦中，而唯一的萃取方式就是對話。關鍵是，這種知識無法轉移：行事曆 App 和排程 App 解決的問題幾乎一樣，需求與「好」的定義卻截然不同。想用一堆設定選項硬吃所有情境、最後還是失敗的軟體——「Jira，我就是在說你」——就是這個病症。

他引用 Fred Brooks 佐證。Brooks 主持過 IBM 的 System 360 專案、寫下《人月神話》，並在 1986 年把困難拆成「偶然複雜度」（工具、語言、語法）與「本質複雜度」（問題本身），預言沒有任何單一工具能讓我們生產力提升 10 倍。Voss 說：「我們讓寫程式快了 8 倍，交付速度卻沒快多少，因為難的是本質的那一部分。」他也引用 OpenAI 的 Sean Grove（大約在演講前一年，也就是 2025 年前後）的論點：程式碼是規格的一種有損投影，所以寫規格的人——PM、立法者、工程師或行銷人員——就成了程式設計師。

Voss 主動點出自己這套論點最明顯的反駁：AI 圈最典型的陷阱，就是相信什麼都能自動化，唯獨自己擅長的那件事不行。「不不不，總有一天會有人自動化你的工作，」他說，並歡迎聽眾若發現他錯了就告訴他。

初階晉升階梯已斷，卻沒人打造替代方案

Voss 稱這是整場演講最急迫的問題，並強調這不是理論。2023 年 1 月以來的勞動統計按年齡分組顯示：22 到 25 歲工程師的就業人數崩跌，41 到 49 歲工程師的就業人數則大幅上升。「我們不招初階工程師了。這不是我覺得未來會發生的事，這是過去兩年一直在發生的事。」

背後的機制是：過去那套訓練迴圈——丟一張規格清楚的票給初階工程師、讓他寫、再告訴他哪裡做錯——正是我們現在對編碼代理做的事。那份工作不再需要人，但產品工程師需要人。Voss 算的供給帳是：Google 的副產品經理（APM）計畫一年產出約 50 人；所有類似計畫加起來一年約 1,000 人；他說需求至少是一年 10,000 人。「大學教資料結構，培訓班教 React，沒人教你去跟烘焙師傅坐一週，然後帶回一份規格。」他指出 IBM 已經在重新設計初階職位，重點放在跟客戶對話、寫規格，而不是寫程式；他也告訴工程主管，必須刻意、快速地養出這批人——「我們該開始的時間是兩年前。」

新職位就是 1960 年代的系統分析師，手藝只剩無償流傳

Voss 把這個角色命名為產品工程師：找出人們需要什麼、定義什麼叫好、讓代理代勞打字並把東西交付出去。他追溯其源頭是 1960 年代的系統分析師，工作就是跟業務端對話、找出問題所在——這個角色後來分裂成今天的產品經理，形成「原本一個半的職業變成兩個」，如今又正在合併回一個。他引用 Gergely Orosz 2019 年在《Pragmatic Engineer》中對「產品思維工程師」的描述，當時那只是個加分特質；他主張，對現在的每個工程師來說，它已從加分變成必備。

他提出的市場證據：2025 年九個月內，派駐客戶端工程師（forward-deployed engineer）的職缺暴增 800%，平均薪酬 24 萬美元——資深工程師的薪水，對應資深工程師的職務。他指出大家對職稱毫無共識；他算過，光是他口中的「產品工程師」就有大約一千種變體。Andrew Ng 告訴他，旗下有團隊提議讓 PM 人數變成工程師的兩倍——這是 Ng 職涯首見——但 Ng 的答案不是多僱 PM，而是模糊職務界線：「當工程師懂使用者、能自己決定要做什麼並直接做出來，他們的執行速度會快得驚人。」

Voss 講得很直白：這不是寫程式。「當軟體開發者和程式設計師，在 2026 年已經離婚了。」而對那些熱愛手藝——漂亮的抽象化、終於被你制伏的難纏 bug——的工程師，他沒有給任何安慰。他唯一的觀察是：很多自以為愛打字的人，其實愛的是打字前那一刻，問題突然通了的那一瞬間——而那部分還在。寫程式會像木工在傢俱工廠之後那樣存活下來：還是有人會為了熱愛而做，「只是那不會再是別人每年付你幾十萬美元請你做的事。」

現在該做什麼：少審一點、便宜驗證、把判斷寫下來

Voss 最後給的是具體處方，不是預測：

• 假設人生產程式碼的環節已經所剩無幾。 找出你的高爆炸半徑程式碼，只讓人在那裡審查；其餘交給自動審查員。
• 把能便宜驗證的事全部外包。 力氣花在建立自動判斷產出好壞的方法，然後把結果餵給代理，而不是手工微調審查流程。
• 把你最強人才的判斷寫進規格、評分標準與評測（eval）。 「把只存在人腦裡的東西變成程式碼」——把對問題的sense 轉成代理能據以建構的規格。
• 量對的東西。 程式碼多 741% 從來就不是重點。要量的是實際交付了什麼、審查意見被採納的比例，以及測試通過與維護者願意合併之間的落差。
• 把生產環境當最後一道審查員，由另一個模型盯著打分——「那就是一個 eval，」他說，這是全場唯一一句自我調侃、指向 Arize 本業的話。

他的總結金句：「三年前，Swyx 寫了 AI 工程師的崛起，講的是工程師學會用模型來打造東西。而產品工程師的崛起，講的是當模型負責打造之後，還剩下什麼。」

未解的張力正是 Voss 自己點出的那個：他預測「定義什麼叫好」會留給人，而這恰恰是他自己警告的那種論調；而 BugBot 的規則數量與 Cognition 的可合併性基準，都是這個瓶頸也可能被寫下來、被訓練掉的早期證據。他最有把握的近期風險，不是資深工程師大規模失業——他們的就業還在上升——而是一整個世代的初階工程師斷層：沒有規模足以替代的培育管道，而第一批人已經在壞市場裡熬了兩年。