I don't want your PRs anymore

Original Article ↗ Hacker News Discussion ↗

More open-source maintainers are starting to refuse pull requests and instead prefer detailed bug reports, feature requests, or specs they can implement themselves—often with the help of AI coding tools. They argue that in an era where code is cheap to generate but costly to review and trust, reviewing drive-by or LLM-generated patches is less efficient and more risky than writing the changes in-house. Critics worry this shift undermines the collaborative ethos of open source, increases fragmentation and security risks, and concentrates control and knowledge in the hands of single maintainers.

Maintainers rejecting PRs

  • Many agree that, in the LLM era, reviewing outside PRs often costs more than implementing the change themselves with an agent.
  • Subjective style, architecture, dependencies, and security concerns make unsolicited PRs unappealing, especially from “randos.”
  • Some maintainers now prefer:
    • Detailed bug reports, specs, or failing tests.
    • Issues/feature requests over code diffs.
  • Others argue PRs are still valuable as a way to grow new contributors and share maintenance load; banning them may discourage the most engaged users.

LLMs shifting the value from code to specs

  • Several commenters say code is now cheap; the bottleneck is design, testing, and integration.
  • For many, the real contribution is:
    • Describing the problem precisely.
    • Providing clear specs or test scenarios.
  • Ideas like “prompt diffs” are floated: contributors share prompts/specs, maintainers generate code. Critics note prompts are non-deterministic and not reusable artifacts.

Forking, “take it home OSS,” and fragmentation

  • It’s increasingly common to:
    • Fork a project, use an LLM to adapt it to personal needs, and never upstream changes.
    • Treat OSS as raw material and the fork as the actual product.
  • Pros cited: speed, autonomy, not having to argue with maintainers.
  • Cons cited:
    • Long‑term maintenance burden of forks.
    • Ecosystem fragmentation, duplicated buggy code, harder vulnerability tracking and coordinated security fixes.
    • Risk of many near‑compatible, partially hallucinated clones.

Security, trust, and review

  • Several note LLM-generated code is not inherently more trustworthy than random PRs and must be reviewed just as carefully.
  • Concerns include:
    • Possible poisoning of training data.
    • Increased surface for subtle bugs and exploits across many slightly different forks.
  • Some suggest LLMs can help review PRs; others see “LLMs writing code and LLMs reviewing it” as breaking the social contract and quality expectations.

Open source ethos and ethics

  • One camp: maintainers owe nothing beyond publishing code; OSS is fundamentally about sharing and forking, not guaranteed collaboration.
  • Another camp: sidelining PRs and reimplementing others’ ideas via LLMs (sometimes without credit) undermines community, learning, and the traditional FOSS spirit.
  • Several predict a messy “Cambrian explosion” of new workflows before more sustainable collaboration patterns re-emerge.