AI Engineer onepage/ The Pipeline Is Dead
Iris ten Teije, Sky Valley Ambient Computing · 19:50
這支影片在講：軟體發佈管線正在被 runtime 個人化改寫
傳統發佈系統假設「每個人跑同一版軟體」。Iris ten Teije 的主張是：當 AI 讓變更幾乎零成本、可在 client 和 user session 裡即時生成，development 和 distribution 的邊界會溶解，infra 要重新回答版本真相、debug 與隔離問題。
Published: 2026-07-07Video ID: bRnoEpoK5m4
01 / 問題
發佈管線假設過時
既有 stack 以單一版本、集中測試、固定 rollout 為核心，因為過去每次變更都很貴。
02 / 反轉
變更變得接近免費
AI 讓變更可以在 runtime、client、甚至使用者當下 session 內生成，distribution 和 development 開始重疊。
03 / 解法
把「真相」搬進 infra
新問題不是怎麼 ship，而是哪個版本對哪個人存在、如何重播、如何診斷、如何把風險框住。
Watch for this
影片最值得抓的四個訊號
Old invariant
1 version
傳統 pipeline 假設同一版軟體服務所有人，測試與 rollout 都圍繞這個不變量。
New unit
Session
變更可以在使用者 session 中發生，版本邊界從 release artifact 移到互動現場。
Scale shift
1M variants
講者反向提出：百萬個 per-user versions 可能比單一糾結 codebase 更可控。
Hard part
Truth
真正的架構問題是 truth lives where：哪個變更生效、為誰生效、如何查證。
Core story
Pipeline 死掉後，infra 要接住三件事
01
版本真相不再只是 git sha 或 release number
如果每個使用者都可能跑不同變體，系統必須能回答：這個人當下看到的是哪個 behavior、由哪些 runtime 決策生成、可否重播同一狀態。
02
Debug 對象從「一個程式」變成「一個人的程式」
錯誤可能只存在於某個使用者、某段上下文、某個當下生成的變更。傳統 log、stack trace、版本標籤不足以重建問題。
03
Containment 可能比單一 codebase 更重要
直覺上百萬個版本很可怕，但若每個變更都有清楚 scope、回溯與隔離邊界，反而可能比大家共用一個高度耦合的版本更安全。
Design trade-offs
這不是「更快 deploy」而已，是軟體單位改變
從 release artifact 轉向 runtime decision以前版本是 build 出來的東西；現在版本可能是模型、policy、context、user state 在 runtime 合成的結果。
從 staging 測試轉向可重播使用者現場當 bug 只在一個人的 session 裡存在，debug 需要 capture decision trace，而不只是收集通用 crash log。
從全域 rollback 轉向局部 containment如果變更 scope 精準，失敗可以限制在特定使用者或任務，而不是整個產品一起回滾。
從「發佈完成」轉向「持續校準」Development 和 distribution 邊界模糊後，系統要能在使用中學習、調整、驗證，同時保留可審計性。
Use this checklist
如果你在做 adaptive software，先檢查這五點
每次個人化變更是否有可查的 lineage？至少要能追到來源 prompt、policy、model output、user context 與生效範圍。
你能否重播某個使用者當時看到的版本？沒有 replay，debug 會變成猜測；有 replay，per-user bug 才能被工程化處理。
變更 scope 是全域、群組，還是單一 session？scope 越清楚，rollback、containment、責任歸屬與安全審查才越可控。
真相來源是否被產品邏輯偷渡？不要只把個人化結果藏在 client state；infra 層要知道什麼變體存在，以及它為誰存在。
你的 observability 是否看得懂「使用者版軟體」？Metrics、logs、traces 要能按 variant / session / decision 切分，否則只會看到平均後的假穩定。
Source video