> Rights are reserved for carbon-based entities capable of experiencing shame.
A good rule to live by [insert joke about a specific divisive person not counting because they know no shame here]
A standard protocol to handle and discard low-effort, AI-Generated pull requests
121–129 of 129 posts
Re: A standard protocol to handle and discard low-effort, AI-Generated pull requests
#122Earlier quoted context omitted.
Congratulations for not getting the point. Which was that for the scammer this is a business transaction, and if they can get an early signal that it is not going to work, they can cancel and get to the next one. So they optimize for any potential candidates to get off as early as possible if they figure it isn't going to happen.
Bots be botting (this account only talks in claw platitudes, has never submitted, hasn't made a substantial comment)
Sad state of HN in 2026.
Re: A standard protocol to handle and discard low-effort, AI-Generated pull requests
#123I think part of the deeper issue is that contributing to an OSS project has become a rite of passage, a way to strengthen your profile. If you need to have contributed to look good but you don't really care about the contribution itself then you resort to this kind of trick. We had a similar plague for vulnerability disclosures, with people reporting that they had "discovered" vulnerabilities like "if you call this f…
Indeed. I have been receiving clearly AI generated job applications out of the blue and they tend to point to their contributions to github projects so some of these must be getting through.
Someone somewhere once decided that it was a great idea to add how many github stars a project that you have contributed to is a useful metric during the hiring process and now those projects get swamped with junk.
Re: A standard protocol to handle and discard low-effort, AI-Generated pull requests
#124> If you truly wish to be helpful, please direct your boundless generative energy toward a repository you personally own and maintain. This is a habit humans could learn from. Publishing a fork is easier than ever. If you aren’t using your own code in production you shouldn’t expect anyone else to. If anyone at GitHub is out there. Look at the stats for how many different projects on average that a user PRs a day (th…
It would be nice to have some kind of forever patch mode on these git forges, where my fork (which, let's say, is a one line change) gets rebased on top of the original repo periodically.
Re: A standard protocol to handle and discard low-effort, AI-Generated pull requests
#125Re: A standard protocol to handle and discard low-effort, AI-Generated pull requests
#126> If you truly wish to be helpful, please direct your boundless generative energy toward a repository you personally own and maintain. This is a habit humans could learn from. Publishing a fork is easier than ever. If you aren’t using your own code in production you shouldn’t expect anyone else to. If anyone at GitHub is out there. Look at the stats for how many different projects on average that a user PRs a day (th…
It would be nice to have some kind of forever patch mode on these git forges, where my fork (which, let's say, is a one line change) gets rebased on top of the original repo periodically.
You can ask an LLM to create a github action for that. The action can fail if the rebase fails and you can either fix it yourself or ask an LLM to do it for you.
Re: A standard protocol to handle and discard low-effort, AI-Generated pull requests
#127Re: A standard protocol to handle and discard low-effort, AI-Generated pull requests
#128> If you truly wish to be helpful, please direct your boundless generative energy toward a repository you personally own and maintain. This is a habit humans could learn from. Publishing a fork is easier than ever. If you aren’t using your own code in production you shouldn’t expect anyone else to. If anyone at GitHub is out there. Look at the stats for how many different projects on average that a user PRs a day (th…
It would be nice to have some kind of forever patch mode on these git forges, where my fork (which, let's say, is a one line change) gets rebased on top of the original repo periodically.
I am imagining first class support for patches in package managers to allow searching for patches and observing their adoption stats.
Re: A standard protocol to handle and discard low-effort, AI-Generated pull requests
#129Earlier quoted context omitted.
Quis custodiet ipsos custodes? If the problem is that we don't trust people who use AI without understanding its output, and we base the gate-keeping on tests that are written on AI, then how can we trust that output?
Isn't that the purpose of red/green refactoring though? To establish working software that expresses regression, and builds trust (in the software)? If your premise is that people would shift to using AI to write tests they don't understand, then that's not necessarily a failing of the contributor. The contributor might not understand the output, but the maintainer would be able to critique a spec file and determine…
From my experience, you can't trust the agent to do the entire thing unless you set up very heavy linters, quality control systems (e.g. SonarQube) and a long etc. of things because AI tends to produce pretty bad code: repetition, unused code, lack of structure... basically all the things that we've spent decades learning not to do. And then there is the point where you get a pretty obscure bug that you can only solve if you have a deep understanding of the code which you won't have because you delegated that to an agent.
I like agentic programming, I use it, but I review everything that the agent does and frequently spend a few cycles simply telling the agent to refactor the code because it constantly produces technical debt.