I don't want your PRs anymore

I hope you realize how bad this feels to the person who sent you the patches. They made a concerted effort to explore your codebase, improve it and send you improvements, but you felt they weren't worth the time of day. To you, engaging with someone who cared enough to send you code is "puppeteering someone halfway across the globe".

My most negative experiences with free and open source contributions have been like that. The one maintainer who engaged with me until my patches got into master was the best experience I ever had contributing to open source software to this day. That's how I want to maintain my own projects.

While I understand the sentiment I am glad I got into open source more than fifteen years ago, because it was maintainers “puppeteering” me that taught me a lot of the different processes involved in each project that would be hard to learn by myself later.

So you can still contribute, you just not need to provide the code, just the issue.

Which isn't as bad as it sounds, it kind of feels bad to rewrite somebody's code right away when it is theoretically correct, but opinionated codebases seem to work very well if the maintainer opinions are sane.

Oh god, I needed to add a feature to an open source project (kind of a freemium project) about fifteen years ago. I had no experience with professional software development nor did I have any understanding of pull requests. I sent one over after explaining what I was trying to do and that I thought it would be a good feature for the project.

Now they probably shouldn’t have just blindly merged it, but they did, and it really made a mess.

Learned a valuable lesson that day haha.

When you actually work alongside people and everyone builds a similar mental model of the codebase then communication between humans is far more effective than LLMs.

For random contributions then this doesn’t apply

This is similar to what we’ve started to do at work. The first stage of reviewing a PR is getting agreement on the spec. Writing and reviewing the code is almost the trivial part.

By the end, the project manager begged me to turn off my flamethrower, as I was ripping it all out for a clean west manifest to tagged versions and stacks of patches. "Take it home OSS" is like take-out food: if you don't do your chores and leave it out for months or years on the kitchen counter, the next person to enter the apartment is going to puke.

If it’s "take it home OSS" and "there is not much need to submit PRs or issues" then why would anybody submit PRs and issues for "for critical bugs or security fixes"? If they have fix and it works for them, they’re fine, afterall.

And while we’re at it, why would anybody share anything? It’s just too much hassle. People will either complain or don’t bother at all.

I think that after few years, when LLM coding would be an old boring thing everybody’s used to and people will learn few hard lessons because of not sharing, we’ll come to some new form of software collaboration because it’s more effective than thinking me and LLM are better than me and LLM and thousands or millions people and LLMs.

Collaboration is a common pattern in larger projects but is uncommon in general

Even if they worked, it would be easier for the maintainer to just do that themselves rather than review and communicate with someone else to resolve issues.

Sometimes I'm not a fan of the change in its entirety and want to do something different but along the same lines. It would be faster for me to point the agent at the PR and tell it "Implement these changes but with these alterations..." and iterate with it myself. I find the back and forth in pull requests to be overly tiresome.

Somehow it's not really happening.

Submitters use LLMs to generate the code and reviewers use LLMs to review it.

PRs, at the very least, provide a quality gate. You have to a) express the idea in runnable code and b) pass the tests.

This is just a change in position of what work is useful for others to do.

Give me ideas. Report bugs. Request features. I never wanted your code in the first place.

It feels like a lot of people assume a sense of entitlement because one platform vendor settled on a specific usage pattern early on.

Maybe I'm not up to date with the bleeding edge of linters, but I've never seen one that adequately flags

    let out = []
    for(let x of arr){
      if(x > 3){
        out.append(x + 5)
      }
    }

   let out = arr
             .filter(x => x > 3)
             .map(x => x + 3)

I find myself doing the same, nowadays I want bug reports and feature requests, not PRs. If the feature fits in with my product vision, I implement and release it quickly. The code itself has little value, in this case.

1 year ago Claude Code was relatively new, and a first polished tool that really fitted my CLI-centeric dev-views. I used Aider before, but Claude Code was just much better. The autocomplete AI coders did not seem useful, and didn't have good integrations with Helix text editor. However even the frontier models were relatively bad in practice. Useful but not trustworthy at all. Being wrong/stupid 5-10% of the time compounds quickly.

6 months ago agents became really robust at just writing code they were told to write. Around that time I started really leaning into LLM-assisted coding, which require some skill, experience and adapting own workflows and tooling. And it takes time and effort.

Right now frontier models are really productive and robust. Sure it's still a fancy-autocomplete under the hood, so one needs to plan around that, but it's more common for Slopus finds bugs in my old human-written code, than I find bugs in its new code, especially that one can now easily write and maintain tons of tests which otherwise would never get done. LLMs don't have context and good judgment, so it still takes a lot of designing and steering the agent to write the right thing, but that's OK. And as the productivity bottleneck shifted very heavily from writing code to all other thing around it, it makes it very apparent that it's not the clanker now that needs to get better, but the process around it.