前一陣子因應 rsync 專案在引入 AI 代寫的程式碼後，釋出的新版本出現部份功能故障的事故。主掌 rsync 開發、同時也是知名開發者的 Andrew Tridgell，發表了一篇文章《rsync and outrage》，一方面向使用者致歉，不過另一方面也捍衛自己的立場，認為導入 AI 工具來修補程式碼是勢在必行。Tridgell 表示自己已經算是退休人士了，之所以決定導入 AI，是評估此舉能夠更有效率地修補 rsync 的安全性。至於 AI 所引致的缺失未被發現到，則是過去的軟體測試規劃未盡完善所致，已經務實地做出檢討並進行補強。並且在另一篇文章《rsync 3.4.4 released, life in the security trenches》裡，有更進一步的說明。
網路上對此事件的反饋，可見於例如 OSnews 及 LWN.net 等網站的訪客評論。然而由於畢竟這是別人開發的軟體專案，DR 不過就是終端使用者而已，所以東西若能用、好用、可以繼續用就好。至於背後怎麼維護，只要有人願意承擔責任，其實自己是沒有什麼負面的意見。不過這也讓人想起，在所謂的大型語言模型（Large Language Model，LLM）熱潮出現以前，其實人類對於自動化技術的追尋，早在更早的年代，比方說在機器翻譯（machine translation，簡稱機翻）問世時，就已出現過一輪爭議。
許多年以前，當 DR 還在出版社做資訊類書籍的編輯時，曾經有一次校稿，發現有一段內容的翻譯是錯的，而且能夠錯成這樣也讓人很狐疑。於是把原文丟上去 Google 翻譯，結果竟然得到完全一樣、一字不差的錯誤翻譯（在大模型的時代以前，機翻的結果往往是很一致的，很容易抓得出來）。由於譯稿是律定逐章交付初稿、並逐章審閱，這樣才能及時對內容做溝通，於是在抓出這件事情之後，就發信詢問交稿的譯者。實際上是一段很平和的信件互動，並沒有什麼言語上的衝突。譯者表示歉意，也詢問是否是不允許使用機器翻譯，DR 則回應沒有這個規範（而且實質上也無法有效地禁止），然而譯者有責任確保翻譯結果的正確性。今天會被抓出來，不是因為他使用機器翻譯，而是因為他提交了錯誤的翻譯。
至於其它的例子，也包含自己好像始終無法理解，為什麼會有人想要在中文維基百科提交品質低劣的機器翻譯──你如果不懂得怎麼翻譯，你可以不要翻，不要去編輯條目啊……並且由於維基百科的開放特性，這個問題從來沒有被真正消弭過。而追根究底來說，所有實現加速或自動化的工具往往都有正確與錯誤的用法，AI 也不例外。錯誤的用法，可能包含不願對產出的結果擔負責任，就隨意交付；或者是對於產出的好壞不具備辨識或排查能力。但反之，如果使用者能夠具備審慎為之的責任感，並願意付諸行動來加以確保，那麼至少在交付品質的層面上，應該還算是可以被人信賴的。