Read the actual post. The stance is much the same as the kernel’s: If your code is solid, it doesn’t much matter how it came about.
The idea is that good code shouldn’t be identifiable as LLM-generated. If it’s within the general variance of human coding styles, abides by standards and the logic is sound and humanly understandable, it’s practically impossible to prove that it’s AI anyway.
If your code reeks of AI slop, it’ll be rejected because nobody wants slop. You, not your tools, are responsible for the quality of your contribution.
That is very different from the “fuck quality, use LLM for the sake of using LLM” mentality Micro$lop are exhibiting.
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.
Humans are fallible. No matter how well you review the code. It would be good if AI code can be identified. The kind of mistakes might be very different from the kind of mistakes human do. So when something happened, it can be identified to be AI generated. That data can be used to get an idea of what kind of mistakes are being committed.
Read the actual post. The stance is much the same as the kernel’s: If your code is solid, it doesn’t much matter how it came about.
The idea is that good code shouldn’t be identifiable as LLM-generated. If it’s within the general variance of human coding styles, abides by standards and the logic is sound and humanly understandable, it’s practically impossible to prove that it’s AI anyway.
If your code reeks of AI slop, it’ll be rejected because nobody wants slop. You, not your tools, are responsible for the quality of your contribution.
That is very different from the “fuck quality, use LLM for the sake of using LLM” mentality Micro$lop are exhibiting.
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.
Humans are fallible. No matter how well you review the code. It would be good if AI code can be identified. The kind of mistakes might be very different from the kind of mistakes human do. So when something happened, it can be identified to be AI generated. That data can be used to get an idea of what kind of mistakes are being committed.
https://en.wikipedia.org/wiki/Entryism
Did you even look at that Wikipedia article you linked?