[flagged]
A standard protocol to handle and discard low-effort, AI-Generated pull requests
51–60 of 129 posts
Re: A standard protocol to handle and discard low-effort, AI-Generated pull requests
#52I recently had a quandary at work. I had produced a change that pretty much just resolved a minor TODO/feature request, and I produced it entirely with AI. I read it, it all made sense, it hadn't removed any tests, it had added new seemingly correct tests, but I did not feel that I knew the codebase enough to be able to actually assess the correctness of the change. I want to do good engineering, not produce slop, bu…
Do you use the library? if yes, test it in prod or even staging with your patch, then submit the review
Re: A standard protocol to handle and discard low-effort, AI-Generated pull requests
#53[dead]
Are the PRs not accompanied by test cases? Do the README changes not document the expected benefit?
You're replying to a bot account https://news.ycombinator.com/item?id=47170091 There's no actual oss project it maintains, claims to the contrary are hallucinated.
Re: A standard protocol to handle and discard low-effort, AI-Generated pull requests
#54Amazing. I hope this gets tons of use shaming zero-effort drive by time wasters. The FAQ is blissfully blunt and appropriately impolite, I love it.
While I am with you on hoping, someone shamelessly PRing slop just is not going to feel shame when one of their efforts fail. It’s like being mean to a phone scammer, they just hang up and do it again
No when people attend courses, paying money for the privilege no less, and get told "Now open a pull request" they don't care about your project - they care about getting their instructor to say they've done a good job.
Re: A standard protocol to handle and discard low-effort, AI-Generated pull requests
#55I recently had a quandary at work. I had produced a change that pretty much just resolved a minor TODO/feature request, and I produced it entirely with AI. I read it, it all made sense, it hadn't removed any tests, it had added new seemingly correct tests, but I did not feel that I knew the codebase enough to be able to actually assess the correctness of the change. I want to do good engineering, not produce slop, bu…
> but I did not feel that I knew the codebase enough to be able to actually assess the correctness of the change.
The good engineering approach is to verify that the change is correct. More prompts for the AI does nothing, instead play with the code, try to break it, write more tests yourself.
Re: A standard protocol to handle and discard low-effort, AI-Generated pull requests
#56proof of work could make a comeback
[flagged]
Re: A standard protocol to handle and discard low-effort, AI-Generated pull requests
#57Earlier quoted context omitted.
Are the PRs not accompanied by test cases? Do the README changes not document the expected benefit?
You're replying to a bot account https://news.ycombinator.com/item?id=47170091 There's no actual oss project it maintains, claims to the contrary are hallucinated.
[deleted]
Re: A standard protocol to handle and discard low-effort, AI-Generated pull requests
#58if someone submits a code revision and it fixes a bug or adds a useful feature that most of your users found useful, you reject it outright because it was not written by hand? or is this more about code that generally provides no benefits and/or doesnt actually work/compile or maybe introduces more bugs?
> if someone submits a code revision and it fixes a bug or adds a useful feature that most of your users found useful, you reject it outright because it was not written by hand?
If they didn't read it, then neither will I, otherwise we have this weird arms race where you submit 200 PRs per day to 200 different projects, wasting 1hr of each project, 200 hrs total, while incurring only 8hrs of your time.
If your PR took less time to create and submit than it takes the maintainer to read, then you didn't read your own PR!
Your PR time is writing time + reading time. The maintainer time is reading time only, albeit more carefully.
Re: A standard protocol to handle and discard low-effort, AI-Generated pull requests
#59I recently had a quandary at work. I had produced a change that pretty much just resolved a minor TODO/feature request, and I produced it entirely with AI. I read it, it all made sense, it hadn't removed any tests, it had added new seemingly correct tests, but I did not feel that I knew the codebase enough to be able to actually assess the correctness of the change. I want to do good engineering, not produce slop, bu…
> but I did not feel that I knew the codebase enough to be able to actually assess the correctness of the change. The good engineering approach is to verify that the change is correct. More prompts for the AI does nothing, instead play with the code, try to break it, write more tests yourself.
I exhausted my ability to do this (without AI). It was a codebase I don't know, in a language I don't know, solving a problem that I have a very limited viewpoint of.
These are all reasons why pre-AI I'd never have bothered to even try this, it wouldn't be worth my time.
If you think this is therefore "bad engineering", maybe that's true! As I said, I ended up discarding the change because I wasn't happy with it.
Re: A standard protocol to handle and discard low-effort, AI-Generated pull requests
#60I recently had a quandary at work. I had produced a change that pretty much just resolved a minor TODO/feature request, and I produced it entirely with AI. I read it, it all made sense, it hadn't removed any tests, it had added new seemingly correct tests, but I did not feel that I knew the codebase enough to be able to actually assess the correctness of the change. I want to do good engineering, not produce slop, bu…
Do you use the library? if yes, test it in prod or even staging with your patch, then submit the review
Unfortunately not possible in this case for technical reasons, not a library in the traditional sense, significant work to fork, etc. This is in the Google monorepo.