GitHub 共同創辦人：AI 時代最強開發者，是會寫字的人

本文整理自《AI + a16z》2026 年 4 月播出的單集。

{{< youtube vJiCnQeYLho >}}

---

程式碼不再是瓶頸，共識才是

GitHub 共同創辦人暨 GitButler 執行長 Scott Chacon 在 a16z 的 Podcast 上丟出一個讓很多工程師不太舒服的判斷：AI 時代最能產出好產品的軟體開發者，不是技術最強的人，而是最會溝通、最會寫作、最能把想法說清楚的人。這不是一個雞湯式的鼓勵，而是他帶領團隊深度使用 AI coding agent 之後得出的實戰觀察。

他的推論邏輯是這樣的：當 agent 能夠處理越來越多的實作細節，開發流程的瓶頸就會往上游移動。過去我們花最多時間在「怎麼寫」，現在這個環節被壓縮了，但「寫什麼」「為什麼要寫」這些問題並沒有被 AI 解決，反而因為執行速度變快而更加突顯。如果一個團隊花三天就能把想法變成可運行的程式碼，那麼決定「我們到底想要什麼」這件事就變成了真正的限速步驟。

Chacon 觀察到，很多自認為或確實很聰明的開發者，習慣把東西留在腦子裡。他們覺得不需要向別人解釋自己在做什麼，程式碼會替他們說話。這在過去或許行得通，因為寫程式碼本身就是思考的過程，但在 AI 時代，如果你的想法只存在於你的大腦裡，agent 就無法幫你執行。你必須把它寫下來，而且要寫得夠清楚，清楚到機器和隊友都能理解。

---

規格文件成為新的核心產出

Chacon 用自己在 GitButler 的工作方式舉例。他目前花最多時間的不是寫程式碼，而是寫規格文件（spec）。他描述了一個循環：花大量時間在規格上，碰到需要決策的地方就讓 agent 快速實作一個概念驗證，看看結果，然後回頭修改規格，再讓 agent 重新實作。這個循環讓他不需要花所有時間在實作上，也不需要寫一份完美的規格去說服別人同意。他可以隨時 show-and-tell，讓成品說話。

這個工作模式的關鍵在於：規格文件的品質直接決定了產出的品質。如果你寫得模糊，agent 就會用它自己的理解去填補空白，結果往往不是你要的。如果你寫得精確，agent 的產出就會接近你的預期。寫作能力在這裡不是一個加分項目，而是核心生產力工具。

Chacon 也指出，目前阻礙 coding agent 真正發揮潛力的，不是模型能力不夠強，而是大多數團隊的 ticket 和 task 描述品質太差。打開任何一個專案管理工具，裡面的票大多是一兩句話的草率描述，缺乏脈絡、缺乏設計意圖、缺乏對邊界情況的考量。把 agent 接上 Linear 然後說「全部解掉」的想法之所以不切實際，不是因為 agent 不夠聰明，而是因為那些 ticket 根本不構成一個清晰的指令。寫好一個 ticket 本質上就是一次寫作行為，它需要你想清楚問題是什麼、預期結果是什麼、有哪些限制條件。

---

Agent 擅長的事和不擅長的事

在 Chacon 的觀察中，agent 非常擅長一件人類長期做不好的事：團隊間的即時協調溝通。軟體開發裡一個永恆的痛點是，你在改一個檔案的同時，另一個人也在改同一個檔案，但你們雙方都不知道，直到合併的時候才爆炸。對人類來說，即時通報自己在做什麼是巨大的認知開銷，但對 agent 來說這完全不是問題。它可以在「閒置時間」和其他 agent 交換資訊，告訴你的 agent：「隊友的 agent 正在修改認證模組，你等等碰到相關程式碼要注意。」

Chacon 認為，與其追求同時跑 20 個 agent 來最大化產出，不如讓 agent 扮演一個更細膩的角色：幫你了解團隊裡正在發生什麼、什麼東西可能影響你的工作、下一步該考慮什麼。這比單純的程式碼產出可能更有價值，但需要人類先把自己的意圖和脈絡表達清楚。

相對地，agent 不擅長的是定義產品願景。它能幫你把想法變成程式碼，但不能替你決定應該建造什麼。「為什麼」（why）比「怎麼做」（how）更重要，而「為什麼」需要人類之間達成共識。這就回到了溝通和寫作的核心：你能不能把你腦中的產品樣貌寫成一份讓所有人（包括 agent）都能理解的文件？

---

我的觀察

Chacon 的判斷聽起來像是在說「軟體工程師要變成產品經理」，但我覺得更精確的說法是：AI 時代的軟體開發者需要同時具備工程師的技術判斷力和作家的表達能力。過去這兩種能力被認為是不同的專業，你可以選擇當一個埋頭寫 code 的人，溝通的事交給 PM。但當 agent 接管了大部分的「埋頭寫 code」工作，你剩下的核心價值就是判斷力和表達力。有意思的是，Chacon 本人就是這種雙重能力的具體案例：他是工程師出身，但讓他在業界留下最深印記的作品是一本書。