Map

I don't want your PRs anymore

Wiki summaryai-agentsopen-sourcemaintainer-experience ↳ show in map Markdown
title
I don't want your PRs anymore
type
summary
summary
Ciężarkiewicz's post-LLM rethink of open-source collaboration — what maintainers want from contributors now that writing code is cheap
tags
ai-agents, open-source, maintainer-experience
sources
i-dont-want-your-prs
created
2026-04-22
updated
2026-05-13

Dawid Ciężarkiewicz's April 2026 post reframes how open-source maintainers should think about external contributions now that LLMs have removed "writing code" as the bottleneck. The argument isn't anti-collaboration — it's that the shape of useful collaboration has moved.

The pre-LLM tradeoff

A drive-by PR from someone the maintainer doesn't know always carried costs: security risk (malicious code hidden in the patch), style conflict (contributor's preferences don't match project conventions), coordination overhead (review rounds, CI, merge conflicts, timezone drift). Those costs were worth paying because writing the code was genuinely time-consuming, so a "solid, working, easy-to-review PR" paid for itself in saved implementation time.

Why LLMs invert it

For a maintainer using LLM tooling, writing the code is no longer the bottleneck. The actual bottlenecks are:

  • Understanding — reading the existing code deeply enough to reason about it.
  • Designing — deciding what changes and what architecture are right.
  • Reviewing — verifying that the produced code does what was intended.

A PR helps with none of these. The maintainer still has to understand the change, decide if the design fits, and review the code — and they have to do it on someone else's timeline, with someone else's style, and with residual security concern baked in. The counter-move is just to have the maintainer's own LLM implement the change: no style conflict (the LLM follows the project's codified preferences), no security risk (the maintainer reviewed what the LLM wrote), no coordination overhead.

Source is less "source" than it used to be

Ciężarkiewicz's meta-argument is that the code itself is becoming more of an intermediate formalized layer between ideas in the maintainer's head and the machine, and less of a primary artifact. That framing isn't new — arguably it's always been true — but it becomes operationally visible when the expensive step is moving ideas to code, not typing the code out.

This lines up with threads already in the wiki:

Ciężarkiewicz sits with the "AI helps but understanding and design stay with the human" camp from that set.

What to do instead

The post lists the higher-value ways to help a maintainer who has this posture:

  • Give feedback. Maintainers ship fast but don't have time to actually use what they ship. User experience reports matter.
  • Discuss ideas. Different perspectives shape what gets built and how.
  • Report and investigate bugs. A good bug report is 3/4 of the fix. Reproduce it, localize it, suggest solutions.
  • Prototype changes as reference PRs — but include the prompt. A quick PR can be illustrative; the actual shareable artifact is the prompt that produced it. Prompts compose and refine; PRs have to be merged or rejected.
  • Review code and point out problems. Reviews are the maintainer's bottleneck, so another pair of eyes is net positive.
  • Fork and report back. Don't wait for consensus on multi-use-case designs. Make the change your way, rebase (or not) at your own pace, share what you learned.

The "fork and report back" piece is the most structurally interesting. It treats forking as first-class collaboration rather than as divorce — the maintainer gets signal from someone else's experiment without owning the design tradeoffs.

Why this might not generalise

The post is written from the perspective of a solo or small-maintainer-team project. For projects with:

  • Contributor onboarding as a goal (mentorship, gradual trust-building) — rejecting PRs removes the primary trust-building ramp.
  • Code review as audit trail — regulated or security-critical projects need multiple eyes per change by policy, not by maintainer preference.
  • Large teams — the coordination costs the post complains about are what you're paying for to have a team.

So the post's recommendations are most applicable to indie and small-group OSS, less so to Apache/Eclipse/CNCF-scale projects or anything with compliance requirements.

Linked from