我最近一位朋友參加了一場關於工程團隊如何更好支持工程師的公開論壇，討論中出現的主題並不令人意外：
犧牲品質讓人難以對工作感到驕傲，沒有人承認目前的開發速度。如果我們用衝刺的方式交付，期望就會變成永遠持續衝刺。
我聽過這種說法已經有一段時間了，但現在我也開始聽到並同意「AI並不總是讓我們更快」這種觀點。
過去開發者會用Google搜尋，閱讀StackOverflow的答案、文章或GitHub問題，做一些研究，並根據自己的情境驗證後得出結論。沒有人會說「Google幫我寫的」或「因為它是第一個結果所以一定正確」。
但現在我開始聽到「AI幫我做了」這種說法。
這要麼是過度誇大了發生的事情，要麼代表開發者沒有自己得出結論。兩者都不好。如果我團隊裡有人說他們的程式碼是Google寫的，因為他們複製了StackOverflow的答案，我會擔心同樣的問題：你真的理解你貼上的東西嗎？
隨興編碼一開始很有趣。對於原型設計或低風險的個人專案很有用。但當風險變得真實，每一行程式碼都有後果。
我在一個個人專案中，請AI代理幫我在特定檔案新增測試。該檔案請求前有500行，請求後只剩100行。我問它為什麼刪掉其他內容，它說沒有。接著又說該檔案之前不存在。我給它看git歷史，它道歉了，說應該先檢查檔案是否存在。（謝謝git）
現在想像這種情況發生在醫療保健的程式碼庫，而不是個人專案。
AI輔助有時花費的時間比節省的還多。這聽起來很反直覺，但這就是我遇到的情況。我花更多時間和代理爭論並恢復檔案，反而比自己寫測試還久。
把AI當作調查工具，而不是直接跳到AI解決方案提供者，是有些人會跳過的一步。AI輔助調查是一項被低估且不容易的技能，需要練習才能知道AI何時出錯。使用AI生成的程式碼可以有效，但如果我們把更多簡單的寫碼任務交給AI，就可能陷入AI輔助花費的時間比節省還多的陷阱。
大多數人忽略了AI輔助開發的這點。寫程式碼是工作中簡單的部分，從來都是。困難的是調查、理解背景、驗證假設，以及知道為何某種方法適合當前情境。當你把簡單的部分交給AI，你並沒有減少工作量，而是只剩下困難的工作。如果你因為AI已經給了答案而跳過調查，你就沒有足夠的背景去評估它給你的結果。
閱讀並理解別人的程式碼比寫程式碼困難得多。AI生成的程式碼就是別人的程式碼。所以我們把開發者擅長的寫作部分交給機器，自己只剩下更難的閱讀與審查，卻沒有透過自己寫作累積的背景知識。
我朋友的論壇提出一個我一直在思考的觀點：如果我們用衝刺方式交付，期望就會變成永遠持續衝刺。疲憊的工程師會忽略邊緣案例，跳過測試，釋出有缺陷的程式碼。更多事故，更多壓力，更多衝刺。這會自我惡化。
這是管理問題，不是工程問題。當領導看到團隊曾經快速交付（可能有AI幫忙，也可能沒有），那就成為新的基準。討論從「他們怎麼做到的？」變成「為什麼他們不能每次都做到？」
當有人聲稱AI讓他們的生產力提升10倍，也許他們只是從0.1倍工程師變成1倍工程師。技術上是10倍提升，但問題是這是生產力的提升，還是暴露出他們之前調查做得很少。
倦怠和草率交付會吞噬AI帶來的任何生產力提升。你無法透過優化解決人們太累而無法清晰思考的問題。
我用「AI是資深技能，初級信任」這句話來形容AI編碼代理的運作方式。它們寫程式碼非常厲害，但我們必須像信任初級工程師一樣信任它們的輸出。程式碼看起來不錯且可能可用，但我們應該更仔細檢查，因為它們沒有經驗。
換個角度看：AI編碼代理就像一個閱讀速度極快、剛走進門的天才。他們可以協助調查，也能寫一些程式碼，但他們沒參加上週討論重要背景和脈絡的會議。
開發者必須對每一行交付的程式碼負起負責任的擁有權，不只是自己寫的，AI生成的也一樣。
如果你因為有人設定不切實際的速度目標而複製貼上AI輸出，六個月後新成員試圖理解程式碼時會有問題，或是凌晨兩點程式碼出錯時也會有問題。「AI寫的」這句話在這兩種情況下都幫不了你。
前幾天發生一個生產環境的錯誤。使用者在大版本釋出後幾小時向客服團隊詢問，發現一個邊緣案例的時區顯示錯誤。修改程式的工程師離開前還有30分鐘要去教課，我已經在家了。我用AI協助調查，告訴它錯誤必須基於最近的變更，並解釋如何重現。結果發現一些已棄用的方法優先於目前的時區感知方法，導致時區轉換錯誤。15分鐘內我找出根本原因、解決方案構想和調查筆記，寫在GitHub議題中。工程師確認修正，其他人測試並部署，我則去拿晚餐。
沒有火警演習，沒有加班。AI做了調查的繁瑣工作，我提供背景並驗證，工程師確認解決方案。這就是AI幫助處理困難部分的例子。
AI編碼代理速度快，但它不知道你知道的事。沒有事先規劃，代理會自信地基於錯誤假設搭建整個架構，而你可能不會注意到。
我們都曾在聊天機器人和編碼代理中遇過讓人停止信任第一個答案的時刻，從過度吹捧、編造事實到偏離主題。這就是為什麼有時我們需要……