Capital One 的 Max Kanat-Alexander 在本次演講中，從開發者體驗（Developer Experience）的角度切入，探討在 AI 編碼代理快速演進的時代，軟體工程組織應該做出哪些「穩賺不賠」的投資。他指出，僅靠 AI 代理並不能解決所有問題，組織需要同時改善開發環境、驗證機制、程式碼結構、文件管理和 Code Review 流程，才能真正釋放 AI 代理與開發者的生產力潛能。

---

原影片連結：https://www.youtube.com/watch?v=rT2Del5pwg4

影片重點

• AI 編碼代理很強大，但不是軟體工程組織唯一需要投資的方向
• 開發環境應標準化，使用業界標準工具，避免對抗模型的 training set
• 代理需要 CLI 或 API 來執行操作，文字互動是最原生的介面
• 高品質的驗證（測試、linter）和清晰的錯誤訊息對代理至關重要
• 程式碼庫的結構直接影響代理的推理能力和效能
• 文件需記錄「為什麼」而非「是什麼」——代理無法讀取你的腦袋
• 寫程式碼已變成讀程式碼，每位工程師的主要工作正在變成 Code Reviewer
• Code Review 的速度和品質都需要提升，否則會陷入惡性循環
• 核心原則：對人類好的東西，對 AI 也好

詳細內容

[00:20] 開場：前所未見的變革速度

Max 提到自己從事開發者體驗工作已經很長時間，但過去 12 個月的變化速度是他前所未見的。每隔 2 到 3 週，軟體工程師就會因為新工具的出現而感到震驚。對於負責開發者體驗的人來說，這個問題更加嚴峻——總是有人問「我能不能用這個新東西？」

這種不確定性讓很多 CTO 和技術領導者在問自己：「我的投資會不會白費？」很多人的結論是「就全投 AI 編碼代理吧」，但 Max 認為這不是唯一的答案。

[02:10] 兩個關鍵問題

Max 提出了兩個核心問題來釐清思路：

第一，如何利用我們對開發者體驗原則的理解，找到無論未來如何變化都有價值的投資方向？第二，我們需要在 AI 代理之外做什麼，才能從代理中獲得最大價值？

他強調，這些不是小問題——它們可能決定一家軟體企業的成敗。

[02:42] 標準化開發環境

第一個「穩賺不賠」的投資是開發環境。你應該使用業界標準工具，並且以業界標準的方式使用它們——因為那就是模型 training set 裡的內容。

雖然你可以寫 instruction files 試圖讓模型做一些非標準的事情，但你本質上是在對抗 training set。如果你發明了自己的套件管理器，你可能應該放棄它，回到外界通用的做法。這也意味著你不能再使用冷門的程式語言了——至少不能用在日常的 agentic 軟體開發工作中。

Max 也回應了一個常見疑問：這是否意味著我們永遠不會有新工具了？他認為不會，因為總會有愛好者推動創新，但企業環境中使用未經驗證的新技術，無論有沒有 AI，一直都是個問題。

[04:23] 為代理提供 CLI 和 API

代理需要 CLI 或 API 來執行操作。雖然可以讓代理使用 computer use 或寫 Playwright 來操作瀏覽器，但為什麼要這麼做呢？如果你能提供一個 CLI，讓代理以最原生的文字互動方式執行，準確度會大幅提升。

在準確度至關重要的場景下，選擇代理最擅長的互動方式——文字介面——才是正確的做法。

[04:55] 投資驗證機制

任何形式的客觀、確定性驗證都能提升代理的能力。不管驗證從哪裡來，關鍵是要有高品質的驗證並產生清晰的錯誤訊息。這和你一直以來對測試和 linter 的要求其實是一樣的，但對代理來說更加重要——因為代理無法從「500 Internal Error」這種模糊的錯誤中推斷問題所在。

然而，如果你讓代理在一個完全不可測試的程式碼庫上寫測試，它會寫出那種「我按了按鈕，按鈕成功被按了，測試通過」的假測試。很多企業都有大量 legacy 程式碼庫，它們不是為測試而設計的，只有高層級的端到端測試，缺乏代理能夠迭代運行的優質單元測試。

[06:40] 改善程式碼庫結構

程式碼庫的結構是另一項值得長期投資的領域。代理在結構良好的程式碼庫上表現更好。在大型企業中，存在一些人類都無法理解的 legacy 程式碼庫——因為理解所需的資訊不在程式碼中，而且程式碼結構本身就讓推理變得不可能。

代理也會遇到同樣的困境。雖然它們可以像人類一樣通過反覆試錯來摸索，但這會大幅降低代理的能力。如果程式碼庫唯一能做的就是「按按鈕然後看它有沒有爆炸」，代理也無能為力，除非先進行重構。

[08:00] 文件：記錄「為什麼」

文件一直是開發者體驗領域爭論不休的話題。工程師討厭寫文件，文件的價值也常被質疑。但從 AI 代理的角度來看，問題很清楚：代理無法讀取你的腦袋，它也沒有參加你那場沒有會議記錄的口頭會議。

很多公司依賴部落知識（tribal knowledge）來理解系統需求和規格。如果程式碼是可理解的（前面提到的步驟都做好了），你不需要重新解釋程式碼本身——你甚至可以直接問代理「幫我描述這個程式碼庫的結構」。但代理永遠不會知道「為什麼」你這樣寫，除非那被記錄在某個它能存取的地方。

