※ 引述《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规则 嘻嘻