The way that this is written strikes me as wildly over-optimistic and dangerously credulous towards slopmongers' claims about capabilities.

[glyph@mastodon.social]

@mcc re: the blocklist, I think that it's something that would need to be handled very carefully, as we have previously seen that Making Lists can get us all into trouble very fast. but there's probably a way to do it without turning it into a professional blackball machine when the hype rebounds

[mcc@mastodon.social]

@glyph codeberg could probably be persuaded to add this if they got a PR for it. especially if you want a complex Jira-like flow like that, even if they had the time to architect it out they probably would not come up with the exact design you're looking for.

[pathunstrom@ngmx.com]

@mcc @glyph I feel like I might need to make a corollary to the Olivia Hill rule.

[benjamineskola@hachyderm.io]

@glyph It often feels to me like this relates to a broader problem around boundaries.

Like the smaller scope is what feels to me (subjectively, maybe confirmation bias) like people keep pushing non-users to reconsider trying LLMs. The new model is better, your objections are out of date.

(And obviously the scale of that for a maintainer is likely to be much worse anyway.)

But that in turn also makes me think of the deceptive/coercive patterns of ‘not now’ or ‘maybe later’ where no is never an option; your refusal is always open to reconsideration.

[mttaggart@infosec.exchange]

@glyph I don't disagree on principle, but how do you imagine a hard ban (such as the one I just implemented for IFIN) be enforced? I don't know how you do it other than only accepting PRs from known, trusted members of a community and not the internet at large. Like you need some sort of filtering process if you actually want to ban generative code, and the filter probably won't be anything like a code smell for long.