back
207 comments
I first encountered the following concept in one of Oxide's publications; good chance it didn't originate there though:

There is an implicit social contract with writing that the writer has put more effort into writing than the reader will need to read something. Sure you get crackpots still, but there are only so many Gene Rays in this world, so the volume is limited.

I think the same applies to PRs. Pre-AI , it was usually obvious when a PR was either completely terrible or very half-baked, and the required effort to create even a shitty PR was usually more than that required to reject it.

AI makes it trivial to make a completely terrible PR, and much easier to make a not-immediately-obviously-bad PR.

Given this, you can conclude that writers should be putting in at least at much effort as readers, whether or not they use an LLM. What really seems to be the problem is writers that don't at least check their own work, and pass that burden onto the readers. This is easier than ever with LLMs.

This is toxic behavior that unfortunately rewards a selfish writer. I'm worried the AI push incentivizes this too much, to where in corporate situations a reader can't say no to doing work for a selfish writer.

> Sure you get crackpots still,

They've still put more effort into writing their crackpottery than you will put into reading it, and at worst it's entertaining. The late Ivor Catt's articles on "the death of electric current" - where he expounds the idea that current and indeed electric charge does not exist, because of stuff involving Maxwell's equations where the maths looks about right to me but I'm not a good enough mathematician to prove - were pretty damn odd, but his writing in 1989 on how it would be vital for an interconnected network of computers for information sharing to treat censorship as damage and route around it and some ideas for doing this was bang on the money (as we now see) and his writings on how American business management methods result in the worst possible outcome for everyone that's not already a billionaire have also proven oddly prophetic.

So maybe there's something in the crackpots after all.

I think this is from Sartre's "Literature & Existentialism."

I'm not a big fan of his generally, but I highly recommend this book in particular. A lot of what he wrote there really resonated for me.

if anyones got an active issues list, the maintainers should close all issues and open only ones they intend to fix. A bot should repeat this message to the issuer and point them to issues they're accepting.

So at a minimum, you could maybe fish some useful work out. PRs should be the same.

> Back in pre-LLM days, receiving an unexpected pull request (PR) from a fellow coder was a source of excitement and pride.

As a maintainer of a few FLOSS projects, this tracks.

The Pavlovian PR notification response has gone from, "Oh! What do we have here?" to "Groan. Do we have _anything_ here?"

I won't get specific but I just had to remove a contributor from a project after multiple submissions of either cutesy, fluffy bullshit (add ASCI animations!) or "rewrite entire project in other language". Not only did the PRs result in wasted time and energy but they also resulted in conversations about how to deal with this sort of spam. (Probably good to get out of the way and set policy but still...) So, this person probably spent fifteen minutes prompting together these stupid PRs and multiple maintainers had to spend hours agonizing over what to do about them.

TBH I never contributed to Open Source because of the effort needed to bring my PR from "works on my machine" to "compliant with the rest of codebase". Especially that I only want to implement one small thing.

There's one project where I need to download a new version once in a while and I just rebase my changes.

The thing is I totally, 100% get this. The other thing I can't help but see though is how excited my non-programmer friends are to finally be able to make software. The sense of pride and accomplishment from non-coders who are finally able to make something work the way they wanted to.

We almost need like ... noncanonical software? Not so much forks, but like ... Maybe software as like a cluster? an ecosystem? On-demand app store where features / forks are shared/upvoted/evolved by the community where the maintainers don't have to get burnt out, and when it inevitably becomes a ball of mud oh well it does the job? I really don't know!

I hope we can think about some answers and not get tribal though because this is really a huge problem and also a huge opportunity and so a minor reminder that there is a baby in that bathwater?

I agree. For many people, LLMs are the first time that computers do what they tell them to. Not what some big tech PM has decided is or isn’t possible.

At the same time, OP is in the right to reject contributions they don’t want. Nobody providing open-source software is under any obligations to take changes. Forking is still a viable option in 2026. And I don’t think we need an on-demand app store either because the trust issues will still exist for good reason. We can have highly produced software coexisting with LLM agents.

Who gets a sense of accoplishment from prompting an LLM? Do you get a sense of accomplishment when AI draws a picture or writes a poem for you? I guess there are some minds I'll never be able to comprehend
> I hope we can think about some answers and not get tribal though because this is really a huge problem and also a huge opportunity and so a minor reminder that there is a baby in that bathwater?

