Regressions are bad and they should be avoided. Still, software engineering is a complex thing and regressions happened long time before coding agents were a thing. Unless one can pinpoint regression to changes that were more sloppy than the human-written rsync commits were I don't think coding agents are to blame.
Seems like that it's not that coding agents are to blame, its that the people who are ultimately responsible for committing and merging the offending code are to blame, regardless of its origin.
Or they are to blame because fixing 1000 CVE's doesn't magically absolve one of responsibility for regression bugs, even if one "accepts" them as a psychological salve.
If you are entitled enough then they are to blame they didn't fix everything at once, but in that case you really should be paying for their product and support. Otherwise fixing security issues has high enough priority to accept there might be downstream bugs that will be fixed in due course.
Would you hold off on fixing a security vulnerability if it caused a limited regression?
Regressions should be fixed expediently, but if you apply the criteria "need to not happen" they are literally blocking issues. They could then block security fixes.
Which part of security fixing demands thoughtless generation of code slop without regression testing though?
I worked on major OSS projects and we never just blindly pushed out untested poor quality code for security fixes since that adds WORSE security regressions.
The methodology describes the effort you may be putting into something, The outcomes are about what results are you prepared to accept.
Would you ship an update with a security fix if it had been thoroughly tested was shown to have certain regressions but no worse security regressions? Would you refuse to fix the security issue until you could do so without any degradation?
It's clear that people can and do accept regressions for security updates. Spectre mitigations cause performance regressions. SharedArrayBuffer got taken away for a while. Being absolutist about things seldom helps.
I agree due care should be taken where possible, but I'm also prepared to accept that mistakes can happen even when people have worked diligently to find issues.
Since you have worked on major OSS projects. Have any of them shipped regressions unintentionally? Right now that is the only thing we have to go on, that these things happened. The degree of care taken is an unknown, as is the degree of LLM involvement. We might know more in a week or two.
If you want to condemn something based upon what might have happened you can specifically state what you think shouldn't happen, and that will stand regardless of whether or not it applies to the current incident.
Obviously "Thoughtless generation of code slop without regression testing" is unacceptable, but that is because the conclusion is written into the statement by saying "thoughtless" "slop" and "without regression testing"
If tridge says 'I gave it thought, I don't agree that it is slop, and I did regression testing' then you have nothing further to complain about, because the incident does not fall under the criteria you specified.
It's saying 'things that are bad, are bad'. The defence is to say 'well, this isn't bad'
> ...if it had been thoroughly tested was shown to have certain regressions but no worse security regressions?
You'd have to test to know this, and there is no evidence that tridge did this regression testing - or ask Claude to find possible regressions caused by proposed changes. If tridge did test for regressions, but chose not to document the regression, then it's still negligence, regardless of the tools pr processes involved.
Are you saying that it is irresponsible to test for regressions and to not document the ones you didn't find or that you think it is reasonable to expect regression tests for every possible regression?
What were you trying to say? Because what you wrote is what parent responded to.
> there is no evidence that tridge did this regression testing
What evidence would you be looking for? New tests, like the ones added in the AI-assisted commits? What other evidence?
> If tridge did test for regressions, but chose not to document the regression
Presumably you weren't trying to imply here that tridge found a regression and decided to ship the code anyway; so parent went to a natural assumption - do you think testing for regressions finds all regressions?
Gitcoin's approach thus far has been to stop collusion from unsophisticated actors, then progressively get more organized (as more money gets involved, and as we learn from each round) about stopping collusion from more sophisticated actors.
reply