Copilot 創始工程師：大多數 AI 編碼“就像開著法拉利去買牛奶一樣”

作者 | Darryl K. Taft

譯者 | 明知山

策劃 | Tina

GitHub Copilot 創始工程師 Neel Sundaresan 正在構建 IBM Bob——一款智能編碼工具，目前已有 8 萬名 IBM 開發者在使用。

Neel Sundaresan 回避了三個問題，其中一個是 “IBM Bob 為什么取名叫 Bob”。

這種回避本身就耐人尋味。Sundaresan 現任 IBM 軟件部自動化與 AI 總經理，也是微軟 GitHub Copilot 創始工程師，早年還曾擔任 IBM 研究員，并不是一個擅長做產品營銷的人。他是研究員出身，后來成為產品構建者，再后來成為高管，貫穿這三個角色的始終都是同一個執念：究竟是什么在阻礙軟件開發者提高效率，又該如何消除這些障礙？

他從 2000 年就開始研究這個問題，遠早于 Transformer 架構和大語言模型的問世，也遠早于 AI 與開發者工具被主流技術圈關聯在一起。從那時候起，到已在 IBM 內部為 8 萬用戶提供服務的 IBM Bob 正式發布，這條探索之路遠比發布會新聞稿所呈現的要漫長得多。

在無人關注的時候開始

Sundaresan 為提升開發者效率所搭建的第一個系統和如今我們熟知的 AI 編碼工具截然不同。那是一個 API 調用推薦系統。

“開發者有 30% 的代碼都是 API 調用，”他在接受《The New Stack》深度訪談時表示。“當你在一個類名后面按下點號，就會彈出一長串可供調用的函數，你得從中挑選一個。這本身就是一個效率損耗點。”

目標并不是生成代碼，而是在恰當的時機給出正確的函數調用，本質上是開發者代碼自動補全場景的搜索排序問題。

當時的模型不是 Transformer，甚至從現在的定義來看，也不是深度學習模型。但他表示，開發者們很喜歡這個工具。這個早期的啟示——在開發流程里某個細微的環節降低使用阻力就能收獲超乎預期的用戶滿意度——直到如今，仍在影響著 Sundaresan 對這類問題的思考邏輯。

“編碼是一項分析性工作，和網購不一樣，”他說。“如果系統給出了錯誤的推薦，或是給出會干擾我思路的推薦，那就有問題了。”

他認為，用戶體驗和底層 AI 的實現邏輯是兩個相互獨立、互不干擾的問題。即便模型性能再好，如果表層產品體驗設計出現偏差，整體產品體驗也會大打折扣。

他見證了模型領域的演進：長短期記憶網絡（LSTM）、早期的編碼器解碼器架構、谷歌的 Transformer 論文，以及初代 GPT。在每一個發展階段，他的團隊早已明確了所要解決的問題，只是當時的模型還不夠強大。“如果你回看我們發表的論文，這些相關領域我們都有涉獵，” Sundaresan 說道，“每篇論文都會提到哪種模型適合解決這類問題、哪種模型適合解決那類問題。”

當前沿模型終于具備了足夠的能力，足以支撐更大投入并獲得回報時，Copilot 應運而生，他說道。但到那時，Sundaresan 也已經花了多年時間觀察模型會在哪些場景出現問題——以及圍繞模型的產品設計會在哪些環節出現疏漏。陳舊的訓練數據會導致模型生成看似篤定卻虛假的信息。無論任務是否需要，都傾向調用性能最強、成本也最高的模型。在企業受限的運行環境中部署高性能模型也存在不小難度。

“就連我們的客戶也不放心把數據發送到我們的云端，”他談及在微軟的早年經歷時說道，“他們希望數據留在客戶端。所以我們讓模型直接在個人筆記本上運行，還為此投入了大量工程優化工作，確保它能在筆記本有限的資源條件下順暢運行。”

為什么是在 IBM？

當 Sundaresan 講述這段歷史時，一個顯而易見的問題是：他為什么把多年積累的知識帶到了 IBM，而不是某個更光鮮的地方。他直言不諱：在微軟待了十年后，他想換個環境，而 IBM 給出了一個很有說服力的理由。

但還有一個不那么顯而易見的答案：對于他所研究的問題，IBM 的所謂“劣勢”實際上是“優勢”。

