OpenAI Habitat 用 Codex 重寫 Rust：AI 程式開發如何改變大型遷移

快速解答

OpenAI 在 2026 年 9 月 11 日發布一篇工程文章，說明其線上儲存平台 Habitat 如何從一個小型 Python library，成長為每秒處理超過 7,000 萬次請求、支援每週超過 10 億名使用者所使用產品，並承載超過 500 PB 資料的基礎設施。

對 AI 程式開發最值得注意的資訊出現在文章後段：OpenAI 表示，在 2026 年第二季，兩位工程師搭配 Codex 與 GPT-5.5，完成了整個 Habitat service 從 Python 到 Rust 的重寫。目前 Rust 版本已承擔 95% 的生產請求，CPU 效率是原 Python 版本的 6 倍、記憶體效率是 15 倍，平均延遲與尾端延遲也顯著下降。

這很容易被寫成「AI 幫兩位工程師完成超大型重寫」的故事。但 TowCue 認為，更值得實際工程團隊借鏡的是另一件事：

AI 程式開發確實可能改變大型遷移的成本與時機，但它沒有消除穩定架構、定義行為、建立驗證機制與分階段上線的必要性。

如果想延伸閱讀，可以參考 TowCue 的 GPT-6 Astra 工作流指南、Codex 遠端工作流指南與 AI Agent 最佳實務指南。

OpenAI 實際揭露了什麼

Habitat 在 2024 年中期起步時，只是一個 Python client library，目的是把資料庫的複雜度藏在產品團隊背後。隨著 OpenAI 的產品與服務增加，任何 client library 的修改都必須在大量服務之間協調部署，逐漸變得脆弱而且難以維護。

因此 OpenAI 把 Habitat 拉成獨立 service，集中處理部署、可觀測性、routing、access control、audit logging 與 storage policy。

OpenAI 其實早就知道 Python 最終會在這個規模下變得昂貴。對高吞吐網路服務而言，Python 會帶來額外 CPU、記憶體與延遲成本。但團隊沒有立刻重寫，因為當時更優先的事情不是語言最佳化，而是先把 service boundary 與平台穩定下來。

OpenAI 把這個決策形容成一種策略性的 technical debt，也明確表示，團隊當時押注未來 coding model 的進步，會讓後續遷移更容易。

到了 2026 年第二季，當架構成熟到一定程度後，團隊才重新處理語言問題。OpenAI 表示，兩位工程師使用 Codex 與 GPT-5.5，把 Habitat service 完整重寫成 Rust。

官方公開的生產結果包括：

Rust 已承擔 Habitat 95% 的 production requests。
Python 版本預計在接下來數週完全退役。
Rust 的 CPU 效率是 Python 的 6 倍。
Rust 的記憶體效率是 Python 的 15 倍。
平均與尾端延遲都顯著下降。

需要特別避免一個過度解讀：OpenAI 沒有說「兩位工程師取代了一個更大的團隊」。TowCue 不會從這篇文章推導這種結論。官方能確認的說法只有：兩位工程師在 coding model 協助下，完成了這一次特定的大型重寫。

最重要的決策其實發生在重寫之前

最吸睛的數字是「兩位工程師」。但更深層的工程決策，其實是 什麼時候不要重寫。

OpenAI 已經預期 Python 會成為瓶頸，仍然選擇在 Habitat 快速變化的階段保留 Python。這讓團隊有時間先穩定 service API、集中平台行為，並處理真正的 operational 問題，而不是太早把時間花在換語言。

這個順序很重要，因為 AI 輔助開發在「目標行為已經清楚」時效果通常更高。

大型重寫如果具備以下條件，會更容易驗證：

穩定的 service contract
已知的 request / response 語義
production traces 與 metrics
regression tests
performance baseline
shadowing 或 canary 基礎設施
一個仍可拿來比對的新舊實作

如果這些都不存在，Agent 可以非常快速地生成大量程式碼，但團隊仍然回答不了最難的問題：新系統在應該等價的地方，真的與舊系統行為一致嗎？

所以 TowCue 不會把這個案例解讀為「有 AI 之後應該更早重寫」。更合理的解讀是：先等 contract 穩定，再用 AI 壓縮實作階段的成本。

Coding Agent 真正改變的是哪一種成本

傳統大型重寫經常不是因為技術上做不到，而是因為 opportunity cost 太高。即使新語言更快、更安全，遷移可能要佔用幾個月的工程資源，最後總是輸給眼前的產品需求。

Coding Agent 可以從幾個地方降低實作成本：

大量轉換重複的 code pattern
建立 scaffolding 與 type conversion
一起搬移或補上測試
快速理解不熟悉的 module 與 dependency edge
平行提出 patch
反覆修正 compiler / lint 錯誤
協助比對新舊行為
在遷移過程中整理技術決策與文件

