组里的designer总抢着写代码怎么办

匿名用户 发表于 2026-10-7 10:28
我怕出了事最后还是我修，不明真相的人，很可能以为是我的锅，毕竟现在这个烂摊子是我一个人own了。

这种最好了，既显示了你的ownership和responsibility，又highlight了root cause是designer checkin AI slop。你只需要包揽SEV investigation和review，在root cause analysis里高亮显示who landed which diff without eng approval causing what，然后你是如何给擦屁股的，全程只是陈述事实不需要批评，搞几次designer基本上无了

匿名用户 发表于 2026-10-07 10:45:39
我司 PM 可以 merge 代码。他天天 vibe code。有些仓库有意无意地不要求 PR review...

建议你反馈给repo的owner，把权限收紧一些

xxpxxxxp 发表于 2026-10-07 10:49:15
这种最好了，既显示了你的ownership和responsibility，又highlight了root cause是designer checkin AI s

我感觉每次我修别人的bug和sev，组里的人默认是我出的问题，即便是我有说清楚是别人的代码，出了问题很多时候都会算到我身上。也不知道是不是我错觉。

匿名用户 发表于 2026-10-07 10:45:39
我司 PM 可以 merge 代码。他天天 vibe code。有些仓库有意无意地不要求 PR review...

如果没有review那就是这样啊。。你们自己觉得不重要无所谓的

匿名用户 发表于 2026-10-07 09:57:50
明白了，但是怎么能量化？是不是可以把这个人写的那部分代码里的slop 用AI扫一遍，file成task，明确标出来是现存的问题需要de-slopify，再用AI

不要针对这个人，你可以把这两个half所有diff扫一遍，总结一些anti pattern，弄成skills之类的，可以adhoc算ets之类的东西。

匿名用户 发表于 2026-10-07 09:57:50
明白了，但是怎么能量化？是不是可以把这个人写的那部分代码里的slop 用AI扫一遍，file成task，明确标出来是现存的问题需要de-slopify，再用AI

如果有sev concern的话可以说预防了多少sev，如果per diff 的workflow上线了推广到org就是更大的impact了。

solored 发表于 2026-10-07 11:21:44
不要针对这个人，你可以把这两个half所有diff扫一遍，总结一些anti pattern，弄成skills之类的，可以adhoc算ets之类的东西。

原来可以这样，太厉害了，感谢！

你为啥不跟你mgr讲这个事儿你不讲他就默认你们俩没有任何问题合作愉快

那他写的东西以后有问题他负责修吗? 他负责oncall吗? 不负责的话你去他的scope也搞点活做呗

问题很大啊，倒不是谁写代码这种小事，而是你em居然同意ta写，感觉你和你em都不罩你
跑吧，没什么好纠结的了