I don't want your PRs anymore
by speckx on 4/21/2026, 8:21:40 PM
https://dpc.pw/posts/i-dont-want-your-prs-anymore/
Comments
by: boricj
I've been on both ends of this.<p>As the maintainer of ghidra-delinker-extension, whenever I get a non-trivial PR (like adding an object file format or ISA analyzer) I'm <i>happy</i> that it happens. It also means that I get to install a toolchain, maybe learn how to use it (MSVC...), figure out all of the nonsense and undocumented bullshit in it (COFF...), write byte-perfect roundtrip parser/serializer plus tests inside binary-file-toolkit if necessary, prepare golden Ghidra databases, write the unit tests for them, make sure that the delinked stuff when relinked actually works, have it pass my standards quality plus the linter and have a clean Git history.<p>I usually find it easier to take their branch, do all of that work myself (attributing authorship to commits whenever appropriate), push it to the master branch and close the PR than puppeteering someone halfway across the globe through GitHub comments into doing all of that for me.<p>Conversely, at work I implemented support for PKCS#7 certificate chains inside of Mbed-TLS and diligently submitted PRs upstream. They were correct, commented, documented, tested, everything was spotless to the implicit admission of one of the developers. It's still open today (with merge conflicts naturally) and there are like five open PRs for the exact same feature.<p>When I see this, I'm not going to insist, I'll move on to my next Jira task.
4/21/2026, 9:37:26 PM
by: hunterpayne
Somehow, this seems like a serious negative consequence of LLMs to me. We should consider how security patches move through the ecosystem. Changes like this are understandable but only because PRs from LLMs are so bad and prolific. When a new exploit is discovered, the number of sites that require a change goes up exponentially due to LLMs not using libraries. At the same time, the library contributors will likely not know to change their code in view of the new exploit. This doesn't seem like healing, more like being dissolved and atomized to the point of uselessness.
4/21/2026, 9:51:55 PM
by: eschneider
This seems...fine?<p>I know when I run into bugs in a project I depend on, I'll usually run it down and fix it myself, because <i>I</i> need it fixed. Writing it up the bug along with the PR and sending it back to the maintainer feels like common courtesy. And if it gets merged in, I don't need to fork/apply patches when I update. Win-win, I'd say.<p>But if maintainers don't want to take PR's, that's cool, too. I can appreciate that it's sometimes easier to just do it yourself.
4/21/2026, 9:17:34 PM
by: bawolff
I think every maintainer should be able to say how they want or don't want others to contribute.<p>But i feel like it was always true that patches from the internet at large were largely more trouble then they were worth most of the time. The reason people accept them is not for the sake of the patch itself but because that is how you get new contributors who eventually become useful.
4/21/2026, 9:36:00 PM
by: sfjailbird
Given that submitters are just using LLMs to produce the PR anyway, it makes sense that the author can just run that prompt himself. Just share the 'prompt' (whether or not it is actually formatted as a prompt for an LLM), which is not too different than a feature request by any other name.
4/21/2026, 9:32:39 PM
by: pkulak
Forking and coming back is what I like to do. At this very moment I've got a forked project that I'm actively using and making tiny changes to as things come up in my workflow. In another week or two, when I'm certain that everything is working great and exactly how I want it, I'll file an issue and ask if they are interested in taking in my changes; mostly as a favor to me so I don't have to maintain a fork forever.
4/21/2026, 9:38:45 PM
by: ncruces
I agree with this.<p>Past month or so I implemented a project from scratch that would've taken me many months without a LLM.<p>I iterated at my own pace, I know how things are built, it's a foundation I can build on.<p>I've had a <i>lot more</i> trouble reviewing similarly sized PRs (some implementing the same feature) on other projects I maintain. I made a huge effort to properly review and accept a smaller one because the contributor went the extra mile, and made every possible effort to make things easier on us. I rejected outright - and noisily - all the low effort PRs. I voted to accept one that I couldn't in good faith say I thoroughly reviewed, because it's from another maintainer that I trust will be around to pick up the pieces if anything breaks.<p>So, yeah. If I don't know and trust you already, please don't send me your LLM generated PR. I'd much rather start with a spec, a bug, a failing test that we agree should fail, and (if needed) generate the code myself.
4/21/2026, 9:49:13 PM
by: ChrisMarshallNY
<i>> Users telling me what works well and what could be improved can be very helpful.</i><p>That's a unicorn.<p>If I'm lucky, I get a "It doesn't work." After several back-and-forths, I might get "It isn't displaying the image."<p>I am still in the middle of one of these, right now. Since the user is in Australia, and we're using email, it is a slow process. There's something weird with his phone. That doesn't mean that I can't/won't fix it (I want to, even if it isn't my fault. I can usually do a workaround). It's just really, really difficult to get that kind of information from a nontechnical user, who is a bit "scattered," anyway.
4/21/2026, 10:25:47 PM
by: gavmor
> there's this common back-and-forth round-trip between the contributor and maintainer, which is just delaying things.<p>Delaying what?
4/21/2026, 9:28:45 PM
by: mvvl
This is only going to get worse with LLMs. Now people can "contribute" garbage code at 10x the speed. We're entering the era of the "read only" maintainer focused on self-defense.
4/21/2026, 9:45:58 PM
by: clutter55561
If they are willing to feed a bug report to their LLM, then perhaps they can also feed a bug report + PR to their LLM and not make a big fuss out it.<p>Also, at the point they actively don’t want collaboration, why do open source at all?<p>Strange times, these.
4/21/2026, 9:40:08 PM
by: arjie
Realistically, there are a much larger set of things that I don't mind forking these days. It is quite a bit of effort to get to a set of things that mostly don't have bugs, but in the past I might fork a few things[0] but these days, I vendor everything, and some things I just look at the feature list and have Claude rebuild it for me. So I totally understand why actual project maintainers and authors wouldn't want input. I, as a user, am not super eager to buy in to the actual maintainers' future work. It would be super surprising that they want to buy into strangers' work.<p>0: I liked BurntSushi's Rust projects since they are super easy to edit because they're well architected and fast by default. Easy to write in.
4/21/2026, 10:10:09 PM
by: petetnt
Luckily we have had the perfect paradigm for this kind of mindset for decades: proprietary software. The spirit of open source is already essentially dead due to it being co-opted by companies and individuals working only for their own gain, and for it to rise again we probably need a total reset.
4/21/2026, 10:32:32 PM
by: pncnmnp
I have come to a similar realization recently - its what I call "Take it home OSS" - i.e. fork freely, modify it to your liking using AI coding agents, and stop waiting for upstream permissions. We seem to be gravitating towards a future where there is not much need to submit PRs or issues, except for critical bugs or security fixes. It's as if OSS is raw material, and your fork is your product.
4/21/2026, 9:40:15 PM
by: samuelknight
> On top of that, there are a lot of personal and subjective aspects to code. You might have certain preferences about formatting, style, structure, dependencies, and approach, and I have mine.<p>Code formatting is easy to solve. You write linting tests, and if they fail the PR is rejected. Code structure is a bit tricker. You can enforce things like cyclomatic complexity, but module layout is harder.
4/21/2026, 9:40:02 PM
by: porphyra
Maybe instead of submitting PRs, people should submit "prompt diffs" so that the maintainer can paste the prompt into their preferred coding agent, which is no doubt aware of their preferred styles and skills, and generate the desired commit themselves.
4/21/2026, 9:28:30 PM
by: freetime2
Couldn't you also just have an LLM review the PR and quickly fix any issues? Or even have it convert the PR into a list of specs, and then reimplement from there as you see fit?<p>I guess my point being that it's become pretty easy to convert back and forth between code and specs these days, so it's all kind of the same to me. The PR at least has the benefit of offering one possible concrete implementation that can be evaluated for pros and cons and may also expose unforeseen gotchas.<p>Of course it is the maintainer's right to decide how they want to receive and respond to community feedback, though.
4/21/2026, 9:34:39 PM
by: cadamsdotcom
Yes, reviewing might take 1 hour but taking the PR and using it to guide an implementation also takes 1 hour.<p>Thank your contributor; then, use the PR - and the time you’d have spent reviewing it- to guide a reimplementation.
4/21/2026, 10:10:50 PM
by: jerkstate
Thats fine, the cost for me to re-implement your code is nearly zero now, I don’t have to cajole you into fixing problems anymore.
4/21/2026, 9:15:24 PM
by: Mathnerd314
The author sounds like he actually responds to feature requests, though. Typical behavior I'm seeing is that the maintainer just never checks the issue tracker, or has it disabled, but is more likely to read PR's.
4/21/2026, 9:34:52 PM
by: mactavish88
Great example of how to set boundaries. The open source community is slowly healing.
4/21/2026, 9:29:13 PM
by: woeirua
I agree with this mindset. Instead of submitting code diffs, we should be submitting issues or even better tests that prove that bugs exist or define how the functionality should work.
4/21/2026, 9:34:34 PM
by: vicchenai
had the same realization last year after getting a few obviously AI-generated PRs. reviewing them took longer than just writing it myself. maybe the right unit of contribution is going back to being the detailed bug report / spec, not the patch
4/21/2026, 9:54:58 PM
by: krick
It's good that he is upfront about it, but this surely shouldn't be taken as a general advice, since everybody has his own preferences. So this really shouldn't be a blogpost, but rather a "Contributing Guidelines" section in whatever projects he maintains.
4/21/2026, 9:41:48 PM
by: acedTrex
If i do the work for a feature im usually already using it via fork, i offer the patch back out of courtesy. Up to you if you want it I'm already using it.
4/21/2026, 9:29:21 PM
by:
4/21/2026, 10:06:49 PM
by: vatsachak
LLM psychosis
4/21/2026, 10:12:57 PM
by: tonymet
PRs come from your most engaged community members. By banning PRs you won’t get more contributions, you will discourage your (current and future) most active members.
4/21/2026, 10:21:01 PM
by: cmrdporcupine
Yes I feel very much like what I really want from people is <i>very detailed bug reports</i> or <i>well thought through feature requests</i> and even <i>well specified test scenarios</i> [not in code, but in English or even something more specified]<p>I know my code base(s) well. I also have agentic tools, and so do you. While people using their tokens is maybe nice from a $$ POV, it's really not necessary. Because I'll just have to review the whole thing (myself as well as by agent).<p>Weird world we live in now.
4/21/2026, 10:10:14 PM
by: lou1306
> On top of that, there are a lot of personal and subjective aspects to code. You might have certain preferences about formatting, style, structure, dependencies, and approach, and I have mine.<p>95% of this is covered by a warning that says "I won't merge any PR that a) does not pass linting (configured to my liking) and b) introduces extra deps"<p>> With LLMs, it's easier for me to get my own LLM to make the change and then review it myself.<p>So this person is passing on free labour and instead prefers a BDFL schema, possibly supported by a code assistant they likely have to pay for. All for a supposed risk of malice?<p>I don't know. I never worked on a large (and/or widely adopted) open-source codebase. But I am afraid we would've never had Linux under this mindset.
4/21/2026, 9:15:01 PM
by: grebc
Why bother having a public repository?
4/21/2026, 9:49:04 PM
by: guelo
It's interesting that this is the opposite of Steve Yegge's conclusion in his Vibe Maintainer article where he says he's merging 50(!) contributor PRs a day.<p><a href="https://steve-yegge.medium.com/vibe-maintainer-a2273a841040" rel="nofollow">https://steve-yegge.medium.com/vibe-maintainer-a2273a841040</a>
4/21/2026, 9:44:14 PM
by: yieldcrv
I like how fast this is changing<p>The fact-of-life journaling about the flood of code, the observation that he can just re-prompt his own LLM to implement the same feature or optimization<p>all of this would have just been controversial pontificating 3 months ago, let alone in the last year or even two years. But all of a sudden enough people are using agentic coding tools - many having skipped the autocomplete AI coders of yesteryear entirely - that we can have this conversation
4/21/2026, 9:38:10 PM
by: shell0x
[dead]
4/21/2026, 10:51:44 PM
by: mrluckysmith
[dead]
4/21/2026, 10:18:43 PM
by: MisterTea
[dead]
4/21/2026, 9:25:16 PM