I think no answers are needed.

If anyone can build the software they need, no ecosystem will be needed. There will be no maintainers because no one will be using his thing.

If it makes sense (economical, but no limited to it), then it will progress in that direction. If it makes no sense it is a fad that eventually dies out.

There may or may not be a baby in the bathwater. In truth nothing in this bathtub matter too much.

If you scroll through any personal finance forum every year someone will discover the forum and excitedly share their customised budget tracking sheet they built from scratch and it works exactly as they wanted to. How many do you think even get 1 upvote?

Everyone building a software will just mean people can produce code which others might not really care for and might even be particularly be mean. That’s how the Internet works unfortunately.

The current logic seem to be confusing two things. One AI as a technology and wisdom of the crowd using AI. One might ground breaking tech and improve over time while the other might not move the needle at all.

What is the kind of person who would use such software? What you’re describing is the need for a two sided market where really only one side exists.

A user would have to be someone who doesn’t have access to an LLM to make bespoke software themselves, and isn’t able to use existing software. I think that’s a vanishingly small segment of people.

I do a bit in my IT classes where I show a "spectrum" of computer activities, from "changing a screensaver" to "Assembly" and then challenge people to find the line where "using a computer" stops and "programming a computer" starts.

It was already very fuzzy (Excel?). Soon, this line be non-existent.

I - and many, many others - learned flask from his mega-guide that he obviously spent a lot of time working on.

I feel bad for people like him who get the brunt of dilettantes who can "code" polluting his time and focus. Reminds me of that mitch hedberg joke: "When someone hands you a flyer, it's like they're saying here you throw this away." but for PRs

I recently built a very large test bench for System Verilog.

I ran a bunch of different compilers on it, including some open source ones.

Some of them failed some tests, and it was natural to have my LLM (Claude Fable 5) root-cause the issues, and to double-check my test bench wasn't to blame.

But now I stood with all these patches that I couldn't just throw at the upstream maintainers all at once. I ended up just filing a few issues and moved on to other things.

It felt weird to just file issues when my LLM had already spent a lot of time root-causing and fixing the issues. But then, maybe they could just have their LLMs do the same.

Still not sure if it was the right call?

> My perception is that there is less interest in open source, and in coding in general. The main reason I love coding is that it is a challenge, and I think this is actually the same reason why a lot of people prefer to give money to an AI lab and get a machine to spit out code for them, even with the risk of the code being subpar.

I maintain the hope that those technically minded who are really interested in coding and care about doing things properly using their own reasoning on all levels of detail will find each other and maybe become less diluted as a community by the coding-just-for-money crowd than in the past decade or two.

Even if this guy were not anti-AI, as the primary maintainer of OS projects, it sounds like he's dealing with a genuine problem.

> My initial task when a new unexpected PR arrives is to determine if there is a person behind it or not, and luckily this is easy to figure out in just a few seconds.

OK. How? That would have been an interesting explanation to me.

Asking contributors to first make sure there is an approved requirement before creating a PR sounds like a great idea regardless of the use of LLM.

But another issue is - AI disclosure (agent, model etc). I'm sure others tried similar approaches, but in case this is not common knowledge - I tried to see what happens if you ask agents to disclose themselves in the PR description / comments in a rule file.

It seems to work pretty well as most AI "assisted" PRs will be opened by agents using the gh cli or MCP on behalf of the user. (Of course this can be bypassed, but for someone who doesn't mind disclosing or doesn't care, this is a good step forward)

Example: https://github.com/arnica/depsguard/blob/main/AGENTS.md#ai-d...

(so far worked on PRs from both Claude Code and Codex - both got a footer disclosure of the agent name and model)

We had a process at one company where you had to create an issue before filing a PR. I found it most non-sensical and introducing friction for no good reason. Very surprised to see the author suggesting it in the article.

Review is indeed the main bottleneck now for open source, and we need to solve it. Introducing more friction is hardly helping.

> Generative AI notice: I do not use LLMs, agents or any other generative AI tools for help with writing, coding, image creation or any other tasks related to this blog or my open source work.

This reminds me way back when you would see "Website written in Notepad" on websites.

The article closes with the question: "Does open source matter anymore?"

