Same here.

KMyMoney stopped importing (some) OFX files for me. I asked an LLM to debug.

It was a wild journey. An obscure bug in some QT library that was triggered because of something completely unrelated that I had installed briefly in 2019 (and uninstalled years ago).

I had it fix the issue by cleaning the leftovers from 2019, but it's still a QT bug. I had it do a writeup, but I'll never submit it. It's fairly sophisticated and I don't know QT code at all.

If it can put together a minimal reproduction of the bug I hope you might submit that. Tossing a commit full of slop over the fence is a dick move, sure, but tossing a small script over the fence that has approximately no dependencies and reliably reproduces the bug is pretty much guaranteed to be helpful. Leave it to the experts to figure out how to actually solve the problem.

I never fixed the bug. I just removed the thing that triggered it.

I believe I do have some sort of a reproducer, but I likely wouldn't understand even the reproducer script. I think it won't be taken well if someone files a bug, says "Here's a script that reproduces it", but himself doesn't understand what the script is doing.

That logic is true of "contributions" - here's some undocumented code, it seems to fix my own poorly specified problem, I have no idea how it works, please merge.

For bug reports (at least IMO) a minimal example to reliably reproduce the error without any fuss is the basic building block. The reporter doesn't need to understand why it works let alone offer an explanation. In fact for complex projects more often than not any purported explanation will be subtly incorrect and actively misleading. If anything further "documentation" of bugs is unwelcome. Unambiguously demonstrate the defect and GTFO.

I think my point is that the response could be "This script is nonsense and should fail."

I'd still be wasting someone's time.

I'll probably put a write-up on my blog one day, though.

Well sure, if you use a library in a borderline incomprehensible and clearly unintended manner and encounter an edge case then perhaps it isn't useful to report it. But while obscure, the usage you described (ie encountering stale config or cache data from a decommissioned install) can hardly be said to be unintended.

If an end user encounters an error while staying within the bounds of "expected usage" then the bug is guaranteed to be valid. You just don't necessarily know whose bug it actually is (for example a broken library versus broken usage of the library by the consuming program).

Why not ask someone involved if they want it or tell someone the prompt that made it? Someone who does the work of checking it and sanitizing it can take the credit.

Depends on the project but some actually adopt an outright hostile response to this. Sometimes justifiably. Sometimes not.

It's honestly not worth it. I understand both sides here, but people are going to have to come up with new ways of collaborating. Pull requests are likely not it anymore.

I've actually been doing this in Clojure and that avoids the major pitfall I've seen: the interfaces it makes are clunky. Re-using an existing library starts with a sane interface.

I've seen the same thing in Go, for what it's worth.

The code totally works, I'm not a denier there, but the interfaces are heinous if you don't keep an eye out. Mine wrote a Go function that passed a name variable as a string, but also embedded in 2 separate structs that were arguments. I've also seen it do re-validation of data multiple times in internal functions so everything has to return an error.

It's also stuff that sort of doesn't matter if an LLM is the only user. It probably costs some extra quantity of tokens, but not enough to be worth hand-grooming the code.