“僅軟件部門，我們就有近兩萬名員工。我們有完善的基礎設施與咨詢業務，IBM 內部本身就有大量用戶，”他說道。“如果我能打造出讓他們受益的產品，這本身就是一個體量巨大的產品。”這種內部部署模式——IBM 稱之為“零號客戶”——給了他任何外部產品發布都無法提供的東西：一個規模龐大、多元且愿意容忍早期產品缺陷、換取實際效率提升的固定用戶群體。

另一個優勢在于工作負載的多樣性。IBM 內部的開發者不僅編寫 Python 和 Rust 代碼，還會使用 PL/I、COBOL、大型機 JCL，還有被 Sundaresan 形容為“如同行業俚語一般的自定義語言”。只要 Bob 能夠適配這么廣的技術范圍，就能應對各類企業客戶的任意開發場景。

“在敲開客戶大門之前，我們就有故事可講了，”他說道。

他也直言不諱地說明了自己的研發定位：不是面向開發者的通用工具，而是一個專門針對企業場景的系統，而大多數 AI 編碼工具把這些場景條件當作邊緣情況：遺留代碼庫、嚴格的合規要求、混合環境，以及 AI 生成的看似可以投產但實際上卻不行的代碼所帶來的真實成本。

沒人談及的成本問題

與 Sundaresan 的對話中，有一段十分坦誠的表述，他道出了大多數開發者在不受約束的情況下如何使用 AI 編碼工具。

“人們會選擇最新的 Claude Opus 4.7 這類頂級模型。他們可能只是執行一條簡單的提示詞，但成本卻高達每百萬詞元 40 美元，”他說。“這就好比開著法拉利去便利店買牛奶，完全沒有必要。”

Bob 不會向用戶暴露底層模型，它會根據實際任務需求自動調度路由，可選模型包括 Anthropic Claude、Mistral 開源模型、IBM Granite，以及多款專為 Bob 運行環境定制微調的專有模型。

這種智能路由能力正是 Sundaresan 認為的真正能體現架構設計價值的核心。“這并非簡單地將各類模型接入系統，”他表示，“而是要把模型能力、產品體驗，以及能夠支撐優質體驗的架構有機結合起來。模型只是整體方案的一部分。”

他介紹了在 IBM 內部用戶群體中開展 A/B 實驗的做法：測試各類前沿模型變體、監測用戶使用模式，識別出高成本模型被濫用于普通模型即可勝任的場景。這種內部部署讓這類大規模實驗得以落地，其規模是任何早期初創產品都負擔不起的。

智能體市場究竟將去往何方

被問及 Sundaresan 對智能體 AI 炒作周期的看法，他給出的會是研究者視角的答案，而不是管理者視角的表態。

“無風不起浪，”他接受《The New Stack》采訪時表示，“如果炒作是煙，那背后一定有火。火勢或許沒有煙那么大，但火苗確實存在。”

他的判斷是，基于智能體的開發模式確有實際價值，但并非新生事物。基于服務的開發、基于 API 的開發、基于智能體的開發，這些模式以往早已存在。真正的變化在于，如今的接口是概率性、對話式的，而非傳統的確定性、程序化接口。這種轉變催生了全新的能力，同時也帶來了全新的風險。

“你也可以分散它的注意力，”他談及智能體系統時說。“你可以問不該問的問題，或者透露不該透露的信息。”他所看到的 91% 失敗的 AI 項目歸根結底在于規范或者說紀律的缺失。企業以為和前沿模型提供商簽個協議就夠了，但事實并非如此。“在把它們集成到你的軟件產品之前，你需要遵循已有的規范，”Sundaresan 說道。

他關注一個尚未得到足夠重視的發展方向：智能體之間相互交互對話，最終會采用人類無法直接讀懂的機器原生語言。“倘若這些衍生語言中出現漏洞差錯，這類錯誤很可能會呈爆炸式擴散蔓延，”他說道。“未來還會有諸多變化發生。我們可以因為害怕而什么都不做，也可以勇敢但系統性地向前推進。”

https://thenewstack.io/ibm-bob-agentic-coding/

會議推薦

企業級 Agent 落地，繞不開 4 個真實的工程問題！如何在 Agent 安全性和可用性之間找到平衡點？Agent 需要什么樣的記憶系統才能真正理解上下文？如何通過算法壓榨實現智力增量與成本控制的極致平衡？多 Agent 協作，如何做到可觀測、可治理、可控制？6.26-27 AICon 上海站，國內頭部公司的 Agent 實踐，一次說透。

今日薦文

你也「在看」嗎？