2026年7月，Robert C. Martin 寫道，他已不再閱讀自己的 coding agent 所產生的程式碼。
這番話引發了廣泛關注。但他貼文的其餘部分，才是理解他工作方式的關鍵。Martin 用單元測試、Gherkin 驗收測試、QA 流程、突變測試、覆蓋率檢查和品質指標將 agent 層層包圍。程式碼必須通過這套系統，才能獲得他的信任。
他幾個月前也表達過類似的觀點。他不檢查實作細節，而是查看測試覆蓋率、依賴結構、循環複雜度、模組大小和突變測試結果。當有人將此解讀為完全放棄審查時，他澄清道：「我審查的東西很多——只是不審查程式碼本身。」
他的評論點出了 AI 密集型軟體開發中的一個實際問題：coding agent 產生變更的速度，可能超過人類閱讀的速度。一旦 AI 生成的程式碼量超過團隊的審查能力，逐行檢查就無法再是建立信心的唯一手段。
過去八個月，我們在 vm0 也面臨同樣的問題。我們儲存庫中大部分的實作都由 agent 撰寫——也就是大家常說的 vibe coding——而六位工程師仍然對這些程式碼在生產環境中的行為負責。
摘要
vm0 是一個 vibe coding 的程式庫：agent 撰寫大部分實作，六位工程師對其生產行為負責。歷經八個月，儲存庫已累積 1,329,170 行程式碼，並在單週內合併了 630 個 pull request。五項機制承擔了逐行審查無法單獨承擔的品質責任。
- 統一的環境。 工程師與 agent 在同一個 dev container 中工作，每個 pull request 都可以擁有自己的資料庫分支。對 agent 有效的指令，對人也同樣有效。
- 可執行的約束。 嚴格的 TypeScript、約135個型別化 API 合約模組、Oxlint、ESLint 與架構規則，CI 不接受任何警告。能以機械方式檢查的規則，就不留給人工審查。
- 以邊界為焦點的測試。 採用測試獎盃而非測試金字塔：透過公開模組邊界進行整合測試、使用真實的 PostgreSQL 與真實的 migration，僅在外部系統邊界使用 mock。測試程式碼約佔儲存庫的36%。
- 完整的回饋迴路。 Agent 啟動應用程式和資料庫、執行 migration、驅動真實瀏覽器，並回報所執行的指令、測試路徑和截圖。PR 的合併中位時間約為53分鐘。
- 持續清理。 Knip 以確定性方式移除死碼，每日工作流程清除任何 linter 無法命名的 AI 殘留，而重複出現的模式則會被提升為 lint 規則或納入型別系統。
Vibe coding 與 agentic coding 的真正含義
Vibe coding 是向 LLM 提示生成程式碼、執行其產出、要求修改，並完全不關注生成的程式碼本身。Martin Fowler 的定義刻意保持狹義，他特別強調「忘記程式碼的存在」這個說法。它適合原型、一次性軟體，以及影響有限的小工具。
Agentic coding，即 Fowler 所稱的 agentic programming，是團隊在預期維護成果時所採用的方式。Agent 讀取儲存庫、編輯檔案、執行測試，並在較長時間內獨立工作，而人類則持續掌握結構與行為的所有權，並審查一次執行所產生的證據：測試結果、品質訊號、預覽和生產行為。
差異不在於模型撰寫了多少程式碼，而在於人類的注意力放在哪裡。
| Vibe coding | Agentic coding | |
|---|---|---|
| Agent 自主性 | 提示、執行、再提示 | 讀取儲存庫、編輯、測試、迭代 |
| 誰閱讀程式碼 | 沒有人 | 人類閱讀具有風險的部分 |
| 驗證什麼 | 輸出看起來是否正確 | 型別、合約、測試、預覽、生產訊號 |
| 最適合 | 原型與一次性工具 | 有維護週期的軟體 |
| 典型失敗 | 沒有人理解的程式碼 | 驗證機制不足以應對程式碼量 |
編輯儲存庫的 agent 是更廣泛轉變中的一個分支；我們另外探討了非開發者的那一面。
我們常將 vm0 稱為 vibe coding 專案，因為這個說法已成為主要由 AI 撰寫的軟體的常見簡稱。以 Fowler 的術語來說，它更接近 agentic coding。我們的工程師輸入的實作程式碼比以前少，但仍持續掌握架構、維護成本和生產行為的所有權。
隨著程式碼生成速度加快，更多責任轉移到了開發環境、型別系統、測試套件和自動化維護工作流程中。
Vibe coding 程式庫八個月的成長
vm0 儲存庫於2025年11月建立。在我們最新的每週工程規模報告發布時，它已有大約八個半月的歷史。
儲存庫包含：
| 指標 | 數量 |
|---|---|
| 非空邏輯行數 | 1,329,170 |
| 生產程式碼行數 | 850,913 |
| 測試程式碼行數 | 478,257 |
| 原始碼檔案數 | 5,549 |
| 測試檔案數 | 1,327 |
| 套件數 | 44 |
| 主分支 commit 數 | 14,005 |
這些數據來自2026年7月20日至26日當週的每週工程規模報告，直接從 monorepo 測量而得。測試程式碼約佔測量程式庫的36%。這是程式碼量的佔比，而非測試覆蓋率數字，但它能讓人感受到圍繞驗證所累積的實作規模。
在最近三個完整週中，六位工程師分別提交了541、640和631個 commit。在7月20日至26日當週，GitHub 記錄了630個已合併的 pull request。六位工程師撰寫了其中556個，其餘74個由發布自動化系統撰寫。
從開啟 pull request 到合併的中位時間約為53分鐘，第90百分位數約為7.4小時。
在這樣的變更速度下，人工審查仍然有用，但無法承擔整個品質系統的重量。我們需要在變更生命週期的多個節點上建立獨立的訊號。
我們目前的方法有五個反覆出現的主題：統一環境、可執行的約束、以邊界為焦點的測試、完整的回饋迴路，以及持續清理。
透過 dev container 統一開發環境
許多難以重現的失敗，來自於從未出現在 pull request 中的狀態。
開發者可能有未記錄的環境變數、全域安裝的工具、舊的設定檔，或已運行數月的資料庫。人們習慣了這些細節，但 agent 通常看不到它們。
我們逐漸停止將主機機器視為標準開發環境。工程師和 agent 都在 dev container 內工作。開發映像包含專案工具鏈、PostgreSQL、pgvector、Chromium 和瀏覽器自動化工具。
CI 執行從同一個多階段 Dockerfile 系列建構的版本化工具鏈映像。開發映像和 CI 映像有不同的用途，生產環境也有自己的部署形態。有用的特性是統一性：工具版本、依賴項和執行時假設都是明確且版本化的。
這讓我們有了一個直接的預期：agent 執行的指令，應該可以由工程師在同一個開發容器中重現。在開發期間通過的檢查，應該在 CI 中以密切相關的工具鏈下執行。
我們對資料也應用了類似的概念。每個 pull request 預覽都可以擁有自己的資料庫分支，並執行真實的 migration 和種子步驟。Agent 可以建立資料、修改資料，並重複執行破壞性測試，而無需借用開發者現有的資料庫或繼承其他 pull request 的狀態。
環境變更透過儲存庫傳遞。工具升級、瀏覽器版本和資料庫擴充套件的審查和傳播方式，與應用程式程式碼相同。
將工程標準轉化為型別和 lint 規則中的可執行約束
書面標準有助於人們理解設計決策，但對於確保每次變更都遵循這些決策的效果有限，尤其是在長時間的 agent 工作階段中。
我們盡可能將穩定的規則放入型別系統、linter 和 CI 中，前提是該規則能夠可靠地表達。
vm0 使用嚴格的 TypeScript 設定，包括 strict 和 noUncheckedIndexedAccess。部分套件還啟用了對未使用值和隱式回傳的額外檢查。
API 使用以 schema 為優先的型別化 REST 合約層，基於 tRPC 的型別機制和 Zod schema 建構。Drizzle 將資料庫存取連接到 TypeScript 型別。在本次審查時，儲存庫包含約135個合約模組。
這些選擇無法捕捉錯誤的產品決策，但能及早發現介面漂移。當欄位或回應發生變更時，相關的呼叫端往往在靜態分析期間就會失敗。產生的錯誤通常足夠具體，讓 agent 能在下一次迭代中使用。
Lint 涵蓋第二組規則。平台執行 Oxlint、型別感知檢查和 ESLint，以及專案特定的架構規則。CI 不接受任何警告。可以無限期存在的警告往往會成為背景雜訊，而背景雜訊很容易被人和 agent 忽略。
當問題重複出現時，我們會考慮檢查應該歸屬於哪裡：
- 型別系統能否表達它？
- Linter 或結構工具能否準確偵測它？
- 它是否需要跨儲存庫的語意判斷？
前兩項對每次變更提供快速、確定性的回饋。第三組由本文後面描述的定期工作流程處理。
縮小 AI 生成程式碼中容易出錯的模式
某些語言特性有其合理用途，但也頻繁出現在脆弱的 agent 生成程式碼中。
try/catch 可能模糊錯誤邊界。當 agent 遇到失敗時，加入 catch 區塊和備用方案是保持當前路徑運行的簡便方法，但同時也會遺失原始錯誤。將 Promise 的 .then() 和 .catch() 與 async/await 混用，可能會將控制流程分散到多種風格中。
React 的 useEffect 在狀態管理中製造了類似的問題。它常被用來複製狀態、同步兩個真相來源，或編碼難以從資料模型中看出的順序依賴。
核心 web 平台預設限制這些模式。有正當理由的例外可以保留，但必須在旁邊附上明確的說明。
核心 web 平台的生產程式碼目前不含任何 useEffect。我們使用 ccstate 和其他無副作用模式，以更明確的方式建模依賴和副作用。monorepo 的其他地方（主要是共享 UI 和桌面程式碼）仍存在少量生產環境的 useEffect 呼叫，因此這個說法的適用範圍很重要。
這些規則源於此儲存庫中反覆出現的失敗。當某個模式持續製造相同的維護問題時，我們就將它從審查指引提升為可執行的約束。
在模組邊界進行測試：測試獎盃，而非測試金字塔
vm0 不遵循傳統的測試金字塔。我們的測試指南描述的是測試獎盃：靜態分析作為基礎，整合測試作為主要層，以及少量針對關鍵使用者旅程的端對端測試。
單元測試相對少見。我們選擇性地將其用於安全敏感邏輯、演算法和狀態機。大多數業務行為透過模組的公開邊界進行測試。
API 測試透過合約呼叫真實應用程式。測試資料盡可能透過生產端點準備，斷言則透過公開行為進行。測試避免直接存取內部服務或修改資料庫資料表，因為這會將測試與當前實作耦合。
內部基礎設施在成本合理的情況下保持真實：
- PostgreSQL 和 pgvector
- 資料庫 migration
- 檔案系統
- 內部服務
- 在外部系統邊界使用 mock
這些整合測試比高度隔離的單元測試執行得更慢，也需要更完整的環境。但它們縮小了「測試通過」與「應用程式能以真實資料庫執行此操作」之間的差距。
邊界測試為大型內部重構留有空間。Agent 可以重組模組、拆分服務或更改資料存取層，而公開行為仍受到保護。
Uncle Bob 偏好不同的組合，大量使用單元測試、Gherkin 和突變測試。共同的原則是獨立驗證：生成程式碼的過程，不應該是唯一聲稱程式碼有效的來源。
給予 coding agent 完整的回饋迴路
我們早期的 coding agent 執行結果，常以一個熟悉的回報作結：程式碼已更改，TypeScript 已通過；請啟動應用程式並檢查頁面。
這讓開發迴路的後半段留給了工程師。仍然需要有人準備資料庫、執行服務、開啟瀏覽器、建立資料、觀察失敗，並將其描述回給 agent。
Agent 現在擁有足夠的開發環境，可以自行完成更多工作。它們可以啟動應用程式和資料庫、執行 migration、建立測試資料、造訪 pull request 預覽，並執行真實的瀏覽器互動。
瀏覽器驗證能捕捉一類型別檢查和 API 測試無法良好覆蓋的問題：損壞的導航、永遠無法穩定的載入狀態、只在完整流程中才出現的權限錯誤，以及視覺回歸。
在一次執行結束時，agent 會回報它執行的指令、測試的路徑，以及它觀察到的內容。對於使用者介面的變更，它可以附上截圖。工程師可以在決定是否親自開啟預覽之前，先檢查這些證據。
截圖不是測試，也無法證明不存在其他錯誤。它降低了重建 agent 上下文的成本。對於一個小型介面變更，可重現的步驟和最終截圖，遠比一條說變更「應該已修復」的訊息更有用。
Agent 工作品質在很大程度上取決於它無需等待人類就能獲得的回饋。
透過主幹開發保持分支簡短
快速的程式碼生成可能產生大量分支庫存。
長期存在的功能分支會累積合併衝突、重複工作和過時的上下文。隨著 pull request 增大，審查變得更加困難和緩慢。我們使用主幹開發（trunk-based development）來保持分支簡短，並持續整合到 main。
我們的主分支規則要求：
- 透過 pull request 進行變更
- 線性歷史和 squash merge
- 合併佇列
- Turbo、Rust 和安全性檢查
- 不得例行性地繞過必要的閘門
自動化遵循相同的路徑。Agent 可以建立 pull request，某些低風險的維護任務可以啟用自動合併，但變更仍然必須通過 CI 和合併佇列。
pull request 的大小和存活時間，有助於解釋為何一週內能合併630個。小型變更攜帶的上下文較少，更容易驗證，也較不可能與產品工作或其他自動化修復產生衝突。
Knip 作為儲存庫垃圾回收：移除死碼
程式碼生成自然會增加檔案和抽象層。刪除通常需要另外提示。
重構後，舊檔案可能仍留在儲存庫中。移除功能可能會留下匯出、依賴項和進入點。這些殘留物很少會破壞測試，但隨著時間推移，它們會讓程式庫越來越難以瀏覽。
我們使用 Knip 來尋找未使用的檔案、匯出、依賴項和進入點。TypeScript 可以確認程式碼是有效的；Knip 則詢問它是否仍然參與系統。
這些殘留物對 coding agent 還有額外的成本。儲存庫是它們最重要的上下文來源之一。一個過時的輔助函式或被放棄的實作，在下一個讀取它的 agent 眼中，可能看起來像是一個被認可的模式。保持上下文整潔，是上下文工程中不那麼光鮮的一半：agent 從儲存庫讀取的內容，與給予它的提示一樣，都是輸入。
移除死碼也改善了未來執行可用的輸入。Knip 處理這項工作的確定性部分，速度足夠快，可以成為定期的品質檢查。
定期的 AI 殘留清理工作流程
Knip 和 ESLint 有明確的限制。許多形式的退化需要專案上下文和語意判斷。
我們使用「AI slop」作為這類殘留的實用標籤：不必要的備用方案、重複的抽象層、繞過公開邊界的測試，或針對不可能狀態的防禦性分支。每個實例看起來可能無害，但累積起來，它們會讓儲存庫更難理解，並給未來的 agent 提供不良的範例。
幾個定期的 vm0 工作流程按排程掃描這些模式。
每日的 AI slop 清理會尋找新的殘留，並選取一小組高信心、低風險的修復。其他工作流程則檢查存取內部服務的 API 測試、React 和 ccstate 的反模式，以及可以安全處理的技術債。
每個工作流程都保持其變更範圍狹窄。它開啟一個 pull request，然後依賴正常的型別檢查、lint 規則、測試和合併佇列。設定為自動合併的 pull request 仍然必須通過相同的閘門。
按排程執行 agent 並非免費，我們另外撰文討論了如何控制這些成本。這些工作流程不會嘗試在一次執行中清除所有技術債。每日小批次比每隔幾個月進行一次大規模清理更容易驗證，也更不具破壞性。
當定期工作流程足夠頻繁地發現相同模式時，我們會考慮將檢查移入 ESLint、Knip 或型別系統。語意工作流程充當觀察和精煉規則的場所，然後再將其轉化為更廉價的確定性檢查。
將不穩定的測試失敗轉化為自動化修復
另一組工作流程從 GitHub Actions 的失敗開始。
當測試在主分支或合併佇列中失敗時，工作流程會讀取日誌、檢查不穩定性的證據，並查看重試、時序和環境因素。如果證據支持特定的修復，它會更新測試或實作、開啟 pull request，並再次執行完整的 CI 流程。
在重試時通過，並不能讓原始失敗變得無害。依賴重試按鈕的團隊，會逐漸失去對紅色建置的信任。一旦發生這種情況，失敗的檢查就會成為另一種背景雜訊。
自動化修復工作流程將間歇性失敗轉化為可追溯的程式碼變更。診斷、修補和驗證都保留在 pull request 中可見。工程師可以檢查較高風險的變更，而具有強力證據的狹窄修復則可以通過合併佇列繼續進行。
我們的品質系統目前有三個廣泛的層次：
| 階段 | 機制 | 典型關注點 |
|---|---|---|
| 撰寫時 | TypeScript、合約、Drizzle、ESLint | 型別錯誤、介面漂移、已知程式碼模式 |
| 合併前 | Knip、整合測試、真實資料庫、預覽、合併佇列 | 死碼、模組行為、完整執行時結果 |
| 合併後 | 排程和事件驅動的 vm0 工作流程 | AI slop、語意反模式、不穩定測試、架構漂移 |
這些層次相互回饋。工作流程發現的問題可以成為靜態規則。在 CI 或生產環境中發現的失敗可以成為測試和新的工程指引。
審查 AI 生成程式碼時，人類注意力的去向
vm0 的工程師仍然閱讀程式碼，尤其是架構變更、安全敏感工作、支付和資料 migration。我們沒有將「永遠不閱讀程式碼」設為團隊規則。
改變的是程式碼審查中注意力的分配。程式碼閱讀是合約、測試邊界、預覽行為、截圖、品質指標和工作流程診斷等眾多訊號之一。
幾個決策仍然需要有經驗的判斷：
- 需求是否完整
- 模組邊界應該設在哪裡
- 哪些失敗是可恢復的
- 一個錯誤可能造成多大的業務影響
- 安全模型是否合適
- 當前規則未能涵蓋哪些新的失敗模式
設計端也發生了類似的轉變，design-as-code 將視覺決策移入同一個儲存庫和同一個審查路徑。工程師也維護 agent 周圍的環境。當問題重複出現時，我們決定是否要新增型別約束、lint 規則、測試或定期工作流程。開發系統本身已成為一個重要的工程產物。
可讀的程式碼仍然重要。下一個讀者可能是工程師，也可能是另一個 agent。糾纏的程式碼消耗更多上下文，擴大未來變更的範圍，並使驗證變得不那麼可靠。
安全性與不加速的變更
速度並非均勻施加。vm0 保有一份短清單，列出按自己節奏進行的變更：安全敏感工作、支付、資料 migration 和架構決策。工程師會逐行閱讀這些內容，無論是誰或什麼撰寫了它們。
根據我們的經驗，AI 生成程式碼的安全風險，與其說是奇特的漏洞，不如說是沒有人擁有的合理程式碼。重要的控制措施是普通的，但要一致地應用：
- 單元測試（我們在其他情況下謹慎使用）被刻意用於安全敏感邏輯、演算法和狀態機。
- 測試僅在外部系統邊界使用 mock。內部基礎設施保持真實，因此破壞內部合約的變更會在 CI 中失敗，而不是在生產環境中。
- Agent 在 dev container 內針對每個 pull request 的資料庫分支工作，而不是在開發者的機器上，也不是在共享資料庫上。
- 合併佇列和必要的檢查沒有例行性的繞過，包括 agent 開啟並標記為自動合併的 pull request。
try/catch預設受到限制，因此失敗較不可能被 agent 為了保持路徑運行而添加的備用方案所吞噬。
憑證處理是一個獨立的設計問題，有其自己的答案：我們在另一篇文章中描述了讓 token 遠離 agent 之手的代理人模式。
這些措施本身並不能讓生成的程式碼變得安全。它們縮小了人類決策是唯一控制手段的變更集合，並使該集合變得明確。
這些數字未能呈現的內容
每週報告展示了儲存庫規模和交付速度，但它本身並不能展示生產可靠性。
評估對執行時品質的影響，需要可用性、生產錯誤率、事件數量、變更失敗率、回滾頻率和平均恢復時間。綠色的 CI 執行只描述了交付流程的一部分。
我們正在繼續整合這些結果指標。工程實踐解釋了系統如何管理風險；生產資料則顯示這種管理的效果如何。
常見問題
什麼是 vibe coding？ Vibe coding 是向 LLM 提示生成程式碼、執行其回傳的內容、要求修改，並且不閱讀生成的程式碼。Martin Fowler 的定義刻意保持狹義：開發者應該「忘記程式碼的存在」。它適合原型、一次性軟體，以及影響有限的工具。
什麼是 agentic coding？ Agentic coding 是一種較長時間運行的 AI 輔助開發形式，其中 agent 讀取儲存庫、編輯檔案、執行測試，並在較長時間內自行迭代。人類仍然掌握架構和行為的所有權，並審查一次執行所產生的證據，而非它撰寫的每一行程式碼。
Vibe coding 和 agentic coding 有什麼區別？ 差異在於注意力，而非作者身份。在 vibe coding 中，程式碼從不被檢查。在 agentic coding 中，agent 獨立工作，而工程師檢查其周圍的證據：測試結果、品質訊號、預覽和生產行為。vm0 通常被描述為 vibe coding；以 Fowler 的術語來說，它是 agentic coding。
什麼是 AI slop？ AI slop 是 AI 生成程式碼留下的殘留：不必要的備用方案、重複的抽象層、繞過公開邊界的測試、針對不可能狀態的防禦性分支。每個實例看起來無害，但累積起來，它們讓儲存庫更難理解，並給下一個 agent 提供不良的範例。
你們如何在每週630個 pull request 的情況下審查 AI 生成的程式碼？ 不是逐行審查。在 vm0，人工審查用於需要判斷的地方：架構、安全敏感工作、支付、資料 migration。其他一切由機制承擔：嚴格的型別和合約、在模組邊界進行的整合測試、每個 pull request 預覽中的真實資料庫、瀏覽器驗證、Knip，以及沒有任何變更能例行性繞過的合併佇列。
大規模 vibe coding 的最佳實踐是什麼？ 在 vm0 八個月的實踐中，有五項持續有效：統一開發環境，讓 agent 和人類執行相同的指令；將標準轉化為型別、linter 和 CI 中的可執行約束，而非文件；針對真實基礎設施在模組邊界進行測試；給予 agent 包含瀏覽器的完整回饋迴路；以及持續清理，而非偶爾進行大規模清理。
AI 生成程式碼的安全風險是什麼？
常見風險不是奇特的漏洞，而是沒有人擁有的合理程式碼。vm0 對安全敏感工作、支付和資料 migration 保持人工審查，刻意為這些邏輯使用單元測試，在測試中保持內部基礎設施真實，限制會吞噬失敗的 try/catch 等模式，並不允許例行性地繞過必要的檢查。
AI 生成程式碼會產生技術債嗎？ 它會產生一種特定類型的技術債：仍然能編譯並通過測試，但不再參與系統的程式碼，加上任何 linter 都無法命名的語意殘留。Knip 移除確定性的部分。定期工作流程以每日小批次處理其餘部分，而重複出現足夠多次的模式會成為 lint 規則或型別約束。
vm0 程式庫有多少是由 AI 撰寫的？ 大部分的實作。在2026年7月20日至26日當週合併的630個 pull request 中，六位工程師撰寫了556個，其餘由發布自動化系統撰寫，而 agent 撰寫了這些 pull request 中的大部分程式碼。工程師所擁有的是架構、約束和生產行為。
什麼是測試獎盃，為什麼不用測試金字塔？ 測試獎盃將靜態分析置於基礎，整合測試作為主要層，少量端對端測試置於頂部。vm0 使用它是因為透過模組公開邊界撰寫的測試，在 agent 重組底層實作時仍能持續保護行為，而大型單元測試層則做不到這一點。
如何在 AI 撰寫的儲存庫中找到死碼？ 程式碼生成會增加檔案和抽象層；刪除通常需要另外提示。vm0 定期執行 Knip，以尋找未使用的檔案、匯出、依賴項和進入點。TypeScript 確認程式碼是有效的；Knip 詢問它是否仍然參與系統，這才是死碼問題的關鍵所在。
Vibe coding 的程式碼可以安全地在生產環境中運行嗎？ 這取決於什麼在驗證它，而非誰輸入了它。我們要求的訊號沒有改變：型別和合約、透過公開邊界的測試、真實基礎設施，以及必須是綠色的 pipeline。本文中的數字描述了儲存庫規模和交付速度。可用性、錯誤率和變更失敗率才是回答生產問題的指標，我們仍在整合這些數據。
八個月後
八個月還太早，無法宣告一套最終方法。模型、agent 工具和儲存庫持續變化，我們的規則和工作流程也隨之改變。
有一個轉變已經很清晰。隨著程式碼生成速度加快，環境、約束、測試和回饋系統承擔了更多的品質責任。工程師花更少的時間輸入實作，花更多的時間定義行為、設計邊界和改善驗證。
vm0 程式庫將繼續成長。Knip 移除確定性的殘留。靜態規則阻擋我們已理解的失敗模式。整合測試保護模組行為。定期工作流程處理我們尚無法以機械方式表達的退化。
程式碼仍然重要。本文中的最佳實踐不是關於少寫程式碼，而是關於決定在一個變更屬於主分支之前，什麼必須為真。我們現在使用更多機器可執行的證據，來決定一個變更是否屬於主分支，以及其實作是否應該保留在儲存庫中。
