I don't want your PRs anymore
Source: Hacker News
Why I don’t want to merge your PR
Since I don’t really know you, I always have to assume that you might be trying to sneak in something malicious along with your changes, which makes reviewing and merging them riskier than implementing them myself.
On top of that, there are many personal and subjective aspects to code: formatting, style, structure, dependencies, and approach. We often need to synchronize reviews, CI runs, and resolve merge conflicts, leading to a back‑and‑forth round‑trip that delays things.
Even before LLMs, writing the code was not the main bottleneck for me, but a solid, working, easy‑to‑review PR was often worth the small extra risk and inconvenience. With LLMs becoming quite good at implementing things, that trade‑off is almost never true anymore.
- I still review LLM‑generated code, but I generally don’t have to worry about it being malicious the way an unknown contributor’s code could be.
- I have codified my coding preferences and style guidelines for my LLM.
- I can iterate rapidly at my own pace without having to synchronize with another human in a different timezone.
For these reasons, it’s just easier if I make the code changes myself (with the help of an LLM).
The nature of software development has shifted
It’s increasingly apparent that “the source code” is less “source” and more “code” — an intermediate formalized layer between ideas in the developer’s head and instructions for the computer to execute. This has always been true, but now the code itself is easier to generate automatically, making the shift more visible.
Reactions to coding agents range from banning them to proclaiming that coding is dead and “vibecoding” is the future. Personally, I sit somewhere in the middle:
- I come up with the design.
- I let my agent do a lot of the actual writing.
- I review and refine the result.
I can generate huge amounts of code, but I’m bottlenecked on:
- Understanding – reading existing code to reason about it.
- Designing – coming up with the right changes and architecture.
- Reviewing – ensuring the code does what I intended.
The code in your PR doesn’t help me much with any of these, so let’s skip it—don’t attempt to implement code changes with the goal of merging them into the codebase.
How can you help instead
As “writing the code” becomes less valuable, other ways of helping maintainers become relatively higher value.
Give feedback
I’m busy implementing things and often don’t have time to use them extensively or research improvements. Users telling me what works well and what could be improved is very helpful.
Discuss ideas
I don’t know everything. Discussing things with people who have different experiences and perspectives can help me understand what to build and how.
Report and investigate bugs
A good bug report is three‑quarters of the bug itself being fixed. If you spot a problem, describe it well, reproduce it, pinpoint where it occurs, and discuss potential solutions.
Prototype changes
Send me a reference PR and/or the prompt you used to produce it. With LLMs, it’s easier for me to have my own LLM make the change and then review it myself. Using code for illustrative purposes still makes sense—a quick glance at an implementation can be helpful even if I don’t merge it. Sharing the actual “source” (prompt) lets me reuse and refine it, saving time.
Review code and point out problems
I’m bottlenecked on reviews, so an extra pair of eyes helps.
Fork the code and report back
Don’t be afraid to fork the repository and change it however you want. Designing for multiple use cases, forming consensus, debating outcomes, and looking for compromises is very time‑consuming. LLMs enable a great deal of software customizability: you can make the changes you want faster and easier than ever, then rebase (or not) on top of upstream at your own pace.
Just fork, add support for your own use case, and proceed without asking for permission or forgiveness. As a maintainer, this saves me time too, and we may both learn something from your independent version.