What counts as "AI Slop"?

stephan: > However, I now noticed that GitHub offers Copilot code review. I want to try that out on my code base before publishing, maybe it can find something I haven’t noticed. Would my app count as AI slop then? What’s the threshold to “AI slop”? Using a Copilot review is a blocker in a submission PR. As for the “AI slop” threshold in general: A lot of submissions nowadays are done in a few days by likely inexperienced people who relied heavily on their chatbots to create an sort-of working small application. While that may work for an app you only intend to use on your personal computer, it definitely is not working for Flathub. Publishing to Flathub means you give an software to many different people, who all will expect a qualitive application that they can keep using. So that means an application needs to not just have code that “works for me”. It needs to have enough quality to work for a new user. And, quite importantly, the project should be able to be maintained over a long timespan. You will need the capacity to resolve issues user will have. You will need to regularly update your dependencies and runtime. And you need a project structure that can invite new contributors if your an open-source project. Publishing an application to any software store should be taken seriously. And, well, people who push an app quickly cobbled together by an chatbot and immediately submitting it, well they either don’t understand this or are willfully negligent about that. And we’re at the point where we are simply exhausted by all this slop. Which is why the rules are now “you can’t use AI to create your software”. So, main point would be, you’d better be of avoiding Copilot reviews. stephan: > I originally wanted to merge all current commits into a single commit because they all represent intermediate states and contain some debug code and mistakes that I prefer not to show publicly. But I’m afraid that if I compress all commits into a single large one, it would also be a strong sign for “AI slop”. Well, having immediate states, debug code and mistakes are part of the developing process. With any real project you will have small steps, you will have mistakes to fix, etc. I don’t think that is something you need to hide. We all work through mistakes and small steps to build our software and learn our craft in the process. There can be reason to rebase your commits. Sometimes it can make sense to only have one commit that adds a new function and squashing the commit that fixed a typo into that one. But commits should give a history of development. One that can be used to understand how an application was build. By us reviewers, by new contributors trying to learn your codebase, or maybe yourself in a few years time. So, what I would say: If you want to restructure you commits for better clarity, you can. But there is no reason to hide how you developed your software by compressing it into one commit. If you are proud of what your development has resulted in, you can be proud of the process that lead to it as well.