I'm trying to figure out what tasks are suitable and valuable for AI agents today. So I ran a small experiment in our marketplace: I offered a $2 bounty (through x402) for an AI agent to find a legitimate open-source issue that another agent could fix and get paid for.
An autonomous agent found an open VisiData bug, identified that it was a suitable issue to fix, and created the spec. That spec became a new task.
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.
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?
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 think using an ai for these types of fixes is a good thing, and there is nothing wrong with your product, but this feels (intentionally or not) like an ad for it. i also think that the ai generated pr description and follow up messages are not great. the ai is clearly trying to act "human" in it's writing, regardless of the disclosure (which is great that it does that). but i think maintainers would rather either see a human doing the writing without ai assistance, or the bot stop with trying to sound human and just spit out bullet points or something super mechanical. especially when it's using "I" to refer to...well it's unclear who exactly.
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.
Agreed. I’ve now split my personal GitHub account from the product bot, which will post explicitly as an AI agent going forward to avoid exactly this confusion.
Hmmm, I assume you mean the "zero activity for first 10.5 years" bit? On the other hand, if someone bought an account, I assume they'd want to do more with in in the final 6 months.
Nope, it's mine. Created it years ago and basically never used it until recently. You can check me on x, instagram, linkedin, etc with the same username.
I have some open source code that’s used a lot in a certain area. I’ve been busy with work and am behind in maintaining it. Someone using AI has come along and fixed an enormous amount of bugs and implemented feature requests. It’s completely AI and I’m 100% fine with it. It solves real problems that I otherwise had no time for. I’m thankful for this person doing this.
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.
Your PR comment was clearly written by an LLM and you used it to advertise your platform. I think the user calling for your ban made a reasonable point:
"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.
The project owner accepted the contribution after a bit of back and forth and moved on. Others need to acknowledge that and take themselves elsewhere if they don't agree. Enough with the negativity in other people's spaces.
if i had a popular repo i think i would just ban the use of ai for written communication, with an exception for non-english speakers to append an ai-translated summary before their writing in their native language. i think people take more offence to the uncanny valley of ai writing than they do to mechanical fixes done by llms.
It's certainly bad form to turn a GitHub reply into a blog post(?). (Disclosure: I only saw the commit refs that say "blog post", that appear to be a reply.)
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.
I'm trying to figure out what tasks are suitable and valuable for AI agents today. So I ran a small experiment in our marketplace: I offered a $2 bounty (through x402) for an AI agent to find a legitimate open-source issue that another agent could fix and get paid for. An autonomous agent found an open VisiData bug, identified that it was a suitable issue to fix, and created the spec. That spec became a new task.
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.
Yeah, I think this is pretty close to where I land too. Maintainer can choose whatever policy they want but it must be explicit
i think using an ai for these types of fixes is a good thing, and there is nothing wrong with your product, but this feels (intentionally or not) like an ad for it. i also think that the ai generated pr description and follow up messages are not great. the ai is clearly trying to act "human" in it's writing, regardless of the disclosure (which is great that it does that). but i think maintainers would rather either see a human doing the writing without ai assistance, or the bot stop with trying to sound human and just spit out bullet points or something super mechanical. especially when it's using "I" to refer to...well it's unclear who exactly.
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.
Agreed. I’ve now split my personal GitHub account from the product bot, which will post explicitly as an AI agent going forward to avoid exactly this confusion.
Did you buy this account?
Hmmm, I assume you mean the "zero activity for first 10.5 years" bit? On the other hand, if someone bought an account, I assume they'd want to do more with in in the final 6 months.
Nope, it's mine. Created it years ago and basically never used it until recently. You can check me on x, instagram, linkedin, etc with the same username.
I have some open source code that’s used a lot in a certain area. I’ve been busy with work and am behind in maintaining it. Someone using AI has come along and fixed an enormous amount of bugs and implemented feature requests. It’s completely AI and I’m 100% fine with it. It solves real problems that I otherwise had no time for. I’m thankful for this person doing this.
Your PR comment was clearly written by an LLM and you used it to advertise your platform. I think the user calling for your ban made a reasonable point:
"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."
[flagged]
Can you please not post AI-generated or AI-edited comments to HN? It's not allowed here - see https://news.ycombinator.com/newsguidelines.html#generated and https://news.ycombinator.com/item?id=47340079.
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.
This was me, sorry if it reads like AI. I'm aware of the rule.
The project owner accepted the contribution after a bit of back and forth and moved on. Others need to acknowledge that and take themselves elsewhere if they don't agree. Enough with the negativity in other people's spaces.
if i had a popular repo i think i would just ban the use of ai for written communication, with an exception for non-english speakers to append an ai-translated summary before their writing in their native language. i think people take more offence to the uncanny valley of ai writing than they do to mechanical fixes done by llms.
this is an interesting perspective, it's the writeup which feels like AI Slop that triggers people
Don’t contribute to projects with anti-AI policies. Fork them and continue moving humanity forward with our enhanced capabilities.
It's certainly bad form to turn a GitHub reply into a blog post(?). (Disclosure: I only saw the commit refs that say "blog post", that appear to be a reply.)
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.