I don't want your PRs anymore

Original Article ↗ Hacker News Discussion ↗

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.