Qodo：最後一次人類 Code Review | DevDay 2026 ☕ Buy me a coffee

🧑‍🏫 這支是 Qodo 執行長 Itamar Friedman 的訪談。他談的是 AI 寫程式越來越強之後，人要怎麼把團隊經驗整理給 AI 用，以及怎麼讓好幾個 AI 分工合作，最後讓人不必再逐行審程式。就算你不寫程式，也能從這支看懂 AI 協作接下來的方向：人不用一直下指令，主要負責訂規則、補經驗。

• 00:00 主持人 Danielle（developer experience 團隊）訪問 Qodo CEO Itamar Friedman。
  ↳ 主持人 Danielle 來自 developer experience 團隊，這個團隊負責讓開發者用工具時更順手。她訪問 Qodo 執行長 Itamar Friedman。
• 00:33 Qodo 從工程團隊的 tribal knowledge 蒐集 context，再提供給 coding agent。客戶形容 Qodo 是它的 best friend（字幕原文為「Kodak's best friend」）。
  ↳ coding agent 是會自己寫程式、改程式的 AI。tribal knowledge 是只存在老員工腦中的眉角。Qodo 把這些眉角整理好交給 AI，有客戶形容它是 AI 的最佳拍檔。
• 01:05 Qodo 也在寫程式的過程中做 review，目標是一開始就產出乾淨的 PR。
  ↳ PR（pull request）是工程師改完程式後提出的合併申請，要給別人審過才能併進去。Qodo 在寫程式的當下就挑錯，讓 PR 送出時已經是乾淨的。
• 01:05 Qodo 最終是一層 governance layer，呈現 software map 以及它隨時間的 drift，方便團隊控管。
  ↳ software map 是整套系統各部分怎麼連在一起的地圖。drift 指系統隨時間慢慢偏離原本的樣子。governance layer 是管理層，讓團隊看得到這些變化，也管得住。
• 01:05 Qodo 有三種 workload，每一種都相當獨特。
  ↳ workload 指的是一類工作。Qodo 處理三類工作，每一類的需求都很不一樣，沒辦法用同一招全部搞定。
• 01:39 Qodo 從 prompt engineering 演進到 flow engineering，再到 swarm engineering。swarm 聚焦在特定 use case 時效果很好。
  ↳ prompt engineering 是琢磨怎麼對 AI 下指令，flow engineering 是設計整套步驟，swarm engineering 是安排一群分工的 AI 一起做事。AI 團隊鎖定單一用途時最有效。
• 01:39 其中一個 use case 是建立 software map，作為產生程式碼與 review 的 context。Qodo 稱它為 wisdom base。
  ↳ 舉例來說，「建軟體地圖」這件事可以交給一組 AI 負責。這張地圖是 AI 寫程式、審程式時要參考的背景資料，Qodo 把它叫做 wisdom base（智慧庫）。
• 02:15 資料的層次依序是 raw data、information、knowledge、intelligence。從 intelligence 跳到 wisdom 的關鍵是經驗：intelligence 像大腦，experience 需要完整的系統（身體）。
  ↳ 資料一層層往上提煉：原始資料、資訊、知識、智力。再往上到智慧，靠的是經驗。光聰明只是有大腦，要累積經驗還得有身體親自走過。意思是光有模型不夠，要靠整套系統累積經歷。
• 02:46 想做端到端的 software factory、讓人類專注在 policy 和管理 swarm，就必須把 wisdom 與經驗 codify。某些情況下 wisdom 可能比程式碼本身更有價值。
  ↳ software factory 是自動產出軟體的產線，人只負責訂規則、管 AI 團隊。要做到這一步，得把經驗 codify，也就是寫成明確可用的紀錄。有時候這些經驗比程式碼本身還值錢。
• 03:20 有些改動在局部看起來很好，也沒有語意問題，卻可能造成下游問題。這類問題 coding agent 很難發現。
  ↳ 有些修改單看那一段完全正確，邏輯也沒問題，卻會連帶弄壞依賴它的其他地方，也就是下游。寫程式的 AI 只看得到眼前那一段，很難發現。
• 03:54 客戶案例：服務數百萬中小企業，這些企業幾乎能直接存取資料庫，許多改動都會碰到資料庫。局部沒問題的改動，可能在下游造成大規模 outage。
  ↳ 例子：某個客戶服務幾百萬家小企業，這些企業幾乎能直接碰到資料庫。一個看起來無害的小改動，可能讓一大片服務一起停擺，這種停擺就叫 outage。
