軟件工程不是寫代碼！谷歌DeepMind高管坦言：代碼接近免費，但程序員最難的工作才剛開始

來源：市場資訊

（來源：51CTO技術棧）

編輯 | 姜篇

“Software engineering is not about writing code.”
Benoit Schillings：軟件工程不是寫代碼。

Benoit是谷歌DeepMind研究總裁，同時也是一位寫了45年代碼的老工程師。

備注：Benoit最早在Apple II和Commodore 64上用匯編寫游戲，后來用過C++、Python，如今也在Vibe Coding。曾供職Google X，現在是Google DeepMind研究總裁，帶領團隊負責AI面向Gemini落地。

在Benoit看來，寫出一段能夠運行的代碼，只是完成了軟件開發的第一步，工程師還要理解系統結構、理清模塊依賴、判斷改動范圍，并證明修改不會破壞已有功能。

在AI Engineer World's Fair 2026上，他用20分鐘講了一件事：代碼正在變得便宜，但軟件并沒有因此變得容易開發。

新入職的工程師面對一個有3500萬行PHP的代碼庫，需要在不破壞系統的情況下動一處邏輯。

這才是Benoit眼里的軟件工程。

以下為演講內容，我們進行了翻譯與整理。

寫了45年代碼，他最早也不相信編譯器

Benoit回憶道，早年在他一直用匯編語言寫代碼時，他并不信任編譯器，總擔心機器轉換出來的代碼會出錯。

后來，他逐漸接受了C++和編譯器，卻又對帶有垃圾回收機制的語言產生懷疑。

在當時的他看來，程序員如果不親自管理內存，就不能算真正會編程。

但是現在，他每天用Python，也用Vibe Coding。他拿自己開玩笑：老狗也能學會新把戲。

這段經歷很像開發者面對Coding Agent時的心路。

從“它寫得沒我好”，到把一個函數交給它，再到讓它讀倉庫、改文件和跑測試。工具變了，程序員對“什么才算編程”的理解也會跟著變。

回顧45年編程經歷

函數和模塊，最初是為人腦減負

Benoit把軟件開發分成了幾個階段。

他剛入行時，限制程序的是機器。

內存少，處理器慢，工程師要從硬件里擠出最后一點性能。計算資源降價后，這個矛盾慢慢退了下去。

系統越來越大，新問題出現了：代碼庫規模太大，單個工程師不可能記住并理解其中所有代碼

Benoit Schillings：我們開始思考如何構建庫、如何寫函數，以及如何把問題拆成可以長期管理的部分。
決定軟件流程的限制，已經變成人腦。函數、模塊、命名、接口和文檔，都在幫人把復雜系統切成可以理解的小塊。它們也讓幾百名工程師能在同一個代碼庫里合作。

當Agent能讀取整個倉庫，人類的上下文限制不再是唯一尺度。但團隊還需要理解、審查、交接和維護這套系統。模塊化不會因為模型記性更好就立刻消失，它的服務對象開始多了Agent。

解釋函數、庫與長期可維護性

3500萬行PHP，才是軟件工程開始的地方

“Software engineering is not about writing code.”
Benoit Schillings：軟件工程不是寫代碼。當你第一次加入一家公司，發現代碼庫里有3500萬行PHP，還必須在其中完成修改，那一天你才會明白什么是軟件工程。

在這樣的代碼庫里，一行正確的代碼也可能帶來錯誤結果。

它可能繞過了權限邊界，破壞某個歷史兼容行為，或者把一次普通查詢變成性能瓶頸。單元測試通過，也不代表這次修改適合整個系統。

Benoit：人類目前仍擅長把系統放進更寬的上下文里，找到模式，然后判斷一個技術決定會留下什么后果。

這是開發者在Agent時代需要保住的部分。你可以不親手寫每個函數，卻得知道改動會沿著哪些依賴擴散，哪些限制不能被繞過。

解釋什么時候才會明白軟件工程

代碼接近免費，系統的賬才剛開始算

“Writing code is free or nearly free.”
Benoit Schillings：我們圍繞“寫代碼最難、成本最高”這個假設，建立了整套軟件工程文化、基礎設施和公司。現在，寫代碼正在變得免費，或者接近免費。