基本原則是：任何不在程式碼中或無法存在於程式碼中的資訊，都需要被寫下來放在代理能存取的地方。

[09:44] 寫程式碼已經變成讀程式碼

我們一直都花更多時間讀程式碼而非寫程式碼。但今天的差異是：寫程式碼本身已經變成了讀程式碼。即使在「寫」程式碼的時候，我們花在閱讀上的時間也遠多於實際輸入。

這意味著每位軟體工程師的主要工作正在變成 Code Reviewer。而在深度採用 agentic coding 的團隊中，PR 的數量遠超以往，導致 Code Review 本身成為瓶頸。

[10:41] 提升 Code Review 速度

需要提升 Code Review 的速度——不是縮短整體 Code Review 的時間（因為那是品質流程），而是讓每一次回應都更快。同樣的邏輯也適用於和代理的迭代：你要追求正確的結果，而不是在時間限制內交出不能用的垃圾。

在團隊層級，Max 指出一個常見的「社交疾病」：人們在 Slack 群組發訊息請求 PR Review，結果總是同一個人做了所有的 review。當 PR 數量劇增時，這個人根本扛不住。解決方案是：將 review 分配給特定個人，建立分配系統，並設定 SLO（Service Level Objectives）。

另一個問題是 GitHub 目前不擅長顯示「現在輪到誰行動」。很多人依靠 Slack 告訴對方「你可以再看一次我的 PR 了」，這是一個糟糕又低效的系統。

[13:14] 堅持 Code Review 品質

Code Review 的品質同樣重要——無論是開發者和代理的互動，還是正式的 Code Review 流程。必須堅持高標準。

軟體設計的目標不是完美，而是「夠好且比之前更好」。但對於長期存在的系統，「夠好」的標準遠比大多數人想像的要高。如果你沒有能力拒絕不該合併的東西，agentic coder 的生產力增益會逐年遞減，因為系統會變得越來越難以維護。

問題在於，很多公司裡最擅長 Code Review 的人把所有時間花在開會和策略討論上，根本不做 Code Review，也沒有在教導資淺工程師。Max 認為必須透過師徒制（apprenticeship）讓最優秀的 reviewer 帶領新人，因為在他 20 多年的經驗中，他從未找到比「一起做 Code Review」更好的教學方式。

[14:54] 惡性循環 vs. 良性循環

如果不做前面提到的這些投資，會發生什麼？糟糕的程式碼庫配上混亂的環境，代理產出垃圾，開發者感到挫折後放棄掙扎直接送 PR，品質低落的 Code Review 讓一切橡皮圖章式地通過——大量的 rubber stamp PR 不斷湧入，陷入惡性循環。Max 預測，處於這種循環中的團隊，代理生產力會在一年內持續下降。

反過來，如果你投資改善這些基礎設施，代理能幫助開發者更有生產力，而更高的生產力又反過來加速改進，形成良性循環。雖然這些聽起來是昂貴的基礎投資，但現在正是做這些投資的時機，因為這是你能在軟體工程速度上拉開最大差距的時刻。

[16:30] 總結：穩賺不賠的投資清單

Max 最後總結了一系列「穩賺不賠」的投資方向：

• 標準化開發環境
• 為需要的功能建立 CLI 或 API（且必須能在開發階段運行，不只是 CI）
• 改善驗證機制
• 重構以提升可測試性和程式碼可推理性
• 將外部脈絡和設計意圖（the why）寫下來
• 加速 Code Review 的每一次回應
• 提升 Code Review 的品質標準

如果 CI 需要 15-20 分鐘才能跑完，而代理又比人類更容易犯錯、需要反覆執行，那開發者的生產力就完了。把回饋循環縮短到 30 秒，體驗會完全不同。

[17:34] 核心原則：對人類好的，對 AI 也好

所有這些投資的背後有一個共同原則：對人類好的東西，對 AI 也好。 這意味著當我們投資改善開發者體驗時，無論如何都會幫到開發者。即使有時候我們沒能幫到代理，我們至少保證幫到了人類。

我的想法

Max 的演講精準地點出了很多團隊在擁抱 AI 編碼代理時容易忽視的盲點。許多組織急於導入 AI 工具，卻忽略了「地基」的重要性——如果你的程式碼庫是一團亂、沒有測試、缺乏文件，那麼再強大的 AI 代理也只能在泥巴上蓋房子。

特別值得注意的是他對 Code Review 的觀點。在 agentic coding 時代，PR 數量爆炸性增長，但 Code Review 的能力並沒有跟著線性增長。如果不主動建立分配機制和品質標準，這個瓶頸只會越來越嚴重。他提到的「rubber stamp PR 惡性循環」是一個非常真實的風險。

「對人類好的，對 AI 也好」這個原則非常有力。它提供了一個簡潔的決策框架：在不確定該投資什麼的時候，優先改善對人類開發者有幫助的基礎設施，這樣無論 AI 技術如何演進，你的投資都不會白費。這也呼應了軟體工程中一個永恆的道理——好的工程實踐從來都是值得的，只是在 AI 時代變得更加不可或缺。