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 (that they aren’t a maintainer of). My analysis of a recent day using gharchive showed 99% 1, 1% 2, 0.1% 3. There are so few people PRing 5+ repos I was able to review them manually. They are all bots/scripts. Please rate limit unregistered bots.

A good rule to live by [insert joke about a specific divisive person not counting because they know no shame here]

We had a similar plague for vulnerability disclosures, with people reporting that they had "discovered" vulnerabilities like "if you call this function with null you get a NullPointerException". D'uh.

There is also the fact that we're measuring the wrong thing like speed of development. In my previous employer people had jumped in fully into the AI bandwagon, everyone was marvelled at how fast they were. Once I was reviewing the PR and I had to tell the author "dude, all your tests are failing". He just laughed it out. Everyone can produce software very fast if it's not required to work.

AI-assisted gamification.

> If you can't explain what your changes do and how they interact with the greater system without the aid of AI tools, do not contribute to this project.

edit: added that quote

Do what I do:

1. Close PR

2. Block user if the PR is extremely low effort

The last such PR I received used ‘’ instead of '' to define strings. The entirety of CI failed. Straight to jail.

If its a feature, i want acceptance criteria at least

If its docs, I don't really care as long as I can follow it.

My bar is very low when it comes to help

The answer to this implies that the requirement to be welcoming only applies to humans, but even in this hostile and sarcastic document, it doesn't go far enough.

Open source maintainers can be cruel, malicious, arbitrary, whatever they want. They own the project, there is no job requirements, you have no recourse. Suck it up, fork the thing, or leave.

I want to do good engineering, not produce slop, but for 1 min of prompting, 5 mins of tidying, and 30 mins of review, we might save 2 days of eng time. That has to be worth something.

I could see a few ways forward:

- Drop it, submit a feature request instead, include the diff as optional inspiration.

- Send it, but be clear that it came from AI, I don't know if it works, and ask the reviewers to pay special attention to it because of that...

- Or Send it as normal, because it passes tests/linters, and review should be the same regardless of author or provenance.

I posted this to a few chat groups and got quite a range of opinions, including varying approach by how much I like the maintainer. Strong opinions for (1), weak preferences for (2), and a few advocating for (3).

Interestingly, the pro-AI folks almost universally doubled down and said that I should use AI more to gain more confidence – ask how can I test it, how can we verify it, etc – to move my confidence instead of changing how review works.

I thought that was an interesting idea that I hadn't pushed enough, so I spent a further hour or so prompting around ways to gain confidence, throughout which the AI "fixed" so many things to "improve" the code that I completely lost all confidence in the change because there were clearly things that were needed and things that weren't, and disentangling them was going to be way more work than starting from scratch. So I went with option 1, and didn't include a diff.

https://en-wikipedia--on--ipfs-org.ipns.dweb.link/wiki/Plonk...

> Perform a hard reboot of your organic meat-brain.

rm -rf your brain, really

  The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted exactly as how much we do not want to review your generated submission.

You MUST use less ambiguous language and default to “MUST” or “SHOULD”

Let's do `chmod -R 000 /` instead.

"I see you are slow. Let us simplify this transaction: A machine wrote your submission. A machine is currently rejecting your submission. You are the entirely unnecessary meat-based middleman in this exchange."

Love it..

Especially the FAQ. It doesn't need to be so snarky.

I think the Ghostty-style policy (linked in another comment) gets the principle right: the bar should be "can you explain what your change does and why, without AI assistance." That is not anti-AI -- it is anti-outsourcing-your-understanding. If you used AI to help write the code but you genuinely understand the change, you can answer questions about it. If you cannot, you have not actually contributed engineering work, you have just created a review burden.

What I have found works well in practice for projects I maintain is treating the PR description as the real signal. A good PR description explains the problem being solved, why this approach was chosen over alternatives, and what trade-offs were made. That is very hard to fake with a quick LLM prompt because it requires actual understanding of the codebase context. When I see a PR with a vague one-liner description and a large diff, that is an immediate close regardless of whether AI was involved -- the submitter has not done the work of communicating their intent.

Why not restrict the agents to writing tests only?

If the tickets are written concisely, any feature request or fix could be reduced to necessary spec files.

This way, any maintainer would be tasked with reviewing the spec files and writing the implementation.

CI is pretty good at gatekeeping based on test suites passing...