把每日處理約 9,200 萬則訊息的核心服務交給 AI 重寫，最值得注意的並不是「一夜產出 1.3 萬行 Go」，而是 Checkly 如何把原本依賴工程師經驗的正確性，轉換成可由機器反覆驗證的行為契約。這個案例證明 AI Agent 可以參與高流量系統遷移，卻也同時揭示：測試沒有描述到的世界，Agent 就看不見。
事件背景：瓶頸不只在效能
依 Checkly 的https://www.checklyhq.com/blog/agentic-rewrite-nodejs-to-go/自述，Results Daemon 負責接收監測結果、寫入資料庫、判斷狀態、發出警示、安排重試，以及發布 WebSocket 更新；每日約有 4,000 萬則監測結果，其餘為 WebSocket 訊息。隨平台檢查量一年內倍增，這套 vanilla JavaScript 服務逐漸成為瓶頸，也更頻繁驚動值班工程師。
因此，重寫目標並非單純降低 CPU，而是同時處理型別安全、資料庫負載、可觀測性與變更風險。Checkly 讓 Claude Code 參考舊實作，在一夜之間產出約 1.3 萬行可部署的 Go 程式；但先前使用另一模型的版本未達標而遭捨棄。這一點很重要：成功不是「下提示就完成」，而是允許失敗版本被驗收機制淘汰。
真正的運作機制：先定義什麼叫做正確
團隊在 Agent 寫程式前先建立黑箱測試框架。測試把輸入送進服務，再以舊版產生的 golden files 比對輸出；UUID、時間戳等非確定欄位雖以占位符處理，仍檢查型別。PostgreSQL 等邊界使用真實容器，網路與基礎設施故障則透過 Toxiproxy 注入。如此一來，驗收標準不依附 Node.js 或 Go 的內部結構，而依附可觀察行為。
測試資料來自前 24 小時的內部資料湖，涵蓋帳戶、群組、檢查設定與結果狀態，再壓縮成不重複的情境組合。團隊以 90% 至 100% 程式碼涵蓋率尋找缺口，但也坦承，高涵蓋率不等於所有邊界案例都正確。合理推論是，Agent 在這裡比較像受約束的搜尋與實作引擎：舊程式提供參考，測試提供目標函數，人類則決定邊界與品質門檻。
為何現在值得注意
AI 寫碼的討論常以產碼速度或完成任務數衡量，但這些指標未必代表交付速度。METR 在 2025 年對 16 名熟悉既有開源專案的工程師、246 項真實任務進行隨機對照實驗，當時觀察到允許使用 AI 反而使完成時間增加 19%；研究也強調，結果只適用於特定工具、受試者與時點：https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study-paper.pdf。
METR 後續表示，較新的 Agent 可能已帶來加速，但因不願停用 AI 的開發者退出、多人同時操作多個 Agent 等選擇偏誤，無法可靠估計幅度：https://metr.org/blog/2026-02-24-uplift-update/。因此，Checkly 案例的價值不是推翻或證明「AI 提升生產力」，而是展示一種不同工作單位：不是請 AI 零碎修改熟悉的程式，而是先花人力建立封閉且可自動評分的遷移問題。
上線結果，以及不能混為一談的因果
依公司公布的結果，新服務所需執行中的 Pod 減少 70%，釋出約 15 vCPU、45GB 記憶體；資料庫平均活躍工作階段減少 60%，CPU 約下降 15%。團隊將改善歸因於 sqlc 產生的查詢與較快完成交易、降低列鎖定。Go 官方文件確實說明 goroutine 為輕量並行單元，會多工映射至作業系統執行緒；標準資料庫介面也管理可供多個 goroutine 使用的連線池：https://go.dev/doc/effective_go。
但官方語言機制只能支持「Go 適合建構並行服務」，不能獨立證明上述節省是語言本身造成。查詢重寫、交易範圍、連線池設定、架構整理與移除舊包袱都可能共同貢獻。公司所稱「Go 的型別系統更適合 Agent」也是團隊經驗，而非已被這個單一案例普遍驗證的定律。
零事故背後，仍有一次關鍵失手
文章以「零事故」描述最終遷移，但首次導入內部正式流量後，重試立即失敗。原因是本機測試只模擬依檢查類型分流的 3 條佇列；正式環境還依優先權、託管方式等條件路由，每個區域共有 18 種可能。Agent 忠實通過了錯誤規格，卻沒有能力自行知道規格遺漏了正式環境拓樸。
團隊補齊測試、移除本機專用分支，並由人類監督重構重試模組。其後先承接約 3% 的內部流量，再按免費、月繳與企業客戶分批切換；每批觀察 24 至 48 小時，確認沒有遺失結果、全站失敗率未異常，也沒有相關客服升級才繼續。新舊服務並行期間，CI 同時對兩者執行同一套測試，功能旗標則提供即時切換能力。這些傳統發布工程措施，才是限制事故半徑的主角。
對台灣團隊的實際意義
對金融、電商、製造 SaaS 或內部資訊系統而言，最可複製的不是更換特定模型，也不一定是從 Node.js 改寫成 Go，而是先盤點「哪些業務規則只有正式環境才知道」。帳務狀態、租戶隔離、訊息至少一次投遞、重試與死信佇列，往往比函式本身更容易造成事故。
作者觀點是，導入 Agent 重寫前，預算應先投向測試資料治理、邊界清冊、可觀測性與回滾能力。若團隊沒有可重現的正式拓樸、代表性資料與明確 SLO，即使 Agent 能快速產出大量程式，仍只是更快抵達一個未被定義的終點。反之，一旦行為契約足夠嚴密，模型便可被替換，測試資產卻能持續服務後續維護。
容易忽略的限制與後續指標
目前所有營運成效皆來自 Checkly 自行發布，未提供原始監控圖、統計區間、完整人力投入或長期維護成本；「一夜完成」也未包含事前建置資料湖、測試框架，以及事後審查、重構與分批上線的工時。因此不能拿 200 美元訂閱費與 1.3 萬行程式，直接計算專案投資報酬率。
- 遷移後三至六個月的事故率、回滾率與值班告警是否持續下降。
- 相同流量下的單位訊息成本、尾端延遲與資料庫鎖定時間。
- 人類投入測試框架、審查與修補的總工時，而非只有 Agent 執行時間。
- 新缺陷中有多少源自缺少測試、錯誤環境假設或生成程式本身。
- 後續功能變更時，雙實作相容測試能否持續通過，測試資料是否隨正式環境演進。
這個案例真正跨過的門檻，不是 AI 已能獨立擁有生產系統，而是團隊把「信任工程師」重新設計成「信任可驗證、可觀察、可回滾的流程」。Agent 寫了大量程式；人類仍負責定義現實、辨認錯誤假設，並承擔上線決策。