A slop inbox for open source projects

11 October 2026

Maintainers are having problems with slop contributions, especially if they like to keep their codebase human-written. Meanwhile, people like me are finding and fixing more bugs than ever because we can just direct our agents to do it. How can a software project manage this while upholding their values and staying sane?

Today, when I fix something I have a few options.

1. Just use it locally and keep the patch to myself.
2. Create a fork and put it on a git forge somewhere, with no particular expectation of maintaining it, probably falling behind upstream.
3. Try to send the fix upstream so that other people can benefit.

Upstreaming sounds most beneficial but it tends to be a bunch of work. Unless the project is already heavily into LLM workflows, maintainer time is a scarce resource and you want to do a lot of reading and verifying before you send something in. That’s assuming they’re open to including code that was AI-assisted in the first place, which is sometimes not the case.

I find myself in the situation where I have a bunch of patches sitting on my hard drive that I lack time or energy to upstream. It’s slop, but it’s validated slop—a specific problem was investigated, a specific fix was applied, and it seemed to work, at least for my use case. That has some value to developers or other users facing the same bug, even if it doesn’t meet the bar for direct inclusion.

What I think might help everyone is the concept of a slop inbox: a project could have a public dumping ground for anyone who’s messing around using LLMs. They can submit possible bugs, speculative patches, or essays written by Claude without any guarantee of quality or human validation. This would have several benefits.

• People who come across something interesting but don’t want to pursue it fully have somewhere to share their preliminary findings.
• Developers who are hostile to AI can ignore it entirely. This could even be the entire maintainer team.
• Traditional issues and PRs are reserved for high quality human-vetted material. There’s much less incentive to jam AI output in there if it has another home.
• Developers or potential contributors can keep an eye out for real problems or solutions in the slop inbox and take on the work of verification or polishing to bring it properly upstream.

Ideally it would be part of the code forge so LLM users can be steered away from the issue/PR section if that’s what a project wants. It could be a forum or mailing list. It just needs to be something that can be moderated for outright spam.

In theory you could tackle this from the other direction and try to find all the random forks on the internet and check those for anything of value. It seems more manageable and useful if it’s centralised per-project though.

For projects that want to know about problems their users have, it would be a shame to miss out entirely on the deeper analyses that came from their LLMs, even if they’re unreliable. So are regular bug reports, after all.

Serious Computer Business Blog by Thomas Karpiniec
Posts RSS, Atom