GitHub Copilot 反彈：開發者氣的是失去控制，不是集體出走

Copilot 為何成為引爆點？

這波反彈不是單純反對 AI 補完，也不是否認 AI 工具可能提高效率。真正敏感的是 Copilot 被允許出現與行動的位置。

《The Register》報導，在過去 12 個月，GitHub Community 最受關注的討論，是要求提供方法，阻止 Copilot 在儲存庫中產生 issue 與 pull request 。同篇報導也指出，以 upvote 衡量，第二受關注的討論是一則 bug report，要求修正使用者無法停用 Copilot code review 的問題 。

這個差別很重要。AI 在個人編輯器裡建議一段程式碼，和 AI 出現在 issue queue、PR 流程與 review 介面，是兩種完全不同的權力關係。後者等於進入了專案的公共空間。對維護者而言，核心問題不只是 Copilot 產出的品質，而是專案擁有者能不能為自己的社群設定規則 。

品質抱怨讓「不請自來」的自動化更難被接受

部分不滿也來自使用者對可靠性的質疑。GitHub Community 有討論串指稱，VS Code 裡的 Copilot 不可靠，甚至對專案造成損害 。這類討論不能當成 Copilot 在所有使用者、所有工作流中的客觀品質基準；但它能說明，為什麼一些開發者不再把不想要的 Copilot 行為視為無傷大雅的自動化 。

當一個工具既難以迴避，又被部分使用者認為不穩定時，爭論就會從「能不能提升生產力」轉向「使用者是否同意」。

AI agent 的可靠性，已經變成營運問題

GitHub 自己的狀態頁也顯示，agentic workflow 會把風險放大。GitHub Status 記錄，2026 年 4 月 22 日 18:49 至 19:32（UTC，協調世界時），Agent HQ Codex agent 的 Copilot Cloud Agent session 無法從 issue assignment 與 @copilot 留言提及等入口啟動 。GitHub 表示，受影響的是 Copilot Cloud Agent 總工作量的 0.5%，約 2,000 個失敗工作；Copilot 以及其他 agent session 未受影響 。

這不是整個 GitHub 平台崩潰。但它說明了一件事：一旦團隊把實際工作交給 AI agent，AI 的可用性就會進入交付規劃。若開發者會把 issue 指派給 agent，或透過 PR 留言觸發工作，Copilot 的穩定度就不再只是「工具體驗」，而是專案流程的相依條件 。GitHub 的 news 頁面也承認近期曾發生可用性事件，並表示停機會影響客戶 。

Microsoft 的 AI 路線，改變了信任公式

《Business Insider》報導，Microsoft 正在重整團隊以強化 GitHub，並讓 GitHub 朝 AI coding 與 agent 方向改造；GitHub 也面對 Cursor、Claude Code 等 AI coding 競爭者 。從產品策略來看，這個方向並不難理解：repository、PR、issue、review 本來就是程式開發流程中最自然的 AI 助手入口。

但在文化上，這件事更敏感。許多開發者把 GitHub 視為共享的軟體基礎設施，而不只是 Microsoft 的一款產品。當 Copilot 功能讓人感到難以避開，維護者可能就不會把它看成「可選的生產力工具」，而會理解成 Microsoft 正利用 GitHub 的核心位置，推動自己的 AI 策略 。

AI Credits 讓邊界問題也變成預算問題

GitHub 表示 Copilot 將轉向依使用量計費，且自 6 月 1 日起，Copilot 使用量會消耗 GitHub AI Credits 。這不代表每個團隊都一定會付更多錢；但它確實意味著組織需要弄清楚 Copilot 能在哪些地方執行、誰能觸發、以及 AI 使用量如何對應到預算 。

對於已經不滿 Copilot 進入共享儲存庫空間的團隊來說，計量式 AI 使用可能讓 GitHub 的方向更不像「可選助手」，而像是被縫進開發流程裡的一層可計費自動化 。

不是每個反平台故事，都是 GitHub 出走證據

更廣泛的「開發者想降低平台依賴」敘事，常被一起放進 GitHub 反彈裡，但兩者不一定相同。David Heinemeier Hansson 的 HEY 個人頁介紹他是 37signals 共同所有人與 CTO，也是 Ruby on Rails 的創造者 。他近期的文章談的是 37signals 的 cloud exit：包括 20 台 Dell R7625 伺服器到貨，以及想擺脫雲端複雜度的計畫 。

這些文章談的是雲端基礎設施，不是有文件支持的 GitHub 離開案例。這個區別很重要：對大型集中式軟體平台的懷疑可能正在升高，但這不等於開發者正在大規模離開 GitHub 。

工程團隊現在該做什麼？

實務上的回應不該是恐慌，而是把 GitHub 與 Copilot 的假設明文化。

• 盤點 Copilot 的入口。 檢查 Copilot 可能出現或行動的位置，包括 issue、PR、code review、留言、issue assignment，以及 @copilot 工作流 。
• 制定儲存庫層級政策。 決定哪些 Copilot 功能可用、哪些受限、哪些禁止；開源專案與合規敏感的儲存庫尤其需要清楚規則 。
• 在 6 月 1 日前檢查 AI Credits。 Copilot 使用量將消耗 GitHub AI Credits，工程、平台與財務團隊都應理解使用量如何計算 。
• 把 AI agent 事件納入營運規劃。 如果交付流程依賴 issue assignment、PR 留言或 agent session，就應把 Copilot 可用性視為一項營運相依 。
• 保留簡單的人工作業備援。 關鍵儲存庫仍應有明確的人類負責人、文件化的發布流程，以及自動化失效時的復原路徑。

結論：GitHub 仍重要，但開發者會要求更多控制權

「開發者正在大規模拋棄 GitHub」這個說法，目前沒有足夠證據支持。更強而有力的結論是：GitHub 正面臨信任問題。Copilot 正進入共享開發流程，Microsoft 據報正在圍繞 AI coding 與 agent 重整 GitHub；當 agent 開始承接真實工作，可靠性事件的後果更大；而依使用量計費的 AI Credits 也即將成為開發流程的一部分 。

GitHub 仍然重要。真正的開放問題是：當它變成一個更積極的 AI 平台時，開發者會要求多少控制權才願意繼續信任它。