這個笑話之所以成立，是因為它根本不只是笑話
在華文語境裡，它更常被直接叫做「隕石開發」；這個說法本來就帶著日文工程圈裡 Meteo Fall 的梗味。終點先宣布，站點中途再改，預算默認你會自己吞下，而工程團隊必須在列車已經「快要發車」時繼續鋪軌。
這個工作流做成梗會好笑，是因為現實團隊裡它真的一直在發生。
創辦人先談成一筆合作，再倒過來承諾一個連邊界條件都還沒釐清的 feature。產品團隊在 design 已經往前走之後，又把 onboarding flow 重畫一遍。管理層看到 AI 已經把上一個 screen 做得這麼便宜，就覺得再加「一個 integration」也不會太難。路線一直在變，期限卻完全不動。
壞消息是，沒有任何架構模式能阻止人類提出不現實的期待。
好消息是，不現實的期待已經不必再自動演變成工程停擺。
真正的痛點從來不只是期待不現實
糟糕的規劃當然很煩。它會耗掉時間、製造壓力，也逼團隊反覆談判。但它本身還不是最致命的部分。
真正會拖垮交付的，是每一次晚到的產品變更都立刻變成一次全系統風險。
這正是快速 AI-generated codebase 最常見的 failure mode。Version one 上線得太快，於是所有人都開始相信後面的每次改動也應該一樣快。然後現實到了：
- auth provider 要換
- analytics 得改成 optional
- 某條 deep link path 是錯的
- 一個 styling 決策擴散到 40 個 screen
- 一個「很小」的 feature 穿過三個本來無關的 module
這時團隊面對的就不只是不現實的期待，還得面對一個 無法局部吸收變化 的 codebase。
這就是雙重稅負。組織層面的問題已經夠難了，技術層面的問題只會再把它放大。
隕石開發最先壓垮的是脆弱的程式碼庫
這也是為什麼這個梗會那麼準確地打中工程師。
我們都看過同一種模式：
- 路線在地圖還沒成形前就先被宣布。
- 實作已經開始後，範圍還在持續膨脹。
- 投影片上的期限完全不變。
- 工程團隊被要求「先適應再說」。
如果系統的 boundaries 很弱，那麼所謂的「適應」通常真正代表的是：
- 逆向理解那些根本沒人設計過的 AI-generated abstraction
- 拆開彼此直接伸手進內部實作的 module
- 修復那些本來沒想碰卻被連帶打壞的部分
- 花上一整週去保留一個本來就不該保留的 implementation
到了這一步，團隊已經不是在 build product，而是在期限壓力下做考古。
這一部分，我們已經沒必要再接受。
Autotomy 改變的是失敗方式
Autotomy 不會讓幻想式預估 magically 變得現實。它做的是一件更有用的事：讓系統保持可替換。
核心想法很簡單。當某個 module 錯了、晚了，或已經不再匹配新的路線時，你應該可以 把它切掉、換掉，然後繼續往前走。
這需要幾個不能談判的前提：
- 給 auth、analytics、storage、notifications 這類易變服務加上 interface
- 用一個 composition root 決定 app 真正使用哪套 implementation
- 用 dependency boundaries 阻止 screen 直接 import vendor details
- 用 contract tests 和 deterministic checks 驗證模組替換後的行為
- 用 dependency tiers 避免 optional tools 像 launch-critical infrastructure 一樣運作
這些一旦到位，不斷移動的目標依然煩人，但它已經不再是生死問題。
provider 變更會變成 interface 背後的一次 replacement。產品繞路會變成局部重寫，而不是系統級 refactor。糟糕的 AI-generated module 會變成你可以直接刪掉的東西，而不是你必須小心保留的東西。
當路線變了，開發仍然可以繼續
這才是真正重要的實際轉變。
沒有 Autotomy 的時候，隕石開發聽起來通常像這樣：
「我們又改了 onboarding 計畫，所以現在得去動 auth、profile state、analytics、styling 和 navigation。先給我們一週時間看看會壞掉什麼。」
有了 Autotomy，它更像這樣：
「期待依然不現實，但這次變更是局部的。我們需要重新談範圍或日期，而不是重建整個 app。」
這是好得多的一種失敗模式。
你仍然可能得對交付承諾提出反對。你仍然可能得把 launch 拆開、從路線裡砍掉一站，或對臨時加出來的支線說不。但工程組織不需要再雙倍受苦了。人的問題還是人的問題，軟體問題則維持在可管理範圍內。
AI 速度讓這件事更重要，而不是更不重要
AI coding 正是隕石開發現在更常出現的原因之一。
當 Cursor 或 Claude Code 能在幾小時內生成一個 feature 的 first version 時，管理層就會開始默認後續每一輪迭代也應該像第一稿一樣快。他們看到的是表層速度，於是誤以為 change 在整個系統裡都同樣便宜。
事實並不是這樣。
AI 很擅長補全 implementation，但它不負責在 product reality 改變時保護系統結構的安全。如果 codebase 沒有 boundaries，AI speed 只會幫你更快抵達 fragility。
所以我才會一直回到同一個點：面對 AI-native development，正確反應不是更樂觀，而是更可替換。
快速生成。強制邊界。做 deterministic validation。當路線變化時，刪掉壞模組。把影響範圍控制在局部。
你還是得處理幻想的那一部分
沒有哪個 framework 會自己走進規劃會議，然後告訴別人他們的上線日期根本是想像出來的。
Autotomy 不會解決優先順序規劃，不會解決一廂情願的路線圖，也不會阻止利害關係人在施工開始後又往地圖上畫一個新站點。
那一部分，你還是得以工程師和成年人的身份去處理。
但困難應該只剩這一部分。
這份工作不該還附帶另一個任務：每次計畫一變，就得去搶救一套會跟著垮掉的 codebase。
隕石開發也許會一直像一種組織天氣一樣存在。沒關係。就讓它繼續當期待管理的梗。
有了 Autotomy，它不必再是工程受苦的梗。