「即使有了人工智慧，能力不足的工程師仍然會產出能力不足的產品，只不過速度更快。」 這才是問題的關鍵。人工智慧改變的是速度，而不是判斷力。如果你的團隊原本就很難做出合理的架構決策，那麼這個工具並不能拯救他們，只會讓他們更快做出更多錯誤的決策。同樣的缺陷，只是被壓縮到了一個更短的時間內。
我當時正在和一位經營內容管理系統（CMS）平台的朋友通電話。我們正在討論他的客戶群如何採用人工智慧，結果他只花了十秒鐘就戳穿了那些炒作的本質。
「進去，出來，」他說。 “人工智慧並不能解決分散式團隊幾十年來面臨的問題。”
就是這樣。話題轉移了。他一直看到一些公司做著同樣的賭注…把工作外包給低費率市場，指望人工智慧能彌補缺口。但人工智慧解決不了協調問題，解決不了責任不清的問題，也解決不了每三個月就要重新審視一次的架構決策問題，因為沒人就其中的利弊達成協議。
人工智慧只是產出速度更快。無論好壞，結果出來得更快。
無根基的速度
我的朋友在他的客戶群中發現了這種模式。那些在人工智慧出現之前就苦於架構決策的公司並沒有找到捷徑，而是找到了一種方法，將同樣的缺陷壓縮到一個更短的時間內。那些原本就存在交付模式不一致、責任邊界不清以及技術債悄悄累積的團隊……現在卻更快地完成了所有這些工作。
如果你的團隊本來就難以做出合理的架構決策，人工智慧並不能拯救他們，只會讓他們更快做出更多錯誤的決策。
這種模式我已經看過太多次了，所以一眼就能認出來。團隊採用新工具後，初期速度確實提升了，就誤以為速度快代表系統健康。一兩個迭代周期內，各項指標看起來都不錯。但隨後，先前未經審查的決策所帶來的負面影響就開始顯現。原本應該在程式碼審查階段就發現的重構問題，程式碼庫中出現的各種不一致的模式，以及因為大家行動太快而悄無聲息累積的技術債。
這個工具本身並沒有造成問題，它只是揭示了原本就缺乏結構。
判斷差距
區分那些能夠利用人工智慧取得成功的團隊和那些舉步維艱的團隊的關鍵不在於人工智慧本身，而在於判斷力。
具備敏銳判斷力的團隊能夠評估模型的輸出結果。他們了解模型的運作模式，並明白其中的利弊權衡。他們能夠審視產生的程式碼，並辨識出哪些程式碼適用，哪些不適用。對於那些已經懂得何為優秀的人來說，人工智慧將成為一種倍增器。
缺乏這種判斷力的團隊無法評估他們所獲得的成果。他們將自己從未學會如何做出的決策外包出去。結果並非更好的工程設計，而是更快地執行不確定的選擇。
缺乏判斷力的團隊無法評估他們所獲得的成果。他們將自己從未學會做出的決策外包出去。
這就是人工智慧工具在工程領域令人不安的真相：它並沒有創造公平的競爭環境，反而加劇了差距。擁有強大技術判斷力的團隊與缺乏這種能力的團隊之間的差距只會越來越大，而不是越來越小。強大的團隊行動更快，建立更優質的產品；而弱勢團隊行動更快，卻只能重複利用現有的東西。
我們建構的預言機
我曾經是團隊裡的「先知」。
決策都是我一手操辦的。那些成功的專案都是我密切參與的。我當時覺得這說明我為專案增添了價值。但實際上，這證明我建立的是依賴關係，而不是能力。工程師們並非因為我的判斷力更強才聽我的，而是因為我從未建立起考驗他們判斷力的文化。當我退居幕後時，決策並沒有變得更容易，反而變得更慢，也更不確定了。
正是這種模式讓我擔憂人工智慧工具在工程文化薄弱的環境中應用。當你不再自己做決策時，你就無法建立起評估他人決策（包括模型決策）的判斷力。
一位資深工程師給我講了一個故事，至今仍讓我記憶猶新。他多年來一直從事系統開發，後來轉而主要負責人工智慧代理的指令控制，之後卻遇到了生產環境中的記憶體問題，他這才意識到自己除錯的本能已經消失了。不是退化，而是完全喪失了。
ChatGPT出現後，像我以前管理的那種團隊顯然找到了替代的Oracle。界面不同，但底層問題依舊。
真正重要的是什麼
那些能夠充分利用人工智慧的團隊，早在人工智慧出現之前就已經做好了充分的準備工作。他們不需要人工智慧來告訴他們什麼是優秀，他們早已心知肚明。
他們有清晰的標準。不僅僅是程式碼檢查規則和風格指南……而是真正意義上的標準，它描述了決策是如何做出的，哪些權衡取捨至關重要，何時遵循模式，何時打破模式。這些標準體現在文件和實踐中。同一個人既能解釋為什麼某個東西是這樣建構的，也能解釋為什麼不應該那樣建構。這才是健全標準的標誌。
他們的審核文化注重審慎，在批准之前會深入探討。審核過程中，在勾選任何選項之前，都會追問「為什麼」。這種文化鼓勵提出異議，但又不會將問題上升到個人層面。初級工程師可以質疑高階工程師的決定，而資深工程師也可以坦誠承認自己的疏忽。權威不在於頭銜，而是決策背後的邏輯。
那些能夠充分利用人工智慧的團隊，早在人工智慧出現之前就已經做好了充分的準備工作。他們不需要人工智慧來告訴他們什麼是優秀，他們早已心知肚明。
他們的工程師能夠用自己的語言為決策辯護，而不是引用別人的建議或基準測試結果。他們會建構論證，權衡利弊，並解釋「這是我考慮過的因素，這是我的選擇，這是我正在觀察的，以判斷我的決定是否正確」。正是這種能力，使得人工智慧的輸出結果有用而非危險。
工具使用前的準備工作
如果你所領導的團隊正在採用人工智慧工具，那麼你需要問的問題不是使用率或生產力指標，而是判斷力。
你們的工程師能否評估模型產生的結果？他們是否具備區分好建議和壞建議的能力？他們能否解釋為什麼接受或拒絕人工智慧的建議，還是只是接受那些看起來合理的建議？
真正重要的工作發生在任何人打開工具之前。它包括你所製定的標準、你建立的評審文化，以及你花時間教導工程師思考而非僅僅執行。人工智慧並不會取代這些，它需要這些。
人工智慧並不能取代判斷力的建置，它需要判斷力的建構。
我自己也遇到過這種情況，當時我用的是 Cursor。打開它，花了十分鐘，然後就關掉了。它給的建議太多了，我根本來不及評估。每次按鍵都會產生一個新的選項，一個新的模式需要質疑，一個新的決定需要做出。這根本沒用，反而讓我應接不暇。
後來我才明白那是什麼意思。並非人工智慧不好，而是我需要更清楚地了解自己想要什麼，才能更好地利用它。能夠在這次轉型中脫穎而出的團隊，正是那些能夠辨識出這個訊號的團隊。
這才是真正的問題
我的朋友在電話裡並不擔心公司是否在使用人工智慧，他擔心的是他們期望人工智慧解決什麼問題。幾十年來累積的協調問題並不會因為工具的改進而消失。
人工智慧並不能彌補工程技術的不足，它只是加快了工程速度。
每個團隊都要面對的問題是：這是否是你想要的？你們的基礎架構能否承受這種加速？你們的工程師能否在不偏離真正重要事項的前提下，更快地進行評估？
如果人工智慧能夠勝任，它就能帶來倍增效應。如果不能，它只會更快地產生與你之前遇到的問題相同的結果。
這才是真正值得探討的話題，不是是否要使用人工智慧，而是你是否準備好迎接它將放大的影響。
每週一封來自「建設者領導者」的郵件。內容涵蓋領導者常迴避的框架、盲點和對話。免費訂閱。
原文出處：https://dev.to/jonoherrington/ai-doesnt-fix-weak-engineering-it-just-speeds-it-up-5bak
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
