AI agent 寫程式越快，開發者越需要會算帳
最近看 AI coding agent 的討論，最容易被拿出來講的還是速度。
兩天做了多少功能、多久補完一個 PR、是不是已經可以讓人少寫很多程式。這些故事很吸引人，也不全是假的。可是如果你真的把 agent 放進日常開發，另一個比較無聊的問題很快就會浮上來：
它到底花了多少額度？
這句話聽起來很小氣。工程師好像不該先關心帳單，應該先關心能力。但小團隊的現實剛好相反。工具一旦進入固定流程，成本就不再是採購才要看的東西，而是工程設計的一部分。尤其是 coding agent 這類工具，它消耗的不只是訂閱費，還有 token、session quota、CI 分鐘數、review 時間，以及最麻煩的信任成本。
我越來越覺得，AI agent 的下一個瓶頸不是智力，而是可預測性。
寫 code 變便宜之後，昂貴的是周邊
過去談開發成本，很多人會先想到人力。工程師一天能寫多少、review 要排多久、CI 跑多久、上線風險多高。AI agent 出現後，大家自然會期待「寫 code」這件事變便宜。
但便宜不等於免費。
如果一個 agent 可以連續幫你拆任務、改檔案、跑測試、修錯，它同時也會連續消耗模型額度。你很難只用「一次回答多少錢」來估算它，因為真正的工作流不是一次 prompt，而是一串反覆溝通、讀檔、生成、驗證、再修正的循環。
這也是為什麼 Claude Code 使用者抱怨額度消耗太快，不只是「大家想用更多」這麼簡單。問題在於，當 agent 開始接近真實工程工作，它的消耗模式會變得很像一個會自己打開很多分頁、跑很多命令、反覆查上下文的同事。它做得越多，你越需要知道它用了什麼資源、卡在哪裡、還能不能撐到今天下班前。
如果額度規則不透明，團隊就很難排工作。你不知道一個大 refactor 應該交給 agent 到什麼程度，不知道今天剩下的 quota 夠不夠處理線上 bug，也不知道要不要把某些任務留給人手動做。
這時候，所謂的「AI 開發效率」就不只是模型能力問題，而是排程問題。
AI review 也會進帳本
GitHub Copilot code review 將開始消耗 GitHub Actions minutes，這件事很值得注意。不是因為 Actions minutes 本身多貴，而是它把一個方向講得很清楚：AI review 不是外掛在工程流程旁邊的免費服務，它會吃掉原本屬於 CI/CD 的資源。
這會改變團隊怎麼使用 AI review。
以前你可能會想，每個 PR 都讓 AI 看一下，反正多一層檢查總是好的。但如果它開始消耗 CI 類資源，問題就變成：哪些 PR 值得跑？什麼情況只需要一般 lint 和測試？什麼情況才需要 AI 幫忙做語意層面的 review？
對大公司來說，這可能只是多一個 usage dashboard。對台灣的小團隊、接案團隊、獨立開發者來說，這更像是一個工作流設計題。
你不能把每個工具都設成預設開啟，然後月底才發現帳單和額度爆掉。你需要規則。例如：
只有牽涉 auth、付款、資料遷移的 PR 才跑 AI review。
純 UI copy 或樣式調整先走一般 review。
agent 修改超過一定檔案數時，必須拆 PR。
長任務先要求 agent 寫計畫，再決定是否放行。
這些規則聽起來一點都不酷。可是工程管理本來就常常不酷。真正讓產品穩定交付的，通常不是某個 demo 裡最炫的能力，而是那些會讓系統少出事的限制。
Agent 需要邊界，不需要無限自由
很多 vibe coding 的敘事會讓人以為，最理想的狀態是把需求丟給 agent，然後等它自己完成。
我不太相信這是大多數團隊的好方向。至少現在不是。
比較務實的做法，是把 agent 當成一個能力很強、但需要清楚工作範圍的協作者。你要告訴它能改哪些檔案、不能碰哪些東西、測試怎麼跑、失敗時要停在哪裡。更重要的是，你要知道什麼時候不該讓它繼續跑。
人類工程師做錯了，通常會在某個地方卡住，或者至少會問一句「這邊要怎麼處理」。Agent 做錯了，有時候會很有自信地繼續往下補。它可能把一個小 bug 修成一串大改動，把本來應該問清楚的產品決策變成自己假設的實作。
所以新的 senior 能力，不是比誰更會把 prompt 寫得像咒語，而是能不能設計出好的限制。
限制不是阻礙自動化。限制是讓自動化可以被信任。
小團隊該怎麼開始算這本帳
如果你是一個三到十人的小團隊，我會建議先不要急著追求「全自動開發」。先把 agent 成本拆成幾個看得見的欄位。
第一個是額度成本。每天或每週可以用多少 session、多少 token、多少付費額度，至少要有人知道大概範圍。不是要大家每次使用都填表，而是要避免整個團隊在同一天下午一起撞上限制。
第二個是 CI 成本。AI review、測試、自動修復、preview deployment，都可能在 agent 工作流裡被放大。以前一個人一天開三個 PR，現在 agent 幫你切出十個 PR，CI 壓力就跟著變多。
第三個是 review 成本。Agent 可以產生更多 code，但不會自動讓人類 review 更快。相反地，它可能讓 review 變得更難，因為 reviewer 要先判斷這些改動到底是理解需求後產生的，還是只是把表面錯誤補起來。
第四個是回滾成本。Agent 做出來的東西如果沒有清楚邊界，出事時很難判斷該退哪一段。這比多花一點 token 更可怕。
把這些成本列出來後，你會發現很多決策變得比較清楚。不是每個任務都適合 agent。不是每個 PR 都值得 AI review。不是每次生成都應該一路跑到底。
有些任務適合讓 agent 大量處理，例如重複性 migration、測試補齊、文件同步、已經有明確規格的小功能。有些任務最好先由人類定義清楚，例如資料模型、權限邏輯、付款流程、牽涉品牌語氣的產品文案。
這不是保守，而是把工具放在它最能發揮的位置。
Vibe coding 不是不用學工程
台灣最近也開始更常看到 vibe coding 的討論。很多問題會被包裝成「人類還需不需要學寫程式」。我覺得這個問法有點偏。
AI 的確讓入門變快。很多原本要卡很久的環境設定、樣板程式、API 串接，現在可以用比較短的時間跨過去。這是好事。
但如果你真的要把東西做成產品，工程能力沒有消失，只是換了位置。以前你需要親手寫每一行，現在你更需要知道哪一行不該被接受。以前你要記住很多語法，現在你要更會讀 diff、切任務、設計驗收條件、控制權限和成本。
也就是說，vibe coding 不是不用學程式，而是你更早碰到工程判斷。
當 agent 寫 code 越快，錯誤也會更快累積。當工具越容易啟動，濫用也越容易發生。當每個人都可以生成一堆功能，真正稀缺的能力反而是知道哪些功能不該現在做，哪些自動化不該預設開啟，哪些成本要先算清楚。
會算帳，才真的能放手
我不想把 AI agent 說成只是另一個需要管控的成本中心。它確實改變了開發方式，也讓很多小團隊可以做以前做不到的事。
但越強的工具，越需要清楚的邊界。
未來幾年，大家可能會慢慢習慣一件事：寫程式本身不再是最慢的部分。比較慢的會是定義問題、控制資源、驗證結果、承擔責任。
所以開發者要學的不是少了，而是變了。
你要會用 agent，也要會停 agent。你要知道什麼任務值得花額度，什麼任務只是在浪費 context。你要能看懂它生成的 code，也要能設計出它不容易亂跑的流程。
AI agent 寫程式越快，開發者越需要會算帳。這本帳不只是錢，也是時間、風險、注意力和信任。
會算這本帳的人，才比較有資格把一部分工作交出去。