A 組 vs B 組：一個 AI coding agent 的對照測試

唐鳳前陣子在 Threads 提到一個做法：用 Sakana 的 fugu-ultra 當 omp 的 advisor，去即時審一個便宜快模型（像 Gemini 3.5 Flash）的產出。我想說來測一下。

我讓兩組設定做同一個 coding 任務：

• A 組：omp，worker 是 Gemini 3.5 Flash，配 fugu-ultra 當 advisor。
• B 組：Claude Opus 4.8 + ultracode，會自己開一堆 sub-agent 互相審查——這是我平時處理複雜專案的最重量級武器。

任務是同一個專案裡的三個改動：一個計時器的提示音、一個數值輸入加一張累積圖表、一個資料模型的重構（刪掉一些舊項目、把歷史紀錄遷移過去）。兩組各開一個 git worktree，丟一樣的 prompt，自動跑，我開 tmux 看著。

結果：

兩組都 typecheck 過、build 過、測試全綠（一個 1530、一個 1539）。

前兩個功能，A 組做得不差，有些細節甚至比 B 組完整。成本大概八美金、跑一輪就好；B 組開了一堆 sub-agent，跑了一個多小時。

第三個出事了，是資料庫遷移。A 組的做法是 DELETE 掉舊資料、再把外鍵指到新的；它照搬專案裡一份舊的遷移範本，只處理了範本列的那四張表。但專案後來新增的兩張表，外鍵是 ON DELETE CASCADE——所以那行 DELETE 會連帶把一批歷史紀錄靜默刪掉。不報錯，測試也抓不到，因為那是資料庫層的事，前端 typecheck 跟單元測試碰不到。

B 組寫完之後，ultracode 另外開了一個專門審資料安全的 agent，掃過所有外鍵跟 ON DELETE 規則，抓到了。它選的做法是不刪、就地改名、保留原本的 id，所以歷史紀錄不用搬就完好。

A 組事後自己分析，承認它太相信舊範本，又把「測試全綠」當成安全，漏了重新掃一次外鍵。

結論：A 組這種又輕又便宜的配置很划算，甚至更完整。但不可逆的東西——資料遷移、刪除——A 組少了一個會挑剔的審查角色，會漏掉測試碰不到的地雷。所以我之後會分開：一般功能用 A 組，碰到 DELETE 或 migration 就升級到 B 組的多 agent 審查。