對任何做產品的人來說，最怕的不是功能做不完，而是「準時上線」和「品質達標」只能二選一。維珍航空（Virgin Atlantic）這次用 OpenAI 的 Codex 交出一個少見的答案：兩者都要，而且都做到了。
為什麼聖誕檔期是最高風險的發布時機
航空公司不像一般軟體公司，App 出錯不是改版重發就好。維珍航空數位工程副總裁 Neil Letchford 說得很直接：「人們帶著這個 App 在飛，他們需要能辦理登機，需要能登上飛機。」
所以他們對「何時把應用程式交付給客戶」非常謹慎。偏偏這次要重做的手機 App，目標是在聖誕旅遊旺季前上線——這正是一年中最容易因為趕工而引入軟體錯誤的時期。
Codex 的介入讓團隊在 deadline 壓力下反而提高了品質標準：上線時達到近乎完整的單元測試覆蓋率，而且 P1（最高優先級）缺陷數為零。Letchford 形容，這在過去是「我們不習慣的事」——用 Codex 之後，「事情不會再延遲了」。
從 App 到遺留程式碼：速度與縮減幅度
Codex 的效益不只在新 App。維珍航空團隊維護多年的遺留程式碼，原本要花兩週的重構工作，現在「大概 30 分鐘到 1 小時」就能完成。在某些案例中，程式碼庫大小減少了 78% 到 80%。
這種速度甚至開始超出交付流程的其餘部分。最近一個 sprint 裡，一位重度使用 Codex 的前端開發者，從 Figma 原型做出一個完整可運作的前端應用程式（後端先以 stub 模擬），只花了一週。結果 Scrum Master 抱怨的是：「我們連後端 ticket 都還沒準備好。」
換句話說，瓶頸已經從「寫程式」轉移到「準備工作」上。
數據團隊的轉變：內部工具不再排隊
同樣的效益也發生在數據端。數據與 AI 副總裁 Richard Masters 表示，Codex 幫助他們「解除阻塞並降低風險」地將多個資料庫遷移到核心資料倉儲。分析師團隊現在可以直接在資料倉儲上開發原型——「大概幾個小時，或是在一場工作坊內」就能完成。
這改變了組織內部的協作方式。網路規劃、客戶體驗、工程與維修等團隊，現在直接用 Codex 打造自己的內部應用程式，而不是把需求排隊送進中央數據與 AI 團隊。Masters 認為，Codex 的軌跡是「超越純工程師，變成每個人都能用的工具」。
值得追蹤的下一步：當工程速度超過流程
維珍航空的例子說明了 AI 編碼工具的真實價值，不只是「寫得快」，而是讓團隊在關鍵時刻能同時兼顧速度與品質。但這也帶來新的問題：當工程比流程其他部分更快時，該怎麼規模化？
Letchford 自己提出的問題是：「我們要如何把這件事擴大，不是只在某些角落，而是貫穿整個軟體開發生命週期？」這是個「有趣且好的問題」。
對產品建造者來說，這個案例的啟示是：AI 工具最大的槓桿點，可能不在於取代工程師，而在於重新分配團隊的注意力——把時間從「寫程式」挪到「定義問題」和「準備交付」上。下一步，或許是重新設計你的 sprint 流程，讓它跟得上 Codex 的速度。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。