Reco（一家 SaaS 安全公司）用 AI 在七小時內把 JSONata 從 JavaScript 重寫成 Go，產出 13,000 行程式碼，通過 1,778 個測試案例。token 花費 $400。上線後每月省 $25,000 compute 費用，加上後續的 pipeline 優化，年省 $500K。
這個故事在 Hacker News 上拿了 207 分和 186 則討論。數字很吸睛，但真正值得學的不是數字——是他們怎麼確保 AI 生成的 13,000 行程式碼不會在生產環境炸掉。
問題：一條昂貴的語言邊界
Reco 有一個 policy engine，用 JSONata（一種 JSON 查詢和轉換語言，類似 jq 但有 lambda）對資料管線中的每條事件做規則比對。幾十億條事件，上千條規則。
JSONata 的參考實作是 JavaScript。Reco 的 pipeline 是 Go。所以他們多年來一直在 Kubernetes 上跑一整組 Node.js pod——Go 服務透過 RPC 呼叫 Node.js 來做 JSONata 運算。
每次呼叫的代價：序列化 → 網路傳輸 → 執行 → 序列化結果 → 傳回。一次 RPC round-trip 就是 ~150 微秒的開銷，而很多簡單查詢（像 user.email = "admin@co.com"）本身只需要奈秒。
他們最大的叢集光是 JSONata 就跑了超過 200 個 replica，月費 $25K，而且還在隨客戶數成長。甚至因為 pod 太多，撞到了 Kubernetes 的 IP 分配上限。
過去幾年他們試過幾種方案——優化表達式、結果快取、把 V8 嵌進 Go 裡（省掉網路跳轉）。都是微調，根本問題沒解決。
方法：Cloudflare 啟發的 AI 重寫策略
靈感來自 Cloudflare 公開的「一週用 AI 重寫 Next.js」文章。方法論一模一樣：
- 把官方 jsonata-js 的測試套件搬到 Go
- 讓 AI 實作 evaluator，直到所有測試通過
- 不用 AI 猜怎麼寫——用測試套件當 spec
作者花了一個週末用 AI 做計畫，把工作分成「waves」。隔天開始跑，用 Cursor，七小時後出了 13,000 行 Go 程式碼，1,778 個測試全過。
成品叫 gnata，已經開源。
架構：不只是翻譯，還重新設計了 fast path
gnata 不是盲目的 1:1 翻譯。它有一個雙層求值架構：
Fast path： 簡單表達式（欄位查詢、比較、21 個內建函數）直接在原始 JSON bytes 上求值，不解析整份文件。像 account.status = "active" 這種查詢，零堆積分配（0 heap allocations）。
Full path： 複雜表達式走完整的 parser + evaluator，但只解析實際需要的子樹。
上面還有一個 StreamEvaluator 批次層：N 個編譯好的表達式對每個事件做求值，所有欄位路徑合併成一次掃描。事件的結構相似時，求值計畫只算一次然後快取。hot path 無鎖。
效能數字：
| 類型 | 加速倍數 | 原因 |
|---|---|---|
| 簡單查詢 | ~1,000x | 消除 RPC + 直接 byte 操作 |
| 複雜表達式 | 25-90x | 仍有 JSON parsing，但省了序列化和網路 |
上線：七天的 shadow mode 才是關鍵
Day 1： gnata 建好，開 PR。
Day 2-6： Code review、QA、部署到 preprod 的 shadow mode。gnata 處理每一條事件，但實際使用的仍是 jsonata-js 的結果。兩邊結果不一致時觸發告警。
Day 7： 連續三天零 mismatch，gnata 升為 primary。
在升級之前，gnata 已經處理了數十億條事件，結果與 jsonata-js 完全一致。他們甚至發現了 jsonata-js 本身的 bug——參考實作沒遵守自己的 spec。
這個 shadow mode 基礎設施不是臨時搭的——他們幾個月前就為另一個 local evaluator 建好了 feature flag、shadow evaluation、comparison logging。接 gnata 進去只是接線的事。
這是整個故事裡最關鍵的一點：AI 幫你寫完 13,000 行程式碼，但你能不能上線，取決於你有沒有基礎設施來驗證這些程式碼。
後續的 $200K
消除 RPC 省了 $300K/年。但 JSONata 的單次求值限制一直在影響 pipeline 設計——他們得開上萬個 goroutine 來最大化並行，記憶體和 CPU 都很吃。
gnata 沒有這個限制，所以他們重構了 rule engine：just-in-time batching、短期快取、分組 enrichment 查詢。pipeline 簡化了，throughput 大幅提升，又省了 $200K。
HN 社群的質疑和回應
186 則討論裡最常見的質疑：
「七小時寫 13,000 行？那維護怎麼辦？」 合理的擔心。但 gnata 有 1,778 + 2,107 個測試案例，coverage 很高。而且他們提到了一個有趣的副作用：AI agent review AI-generated code 時，會同時標記真正的並行問題和無關緊要的 cosmetic 問題。團隊得教 AI review agent 分辨輕重——這個經驗反過來改善了他們整體的 AI code review 流程。
「$400 token 費不包含工程師時間。」 對。作者花了一個週末做計畫，七小時盯著跑。但對比原本的選項——手動重寫 JSONata 2.x 全 spec 的 Go 版本——那是數個月的工程。
「換個公司能複製嗎？」 能複製的前提是你得有：(1) 完整的測試套件當 spec；(2) shadow mode 基礎設施做驗證；(3) 工程師有能力判斷 AI 產出的品質。缺任何一項都不行。
對你的團隊意味著什麼
這個案例提供了一個清晰的 AI 輔助重寫 playbook：
1 | 1. 確認你有完整的測試套件（這是 spec，不是可選項） |
適合這個方法的場景：
- 跨語言重寫（JS→Go、Python→Rust）
- 有明確 spec 和測試套件的 library
- 效能瓶頸在語言邊界或序列化開銷
不適合的場景：
- 沒有測試套件的遺留系統（先補測試，再談重寫）
- 業務邏輯複雜且 spec 模糊的核心系統
- 「重寫」的動機是技術潮流而不是真實的效能或成本問題
Reco 的成功不是因為 AI 很厲害。是因為他們有完整的測試基礎設施、成熟的 shadow mode 流程、和一個真實且量化的問題（$300K/年的 compute 費用）。AI 是工具，不是魔法。