• 04:29 這類問題人類 reviewer 也很難找。coding agent 是 just in time 執行，Qodo 則有在背景跑的 workflow（sleep time compute），持續計算 software map／software graph。
  ↳ 這種問題連人類審查者也很難抓到。coding agent 是要用時才臨時開始跑；Qodo 則一直在背景運算，這叫 sleep time compute，意思是閒著時也在算，持續更新軟體地圖。
• 05:29 2023 年有 prompt engineering 這種職業，當時用來做簡單的問答，也用在 coding 競賽。
  ↳ 2023 年「提示詞工程師」還是一種正式職位。那時候主要拿 AI 做簡單的問答，也有人用它參加程式競賽。
• 05:29 2024 年 Qodo 發表論文 AlphaCodium，主張別只想著來回問答與 prompting，要把整個 flow 當成工程來設計，這就是 flow engineering。
  ↳ 2024 年 Qodo 發表了 AlphaCodium 論文。論文主張別只靠一問一答反覆調整提示，而是把整段工作步驟當成工程來設計，這就是 flow engineering。
• 06:00 現在模型已能自己建 workflow。仍很有價值的是設計整個 swarm：有哪些 agent，各自的目標、工具、guardrails 和 policy。
  ↳ 現在模型自己就會排流程，所以人的價值轉到「編組」：要用哪些 AI、各自負責什麼、能用哪些工具、要守哪些護欄（guardrails）和規則（policy）。
• 07:41 早期階段的做法是 code review 工具在 PR 頁面列出 findings。他認為到 2027 年這會顯得很荒謬，因為心智負擔太大。
  ↳ 早期的 code review 工具（自動審程式的工具）會把一堆問題列在 PR 頁面上。他認為到 2027 年大家會覺得這做法很荒謬，因為一次要看那麼多，負擔太重。
• 07:41 code review 應該在開發者與 agent 寫程式的當下就給 feedback。
  ↳ 比較好的做法是在開發者和 AI 正在寫程式時就即時給意見，不要等寫完才一口氣丟出一整串。
• 08:11 coding agent 和 code review 要先彼此達成共識，意見不合時才交給開發者。
  ↳ 寫程式的 AI 和審程式的 AI 應該先自己討論出共識，只有意見談不攏時才請人類決定，這樣能少打擾人。
• 08:11 衡量指標：完成一個高品質 PR，開發者需要被 prompt 幾次。也就是變成 agent 在 prompt 人類。
  ↳ 新的衡量方式是：完成一個好的 PR，AI 需要回頭問人幾次，次數越少越好。這也代表角色反過來了，變成 AI 在向人提問。
• 08:41 Danielle 引述一位 OpenAI 的 API 開發者：「我不再 prompt Codex，是 Codex 在 prompt 我。」
  ↳ Danielle 引述一位開發者的話：「不是我在對 Codex 下指令，是 Codex 在問我。」Codex 是 OpenAI 的寫程式 AI。
• 09:11 有理論認為：兩個理性的 agent（人或 AI）擁有相同資訊，就應得出相同結論。結論不同，是因為各自的 context 不同。
  ↳ 背後的理論是：兩個講理的人或 AI 拿到一樣的資訊，結論應該相同。會意見不同，通常是因為各自掌握的背景資料不一樣。
• 09:44 coding agent、adversarial agent、人類以及最後的 reviewer 各有不同 context。讓一切都 grounded，最終就「應該」能達成共識。可參考 reviewer-critic generative networks 的相關論文。
  ↳ 寫程式的 AI、專門唱反調挑錯的 AI（adversarial agent）、人類和最後的審查者，看到的背景都不同。讓大家都依據同一套事實（grounded），理論上就能取得共識。
• 10:14 agent 都同意卻都錯了的情況一定會發生。目標是同樣的錯不犯第二次。
  ↳ 一定會遇到大家都同意、結果卻一起錯的情況。目標不是永遠不犯錯，而是同樣的錯不要犯第二次。
• 10:46 上線後若發生 incident 或 bug，要聰明地記錄進 knowledge base（wisdom base）。這在 AI 之前很難做到，AI 之後才有這個潛力。
  ↳ 上線後出了事故（incident）或 bug，要把原因和教訓有條理地記進知識庫。以前靠人工很難做到，有了 AI 才有機會做好。
