There is a saying in Russian that sounds something like “one little claw is stuck means the whole bird gets eaten”. In other words, slop, not even once.
I have an old collegue that I meet about once a year. A year ago he was all about using it responsibly and stuff, this year we started arguing about merits of slop, and in the middle of conversation he opened a phone, asked a bot for more arguments, and read the response verbatim.
The saying applies to the “bird”, meaning the person using language models to generate code, not to the projects that code is contributed to. The risk of sliding into overreliance and dependency on machine-generated code is real and part of the reason I staunchly refuse to try it, but it’s not the responsibility of the maintainers of the project to guard its contributors against their own lack of care.
The project maintainers only care about the quality of their contributions, so that is the target we should judge the policy by.
We know that AI “guardrails” are about as reliable as the models they’re supposed to guard. So instead, we need human safeguards in place to hold the result, whatever its origin, to a high standard.
In that spirit, the KDE contributor guide makes it clear that you need to be able to own and explain the code and answer any questions, “even if it originates from the internet, an LLM, a friend, or your pet lizard.” Whether that slop is natural or artificial in origin matters less than the fact that it’s slop.
There is also a provision for dealing with unvetted contributions: “Throwing code over the wall” explicitly uses the example of “relying on an LLM to generate a patch, and then trying to get it merged without understanding the actual changes” and encourages maintainers to reject such requests.
So by these policies, if that proverbial bird gets stuck and stops delivering useful contributions, their slop should be rejected. Whether they use a text generator to produce arguments why it should be accepted doesn’t matter if it’s unacceptable.
There is a saying in Russian that sounds something like “one little claw is stuck means the whole bird gets eaten”. In other words, slop, not even once.
I have an old collegue that I meet about once a year. A year ago he was all about using it responsibly and stuff, this year we started arguing about merits of slop, and in the middle of conversation he opened a phone, asked a bot for more arguments, and read the response verbatim.
The saying applies to the “bird”, meaning the person using language models to generate code, not to the projects that code is contributed to. The risk of sliding into overreliance and dependency on machine-generated code is real and part of the reason I staunchly refuse to try it, but it’s not the responsibility of the maintainers of the project to guard its contributors against their own lack of care.
The project maintainers only care about the quality of their contributions, so that is the target we should judge the policy by.
We know that AI “guardrails” are about as reliable as the models they’re supposed to guard. So instead, we need human safeguards in place to hold the result, whatever its origin, to a high standard.
In that spirit, the KDE contributor guide makes it clear that you need to be able to own and explain the code and answer any questions, “even if it originates from the internet, an LLM, a friend, or your pet lizard.” Whether that slop is natural or artificial in origin matters less than the fact that it’s slop.
There is also a provision for dealing with unvetted contributions: “Throwing code over the wall” explicitly uses the example of “relying on an LLM to generate a patch, and then trying to get it merged without understanding the actual changes” and encourages maintainers to reject such requests.
So by these policies, if that proverbial bird gets stuck and stops delivering useful contributions, their slop should be rejected. Whether they use a text generator to produce arguments why it should be accepted doesn’t matter if it’s unacceptable.