摘要： Nextdoor 工程副總裁 Cory Dolphin 說明團隊改用 Codex 做結果工程，工程師定義可驗收結果，代理負責實作與深入除錯。文章舉 Opportunity Alerts 地圖功能為例，過去需要三個團隊合作，現在一位工程師能端到端完成。速度提升後，組織瓶頸轉向選題與產品策略，但仍需要乾淨環境與人工驗證。
6 月 9 日，OpenAI 公布了 Nextdoor 工程團隊採用 Codex 的案例。這個平台的用戶超過 1.1 億、遍布 11 個國家，工程團隊扛著多大的壓力，不難想像。不過，工程副總裁 Cory Dolphin 談的重點並不在寫程式的速度快慢，而是工程師這個角色出現了根本變化：告別「迭代地提示 agent」，投入「結果工程」（outcome engineering）。
用 Dolphin 的說法，如今工程師花在「要做什麼」上的心思多了，花在「怎麼做」上的時間少了。這話乍聽像老調重彈，真正的差別卻很具體：大量實作細節可以整包交給 agent 扛，工程師於是能直接朝結果邁進——那個結果也許是一張截圖、一段影片、某項效能指標，或只是一個新功能的點子。
三個團隊才湊得齊的工程，現在一位工程師就夠
Nextdoor 最近上線的 Opportunity Alerts 功能，是幫用戶尋找住家附近的服務提供者。有位工程師想到，把這些提供者直接畫在地圖上，實用程度會再上一層。換作以前，這種需求得動員行動端、前端、後端三個團隊聯手，而它也很可能就此永遠留在 backlog 裡。
導入 Codex 之後情況不同了，Dolphin 說：「我們能讓一個工程師端到端地建置它。」意義不只是開發變快，更在於這位工程師對產品體驗的理解完整得多，也更有能力判斷什麼才是值得出貨的東西。
Dolphin 從這類例子看到一條更大的走向：工程師的位置正在上移，不必再把自己綁在某個系統或框架的專精裡，而是能把產品整個握在手裡。他的說法更直白：「你真的會看到個別工程師開始驅動產品。」
拿 Codex 追最難重現的 bug，順帶談 Fast Mode 的魅力
Codex 的舞台不只有功能開發，也包含那些最難重現的 bug。Nextdoor 手上既有嵌入式 Rust 資料庫，也有 race condition 限制嚴苛的系統；他們的做法是交給 agent 一個乾淨的環境，再配上一套調查框架，讓它自己去追 Kubernetes pod 為什麼遲遲起不來，或是把資料分析裡那條正確的趨勢線找出來。
GPT-5.4 和 5.5 這兩代升級讓 Dolphin 特別有感：「Codex 非常擅長保持極度堅持，嘗試找出正確的解決方案，深入一些看似冷門的技術細節，最終找到根本原因。」
說到 Codex 的 Fast Mode 配上 GPT-5.5，他的形容同樣直接：「我必須誠實說，團隊很多人對它上癮。當你有一個快速的回饋迴圈，那種感覺對工程師來說是令人興奮的。」
卡住組織的不再是工程，而是策略
真正值得留意的，其實是壓力在組織內部換了位置。Dolphin 看到，工程的推進速度快到「瓶頸不再存在於工程部門」，真正的問題已經變成：「我們要如何找出正確的事情來做、正確的策略——而不是我們要如何建置它。」
對產品經理和技術領導者來說，這是很關鍵的訊號。功能蓋得快之後，誰能選對「做什麼」，誰就握有真正的競爭優勢。這也表示工程師得靠產品策略更近一些，而產品團隊則要把「結果」交代得更清楚，而不是只給一份「規格」。
給想跟進的人：從結果著手
如果你也在評估讓 coding agent 進駐團隊，Nextdoor 走過的路可以直接借鏡：把起點從「任務」換成「結果」。先幫 agent 準備好乾淨的環境、把驗收標準寫清楚，再把工程師的心力放在判斷「這是不是對的產品」上。
當然，這不是在宣告 coding agent 能取代工程師——改變的是工程師的身分：從「寫程式的人」變成「定義結果並驗證結果的人」。新的技能要學，工作流程也得重排。但 Nextdoor 的例子已經證明這條路走得通，而且收穫不只是速度，還有整個團隊對產品的那份擁有感。