AI 是放大器，不是方向。文章作者、來源：InfoQ
AI 讓你寫代碼快了 10 倍，然後呢？更多的代碼意味著更長的編譯、更重的測試、更堵的代碼審查，以及一個沒人能理解的代碼庫。軟體是負債，你寫得越快，欠得越多。
Google 首席軟體工程師 Adam Bender 的警告很直接：今天你構建軟體的方式，在 10 倍速度下根本行不通。但 AI 時代的真正贏家，不是產出最高的團隊，而是基本功最紮實的那些人。因為 AI 只負責放大，不負責方向。
在 Google I/O 2026 的一場主題演講中，Adam Bender 提出了一個大多數人還來不及思考的問題：當 AI 將代碼產出速度推至現有工程流程無法承載的地步時，我們的開發者生態系統中，什麼會最先崩潰？他用一個你可能沒聽過的概念串起了整場演講：軟體生態學，即對生產軟體的社會技術生態系統進行整體性研究的學科。換句話說，你不只要看技術，還要去看人、去看文化、去看組織中那些不成文的規則。基於該演講影片，InfoQ 對內容進行了整理。
核心觀點如下：
- AI 不會自動幫你解決任何問題。如果你的實踐是良好的，它能放大它們；但如果不夠好，它只會製造更多麻煩。
- 人人都是構建者很酷，直到你必須維護所有人所構建的一切。
- Engineering practices are not sacred or inviolable. Practices change; principles are what matter.
- 作為一線軟體工程師，在這個關鍵時刻，你正處於決定軟體工程未來走向的核心位置。從工具到工作流程，從工程實踐到工程文化，如果你能看清正在運作的系統，你就會找到槓桿點。
什麼是“系統”
你 2026 年的工作，跟你 2020 年想像的樣子完全不一樣。如果你試圖向 2020 年的我解釋今天發生的事，我不會相信。變化太多了，多到讓人有點招架不住。我無法預測未來，但我相信，如果我們仔細研究當下的軟體生態系統，有些答案比我們想像中更近。
我今天要跟你聊一個詞：軟體生態學（Software Ecology）。聽起來像是我為了上台隨便編的，但不是，這是個正經術語。在給出定義之前，我想先鋪墊一些背景，我們稍微深入一下系統思維。
一個系統是一組相互關聯的元素，按照一套規則運作，形成一個統一的整體。聽起來很抽象，但你對系統並不陌生。例如空調：一個知道目標溫度的恆溫器、一個負責升溫或降溫的暖通空調、一個房間，當溫度合適時，信號就停止了，這就是一個系統。
如果你是軟體工程師，你每天都在與系統打交道，你設計系統、構建系統、運維系統，在這個過程中你大概學會了一件事：一切皆關聯。
接下來是生態系統，這是一種特殊的系統。定義有點長，但很重要：生態系統是由相互依賴的行動者組成的動態網絡，這些行動者與其環境共同演化，其特點是湧現行為和去中心化的自主性。說人話就是，生態系統非常複雜，組件之間深度連接，每個組件都有自己的自主性，能夠做出決策、採取行動。而最關鍵的一點是：環境是系統的一部分，你無法將兩者分開。
生態系統也是一種複雜適應系統，能夠隨時間增長、變化和演化。它們還具有一種稱為「湧現」（Emergent Property）的特性，即你無法透過觀察任何單一部件來看到的東西，只有當系統整體組裝起來時，行為才會從中湧現。正是這種持續變化、持續學習加上湧現，使得弄清楚生態系統中到底發生了什麼變得極其困難。
提到生態系統，你腦海中可能浮現的是山川河流、鳥語花香。但內部開發者環境，也是一種生態系統：它包含各種工具與服務、帶著各自想法與需求的人，以及業務限制。而且它是一種特殊的系統：社會技術系統，即由人與技術共同構成的系統。社會技術系統極其複雜，因為你從所有這些技術出發，再將人也融入其中。
你很可能在不知不覺中已經接觸過社會技術系統的智慧。你們知道康威定律嗎：組織所構建的技術，會鏡像其內部的溝通結構。通俗地說，如果你有四個團隊在做同一個編譯器，你就會得到一個四遍編譯器，事情就是這樣。康威定律的核心觀察是，我們構建技術的方式，與構建它的組織結構不可分割，組織塑造了最終被構建出來的東西。
但不僅組織結構影響開發者生態，價值觀和文化同樣影響深遠。你的生態系統所培育的，正是組織所激勵的東西；你的工程文化創造了圍繞開發者生態的環境。一旦你理解了社會技術系統，你便會在軟體開發的每一個角落看到它們：架構、事故復盤文化、程式碼審查、安全策略，無處不在。我們所構建的東西，以及我們選擇構建它們的方式，反映了我們重視什麼。如果我們足夠用心，就可以利用這種認知來放大我們的價值觀，將它們注入到我們所構建的東西中。
現在我可以給你一個正確定義了：軟體生態學是對生產軟體的社會技術生態系統進行整體性研究的學科。如果剛才那些有點抽象，沒關係，現在來看一個真實的案例。
Google 的開發者生態
我談 Google，不是因為我在那裡工作所以要吹它，而是因為它是我在開發者生態中最具體了解的案例。我的目的不是要你們照搬 Google，那對你們沒有好處。你們是不同的公司，處於不同的階段，面臨不同的權衡。Google 所做的許多選擇，都是針對當時我們建構生態系統時的具體需求。
幾年前，我們寫了一本書，內部稱為「火烈鳥書」。書中一半內容講述版本控制和測試，但整個前半部分都在探討工程文化。很多人問，為何要花這麼多篇幅講文化？因為如果你不理解 Google 的文化，就無法理解我們為何做出那些技術選擇，這些事情是相互關聯的。
Google 擁有幾個獨特的文化特質。我們是深度工程導向的，在做重要決策時，工程師總是在場；我們極度重視透明度，盡可能讓所有文件和代碼對所有人開放；我們鼓勵樂於助人，實際上，任何離開過 Google 的人，都會首先提到同事們的樂於助人；我們將代碼審查視為指導的機會，而非批改試卷；我們極度重視標準化；我們相信持續改進；我們推崇無追責的事故復盤；我們堅信可持續性優於英雄主義，自動化優於手工勞作。當然，我們並不總能達成所有這些理想，但這正是我們在文化上努力追求的方向。
在技術方面，我們使用單體代碼倉庫，幾乎所有代碼都集中於一個倉庫中；採用基於主幹的開發模式，每次更改直接合併至主線；構建二進制文件時，幾乎每一行代碼都從源碼重新編譯；使用統一的構建工具鏈，所有人都使用同一套工具；全球化的測試自動化平台，可在單一地點運行所有測試，每天執行數十億個測試用例；擁有全局的「最後綠色」信號，我只需透過一個簡單的內部網站，就能告訴你任何構建的狀態；統一的計算環境，因此「在我機器上能跑」這種情況幾乎不可能發生；並採用高度規範化的開發者框架與一小組核心編程語言。
這種文化與技術的混合，造就了 Google 今天的模樣，你沒辦法只理解其中一半而忽略另一半。
Shared Fate
如果要我選一個一直隱隱指導我們的原則，我會選「共享命運（Shared Fate）」。它描述的是一個生態系統及其組件之間緊密關聯的程度，在一個高共享命運的生態中，一個組件可以影響所有其他組件。在開發者生態系統中，共享命運既是一種技術選擇，也是一種社會選擇。你不可能僅僅通過讓所有人都使用同樣的技術來實現共享命運，你還需要建立關於如何管理這些技術的社會契約。
在 Google，共享命運始於單體程式碼倉庫。公司的每一行程式碼，除了少數例外，例如 Android 和 Chrome，都存在於一個共享倉庫中。所有程式碼都提交至主幹，沒有分支，沒有版本號，一切都在同一個地方。這種共享命運讓我們能夠在一個檔案中套用安全修補程式，並確信在一周之內，公司內每一個應用程式都會被修復。十行程式碼修補一百億行程式與系統軟體，這就像超能力一樣。
但共享命運並不總是好事，這是一種選擇。有些情況下共享命運並不合適，例如在生產環境中，我們絕不希望一個服務拖垮所有其他服務，或是一個叢集感染整個區域。因此，我們在避免會導致級聯故障的危險共享命運方面下了很大功夫。共享命運是一種權衡，你必須找到正確的放置位置，並確保它為你服務。
重大變更
在我們共享命運的環境中，最有趣的突現屬性之一就是大規模變更。請注意：早在 AI 出現之前，Google 的內部工具就已讓一名開發者有可能修改數百萬行程式碼——這些程式碼他們根本不會去閱讀、再也不會查看，甚至可能完全不了解。我們建構了讓這一切自動成為可能的工具，今天依然如此，而且我們至少在過去十五年裡一直如此。
這種能力讓我們能夠持續演進單體程式碼倉庫，更新語言和框架，防止內部環境變得僵化。毫不誇張地說，沒有大規模的變更，我們就不會是今天的 Google。製作這些工具的同事從事的是一種幕後英雄式的工作，讓公司能夠以所需的速度前進。
但關鍵在於，如果你不了解讓大規模變更成為可能的那些文化組件與技術組件，你就無法真正理解它。你需要什麼？普及的測試文化，每個人都必須寫測試。統一的測試平台，你知道哪裡可以取得結果。共同的建構工具，你建構出來的結果和我建構的一樣。標準化的函式庫，更換元件時不會東找西找哪個版本對你有用而對我沒用。標準化的程式碼審查，以及程式碼倉庫本身的透明度，這樣你才知道哪些程式碼需要修改。大規模變更是 Google「自動化優於手工勞作」這一理念的最終體現，而且只有在整個生態系統協作的情況下才有可能實現。你無法指著開發環境中的某一部分說，這就是它產生的原因；所有部分彼此連接，才是真正的關鍵。
你的生態系統，你的權衡
每個開發者生態系統都有這樣的突現特性。它們通常就是讓你感覺自己工作的地方有些獨特的東西，因為它們是你所做的一系列選擇的產物。
Google 的開發者生態系統產生了一套獨特的權衡，以服務於我們的技術和業務目標。但與每一個生態系統一樣，它不可能在所有任務上都表現出色。我們選擇優化的是極致規模、安全性和性能，即使這意味著有時需要犧牲開發者生產力，我們也願意做出這樣的權衡。一個五人初創公司的生態系統將會完全不同，速度和敏捷性才是最重要的。
你們大多數人所處的生態系統介於五人與二十萬人之間。你們需要做出的權衡取捨非常值得關注，因為當你審視這些權衡時，就能開始理解組織的價值觀：它真正在乎的是什麼，而不是口頭上聲稱在乎什麼，而是你實際觀察到的選擇揭示了什麼。當你理解了這些價值觀，就能開始塑造正在展開的變革。
10x 時刻：每個節點都在承壓
是時候談談房間裡那頭吃 token 的大象了：一個 AI first 的開發者生態系統到底長什麼樣？
從零開始構建一個全新的生態系統當然很好，但你們沒有人有這種奢侈。你們必須一邊繼續交付軟體，一邊更換其中幾乎每一個部分。公司期待你繼續創造價值，同時確保不出問題。
那麼問自己一個問題：你對今天自己的開發者生態系統了解多少？你能將它完整畫出來嗎？你知道所有部件在哪裡嗎，不僅是技術的，還有社會的？你能列舉出你的生態是由什麼構成的嗎？你組織裡的其他人了解多少？它的優勢和劣勢是什麼？瓶頸在哪裡？哪裡受到限制，哪裡是自由的？你有什麼樣的選擇餘地？你見過什麼樣的突現屬性？也許最關鍵的是：如果你的生態系統突然必須在未來十八個月內吞吐 10 到 15 倍的代碼量，你知道什麼會最先崩潰嗎？
地球上每一個開發者生態系統都正在經歷一場徹底變革，也許它尚未抵達你所在的每一個角落，但它正在前來的路上，每一個開發者生態都將不得不面對這個 10 倍時刻。這是令人難以置信的時代，但也相當令人困惑。過去二十五年我們有意演化出來的每一個權衡取捨，都將被重新平衡。
生成代碼快 10 倍，和工程開發快 10 倍，是兩件不同的事。在 Google，我們常說，工程是隨時間積累的程式設計。但問題是，我們正在大幅加速程式設計這一環節，讓代碼機器加速運轉。因此，我們必須想辦法圍繞這台代碼機器做好工程工作，才能真正為客戶交付成果。沒有人知道這輪生產力提升能推多遠，但有一件事是確定的：我們從這裡開始是往上走的。
問題是，我們今天構建和交付軟體的方式，在 10 倍或 100 倍的速度下行不通，某些東西必須改變。
讓我們從一個簡化版的開發者生態系統圖開始看。在一個活動量增加 10 倍的世界裡，什麼必須改變？
代碼入庫
撰寫原始碼。如果每個人寫代碼的速度都快了很多，代碼量就會大幅增加，這可不是好事。Jeff Atwood 曾說過，軟體是一種負債。因此，10 倍的代碼，就是 10 倍的負債。而且你不能直接給每人發一堆 token，然後說「祝你好運」；我希望你在完成培訓後再進行投資：你知道你的工程實踐文檔在哪裡嗎？知道如何演進它們嗎？之後再考慮吧。
構建系統。更多的代碼、更大的系統意味著更長的編譯時間。我敢肯定你們公司現在沒人抱怨過編譯慢。但猜猜怎麼著，它們會變得更慢。而且如果 agent 在驅動大量工作，編譯次數也在暴增。編譯不是免費的，無論在時間還是計算資源上。你可能從來沒有注意過自己在編譯上花了多少時間，但在 10 倍規模下，你一定會注意到的。
代碼設計。你有合適的 agent 化技能來鼓勵解耦嗎？有合適的伺服器框架來確保快速安全地組合各種能力嗎？你知道你們公司裡的 Web 應用有多少種部署方式嗎？有多少種不同的伺服器框架在運行？你如何管理 agent 所寫代碼的組件複用？也許你賭這不重要。但如果 agent 寫出了容易撰寫但難以維護的代碼，別太驚訝，這就是當前的基準水平。Agent 擅長寫代碼，但並不總是从長遠角度思考。這些代碼，我確定不會輕易被重構。沒關係，這部分我們將來會解決。但事實是，agent 正在為我們承擔大量工作，我們必須每天想辦法最高效地應用這些能力。
到了某個時候，這些 agent 化工作可能會讓你的二進制文件大到無法編譯，或者大到無法再推送到手機上。你有沒有問過這個問題：你能編譯的最大二進制文件是多大？我不知道答案，但我知道在 Google，我們正在觸及極限，有些地方的二進制文件已經大到無法編譯了，我相信我們會解決的。但事實是，大規模會帶來許多連鎖反應，規模的影響無處不在。
也許你是微服務技術棧，你正想：我的服務都很小，我幹嘛要擔心？但我有個問題：10 倍網絡流量、10 倍服務數量、10 倍通信量，你準備好了嗎？沒有人能全身而退，規模的影響無處不在。
代碼審查。假設你無法可靠地編譯所有這些代碼，你的代碼審查流程會如何？每個人都在擔心代碼審查，這是有理由的。我們正在對這個極具人性化的流程施加巨大壓力，在許多情況下，它已成為瓶頸，而人們不喜歡成為瓶頸。當你給他們施加壓力時，他們的行為會變得異常。10 倍的代碼量，你要麼得到 10 倍大的變更，要麼 10 倍多的變更。你的技術負責人能維持必要的審查速度嗎？大多數技術負責人連五個 10 倍開發者一天的代碼量都審查不完。
因此，為了不成為瓶頸，他們會開始重新安排流程，走捷徑，確保不阻礙任何人，因為沒有人想當阻塞者。你或許可以透過 AI 解決部分問題，部署 AI 來改善程式碼審查。但這只解決了部分問題，因為如果你的團隊成員不再寫程式碼，他們唯一接觸程式碼的時刻就是在審查時，而審查時的注意力又不足，那誰在關注程式碼庫的演變？沒有人。很快，你的程式碼庫就會變成一個沒人能理解的爛攤子。
代幣經濟學。代幣很貴，你們有些人已經知道了。在大規模下，代幣是你必須納入考量的實際成本。如果公司裡每個人開始使用 10 倍或 100 倍的代幣，會發生什麼？如果你不小心在一天之內花光整個月的預算呢？如果你必須優先決定代幣花在哪裡，你知道該優先投入哪裡嗎？你甚至有沒有看到代幣正流向何處的可見性？
僅在這個簡單系統的前幾個節點中，我們就已經發現了問題。而且非常清楚，將會出現一些具有挑戰性的二階效應。
測試和版本控制
你曾經看過你的測試基礎設施消耗了多少計算資源嗎？在 Google，我從來沒有對自己的測試速度感到滿意。
每一個進入版本控制的變更都必須經過測試。但除此之外，agent 也非常喜歡運行測試，因為測試能告訴它們自己做得好不好。因此，agent 產生了額外的工作量，讓我需要處理的任務更多了。那麼，10 倍的提交量加上 agent 所做的所有工作，現在消耗了多少測試計算資源？
實際情況可能更糟。我們在 Google 觀察到的是，隨著程式碼庫增長，依賴圖呈二次方增長，而非線性。因此，當程式碼庫增大 10 倍時，你需要運行的測試可能不是 10 倍，而是 100 倍甚至 1000 倍。這將是一個非常有趣的挑戰，並且它終將成為你預算表上的一行。如果你現在不擔心測試計算資源的開支，那才更讓我擔憂，因為這意味著你可能根本沒有足夠的測試，那些 agent 正在沒有安全網的情況下於你的程式碼庫中 YOLO。
假設編譯和測試都已解決，現在來看版本控制系統。大多數流行的版本控制系統並非為效能優化，它們是為一致性與排序而優化的。這正是它們的本職工作：保持完整的記錄，而不是跑得飛快。你的版本控制系統每分鐘能處理多少次提交？我保證，比你想像的要少得多。它無法擴展到你需要的 10 倍速度。你上一次想到版本控制系統的效能是什麼時候？如果你不是在開發 Git，大概從來沒想過。老實說，淪落到要討論版本控制效能的地步，代表某些事情已經嚴重偏離軌道了。我們已經站在開發者體驗的最底層，但這正是系統性變化的後果：它會找到你系統的每一個角落，然後說：嘿，你注意到了嗎？因為你沒預料到的事情來了。
對於那些打算用大量小型倉庫來解決版本控制問題的朋友，去問問任何運行過幾百個、幾千個小型倉庫的人吧，我可以保證，這只是一整套全新的挑戰，AI 並不能必然讓這些問題變得更容易。
意外清單
到目前為止，我們只關注那些相對容易發現的容量型節點，也就是將一個數字乘以 10，然後問是好還是壞，還有許多意想不到的挑戰。
驗證策略。你今天的驗證大概就是很多單元測試加上一些整合測試。但在 10 倍程式碼和 10 倍服務的世界裡，整合測試會成為品質策略中最重要的部分。你們有多少人對自己今天的整合測試方案感到滿意？我也不滿意。整合測試真的非常困難，我目前還沒有能按照我想要的方式進行整合測試的工具。
布爾值合取問題。今天你要發布軟體，你要求每一個測試都通過，所有布爾值都變綠，一切沒問題了你才發布，這很合理。當你有一百萬個測試，而底層測試基礎設施運行一百萬個測試的可靠性本身就成問題的時候，會發生什麼？可能所有布爾值都必須為真才能發布軟體這件事就做不到了。你需要一種新策略，大概基於統計的方法，來判斷哪些是正確的測試去運行，因為你不可能跑所有測試。
巨大的變更。能夠全面重構、更換語言和框架，確實令人興奮。但你有支援的工作流程與社會契約，能讓人們管理數以萬計、十萬計、百萬計行程式的合併衝突嗎？大概沒有。如果公司裡每一個人都能進行巨大的變更，我們就需要新的工作流程策略。
代理編輯戰爭。一個代理做了修改，另一個代理跑來說：不，我不喜歡，我要做不同的修改。看起來挺搞笑，直到你意識到你正在為雙方支付 token 費用。
發布節奏。你今天多久向客戶發布一次？每天？那挺好的。如果不是，這裡有個問題：你會得到十倍以上的軟體，這些軟體總得放到某個地方。如果你不是每天都在發布，每次變更會變得大很多。而我的 SRE 朋友們會告訴你，非常大的變更非常可怕。別這麼做。但代碼總得部署才能產生價值，所以你可能會嘗試更頻繁地發布，這很好，DORA 的朋友們會感到欣慰。但在某個點上收益會遞減，每秒發布一次大概不會給你帶來太多價值。代碼還是會增長，你需要搞明白把它放在哪裡才不會製造更多風險。
內部 API。我一直在跟共事的朋友们說，你的所有 API 突然之間都變成公開的了。Agent 不會跟你商量，它會找到 API 然後直接調用。它能訪問到什麼就會用到什麼，我保證。如果你從來沒有像對待公網 API 那樣加固內部接口和內部數據集，agent 會找到那些你並不希望它們找到的東西。
傑文斯悖論。傑文斯說，一種資源越便宜、越高效，我們就用得越多。Token 的爆發就是活生生的例子。我們正在把它們放到所有地方，這改變了我們怎麼工作，以及怎麼思考工作。我們正在為以前那些隱形生產力勞動定價，這會對我們的行為產生什麼影響？我還不知道。
回滾。你知道為什麼今天回滾基本可行嗎？因為你發布軟體的速度略慢於你在生產環境中檢測到問題所需的時間。如果你能非常非常快地發布，快到你還來不及檢測到任何問題，你的回滾姿態會怎樣？每次回滾都不得不應對堆疊在其上的多個相互衝突的變更。因此，僅僅發得更快是不夠的，你必須考慮整個系統，包括回滾這個重要的安全閥。順便說一句，你需要小心將 token 引擎放在哪裡。如果你的回滾流程依賴某個 agent 有足夠的容量，而之前有人把那個 agent 的 token 預算耗盡了，導致你現在無法回滾，那大概不是什麼好事。
每個人都是一個建設者。你可能曾想過，為公司裡你不喜歡的工具開發一個替代品。現在，將這個想法乘以公司裡每一個人和每一個工具。當每個人使用的工具都完全不同時，公司的社會結構會發生什麼變化？如果你運氣好，有一個統一的數據底層，所有數據都匯聚到同一個地方，那還好。但若沒有呢？每個人都是一個建設者，這很酷，直到你必須維護每個人所建的一切。
技術領導力速成班。成為一名技術負責人之所以需要那麼長時間，是因為你必須累積直覺、判斷力和專業能力，以協助你做出決策，因為當你領導一個團隊時，你的錯誤所產生的影響範圍遠比你單獨行動時大得多。當一名應屆生進入一個可以調用五十個 agent 的環境，卻毫無直覺和判斷力時，會出什麼錯？我該如何在六個月內教出十年的經驗？我不知道。
人類的注意力是我們擁有的最寶貴資源。現在噪音非常多，有那麼多 agent、那麼多事物在爭奪我們的注意力，我們必須想辦法管理這件事。我們以前受益於一個事實：我們製造麻煩的能力不會超過我們投入注意力的能力，但現在情況已經不是這樣了。
這些聽起來很多，是因為在一個系統中，一切皆相互關聯。我剛才提到的所有挑戰，你不可能僅透過觀察系統中的一個節點來解決其中任何一個，你必須觀察整個系統。
為了適應代理化開發，我們都必須開始學會以系統的方式持續思考。當你思考系統時，這些是你應該關注的事：事物如何變大、隨時間變化的效果、因果關係的流向、哪些節點正在與所有鄰居互動、湧現的樣貌，以及那些不知從何而來的東西是什麼。激勵機制呢？包括社會性和技術性的，容量、反饋迴路和瓶頸，這些都是系統分析的工具。
看起來很複雜，但你其實只需要問兩個問題：為什麼（Why？），和如果呢（What if？）。為什麼我們的整合測試這麼少？如果我們的整合測試比單元測試還多呢？為什麼我們使用這些特定語言？如果 AI 寫了所有程式碼呢？
「為什麼」是你用來深入系統核心、搞清楚它如何運作的鑽頭。你們都很擅長問「為什麼」，但「如果呢」才是更困難的部分。「如果呢」可能令人害怕，因為它可能要求你放棄那些你曾認為設計得極好的實踐。如果不這樣測試呢？如果完全不寫測試呢？別走得太遠。但如果你容許它發生，「如果呢」也可以相當令人興奮。
AI 是放大器，不是方向
AI 是放大器。這個想法來自我在 DORA 的朋友們，他們去年的 AI 開發報告發現，那些真正搞清楚了事情的團隊之間存在一種關係：他們弄明白了如何讓 AI 成為放大器。
AI 可以為你帶來更多：更多測試、更多文件、更多代碼，但也帶來更多混亂。放大是幅度，而非方向。AI 不關心這些東西去哪了，它只是給你更多。DORA 真正發現的是，那些基本功紮實的團隊，能夠將放大效應引導至有用的方面。
這就引出了問題：你對自己的基本功感覺怎麼樣？你們公司的決策文化怎麼樣？你能做什麼來改進它？技術戰略呢？有人關注開發者生產力嗎？組織裡的人今天協作得怎麼樣？安全態勢呢？代碼健康度、發布衛生、可靠性呢？AI 默認不會幫你解決任何問題。如果你的實踐是好的，它能放大它們。但如果不夠好，它只會製造更多麻煩。
但即使基本功紮實，我們也即將經歷一段真正的旅程。我猜測，到 2030 年，我們今天的開發者生態系統，大概就像 2001 年在我們今天看來那麼遙遠。2001 年我們還在用 CD-ROM 發佈軟體，到 2030 年我們可能就隔著這麼遠。
在你們繼續夯實基本功的過程中，讓我給你們四件可以沿途思考的事。
第一，基礎設施容量。如果你不知道你有多少資源可以花，你就無法部署 AI，無法部署計算資源，你需要一個好方法來追蹤這些。
第二，驗證策略。你不能也不應該發布未經驗證的軟體。但驗證策略會變化，現在是時候想清楚了。整合測試將成為你最重要的武器，而你可能還沒有趁手的工具。
第三，隔離。你會得到很多用於不同目的的代碼，有些目的以前根本不用代碼。這沒問題，但你不希望一個很酷的原型代碼真的跑進了生產環境。讓好玩的東西不要影響賺錢的東西。
第四，抽象。我們建立抽象是為了防止開發者做出糟糕的選擇，這就是為什麼我們有函式庫和框架。沒有人從零開始撰寫 Web 伺服器。讓 agent 做出大量決策會導致同樣的後果，因此你需要良好的抽象來引導 agent 遵循。不要給它們糟糕的選擇。
你還必須接受一件事：工程實踐並非神聖不可侵犯。實踐會變，原則才是重要的。這說起來容易做起來難，如果你從未真正思考過為何你的團隊以這樣的方式測試軟體，或為何發佈流程如此運作，你就無法讓它演進。理解原則，才會賦予你力量與信心，穿越這個 10 倍時刻。
現在是軟體工程師的迷人時代。我們工作的每一個維度都在被重新定義；我們比以往任何時候都更需要發揮創造力；我們需要技能來應對上下文管理、token 經濟學、模型漂移等問題；我們需要創造力；我們不能過於沉迷於優化一切的誘惑，而應鼓勵探索。
有一個問題一直讓我睡不著，它無法僅靠優化來解決：隨著程式碼庫的增長，我們該如何保持對它的智力掌控？智力掌控指的是人類能否對眼前的事物進行推理。我們至少已經輸掉這場戰爭十五年了，我們最大的系統早已超出任何一個人能思考的規模。如果你不信，回去做個實驗：讓你團隊中的每一個人畫一張系統架構圖，看看你能得到多少種不同的版本。
我們的許多軟體系統非常脆弱，一行糟糕的代碼或一個錯誤的配置標誌就能摧毀一個百萬行的系統，這種脆弱性迫使你在進行變更前不得不三思。但關於 AI，我有一個非常興奮的想法：一個持續更新、幾乎可互動的架構空間，我可以向它提問。如果我們把這裡的容量移到東海岸會怎樣？如果用戶增長突然上升 40% 呢？對於今天哪怕一個中等規模的系統，這樣做在功能上幾乎是不可能的，變量太多了。但 AI 能夠理解極其龐大的數據集，因此我認為這裡有值得挖掘的東西。
我喜歡這個問題的原因是，我們不僅僅專注於讓代碼機器轉得更快，我們還在問：如何加深對我們已建立之事物的理解？
變化發生得非常快，比你們大多數人經歷的都快。你們現在能做的最重要的事情之一，就是去幫助那些正在掙扎的人，向那些還沒搞清楚的人伸出援手。我們都在以不同速度前進，都在以不同方式應對這場變化。感到自己在落後，是很容易發生的事。
資深工程師們，去當導師。找到那些卡住的人，幫助他們。如果你已經搞清楚了 AI 開發工作流，去分享給別人，這不是什麼珍貴的秘密。技術負責人，你必須參與進來，幫助引導軟體工程在你們公司的发展方向。如果你關心軟體品質或軟體設計，你必須用你的聲音去為它發聲。在座各位就是要去做到這些的人，你們的老闆大概不會。
如果我們把開發者生態系統想像成一個活的生態系統，我們都已經習慣了緊緊盯著每棵樹的每一根枝條和每一片葉子，像照顧某種特殊生命形態一樣照料每一棵樹。但用不了多久，我們要管理的就不再是單一棵樹，而是整片森林。而你不能透過盯著單一棵樹來管理一片森林，你必須把森林當作一個生態系統來管理。
系統性變化有一種特質：它同時在所有地方、所有事物上發生，大到讓人覺得什麼都抓不住。此時此刻，你可能覺得什麼都無法讓你在似乎每周湧來的變革浪潮中站穩腳跟。但正如我們剛才發現的，在一個系統中，一切皆相關，微小的行動可以產生巨大的後果。
無論表面上看來如何，AI 轉型並非僅屬於公司領導者的領域。作為一線軟體工程師，在這個關鍵時刻，你正處於決定軟體工程未來走向的核心位置。從工具到工作流程，從工程實踐到工程文化，如果你能看清正在運作的系統，你就能找到槓桿點。你擁有的自主性比你以為的更多，善用這份自主性，為你的組織、你的團隊和你自己創造未來。