追逐AI的高潮:黏土、窯爐與紅皇后競賽
本文探討了過度依賴AI編碼代理的陷阱,引用《鏡中世界》中的紅皇后競賽。作者認為,移除軟件開發中的人類摩擦(如代碼審查和設計辯論)會導致脆弱的、未經“燒製”的黏土代碼,無法承受壓力。文章警告,為了更快交付而使用AI的競賽創造了一個增加複雜性和脆弱性的死亡循環。
在軟件行業,越來越多的人開始嘗試使用大語言模型(LLM)編碼代理,並迅速沉迷於讓多個代理幾乎24/7不間斷運行。這種對AI生產力的追求,被作者稱為“AI精神病態”——人們堅信AI的變革力量,認為如果不全力擁抱AI就會消亡。然而,隨着時間的推移,無論多少生產力都顯得不夠。從單個代理到數十、數百甚至數千個代理,人們瘋狂地試圖用AI消滅積壓任務,甚至讓客户直接通過提示詞創建任務。這種對速度的痴迷,讓人聯想到《鏡中世界》裏紅皇后的話:“你必須盡力不停地跑,才能保持在原地。”
作者指出,設計和編寫軟件本就充滿挑戰和繁瑣,因此我們創造了瀑布、敏捷、Scrum、極限編程等方法來協調集體構建。當AI出現並打破這一切,讓個人能夠快速將積壓任務變成可交互的狀態時,人們開始擔心無事可建,生產力高峯即將消退。為了避免“崩潰”,他們不斷往積壓任務中添加新內容,陷入一種上癮的狀態。
AI帶來的焦慮讓開發者擔憂代理和循環是否卡住,任何沒有生成token的時間都是浪費。既然成了10倍甚至100倍工程師,一小時的損失就相當於一千小時。但這種追求速度的競賽,實際上是一場“紅皇后競賽”——因為競爭對手也在用AI加速,你必須跑得更快才能保持競爭力。然而,問題在於複雜性和熵增。每個人都在用AI飛速奔跑,卻忘了這是一場馬拉松,而不是百米衝刺。代碼庫的增長速度超過了團隊的理解能力,即便有AI輔助也難以掌控。
作者用“黏土與窯爐”的比喻來闡釋AI構建的軟件本質。AI生成的代碼就像黏土:可以快速塑形,幾分鐘內就能做出可識別的東西。但黏土若不經過窯爐燒製,在壓力下就會溶解。在軟件開發中,代碼審查、測試、部署、監控和辯論就是那個窯爐。AI不會反駁你的想法,反而會積極驗證你的意願。當唯一的構建夥伴對你言聽計從時,你從未真正“燒製”過你的代碼,一切保持可塑狀態。更糟的是,不同人用AI生成的代碼就像各自捏的黏土塊,無法有效拼接。這種“加拉帕戈斯效應”導致每個工程師在自己的AI輔助氣泡中進化出完全適應個人對話上下文的解決方案,卻與相鄰工程師的代碼格格不入。表面上風格一致,但底層的設計決策在集成時才會暴露分歧。
作者回憶自己在前公司花費大量時間反對團隊的API設計,堅持要求他們從不同角度思考,創造更易理解、能經得起窯爐煅燒的接口。但若所有構建都是未燒製的黏土,一旦遇到“雨水”(真實世界的壓力),一切都會沖垮。人們可能會説,雨停後可以用AI重建,但問題在於無法區分哪些是已燒製的、哪些不是。沒有人知道什麼是承重結構,什麼是裝飾品,因為通過自己構建所獲得的理解從未產生。
最終,作者描繪了一個“死亡循環”:競賽迫使團隊縮小規模、更依賴AI,這移除了窯爐(人類摩擦),導致更多未燒製代碼產出,增加系統脆弱性和複雜性,讓競賽更加緊迫。組織能看到他們在消除的摩擦,卻看不到那些摩擦曾經的作用。敏捷、Scrum等協調儀式不僅僅是項目管理表演,它們是人類建立對複雜系統共同理解的方式。設計評審、PR辯論、架構爭論就是窯爐。當你移除了不理解其目的的過程時,直到“下雨”你才會發現代價。
文章的核心並非否定AI,而是指出為了加速而移除所有賦予軟件結構完整性的機制是一個陷阱。紅皇后競賽的終點不是跑得更快——愛麗絲從未到達任何地方。身處競賽中的唯一問題是:你減少複雜性的速度是否跟得上創造它的速度?如果不是,你並不是在賽跑,而是在墜落。