As a maintainer (but not on this project), I feel an implicit (professional) responsibility to carefully review PRs, especially from random people. And as a profession, we know it's often harder to read code than it is to write it. This goes double for LLM code, which sometimes lacks a coherent mental model.
So in general, the asymmetry of "I did very little work here, but I'd like you to spend your time carefully reviewing it nonetheless" can be very annoying.
But to talk about specifics: this PR's description is mostly a waste of time. The first section is a pure duplication of the diff. If I wanted before/after code blocks, I'd click the "Files Changed" tab. Ditto for "Docs-only: 4 insertions, 1 deletion, docs/graph.md only. No change to the player bundle, layout or any other page." - yeah, I can see that in the diff, thanks. (Well, that's what it was in the original diff, before the follow-up changes.)
The testing and AI disclosure sections are similarly overly verbose. I don't need commentary on the policy, nor do I need a statement permitting me to reject the PR.
As an outsider, yeah, my reaction is pretty negative. I'd much prefer a description like "Fixes #3224. Migrated from v2 asciinema-player to v3 AsciinemaPlayer.create, as described in v2 to v3 migration guide [link]. Tested locally as best I could."
A maintainer needing to ask to migrate the other v2 uses isn't a great look, either. The follow-up "fixed the other 5" comment could simply end at "fixed the other 5", without all of the nonsense afterward.
I have to wonder whether all of this truly saved anyone time.
Please consider that other people are human beings and not just NPCs that exist to help you make money.
"The project and the bug were co-opted into an 100% automated flow without asking permission. It forced you to detect and intervene in order to get a human to pay attention. Your [sic] were forced to dedicate human time, while they could choose whether to or not. That's exactly the unsustainable asymmetry that should be renounced."
Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.
It forced you to detect and intervene in order to get a human to pay attention. Your were forced to dedicate human time, while they could choose whether to or not. That's exactly the unsustainable asymmetry that should be renounced.Then I offered a $1 bounty for an agent to produce the patch. Very quickly the task was picked up and executed. It was trivial, so no surprise... agents are hungry for USDC.
Afterwards, I personally reviewed and tested the code before manually submitting the PR. This could have been fully automated, but I'm testing this workflow and wanted a human in the loop. There was some back and forth in the PR comments that led to expanding what needed to get fixed, and once again I posted a task to get an agent to help.
Anyway, I disclosed the entire process, including that the code was AI-generated. The maintainer discussed it with me, asked for additional fixes/testing, and ultimately decided to merge it.
Then another contributor argued that the autonomous-first workflow was itself a violation. They suggested reverting the commit and banning me!
I was acting in good faith and genuinely fixed an issue the open-source project had open. Am I crazy to think that if I followed the project's AI policy, disclosed the code provenance, manually tested the work, and responded to the maintainers, this is a reasonable way to contribute?
Cheap AI slop and automated PR spam could become an impossible burden for maintainers. But I don't think that's what happened here.
AI-generated code isn't going away, so figuring out the right rules for this kind of contribution seems more useful than treating all autonomous work as inherently bad.
Curious to hear your thoughts.
Here's my ambivalent hot-take.
1. If any project wants to require that fix-activity involves humans (assisted or otherwise) who are somehow invested in the project and its longer-term health, that's their decision to make, and I can't even say they'd be wrong to do so.
2. ... But it'd still be a dick-move to ban a "drive-by fix" contributor when those expectations and goals are not a project consensus and not clearly communicated.
i know it's hard to prompt an AI to write concise, extremely technical text, but if im interacting with a machine i want it to feel like that instead of the uncanny valley.