敏捷初衷減負，流程泛濫？XP創始人剖析商業化亂象

當AI在極短時間內寫出大段代碼，很多從業者開始感到焦慮：如果編程技能不再是稀缺資源，我們存在的價值是什么？軟件工程領域的傳奇人物Kent Beck，在近期的一場對談中給出了他的答案。作為極限編程（XP）的創造者、測試驅動開發（TDD）的先驅以及《敏捷宣言》的簽署人，Kent Beck在職業生涯的半個世紀中，目睹了軟件工程從蠻荒到繁榮的演變。他認為，在AI時代，開發者面臨的挑戰遠非技術更迭那么簡單，而是需要重新審視這個職業的本質。

很多懷揣技術夢想的人，在職業生涯早期都曾被許諾過一件事：只要你將計算機及其背后的機制徹底研究透徹，你就掌握了職業發展的核心。Kent Beck在回顧五十年的從業經歷時坦言，這其實是一個巨大的錯覺。

在職業生涯的前半段，他曾極度渴望成為最頂尖的程序員，認為那是成功的唯一路徑?，F實卻讓他意識到，軟件工程中最難、也最關鍵的部分，其實是人本身。一個開發者改變世界的能力，很大程度上取決于與他人的溝通、共情以及相互理解的能力。當大家過度沉迷于“搞懂電腦”時，往往忽略了這些至關重要的社交與溝通技能，而這些恰恰是無法通過技術鉆研來彌補的短板。

回顧Kent Beck參與創造的那些方法論，它們在誕生之初往往被外界視為“愚蠢”的想法。例如TDD，當他最初嘗試在寫代碼前先寫測試時，他自己都覺得荒謬，因為明知測試會失敗卻還要寫，這看起來完全違背直覺。但這種方法最終緩解了他的焦慮，并成為保障代碼質量的重要手段。

同樣的，極限編程（XP）的誕生也源于他對項目開發混亂局面的反思。在克萊斯勒項目中，他將各種行之有效的實踐整合在一起，并為了避免概念被他人曲解，特意選擇了一個聽起來不太吸引人的名字——“極限”。他有一個職業哲學：永遠去試那些看起來有些“笨拙”的主意，前提是其成本可控且可逆。絕大多數嘗試會失敗，但只要有一次成功，你就能獲得巨大的競爭優勢，因為很少有人愿意投入精力去驗證這些非共識的路徑。

Kent Beck認為，敏捷的核心本應是及時響應變化，但在實際應用中，它被過度商業化了。人們渴望一種現成的手冊來解決所有問題，卻忽略了軟件開發的內涵遠比那幾條原則復雜得多。如果沒有深厚的技術功底作為基礎，盲目追求敏捷只會導致開發過程的失控。

面對AI工具（如LLM）的沖擊，Kent Beck認為現在的行業正處于一個回歸“探索”的周期。過去二十年里，我們擁有一套相對固定的操作手冊，但現在這套手冊失效了。輸入的微小變化可能導致輸出的巨大差異，沒人能準確預測未來的演進方向。

他建議軟件工程師在AI時代應具備以下心態：

擁抱不確定性：別再試圖尋找通用的秘密手冊?，F在的技術更新速度極快，最好的方式是多試錯、多交流，在實踐中總結經驗，而不是在焦慮中等待答案。

重構角色認知：AI不僅是在加速代碼生產，更是在重構業務交付的節奏。如果一個業務流程原本設計為五年周期，但在AI加持下，競爭對手可能在一個月內就推出了替代產品，那么無論你技術多強，如果流程無法適應這種節奏，就會面臨淘汰。

關注冰山下層：利用AI快速構建原型只是“冰山一角”，軟件開發中真正的難點在于合規、下游數據聯動以及復雜的業務邏輯邊界。天真地以為用AI生成代碼就能取代整個工程團隊，最終會因為忽略這些潛在風險而付出代價。

Kent Beck將自己定義為“搖樹的人”而不是“做果凍的人”。他熱愛的是啟動項目、構建基礎結構、探索未知的創造過程。在AI輔助下，他發現自己四十年來積攢的許多想法，如今終于可以低成本地去嘗試驗證。

對于那些擔心被AI取代的人，他的建議是：不要將身份錨定在“編寫手冊”或“熟練掌握某種語法”上，而要鍛煉那種面對復雜系統時的判斷力。當你積累代碼的速度遠超積累信任的速度時，請停下來思考你真正要解決的問題。

軟件工程始終是一個動態演進的過程。無論是早期的Smalltalk，還是如今的AI agent，工具在變，但通過代碼去表達意圖、通過工程實踐去建立信心，以及通過團隊協作去驗證假設的本質從未改變。保持開放的心態，勇于推倒重來，你依然能夠在新的技術浪潮中找到自己的位置。畢竟，那些真正能改變行業的技術，往往是從一個個被視為“笨拙”的嘗試中生長出來的。