AI 愛好者與時間賽跑,AI 懷疑者與熵增賽跑
這篇文章探討了 AI 愛好者和懷疑者之間日益擴大的鴻溝,指出雙方都有合理關切。愛好者看到 AI 帶來的生產力飛越,而懷疑者擔憂代碼質量下降和系統混亂。作者建議通過講述完整故事和採用工程化方法來彌合分歧。
本文最初發表於 Charity Majors 的 Substack,經作者許可轉載。
最近我參加了一場演講,其中一位演講者聲稱通過純粹的“氛圍編碼”(vibe coding)實現了驚人的成果:解決了棘手的工程問題,清除了積壓任務,甚至將原本需要一年以上的重寫工作壓縮到短短幾周內完成。會後,我聽到許多興奮的討論:“我迫不及待想讓團隊看這場演講,我的工程師們對不閲讀代碼就交付代碼的想法非常牴觸,這下終於有他們無法忽視的證據了!”
然而,問題在於,我認識該公司的許多其他員工,他們將這些項目描述為一場災難。是的,他們承認取得了一些進展,其中部分成果令人印象深刻,但演講者也留下了一條長長的混亂軌跡。數月後,一些團隊仍在處理清理工作。
我不斷回想這個片段:台上講述的是一個高度選擇性的故事,而台下滿是對AI充滿熱情的聽眾,他們不加批判地全盤接受,因為這恰好驗證了他們希望成真的所有假設。我思考着他們帶回家的那種確定性,以及這種能量如何影響他們與團隊的對話。
人們正在退回到各自的陣營,拉緊防線。愛好者與懷疑者之間的鴻溝日益加深。雙方都感到緊張、沮喪,甚至有些恐懼,結果他們停止了相互對話,轉而談論對方——視為障礙、刻板印象或威脅。簡而言之:一方説“那些人被AI洗腦了,根本不懂軟件”,另一方則説“那些人討厭AI,不想快速前進”。
這不是一方正確而另一方完全錯誤的情況。每一方都在應對一個真實、令人擔憂且不斷升級的威脅,而且隨着他們深入觀察,會發現更多真實的證據。
愛好者並沒有錯。我們開始看到那些積極擁抱AI的團隊實現了真正的、非想象的能力飛躍。這不像正常的科技週期,你可以等待塵埃落定;在競爭者奮力前進時按兵不動的團隊,可能在塵埃落定前就已被淘汰。這是真實的生存威脅。
懷疑者也沒有錯。當代碼交付速度超過工程師的閲讀能力,在無人掌握完整上下文的領域,你正在透支多年建立的信譽。可靠性下降,機構知識流失,最終導致系統無人理解,產品失去連貫性,值班輪換讓團隊精疲力竭。這也是真實的生存威脅。
本文面向的是那些正在努力工作的優秀團隊。我談的不是管理層脱離工程現實或聘請麥肯錫顧問的團隊,也不是低工程紀律和低信任度的團隊。我面向的是那些正在從AI前時代向AI原生時代轉變的高績效團隊。這些團隊擁有工程紀律和技能,他們努力掙扎,正是因為存在太多合理且相互競爭的威脅,卻沒有明確的答案。
問題在於,愛好者和懷疑者之間缺乏自然的反饋循環。勝利和成本分別發生在不同羣體身上。演講者可能並非故意誤導,他們甚至可能沒有意識到自己留下的混亂。在沒有上下文或精通的情況下做事變得非常容易,而下游成本往往對產生成本的人不可見,他們只看到勝利。
懷疑者則面臨相反的問題。他們無法避免聽到愛好者的主張,但當這些主張變得越來越誇張、越來越脱離現實時,懷疑者會以越來越強的諷刺態度回應。他們聽到了,但不再相信一個字。許多工程師無奈地告訴我:“我不想成為AI反對者,我在學校學過AI!我覺得它很酷!但我感覺自己被逼到角落,必須成為反對者,因為我是唯一關心現實的人!那些主張到底有多少是真實的?”
好吧,這很公平。我將展示我的工作成果,提供一個“好”的北極星示例。
以Fin(前身為Intercom)的工程組織為例。我一直很欽佩他們。去年,我和Christine制定AI任務時,從CTO Darragh Curran的文章“2x”中汲取了大量靈感,他挑戰研發組織在12個月內將生產力翻倍。最近他公佈的結果顯示,他們超額完成了目標——在9個月內將產出提升了3倍(以合併PR總數除以研發總人數衡量)。當然,PR並非完美的現實表徵,這一點我們大家都知道。
結果喜憂參半,但讀來引人入勝。產品缺陷積壓減少了一半以上;產品變更數量翻倍,從創意到交付的速度提高了39%;代碼質量在經過18個月的可怕下滑後開始初步改善;停機時間減少了35%。
這是真實的、非想象的、不連續的能力飛躍。這並不是因為AI有魔力,而是因為Fin已經具備了極高的工程紀律、快速的反饋循環以及實驗和測量的文化。如果你想知道AI前時代的工程團隊通過擁抱AI能實現什麼,這就是答案。
我們可以解決這個問題。首先,提醒大家:我們關心同樣的事情,我們站在同一邊。我們迫切需要彼此。為了在錯失窗口的“斯庫拉”和系統瓦解為“混沌”的“卡律布狄斯”之間安全航行,我們需要同時關注兩種威脅,協調同步,共同努力。
為此,我們需要做兩件事:將分裂的現實重新縫合,讓大家都朝着同一個方向努力;並對問題應用工程嚴謹性。
第一步:講述完整故事,談論勝利,也談論成本。修復共享現實的差距。你可以慶祝AI帶來的巨大勝利和進步,但也要邀請對成本和下游後果的反思。要非常明確地表明,共同目標是找出如何以更少的不可預測成本交付更多、更大的勝利,而不是扼殺創新。
這聽起來簡單,實則不易。默認情況下,勝利在一個場合(博客、會議演講、全員大會)被宣揚,而成本在另一個場合(SRE團隊會議、值班、回顧、抱怨的私信、酒後的牢騷)浮現。結果是雙方都可能覺得被不公平地噤聲。你可能認為“我們甚至不允許批評AI”和“我們整天都在抱怨AI”這兩種情緒不可能同時廣泛存在,但事實確實如此。這種不對稱並非惡意,而是結構性的,必須加以糾正。
如果你是愛好者,從這裏開始。下次你完成一件真正令人興奮的大事——“我在週末空閒時間完成了一項兩個月前已經放棄的遷移!”——太棒了!告訴你的同事!但同時,也要詢問其他團隊是否有任何意外後果,並納入你的分享。加上一句“如果有任何下游清理工作,我很想聽聽”。尤其是當存在權力動態、人們可能不敢發言時,要讓反饋變得容易。
如果你是懷疑者,正在清理他人AI氛圍編碼勝利留下的下游混亂,不要只是苦澀地嘀咕。以負責任、友好的方式向造成問題的人提出,或者在同一論壇中提出。閉合反饋循環,這是我們學習的方式。
第二步:將其視為工程問題,而非修辭問題。一旦你在同一現實中運作,就可以進行真正的對話。目前,對話往往是這樣:愛好者説“讓我們不進行代碼審查就交付!X公司正在這樣做。這顯然是世界的趨勢。你為什麼討厭未來?”懷疑者回答“你是在開玩笑嗎?我遇到從沒聽説過的人提交的代碼像用蠟筆寫的,你卻想讓我自動接受?”。
其實雙方都可能是對的。是的,行業大方向是走向軟件工廠和AI驗證的差異。是的,考慮到你當前代碼庫和防護措施的現狀,自動接受差異可能是完全不可想象的。但“你怎麼了”和“這永遠行不通”是偽裝成立場的對話終結者。有效的對話應該是:“需要什麼條件才能讓你放心地在不閲讀代碼的情況下將代碼交付到生產環境?”更好的評估?更好的測試?更好的功能開關、防護措施、可觀測性?解耦依賴、減少爆炸半徑?從關鍵路徑之外的小事開始?我們需要做哪些準備工作?先後順序是什麼?能否將其納入路線圖?
將工程紀律應用於AI採納從未像現在這樣重要。正如2025年DORA報告所言:“AI是一個放大器。它放大了高績效組織的優勢,也放大了掙扎組織的功能障礙。”AI無法解決紀律缺失、工具差距或脱離現實的管理。要有效利用AI,你必須投資於工程紀律。