AI 兩週清掉的五年積壓，原本排在 Asana 的「有空再做」

五句話。

Asana 的工程團隊今年 8 月 7 日在自家部落格貼出一段提示詞，說這就是他們交給 AI 代理的全部指令。第一句講目標：把整個程式碼庫的測試從 Enzyme 搬到 React Testing Library。接著要它遵守程式碼庫既有的規範，搬完某個目錄底下所有用到 Enzyme 的檔案。再用指定的指令跑測試，先挑好搬的搬。

文章標題是〈我們兩週搬離了 Enzyme，這件事本來要五年〉。照他們自己的說法，整件事花了兩個日曆週，工程時間大約一週半。OpenAI 十一天後把它做成客戶案例，大字寫著兩週清掉五年的工程工作。

Asana 是做工作管理軟體的上市公司，這個團隊搬的是前端測試框架。Enzyme 是一個失去社群維護的 React 測試函式庫，跟新版 React 處不好；接手的是 React Testing Library（RTL）。這種搬家工程師都懂：苦、長、沒人想做，做完了產品看起來一模一樣。

2022 年開始搬，搬了幾年還剩五年

Asana 部落格說，他們 2022 年就開始搬了。好幾個「多工程師年」規模的專案排進去過，各產品團隊也各自清自己負責的角落。文章承認那些工作都算數，接著寫：「但照我們當時的速度，離搬完還有大約五年。」

另一個版本的起點是 2024 年。這是 Asana 開發者生產力負責人 Dan Ubilla 後來向 The Pragmatic Engineer 說明時給的年份，我把兩個說法並列，不判誰對。

於是團隊訂了一個他們自己叫「刻意不合理」的目標：一週內搬完。結果差一點，一週半。文章寫 Enzyme「現在已經從程式碼庫裡完全消失」。

一週半，四個代理，早晚各看一次

做法他們自己形容「簡單到幾乎讓人不好意思」。用 OpenAI 的 Codex，前沿模型開到最高推理強度，最多同時跑四個代理，每個指一個目錄。機器設成不休眠，讓代理跑一整天加一整夜，工程師早晚各看一次進度、開 PR。

他們也試過更講究的做法：拆成追蹤中的工單、讓代理寫進度筆記、叫它開子代理、寫一份長長的 RTL 規範提示。文章的結論是：「幾乎全部都讓結果變差。簡單贏了。」

卡住的地方多半不在模型。 有幾份不久前才寫的內部文件和給代理讀的指引，還把 Enzyme 寫成建議作法，等於把代理往反方向推。文章說，過時的文件不再只是小麻煩，它是「每一個讀它的代理的誤導性訓練材料」。AGENTS.md 這類給代理讀的檔案，從此跟程式碼一樣會出 bug。

另一個卡點是慢而不穩的工具鏈，一個 lint 步驟偶爾要跑十分鐘以上。Asana 把圍繞程式碼的文件、慣例與回饋迴圈統稱 harness，說它現在才是產品。

模型帳單約 1.1 萬美元，基礎設施再加約 1 千。文章末尾用「餐巾紙數學」替這筆錢找了一個對照。如果用人工做完同等範圍，「大約相當於 600 萬美元的全成本工程投入」。那個範圍不只是搬框架，還包括順手補的測試覆蓋、修掉的爛測試、清掉的舊測試設施。

三週後，有人問那五年是怎麼算的

8 月 18 日，OpenAI 的客戶案例上線，標題是「Asana 用 Codex 兩週清掉五年的工程工作」。頁面上兩塊大字：兩週，完成原本預期要五年的工作；1.2 萬美元，對照 Asana 約 600 萬美元的人力估算。

8 月 27 日，The Pragmatic Engineer 的 Gergely Orosz 寫了一篇文章，第一句評語是：OpenAI 引用的時間和 600 萬美元「感覺被誇大了」。他沒有停在那裡，去問了 Asana。接下來這一段，全部是他轉述 Ubilla 的說明，不是 Ubilla 的原話。

Asana 2024 年開始這一輪遷移時，有四千多個 Enzyme 檔案。團隊先用當時的大型語言模型搬了大約四分之一，挑的是最好搬、最常改的那些。剩下的，降級了。

Asana 內部把遷移分成三層：critical 是「必須盡快做」，important 是「重要、該盡快做」，opportunistic 是「有空再做」。前兩層排滿了別的遷移。Enzyme 剩下的那四分之三，躺在第三層。

所以「五年」是什麼？ 照 Orosz 的轉述，它「是指這個有空再做的 Enzyme 遷移，在它的優先序下，實際上會在什麼時候做完」。不是一個團隊不停做五年。

600 萬怎麼來的，Ubilla 也說了，Orosz 寫成四步。估一個工程師手動搬一個檔案要多久，估得寬一點。乘上剩下的三千多個檔案。加上清掉框架殘跡、監控、靜態分析工具的時間，再乘上一般工程師的時薪。