• 11:16 tribal knowledge 常累積在個人身上，人一離職就帶走了。最有前景的是 continuous learning：犯過的錯從此被 codify 進 wisdom base（developer memory），直到不再相關時再 prune。
  ↳ 經驗常常只存在某個人腦中，他一離職就跟著帶走。continuous learning（持續學習）是把犯過的錯記進 wisdom base，像團隊共用的記憶；過時的內容再刪掉，這叫 prune。
• 12:20 客戶案例：一家大型金融機構，有數百個 repository 和多個 microservices，絕對不能出錯，但懂哪些做法可行的資深開發者有些已經離職。
  ↳ 例子：一家大型金融機構有幾百個 repository（程式碼倉庫）和很多 microservices（拆開各自運作的小服務）。它絕對不能出錯，但懂眉角的資深工程師有些已經離職了。
• 12:52 wisdom base 的做法之一：回溯掃描多年來開發者在 GitHub、GitLab、Bitbucket、Slack、Teams 等處的討論，把 tribal knowledge codify 回來。
  ↳ 其中一種做法是回頭翻多年來工程師在 GitHub、GitLab、Bitbucket（放程式碼的平台）和 Slack、Teams（聊天工具）上的討論，把散落的經驗撈回來整理成紀錄。
• 13:22 目的是理解改動一個 service 對另一個 service 的影響。這種關聯可能經過 streaming，不會直接寫在程式碼裡。Qodo 會分析這些資料並 codify 進 software map。
  ↳ 目的是搞清楚改了 A 服務會不會影響到 B 服務。這種關聯可能透過 streaming（資料即時串流）發生，程式碼裡看不出來。Qodo 會分析這些資料，畫進軟體地圖。
• 13:54 現在的模型是史上最笨的，之後只會更好。這幾個月一直聽到 agent 能 long run，雖然有時成功、有時不成功。
  ↳ 現在的模型是史上最差的版本，之後只會越來越強。最近常聽說 AI 能長時間自己跑任務（long run），不過目前有時成功、有時失敗。
• 14:26 agent 能完成完整任務後，需要重新定義什麼是 task。目前軟體開發把 PR 當作處理單位，但真正在乎的是端到端完成一個新能力或新功能。
  ↳ 當 AI 能做完一整件事，就得重新定義什麼叫「一件工作」。現在是以 PR 為單位，但大家真正在意的，是一個新功能從頭到尾做好。
• 14:56 一個 task 可能橫跨同一個或其他 repo 的 5 或 15 個 PR，不適合在單一 PR 頁面討論。
  ↳ 一個功能可能拆成 5 到 15 個 PR，分散在同一個或不同的倉庫裡。只看單一 PR 頁面，根本看不出全貌。
• 14:56 Qodo 預告未來幾天將推出 work package triage：幫你理解多個 PR 之間如何關聯以完成一個 task，並能整體 review。
  ↳ Qodo 預告幾天內會推出 work package triage。它會把相關的多個 PR 串在一起，讓你看懂它們怎麼合力完成一件任務，並且一次整體審查。
• 15:58 Itamar 對 decision API（字幕原文）感到興奮。他在 Qodo 之前待過做 embedding model 的公司。
  ↳ Itamar 說他對「decision API」很期待，這是字幕原文，影片沒有多做說明。他在 Qodo 之前待過做 embedding model 的公司，這種模型會把文字轉成數字，方便比對意思。
• 16:28 給開發者的建議：思考你的 task，拆成多個 workload，再為每個 workload 設計需要的 swarm（可能 2、3、5 個不同 agent），並思考它們如何協作。
  ↳ 給開發者的建議：先想清楚任務，把它拆成幾類工作，再替每類工作設計一組 AI（可能 2、3 或 5 個），並規劃它們怎麼分工合作。
• 17:00 依特定 workload 設計 swarm 會是 Qodo 未來一段時間的方向。這類系統會被大量使用，所以必須 cost-efficient。
  ↳ Qodo 接下來會專注在依特定工作設計 AI 團隊。這類系統會被大量使用，所以成本一定要壓低，不然用不起。
• 18:01 結語：祝大家幹掉最後一次人類 code review，但仍然需要對開發者做訓練。
  ↳ 結語：祝大家早日不再需要人類 code review。不過開發者還是需要訓練，人的判斷力仍然要培養。

Qodo 在 2024 年發表的論文 AlphaCodium 主要主張什麼？