I wouldn’t pretend to have an answer. of course. Opens Source means, always meant, different things to different people.

I know what always counted for me:

1. Copyleft License

2. No CLA or Copyright assignment

3. Diverse group of contributors

I sympathize with Miguels point but it bothers me it clashes with point 3 in my list. If you hand select your contributors[1] you will never reach the diversity necessary to effectively make relicensing impossible. Without that Open Source matters less to me.

[1] I admit that controlled set of known contributors has other advantages too.

As a systems engineer, ive been a reverse centaur more often than not.

I have a Jira queue. It drives what work I do. I may have some leeway in how I do the work, and what tickets I pull, but Im absolutely at the behest of the ticketing behemoth.

Tickets have been my life since I started helpdesk. And future roles will also be ticketed. And they almost all are customer-facing or system-breakage (which impacts lots of customers).

Im not sure what IT roles im capable of doing wouldnt have tickets. So, yeah. Reverse centaur.. But not an AI driven reverse centaur, yet.

GitHub Issues before PRs is a great approach. The ghostty project takes that one step further: GH _discussions_ before GH issues. Only maintainers can make issues.
The PR quality problem is legit and needs a solution.

But saying his opinion hasn’t changed on this:

“the main and most important reason why GenAI tools do not work for me is that they do not make me any faster.”

It’s been a year and agents and models have improved dramatically.

I can see for some things it doesn’t make sense, but not using it at all because there’s nothing it can help with?

Devs who don’t use models at all are a dying breed and I think it won’t be long before he’ll be forced to concede the point.

To respond to the ending of this piece, I think open source still matters because LLMs generate very specific code for a specific situation. Quality libraries mean solutions can be reliably shared between projects.
Solution: write a markov generator (or use the cheapest AI possible) to generate plausible-looking rejections for PRs.

Let those agents bankrupt their owners in a loop of neverending improvements and changes.

I totally understand the point of view from maintainers. Review fatigue of low quality slop is a legitimate issue.

The worst ones are fully autonomous AI agents looking for open source projects and adding random pull requests.

But in some cases, I find a legit bug that needs fixing. For example, I want to get a particular program working in Wine/FEX on aarch64 [1], or I find a 12 second hang in Darktable [2]. The problem is that, as a software engineer working in a totally different discipline, I have no knowledge of the low level C code to fully understand what the problem even is, or how to fix it. All I want to do is to fix the issue and help other people avoid running into the same issue. Right now, on my machine, I maintain a set of custom patches to get everything working. But I am too dumb and ignorant to figure out how to create the fix by hand, so I can't submit a pull request (or when I do, I feel really bad about it. I honestly feel like a horrible person, e.g. when a project added a "No AI" policy soon after I submitted some AI-generated PRs [3]). Going forward, I feel like this sort of scenario is going to be way more common.

[1] https://github.com/FEX-Emu/FEX/issues/5512

[2] https://github.com/darktable-org/darktable/pull/21069

[3] https://github.com/FEX-Emu/FEX/commit/8c85096f98084ca9438b16...

It seems like there is a ready solution here, have an LLM review and filter pull requests from unknown sources before you read them. My understanding is there are semi-reliable ways to detect AI writing, maybe there is an analog for code. In any case, you can filter according to criteria you set. Analysis and bug-finding is where LLMs shine, much more than their ability to generate code.

I can understand wanting to minimize your interaction with LLMs, so this might not be an attractive solution. But it seems like a worthwhile feature to have on the platform level for people who would like to continue to accept pull requests without the frustration.

What criteria are people using to discern if code contributions are from humans or LLM?

Are there concrete patterns that somebody could write a linter to auto evaluate for this?

> Does open source matter anymore?

Probably not, but maybe free software now matters more.

A reverse centaur is just a person with a horse head right? I don’t get the analogy. I understand he’s talking about getting pushed around by an LLM, but would a normal centaur push an LLM around? It doesn’t even have any hands right? Seems like a reverse centaur is more capable of typing.
Those mad about auto-rejected drive-by PRs should go fork themselves

a copy of the repo.

It's just silliness. Judge the code on the merit of the code, not deciding to reject it if you learn it was constructed with the aid of AI.
The question that resonated with me was whether open source even matters anymore.