軟件的總成本不會跟著清零。

代碼量暴漲之后，開發者得繼續支付設計、驗證、運行、安全和長期維護的成本。

以前團隊會因為開發資源不夠，拒絕一個邊緣需求。當Agent幾分鐘就能實現，類似功能很容易全部進入代碼庫。

生成只發生一次，后面每個版本都要與它相處。

軟件公司接下來可能會發現，短期的開發速度提高了，運維面積、攻擊面和測試組合也一起變大了。

談代碼生成的成本變化

沒人逐行讀AI代碼后，代碼審查得換一種做法

Benoit做了一個很激進的預測：一年后，開發者可能會讓Gemini或其他模型直接生成代碼，不再有人逐行閱讀。

他用編譯器作比較。今天還有多少程序員，會在每次構建后閱讀編譯器輸出的匯編？

如果這一天到來，代碼評審不能連同閱讀代碼一起消失。它會向系統行為移動。

開發者需要查看接口契約有沒有變，權限是否擴大，性能基線有沒有倒退，新依賴帶來了哪些供應鏈風險。

單元測試、集成測試、靜態掃描、運行時指標和回滾記錄，會承擔過去那部分“人肉閱讀”的工作。

人不讀每一行，也必須看得見系統做了什么。

Benoit預測開發者將越來越少逐行閱讀模型代碼

測試通過，只證明了軟件工程很小的一部分

代碼是模型最早大規模突破的領域之一，原因很簡單。

GitHub上有大量可供訓練的代碼，而且結果容易驗證：可以編譯，可以運行，也可以執行單元測試。

但Benoit對現在常用的代碼評測并不滿意。

Benoit Schillings：SWE-bench檢查一段代碼能否運行，以及能否產生正確輸出。這只是我前面所說的軟件工程中很小的一部分。
現有評測善于回答“它能不能完成這道題”，很難回答“這份代碼放進真實系統，一年后會不會成為麻煩”。

這個差距在Agent上尤其明顯。一次修改全部通過測試，可能仍然重復了現有能力，引入了過度抽象，或者讓后續排障更難。

團隊需要給Agent增加更多測試用例，也要補上架構約束、安全規則、性能預算、日志和可回滾的交付過程。

談現有代碼評測的邊界

下一門編程語言，可能不需要讓人讀懂

演講接近結尾時，Benoit扔出了一個更大膽的問題：是不是到了為模型設計新編程語言的時候？

Python等語言是為人發明的。它們易于閱讀和表達，并沒有把安全與可靠性放在最優先的位置。

Benoit：既然寫代碼的痛苦正在消失，可以讓模型承擔更高的生成成本，使用強類型或者借鑒Lean等形式化方法，把“證明自己正確”的壓力交給模型。

他甚至認為，這種語言不一定需要對人友好。

這個設想短期內很難進入大多數團隊。

線上代碼仍需要人類排障，也得與已有工具鏈交接。但它很適合提醒開發者：我們今天看作理所當然的編程語言和代碼形態，也許只是人類親手寫代碼時代的產物。

談為模型設計新編程語言

代碼寫完以后，開發者要把這些事接回來

“Code is over, but there's plenty to do.”
Benoit Schillings：代碼這道難題快結束了，但后面還有大量工作要做。

對一線開發者來說，這些工作已經可以寫進Agent任務單里。

需求要能被驗收。“優化這個頁面”不夠，至少要寫明性能指標、兼容范圍和不允許改動的行為。

系統邊界要能被工具讀取。依賴關系、數據契約、權限要求和部署約束，不能只存在某位老員工的記憶里。

驗收不能只看模型的文字結論。要留下測試報告、性能對比、掃描結果、運行時軌跡和可以執行的回滾路徑。

一個Agent幾分鐘生成了幾千行代碼，不等于一項工程工作已經完成。

正如Benoit所說，每一次林林總總的代碼更改，最終都要回到幾個問題：它是不是我們需要的？能否在真實系統里長期運行？如果錯了，我們能不能看見并撤回？

代碼是軟件工程留下的一種表達。定義問題、管理復雜度、驗證結果，以及承擔上線后的后果，這些工作還留在工程師手里。

寫代碼越便宜，為代碼負責就越貴。