Comment by 0xbadcafebee

2 days ago

Had an experience like this recently. QEMU stopped compiling for old versions of MacOS (pre-13) w/M1 arch, due to it requiring newer SDKs which don't support older MacOS versions. I put Sonnet 4.6 on the case, and it wrote a small patch, compiled and installed it in a matter of minutes, without giving it any instructions other than to look at errors and apply a fix. I definitely would have just given up without the AI.

13 comments

0xbadcafebee

Reply
dudu24  2 days ago

My Nintendo Switch 2 Pro Controller didn't work with my Mac, so I had Claude write me a driver. Amazing times we live in. (As long as I still have a job so I can buy controllers in ten years.)

gregoriol  2 days ago

I've had a similar experience with a very long standing bug on a github project that really annoyed me but I didn't have time nor experience with the project's context to work on it. So Claude investigated and after many iterations (>100, very complex project), it managed to make it work.

hnarn  2 days ago

Why would you solve an issue like this and then not supply a patch upstream, or at the very least contact someone that could? It seems to be like the FLOSS equivalent of posting about a problem on a forum and then replying "nvm, solved it".

  • Avamander  2 days ago

    Primarily because OP can't verify that the patch is truly correct. There's also the fact that anything LLM-generated will likely be frowned upon (for the same reason).

    With some effort OP could review it manually and then try to submit it though.

    But QEMU uses a mailing list for development, it's tedious to set up and then later keep track of. I now fundamentally refuse to contribute to projects that use mailing lists for development, the effort it takes and the experience is just so horrible.

    Especially if it's a small patch that doesn't concern anyone (any big sponsors), you'll probably never get a response. Things get lost easily.

  • 0xbadcafebee  1 day ago

    1) The upstream only supports latest versions of SDK, they're not going to accept a patch to make the app work on an older SDK

    2) I sent the patch to MacPorts which is what I was using and also had failed builds, and the maintainers closed my submission as a dupe (of a ticket which actually didn't have the full patch nor anyone testing it). I offered to do more investigation, no response

    3) It's open source, I really don't owe anyone anything, nor they me

  • ang_cire  2 days ago

    As the other person said, a LOT of github projects with medium-large contributor bases are extremely hostile to AI code contributions. Some of this is about 'slop' coding not being up to par. A lot of it is also about people making their github contributions part of their resume, and thus not wanting the 'devaluation' of their time investments by AI contributions.

  • circularfoyers  2 days ago

    I would hazard a guess that it's because there's been many debates about contributing PRs that might be perceived as AI slop. Not saying that's the case here, but it's possible the fix might be a poor one, not follow the project's guidelines, or one which the contributor doesn't fully understand, but doesn't care because it fixed the issue. I would guess the better approach would be to submit a bug report with the same information the LLM used, and maybe suggest there the fix the LLM provided. Unless this really was a tiny patch and none of the above concerns applied.