I think it does but there are weird dynamics I don’t fully understand. I’m curious about HNs thoughts.

My theories: Centralization around key projects due to AI pointing new users towards them. (At the same time this drives up the PR deluge onto these projects. Especially from newer users already heavily using llms.)

So many low effort AI-generated open source libraries that it becomes harder to tell signal from slop. More movement to the bigger projects because they are perceived as safer bets.

I think the answer to this question probably doesn't exist and opinions will remain divided. I can understand this person's feelings. But I 'won't be able to feel them' because I'm in a different position. The technology this person takes pride in is directly affected by AI.

On the other hand, there are also people who start coding with AI, and those people will love a large part of code that isn't pretty but works.

Some will say that messy code will ruin software in the long run, while others will think otherwise. This reminds me of Sturgeon's law: 90% of everything is crap. This means that for any type of thing, there are quality items and inferior ones, and quality items make up about 10%. The 10% of code created by AI will be valuable, and only 10% of human-written code was valuable. AI has just increased the amount of crap.

Whenever I think about these issues, I always think of Undertale. Undertale's code is overwhelmingly messy, yet it's a masterpiece often cited as one of the best games. I love it too. But Leaked Undertale code (its quality) is terribl

Ultimately, it seems that AI's usefulness and harmfulness are determined by the purpose for which it is used.

If someone enjoys code quality, long-term perspective, and intellectual exchange and interaction with people from these kinds of discussions, they will be hostile toward AI.

On the other hand, someone like me, who is in a community that has a hostile attitude toward on-time delivery for clients and learning (based on mockery and disregard), will be receptive to AI.

Honestly, I am a direct beneficiary of AI. I'm on the side of consuming the results managed by open-source maintainers, so I can't fully understand their position. I just think, 'That must be incredibly hard for them.'

In my case, AI writes English functions and documentation, and by using AI to refactor English function/variable names that were previously hard to use, I can now write code that's easier to read.

But since my role mainly involves assembling things using IoC on top of frameworks, I see more advantages. The downside is that my coding skill declines, I suppose. I'm a traveling contract programmer who often goes on-site to work with legacy codebases and add features to them.

Actually, my workflow hasn't changed much. It's just that the legacy codebase has become an AI-generated codebase. My workflow of debugging and tracing the flow there hasn't changed, so I'm probably in the beneficiary camp.

Conversely, people like the OP have seen a massive change in the number of PRs they need to handle, so it's understandable. The intellectual exchange with people they've always had, and the values that come from that, have been damaged.

This is a really difficult problem.

On the other hand, there’s nothing more frustrating when I submit a hand-written issue to an open source project, happy to implement it if they approve, and then their bot closes it with some AI slop comment that indicates it has no idea what I’m talking about.

On the plus side it’s easier than ever to patch or fork projects. So at least this toxic gatekeeping behavior matters less than it used to.

> Does open source matter anymore?

I mean, did it ever? It depends what you mean. Very few open source or free software projects are successful in any meaningful sense.

I agree with the core maintainer complaint here: PR slop is bad, and maintainers should not be forced into reviewing code the submitter does not understand.

But I think the answer is not “don’t slop me, all you sloppers.” The better answer is closer to: “what problem were you trying to solve?”

There is no obligation to treat every PR as merge-ready code. A PR can also be a concrete issue report or a proof-of-concept for a bug. It can say: I found a problem, I investigated it, and code was the clearest way to show where I think the issue lives and how it might be addressed. Use or ignore the implementation as you like. Human-language descriptions are not always the best way to communicate something you've already traced through the codebase.

That can be a high-value contribution even if the code itself is not accepted. It moves the conversation from “I want X” to “here is where X touches the codebase, here is a failing case, here is a possible direction, here are the tradeoffs I noticed.”

The social contract should be that the contributor does not dump review debt on the maintainer. Mark it as a prototype. Explain the problem in your own words. Say what you tested. Say what you are unsure about. Be willing to revise or accept that the maintainer may throw the patch away.

But once framed that way, the relevant question is not whether AI was used. It is whether the PR reduces ambiguity or increases burden.

A sloppy PR that demands review is bad. A prototype PR that explains a real problem is often useful.

This blog post had serious "old man yells at cloud" vibes for me.
The priesthood doesn’t like that the peasants can read the Bible for themselves now.