我在 2025 年的文章中提到的觀點依然成立：AI 最能嘉惠兩類人。第一類是運用 AI，讓生產力提高一倍甚至三倍的資深工程師；第二類是把 AI 當作學習工具的初階工程師。 不過，和 2025 年主管要求大家採用 AI，還要把所有程式碼變更都貼上「vibe-coded」標籤的情況不同，現在的風向已經完全反轉。如今，YouTube，至少是我所在的組織，開始提倡 程式碼「工匠精神」，並推動各種計畫來防止 AI 垃圾內容。
所謂 AI 垃圾內容，是指在缺乏充分監督下產生的程式碼變更（或設計文件），甚至未經妥善審查就直接發布。這與「工匠精神」恰恰相反；具備這種精神的作者會花時間理解自己的作品，並以此為傲。
這或許會讓人意外，因為 X 上的人似乎已經放棄審查程式碼，宣稱程式碼審查已死，還說審查成了軟體開發的新瓶頸，因此不該再審查程式碼。但 Google 和 YouTube 的情況顯然不是如此： 程式碼審查依然十分重要。不過，審查負擔確實增加了，對「AI 垃圾內容」的擔憂也隨之升高。
過去這一年，和人們一開始擔心軟體工程師會遭遇大規模裁員的情況相反，招募其實並未停止。我們的團隊規模甚至成長了一倍。隨著大量新人和應屆畢業生加入，「AI 垃圾內容」也再度湧現。 我最先是在設計文件中看到這種情況：文件通常又臭又長，塞滿各種術語。裡頭通常也沒什麼圖表，因為 AI 還做不出好的圖表，反而讓設計文件更難閱讀。有時我會指出某段看不懂的內容， 作者常常會說，他自己也不確定，因為那是 AI 寫的。
結果就是，身為審查者的我不再費心讀完每一個字。對於那些只有華麗標題、卻缺乏細節的設計替代方案，我會直接跳過；很多都是增加篇幅的膚淺想法。
新進員工用 AI 產生的程式碼也有同樣的問題：通常篇幅很長，尤其是單元測試。有時作者甚至很難解釋這些程式碼。
為了避免這些「AI 垃圾內容」，以及新進員工的淺層學習，公司提出了新的指導計畫。舉例來說，「反向跟隨」（reverse shadowing）是讓受指導者，也就是作者，透過線上會議向審查者解說程式碼， 以展現自己確實理解程式碼。「AI 配對程式設計」則是建議建立一個包含 AI 的三方群組對話，讓資深同事能旁聽 AI 對話，並即時修正設計方向。
「淺層學習」不只發生在初階工程師身上。現在，任何人都比以往更容易選擇走捷徑，照單全收 AI 提出的建議。我現在得經常提醒自己：每當 AI 提出我不完全理解的想法或程式碼時， 都要深入理解並仔細探究。這麼做不只是為了避免 AI 幻覺，也是為了找出隱藏的陷阱，並促進自己的技術成長。它的想法為什麼比我的好？採用這種方法有哪些優缺點？它適用於所有情況， 還是只適用於我提到的情境？我們不該把思考工作交給 AI，而是應該把 AI 當作學習和探索新點子的工具。