真正有意義的指標不是「AI 生成了幾行程式碼」，而是：每一單位的人類注意力，可以完成多少已驗證的遷移工作。

這可能讓部分原本「技術上值得、經濟上不值得」的專案，重新變成值得測試的選項。

AI 沒有消除什麼

Habitat 的案例也提醒我們，production migration 最難的部分從來不只是打字寫 code。

仍然必須有人決定：

哪些行為必須完全一致
哪些 technical debt 應該先保留，哪些可以重新設計
新系統要怎麼 benchmark
可以接受多少錯誤
production traffic 要怎麼 shadow
流量提升到什麼比例才算安全
哪些 metrics 一旦異常就 rollback
舊實作什麼時候才能真正移除

對一個每秒承擔數千萬次請求的 storage platform，這些都是架構與營運決策，不是 autocomplete 問題。

因此，比起丟給 coding agent 一句模糊的「把這個 service 改寫成 Rust」，更成熟的用法是把 Agent 放進一個高度可驗證的工程迴圈。

TowCue 建議的大型 AI 輔助遷移流程

1. 先把邊界穩定下來

換語言之前，先明確寫出外部 contract：API、schema、錯誤行為、authorization rule、timeout 行為與 operational expectation。

如果這些每週都還在變，重寫目標本身就不穩定。

2. 先做驗證機制，再做新實作

先建立 regression test、代表性 traffic、效能 baseline、安全檢查與 failure-mode test。

Agent 應該拿到一個可以機器判定的「什麼叫更好、什麼叫等價」，而不是只有自然語言 prompt。

3. 用有邊界的小區塊逐步搬移

讓 coding agent 處理介面清楚的 module。每個 slice 都 review diff、跑 test，並把 commit 控制在出錯時仍容易定位的範圍。

一次生成超大規模 rewrite 可能很快，但往往會把驗證成本推高。

4. 新舊系統並行

用 shadow request 或 replay 的方式餵相同或代表性的 production traffic，比對 output、error、CPU、memory、throughput 與 tail latency。

到了這一步，rewrite 才從 AI demo 變成可驗證的工程結果。

5. 逐步增加生產流量

用 canary 與明確 rollback threshold，讓流量從 1% → 10% → 50% → 95% 逐步增加。這會給團隊機會在舊系統消失之前捕捉問題。

6. 累積足夠證據後才退役舊系統

舊 stack 在遷移期間是保險。不要因為新版本「可以 compile」就移除，而要等 correctness 與 operational stability 都有足夠證據。

哪些團隊最值得關注

這個模式尤其適合 platform、infrastructure 與 backend 團隊：手上有成熟、營運成本高，但傳統上又很難排進 roadmap 的系統。

比較適合的條件包括：

系統有清楚 contract
行為可以測試
效能可以客觀量化
新舊版本可以在 rollout 期間共存
現有實作有清楚的成本或 scalability ceiling

反過來，如果產品行為本身還不明確、測試薄弱、business logic 沒文件，或無法安全地分階段上線，那就不是理想候選。

在這些環境裡，AI 可能一邊加速實作，也一邊加速產生難以發現的缺陷。

更大的 AI Coding 訊號

OpenAI 在 9 月 6 日另一篇研究文章中也表示，coding agent 正在改變內部研究人員的日常工作，包括交給 Agent 的工作量與任務複雜度。Habitat 則提供了一個比 benchmark 更接近 production 的具體案例。

AI coding 的戰略價值，未必只是讓每個工程師把「同樣的軟體」寫得更快。

更大的改變可能是：團隊開始有能力做那些過去每次排優先級都會輸掉的維護、重構與遷移專案，因為實作成本終於被壓低。

這會改變小型工程團隊可以合理考慮的工作組合。

但新的瓶頸也會轉移：從輸入程式碼的速度，轉向 specification quality、test、observability、review 與 rollout discipline。

TowCue 結論

Habitat 重寫最值得帶走的結論，不是「兩位工程師可以取代一整個 rewrite team」。OpenAI 沒有這樣說。

更準確的結論是：

AI Coding Agent 有機會把大型重寫的成本壓低到足以變成合理的策略選項——前提是人類先把系統整理到足夠可理解、可驗證。

OpenAI 先延後遷移，讓 Habitat 的架構成熟，再在 service boundary 與 operational evidence 更穩定時使用 Codex 與 GPT-5.5。這個順序，比「用了哪個模型」更值得複製。

如果你正在評估一次 AI 輔助 migration，不要先問：

「Agent 能不能把這份 code 翻成另一種語言？」

先問：

「我們能不能在 rollout 過程中，證明新實作正確、更快、更安全，而且可以隨時回退？」

答案如果是肯定的，coding agent 才真的可能改變這個專案的經濟性。

OpenAI 用兩位工程師與 Codex 將 Habitat 從 Python 重寫成 Rust：AI 輔助大型遷移真正改變了什麼