That is pretty horrible, on the level of "junior engineer" who has no idea of good industry practices and needs careful code review. I would hate to see the system as presented on any of my projects.
Summary: The point of summary is to tell "why" the change was made and highlight unusual/non-trivial parts.. and examples absolutely fails there. To look at first one:
- Why was "generate" result type updated? Was it customer request or general cleanup or prep for some ongoing work?
- The other 3 points - are they logic fallout of output type update, or are those separate changes? For latter case, you really want to list the changes ("Updated examples to use more recent gpt-4 model" for example)
- What's the point of just saying "updating X in Y" if you don't say how? this is just visual noise duplicating "file changes" tab in the PR.
- This is an example file and you know where the "dataset" comes from. Why would you have non-serializeable records to begin with?
- This changes semantics from "let programmer know in case of error" to "produce corrupted/truncated data file in case of error" - which generally makes debugging harder and gives people nasty surprises when their file is somehow missing records. Sure, sometimes this is needed, but in that particular file it's all downsides. This should not have been proposed at all.
- Even if you do want the check somehow, it's pretty terrible as written - the message does not include original error text nor bad object nor even line number. What is one supposed to do if they see it?
----
And I know some people say "you are supposed to review AI-generated content before submitted", but I am also sure many new users will think the kind of crap advice that AI generates is OK.
Ellipsis authors: please stop making open source worse. Buggy patches are worse than no patches, and 1 line hand-written summary is better then AI-generated useless one.
Maintainers: don't install this in your repo if you don't want crap PRs.
I came here to find and agree with this comment. I've been seeing more stuff like this show up recently in OSS projects and it is extremely irritating.
And I know some people say "you are supposed to review AI-generated content before submitted", but I am also sure many new users will think the kind of crap advice that AI generates is OK.
Those who don't know better, think AI is awesome and will solve all their problems. Those who do know enough to see the flaws don't need AI either.
Ellipsis authors: please stop making open source worse. Buggy patches are worse than no patches, and 1 line hand-written summary is better then AI-generated useless one.
I'll extend that to say "please stop making software worse." We were already drowning in mediocrity before AI accelerated it.
And I know some people say "you are supposed to review AI-generated content before submitted", but I am also sure many new users will think the kind of crap advice that AI generates is OK.
We're watching development of idiocracy in real time. It'll start with "yeah, we're reviewing every content it generates" until new generation will stop thinking for itself completely and PRs will switch from machine-sceptic to "who are you to argue against computer?" (and not because machine became so good it's better than human).
Comments
That is pretty horrible, on the level of "junior engineer" who has no idea of good industry practices and needs careful code review. I would hate to see the system as presented on any of my projects.
Summary: The point of summary is to tell "why" the change was made and highlight unusual/non-trivial parts.. and examples absolutely fails there. To look at first one:
- Why was "generate" result type updated? Was it customer request or general cleanup or prep for some ongoing work?
- The other 3 points - are they logic fallout of output type update, or are those separate changes? For latter case, you really want to list the changes ("Updated examples to use more recent gpt-4 model" for example)
- What's the point of just saying "updating X in Y" if you don't say how? this is just visual noise duplicating "file changes" tab in the PR.
Suggested changes: those are even worse - like https://github.com/relari-ai/continuous-eval/pull/38#discuss...
- This is an example file and you know where the "dataset" comes from. Why would you have non-serializeable records to begin with?
- This changes semantics from "let programmer know in case of error" to "produce corrupted/truncated data file in case of error" - which generally makes debugging harder and gives people nasty surprises when their file is somehow missing records. Sure, sometimes this is needed, but in that particular file it's all downsides. This should not have been proposed at all.
- Even if you do want the check somehow, it's pretty terrible as written - the message does not include original error text nor bad object nor even line number. What is one supposed to do if they see it?
----
And I know some people say "you are supposed to review AI-generated content before submitted", but I am also sure many new users will think the kind of crap advice that AI generates is OK.
Ellipsis authors: please stop making open source worse. Buggy patches are worse than no patches, and 1 line hand-written summary is better then AI-generated useless one.
Maintainers: don't install this in your repo if you don't want crap PRs.
I came here to find and agree with this comment. I've been seeing more stuff like this show up recently in OSS projects and it is extremely irritating.
And I know some people say "you are supposed to review AI-generated content before submitted", but I am also sure many new users will think the kind of crap advice that AI generates is OK.
Those who don't know better, think AI is awesome and will solve all their problems. Those who do know enough to see the flaws don't need AI either.
Ellipsis authors: please stop making open source worse. Buggy patches are worse than no patches, and 1 line hand-written summary is better then AI-generated useless one.
I'll extend that to say "please stop making software worse." We were already drowning in mediocrity before AI accelerated it.
We're watching development of idiocracy in real time. It'll start with "yeah, we're reviewing every content it generates" until new generation will stop thinking for itself completely and PRs will switch from machine-sceptic to "who are you to argue against computer?" (and not because machine became so good it's better than human).