JetBrains 調查：GitHub 超過半數程式碼已由 AI 生成，Claude Code 滿意度奪冠

有記錄以來，這是軟體開發史上第一次：GitHub 儲存庫中超過半數的程式碼由機器撰寫。JetBrains 2026 年 4 月發布的 AI Pulse 調查——以 2026 年 1 月蒐集的 183 個國家、10,272 名專業開發者的回應為基礎——顯示 AI 生成或大量 AI 輔助的提交（commit）佔比達 51.3%，較十八個月前同期調查的 24% 翻倍以上。

調查對「AI 生成」的定義較為寬泛：只要 AI 工具產出了初稿，即便開發者事後修改，也計入此類。「大量 AI 輔助」則涵蓋 AI 自動補全、行內建議或對話式重構貢獻超過 50% 鍵擊量的程式碼。兩項合計的 51.3% 代表真正的轉折點——世界上多數專業軟體產出，在進入版本控制前都已通過 AI 系統的處理。

支撐這個數字的市場

AI 編碼工具市場的年度合約金額已達 128 億美元，從 2024 年的 51 億美元與 2022 年 GitHub Copilot 正式開放時的約 12 億美元大幅躍升。JetBrains 預測，受企業席位擴張與超越單一檔案自動補全的代理式（agentic）編碼工作流成熟度驅動，市場規模將於 2028 年達到 280 億美元。

然而，這場成長並非平均分配。調查揭示市場正處於重大洗牌期：傳統領導者面臨成長飽和，新進玩家則在滿意度與品牌認知上取得不成比例的領先。

GitHub Copilot：廣泛採用，但增長趨平

GitHub Copilot 仍是知名度最高的 AI 編碼工具：在專業開發者中擁有 76% 的認知度，以及 29% 的職場採用率——也就是說，近三分之一的專業開發者目前在工作中使用雇主付費的 Copilot。這對任何軟體工具類別而言都是非凡的數字。

但 Copilot 的成長曲線已趨於平緩。認知度年增僅 3 個百分點（從 73%），職場採用率年增僅 4 個百分點（從 25%），NPS（淨推薦分數）從 38 下滑至 31。最常被提及的摩擦點是情境視窗（context window）限制：處理大型程式碼庫的開發者反映，Copilot 難以維持跨檔案與模組的一致語意理解，導致建議在局部語法正確，但在更廣泛的專案脈絡中語意有誤。

微軟已回應，將 Copilot 更深度整合進 VS Code 擴充套件生態系，並推出試圖處理多檔案推理的代理式功能 Copilot Workspace，但開發者的反應顯示這些更新尚未實質改善核心滿意度。

Claude Code 的快速崛起

調查中最引人注目的數據點是 Claude Code 的成長軌跡。Anthropic 的 CLI 式 AI 編碼代理人，從 2025 年中的 31% 認知度，在 2026 年 1 月飆升至 57%——六個月內上升了 26 個百分點。職場採用率達 18%，使 Claude Code 成為繼 Copilot 和 Cursor 之後，第三大被廣泛採用的 AI 編碼工具。

更關鍵的是，Claude Code 在滿意度指標上全面領先：CSAT（客戶滿意度分數）91%、NPS 54——比 Copilot 的 31 高出逾 20 分，比 Cursor 的 39 高出 15 分。這一差距在前端、後端、全端及 DevOps 等各類角色，以及從 50 人以下到千人以上各種規模的公司中均保持一致。

開發者對 Claude Code 高滿意度的原因集中在幾個面向：一是更長的情境視窗與跨多檔案任務的強勁表現——恰好是 Copilot 使用者最常反映摩擦的領域；二是 CLI 架構讓工具能融入現有的終端機工作流，不需要 IDE 專屬插件；三是工具處理多步驟代理任務的能力——執行測試、讀取錯誤輸出、提出修復方案並迭代——深受已超越簡單自動補全需求的開發者青睞。

調查資料顯示，Claude Code 的用戶群偏向資深工程師與 Staff 級別開發者，這些人通常處理規模更大、更複雜的程式碼庫，在這類環境中，簡單自動補全工具的局限性最為明顯。

Cursor 的利基主導地位

Cursor 的定位獨特：48% 認知度、22% 職場採用率（在純採用率數字上略高於 Claude Code）、NPS 為 39。Cursor 的優勢集中在個人貢獻者與小型新創團隊，其基於 VS Code 的使用體驗與積極的免費方案帶動了強勁的自然增長。

調查資料顯示，Cursor 與 Claude Code 服務的使用情境有所差異：Cursor 用戶更傾向於開發消費性產品與網頁應用；Claude Code 用戶則偏向基礎設施、後端系統與大型企業程式碼庫。這種市場分眾或許可以解釋，為何兩款工具能同時強勁成長，卻不直接彼此蠶食。

代理式工作流的轉型

除了工具個別分析，調查也揭示了開發者使用 AI 編碼輔助的結構性轉變。2024 年的主流模式是自動補全——開發者輸入時，AI 逐行提供建議，由開發者接受或拒絕。到了 2026 年，有不斷增長的開發者比例（34% 的受訪者）表示定期以代理模式使用 AI：給定任務描述，讓 AI 跨多個檔案與步驟執行，最後再審核結果。

代理模式大幅放大了 AI 工具對產出量的槓桿效果，但也引發新的品質隱憂。使用代理工作流的受訪者自述整體生產力提升幅度更高（例行任務中位數自估 3.8 倍），但也有更高比例的人（62%）反映，過去一個月內曾遭遇至少一次需花費超過 30 分鐘排查的代理模式引入的隱性錯誤。

這是 51% 數字背後的核心張力：AI 生成的程式碼已是多數提交的來源，但程式碼審查實務、測試文化與品質保證流程，尚未完全適應一個主要作者是非人類的世界。參與調查定性訪談的資深開發者一再強調這一點。

「問題不在於 AI 寫出爛程式碼。它寫的是看起來合理的程式碼，」一位在金融科技公司任職的 Staff 工程師說。「能編譯、能通過單元測試，卻在生產負載的邊界情況下出問題的程式碼，比明顯錯誤的程式碼難多了。」

對軟體團隊的意義

這份調查對工程團隊的影響相當深遠。招募模式已在改變：JetBrains 發現，大量使用 AI 工具的公司，相較於低採用率的公司，招募初階工程師與資深工程師的比例減少了 23%。假說是：AI 承擔了過去大量原本由初階開發者執行的工作，壓縮了傳統的招募金字塔。

程式碼審查的工作量也在轉型。隨著超過半數提交為 AI 生成，審查者愈來愈專注於架構與語意的正確性，而非語法風格——這一轉變對更有經驗的審查者需求更高，但或許不需要那麼多人。幾家規模較大的受訪公司已開始試行專門標記 AI 生成特徵的 AI 輔助程式碼審查工具。

51% 的門檻很可能只是一個中繼站而非上限。JetBrains 自身的模型推算，隨著代理工作流成熟、更多開發者從「AI 輔助」轉向「AI 主導」開發，這個比例將在 2027 年底前達到 70 至 75%。屆時，如何架構軟體團隊、評估工程師績效、定義「程式設計能力」，都將需要比任何單一工具更新更根本的重新思考。

就目前而言，多數 AI 生成的程式碼庫已是工程領導者必須即時面對的現實——儘管手邊的工具、流程與心智模型，都是為另一個時代而建構的。