這個算法沒算熟練效應，也沒假設會用 LLM。Orosz 自己的看法是：「這個數字大概是高估了，但重點不在數字，而是要表達這是很大一堆工作。」

還有一件事我只寫一句：OpenAI 那頁現在的寫法跟 8 月版本不同。標題改成「完成一個多年的程式碼遷移」。大字改成「照先前速度預計還要約五年」，還補上「只有幾位工程師在其他優先事項之間順帶做」。頁面沒有更新註記，改版日期和原因我不知道。

Airbnb 的一年半、Uber 的四個月，分母也各不相同

同一種遷移，Airbnb 2025 年 3 月也公開過一次。它有將近三千五百個 Enzyme 測試檔，原本估「人工做要一年半的工程時間」，最後六週搬完。但六週不含 2023 年中那場證明可行的黑客松，也不含 2024 年搭流水線的時間。

Airbnb 的曲線值得記：第一輪批次跑四小時就搬完四分之三，剩下的靠重試迴圈和塞到十萬 token 的脈絡慢慢磨。它用的不是五句話，是一條流水線。

Uber 今年 4 月公開的 JUnit 4 到 5 遷移是反例，規模是六十萬個測試。文章明寫：「我們試過用生成式 AI 一次遷移多個測試類別檔，但這個做法失敗了。」最後靠的是 OpenRewrite 這類確定性的程式轉換工具，AI 只拿來除錯。

這篇裡的數字，沒有一個經過外人的手

反面我要寫四件事，每一件都在跟我的讀法打架。

第一，全部是自述加合作方背書。Asana 文末寫明這篇是「Asana 與 OpenAI 持續合作關係的一部分」，OpenAI 那頁則是掛著「聯絡業務」的銷售案例。唯一的外部核對是 The Pragmatic Engineer，而且 Ubilla 的部分是轉述。檔案數、PR 數、測試通過率，沒有一個可獨立驗證的數字公開過。

第二，兩個分母不是同一件事。600 萬對應的是擴大後的範圍，含補覆蓋、修測試、清設施；五年對應的是原本那個遷移在原優先序下的時程。把 1.2 萬美元拿去對 600 萬，比的是兩張不同的單子。

第三，成本只算了模型帳。1.2 萬美元不含工程師那一週半的薪水，不含每天兩次審 PR 的時間。Orosz 反過來指出，用更便宜的模型可能還不用這麼多，所以我不自算淨省多少。遷移後的覆蓋率、不穩定測試的比例、回退次數，也都沒公開。

第四，這一點最直接打我的命題：「有空再做」不等於「不會做」。Asana 2022 年起就排過多工程師年的專案，2024 年又搬了四分之一，剩下的每年都在被一點一點清。Enzyme 擋著 React 升級，這件事終究得做。Orosz 的立場更徹底：不管估成多長多貴，照傳統做法它都是不切實際的工程，所以數字本身不重要。

Asana 自己也賣 AI 代理產品，有動機把工程成果講大，這句當背景。

看導入數字，先問沒有 AI 這件事會不會被做

讀完這三份文件，留在我腦裡的不是兩週，是那三層。

「省下 X 年、Y 百萬」的分母，是一張本來就不會被照著執行的工期表；讀任何 AI 導入案例，第一個問題是：沒有 AI，這件事原本會不會做。 Asana 的答案自己寫在優先序裡：至少五年內不會。

這不代表收益是假的。一件本來要躺五年的事做完了，Enzyme 真的從程式碼庫消失了，這是實打實的。只是它的單位不是省下的美元，是「一件原本不會做的事變成做完了」。拿它去對 600 萬，等於把一張不會執行的估價單當成本。

Klarna 那篇我寫的是量尺：第一年量省幾個人，第二年才發現漏量了什麼。Asana 這篇是分母：省下的時間，除以的是什麼。兩個問題都不在模型身上。

我把話停在這裡，因為再往前一步就沒有文件撐。我不知道剩下那四分之三裡，有多少是 2022 年那些專案做過一半的。Asana 的部落格文章本身有沒有改過，網路存檔沒有快照，OpenAI 那頁為什麼改寫也沒人說。這三件事任何一件有了答案，這篇的分母都要重算。

Asana 部落格自己收在一個問題上：有沒有真的試過把代理指向這件事跑一個週末，週一看看回來什麼。你公司裡也有那一層，排在「有空再做」、每季都被往後推的東西。把它丟給代理，成本是幾千美元，值得試。但報戰果的時候，分母要寫清楚：那是一件本來不會做的事，不是省下五年的人力。

查核備註：Ubilla 的說明只讀到 The Pragmatic Engineer 的轉述，未見原話；Asana 部落格無網路存檔快照，無法確認發布後有無修改；OpenAI 案例頁改版的日期與原因未查到。