※ 引述《kkll7952 (KO)》之銘言：
: 推 widec: AI coding到底要怎麼看吶...量那麼大 以後更是指數的量 08/02 14:56
: → widec: 還不如想辦法建立驗證機制 測試再測試 08/02 14:56
這部分我分享一下我的經驗 :)
1. 以前寫測試程式的時候，
因為每次測試系統要在一個虛擬的環境下開啟多個程序，寫測試程式其實很麻煩。
有AI之後，我可以專心地想我想要測什麼，
然後把那些不算難懂但複雜的細節交給AI。
2. 所以，Review的時候，測試的程式碼會相當多，
而這邊我覺得現在是Review最核心的環節，
因為這個可以確保程式一定程度內在規格下運行
3. 也因此，現在大家Review對測試程式的要求會比較高。
我以前不太敢、但現在很敢做的是：
如果覺得測試程式沒有很好懂的話，我會請作者改到我覺得好懂為止
畢竟現在有AI了，我覺得修改是很容易的事情。
4. Product Code 的部份....
這部分我也是～如果我真心覺得很難懂的話，我會跟作者說哪部分難懂，
請他改到我覺得好懂為止XD
因為...理由一樣 現在有AI了，修改應該是很容易的事情。
5. 有人可能有問題了：
那如果一個PR在Product Code的部分改了幾千行，
怎麼看都沒很好懂啊？
這是一個常見的情況，但我和我的不少我的同事是在想：
作者應該要可以把這個大任務分成更小的幾個commit，
而不是無腦地把他想要的事情交給AI之後把東西丟出來，
就認為Review有義務去看這一大陀code然後跟他說該怎麼樣改
但這個我不太敢太造次，
因為我自己幹過幾次這種「讓code變成幾個小commit」，
但是...有時候一開始會想錯，導致邊界訂出來其實程式做不到。
這就會讓AI花超級多時間做沒有用的事情。
6. 這個「AI生成超級多行code」在我們公司有另一個困境：
(1) 把需求交給AI，讓AI寫出你要的code，還保證能跑過那些測試，
這樣生成程式碼可以大幅提升速度。這大家都懂
(2) 但有很資深、真的很資深的Tech Lead表明他的態度是：
你交出PR的時候，就表示你有把你寫的程式每一行都看完，
而且你覺得這樣的東西可以被其他人維護
那要求看起來有點嚴苛，但是也不能說太沒道理。
因為我們的產品，一個Team改的東西弄爛另外一個Team的東西很常見。
更重要的是，我們的產品交到客戶手上如果有問題，
「重灌」是不可能接受的選項，而且如果系統沒辦法跑下去，
當天睡覺前一定要能至少讓客戶系統又能繼續運作，
(不然我猜大概要有一個Team每2小時要回報了)
而你並不是每一次都像在公司裏面，什麼log都在自己手上，
想要的時候還可以爽加一堆用來測試。
很多時候是必須要在有限的log裡面去猜測然後嘗試重現問題
所以目前還處於「程式碼一定要人能夠維護，而不是AI修不好就宣告放棄」的情況
不過AI對我這種不是 CS本科 的人來說真是滿方便的 :)
相比以前，我現在可以花心思在系統結構和產品邏輯上

原則上還是要 Human in the loop

以前碼農看起來工時很長，但大部分時間都不是高階決策，現在agent時代，agent開一堆同時運行反而要頻繁做出很重要的系統高階決策反而累非常多，Tibo reset後還要趕緊起床工作沒有AI的時代就是東翻翻西找找看有沒有source code可抄，上論壇和人筆戰，順便打混摸魚根本沒差最痛苦的大概就是deadline要到了，趕鴨子上架現在可以說，Codex Sol Max還在跑啦

感覺AI時代 還得維護大型codebase會很痛苦 我是有幸能避免

原則是這麼說, 但以現在AI的產能實務上不可能每行真的看完, 都是直接丟實測現在就是等看這些沒辦法人工維護的code會先炸, 還是未來AI先發展到連這些都補的起來

我個人看到幾千行的大PR幾乎都是打槍 請拆成小PR慢慢看之前的經驗 那種幾千行的東西"作者"自己也是不會細看的真的展開來慢慢看會發現AI寫了很多冗餘的東西我是專門卡既有產品啦XD 有些同事後來就去搞另一個新專案最近聽說新專案超級屎山化 要重新制定review規則 嘻嘻