4 ms·
That only works if you're not personally responsible for the code you review, too.
by ffsm8 1y ago
That only works if you're not personally responsible for the code you review, too.
- throwup238 1y agoJust don’t give the AI agent an “approve_pr” tool. It can only comment or reject.
- kortilla 1y agoBut then what? At the end it’s still on you to approve and you have no idea what is hiding in the code.
- jjcob 1y agoYou don't approve it. You just slowly grind the submitter down with minor feedback. At some point they lose interest and after a year you can close the PR, or ask the submitter to open a new PR.
- adastra22 1y agoI hope you don’t actually do this to people.
- lukan 1y agoIf people do this to him? How else to react? The context here is lots of vibe coded garbage thrown at the reviewer.
- jjcob 1y agoIt works best if you don't reply immediately. I recommend successively increasing the response delay. Keep it short enough to make sure that they don't start bugging you on other channels, but long enough to make sure they have time to cool down and question if the continued effort is really worth it. As long as the response delay increases at least geometrically, there is a finite bound to the amount of work required to deal with a pull request that you will never merge.
- oarsinsync 1y agoTragically, when you are organisationally impaired from saying 'no', this is the only way (besides, you know, quitting and getting a new job). It's absolutely soul crushing when you're motivated to do a good job, but have a few colleagues around you that have differing priorities, and aren't empowered to do the right thing, even when management agrees with you.
- adastra22 1y agoI am both an open source maintainer and contributor. This is absolutely despicable behavior. You are purposefully wasting the time of a contributor for no other reason than your own fear of saying “no.” If you’re not going to merge something, just ficking say so.
- thunderfork 1y agoIf you've read the thread, the strategy you're replying to is about a workplace scenario where outright rejection is, for whatever reason, forbidden; not an open source situation where "no" is readily available.
- adastra22 1y agoIt makes even less sense in a work context either. This behavior will permanently alienate this user & potential customer. I’ve seen this exact scenario play out many times before.
- xigoi 1y ago
- estimator7292 1y agoWhy would it be acceptable for the sumbitter to behave this way and not the reviewer? We do have AI "assisted" submitters behaving exactly like this and acting irate when forced to actually reflect on the turd they're trying to shove into my inbox
- Hamuko 1y agoIf they're okay with vibe-coded code, they should be fine with vibe-coded reviews too. You really only should be in a situation where you have more responsibility over your reviews than other people have for their code if you're in charge, and if you're in charge, just ban the practice.
- stevula 1y agoThe problem is other people/teams making PRs to your code that you then have to maintain or fix later. It’s in your interest not to half-ass the review, creating an asymmetric amount of work for you vs them.