I'm an OSS maintainer and to me it's not just about the review itself. Being greeted by a wall of text for every little small thing is counter-productive. I hate going through 2 pages of text for each PR. It usually shouldn't take more than a couple of sentences if you understand the issue and the solution.

But most important for me: lots of time the PR just adds even more code, although other options do exist (ie sometimes REMOVING some code). You have to know the codebase well in order to find those objectively better solutions.

The question becomes, does it take more time to create or review in the Grand scheme of the software life cycle?

Because if it's still a time saver, even with the increased review load, then it's a win, correct?

I'm not a coder so I have zero idea. Thoughts?

This is Amdahl's law in action. [1]

Until we figure out a good way to leverage humans in all of this ("Attention is all you need" applies equally to humans as it does to models) productivity gains for the system will always be limited by Amdahl's law. Gwern has an excellent post on this. [2]

[1] https://en.wikipedia.org/wiki/Amdahl's_law [2] https://gwern.net/guardian-angel

Do all of these folks get the comped Pro Max subscriptions? If not O&A should be.

Or, at the very least, the community should be paying for them.

I'm not convinced it blows up. It might also end up placing a larger burden on contributors, and especially first-time contributors, to provide concise, high-quality documentation that justifies their contribution.

I'm thinking of something like: Explain, in at most 300 characters, why we should merge your change, or at least why we should invest the time to read a longer explanation (somethings things ARE complex). If you don't do that, or those 300 characters aren't convincing, or have nothing to do with your change or the longer explanation, then you get a canned response so the maintainers waste minimal time.

Nah, that was already blown up way before LLMs existed.

Foss wasn't exactly not miserable before 2022. The dysfunction just got amplified so that we cannot fix it anymore by just throwing more human resources at the problem.

that seems like two separate problems.

too many patches from unknown and untrusted contributors is a triage problem - telling a known and trusted contributor they can't use AI to help work on something just because other people are sending slop for review is throwing the baby out with the bathwater.

We need sufficiently severe penalties for vibe coding. First time out we break your legs, but if you come back with another vibed patch its around the back of the barn for you.

Nuke it from orbit.

Nothing. And that's the problem -- the issue isn't "should a contributor be able to use AI" it's quickly becoming "is this entire contributor an AI agent". Every actual-human who gets a bad first experience hurts the project. The contributors having to be suspicious of new people hurts the project. The whole thing just sucks, and I don't know how to fix it.

I use claude-code, but the AI ecosystem and some of the autonomous tooling coming out of it -- which some people "helpfully" use irresponsibly and point at OSS projects they aren't personally invested in -- enables a LARGE amount of abusive behavior towards open source projects. This is even before we get into how many infrastructural resources crawlers eat up.

Me, and most other OSS contributors, signed up to be a mentor, to create software, to work together ... not to be the equivalent of a reddit moderator banning AI agents left and right.

I can't speak for all, but many mature open source communities have explicit or ad-hoc reputation schemes that are used to triage contributions. A fresh account means starting over with zero reputation, which in turn means your contributions wait at the back of the line.

Well. This is Debian, known for how strict they are about vetting developers. I just remembered Sladen refusing to key sign because my passport circa 2005 didn't have a machine readable slug in it.

https://www.debian.org/devel/join/newmaint

What part of [0] or [1] makes you think that it is easy to have multiple accounts?

[0] https://wiki.debian.org/DebianMaintainer#Becoming_a_Debian_M...

[1] https://wiki.debian.org/DebianDeveloper/JoinTheProject/NewMe...

Debian is notoriously very strict on accepting maintainers and they are not anonymous.

Reputation, or lack thereof.

Proof of authority, essentially.

Presumably they are trying to farm karma / reputation, which (I think, mostly) doesn't work if they need to switch accounts all the time.

What stopped them before?

In anonymous systems, where we don't use real names, your "handle" has an "age". That becomes your most prized possession.

I have a reddit account thats over 12 years old. I have left the posts/comments open. That means, my "post history" becomes a way to advertise my skills. I can reference comments from a year ago or 6 months ago about a certain topic to show how I handled something. That does have an effect on people.

As opposed to a random 1 day old account. No one takes them seriously, I guess the same is here as well

So is asking a human to write code, if you think about it…

> Are there examples of anyone discussing this and reaching other conclusions?

Yes. Very notably: https://ziglang.org/code-of-conduct/

Yes. There are pockets of hardline anti-LLM policies for various reasons.

SourceHut bans LLM generated code from their platform https://news.ycombinator.com/item?id=49461724

The Asahi Linux project bans LLMs. Unfortunate as LLM reverse engineering and driver writing would bring Linux to more Mac models much faster.

The Zig project rejects LLM based contributions.

Some of these policies were introduced when LLMs were really bad at writing code and haven’t been revisited. Some groups don’t care about the quality and object on moral or copyright grounds.

I could imagine (in a commercial organization) a case for something like: "we're obviously going to be relying more and more on AI, so if bad code comes out of it, instead of just shaming the engineer, let's study together what happened -- what was the chat context, the model, the system prompt, etc... ? What seemed to cause the issue? What processes or systems could we put in place to improve it? Etc... -- and then use the learnings to improve AI use throughout the whole org."

As others have said there are other conclusions going both ways (though I do think most settle on as you said), though one very fair conclusion I came across is that it's not allowed because the whole issue of copyright is still somewhat unresolved, and though its fine right now, that could (probably wont, but could) massively backfire later.

> I was referring specifically to the idea that you have to stand by the code that you write.

Any serious entity which has experts handling code will do so, yes.

My employer, for example, has various teams of actual developers and others with a significant number of “not really” devs who found their way into DevOps roles. The teams with seasoned developers hold the author responsible as to the integrity and quality of code, regardless of tools used. They won’t hesitate to call someone out directly for low-quality submissions in Teams channels. The teams that have a lot of “not really” devs will blame the model for issues that surface. Of course, they’re also pushing to not have to write any code directly by FY2028, but instead have models do it as part of an internal AI initiative. Somehow the idea of using AI to generate reports, process reports, write code, test and deploy got signed off.

Many.

https://lobste.rs/s/29pm2f/llm_generated_submissions_should_...

https://sourcehut.org/blog/2026-08-27-tos-changes-and-llms/

https://blog.codeberg.org/protecting-our-floss-commons-from-...

https://ziglang.org/code-of-conduct/#strict-no-llm-no-ai-pol...

https://lwn.net/Articles/1086041/

https://asahilinux.org/docs/project/policies/slop/

Yep, in both directions. Some projects ban use of AI entirely. Others are happy to live with slop.

I think the key thing you are missing here is that most successful open source maintainers don’t lack expertise, they lack time. They are generally capable of improving their projects in any direction they want without help. Mentoring new contributors is basically always a loss in the short term as far as the maintainer is concerned. The project does get improved, but it generally takes longer than if they did it by themselves from scratch, and the improvements might be in an area they don’t much care about. The payoff for the maintainers only ever happened in the long term if the mentorship succeeded and they get a viable independent long term contributor.

The change with this justification absolutely exists and has existed for a long time, but this justification only works for small changes (in the past and still today). Don’t come to me with a huge refactor or new feature and this explanation, which is happening more and more recently (it’s an easy strawman to make and hard to prove, but I certainly see it in practice).

I have had the same experience and feel pressured to adopt it. I had one former colleague say “you really have to stop looking at code” almost incredulous that I was uncertain about whether we should let models write really bad code and architecture that never would have been allowed in the before times. I will say when I let the agents go autonomous I often find I spend more time refactoring than if I had moved slower and forced them to write good code and follow project architecture patterns.

IDEs enable us to not bother memorizing the number and order of arguments, long names beyond the first word or two, etc. the impact is comparable, freeing some of the very limited space in our memory for more important things.

sure, students and juniors shoot themselves in the dick if they let LLMs do everything, but they're fucked anyway so it doesn't matter,

It doesn't apply to everyone, but yes I know people who are over-reliant on LLMs and definitely getting dumber. With devs and non-devs too. I hate seeing this happen.

It is insiduous how easy it is to stop thinking. When writing complex code it seems like most of the time it would have been faster just to write it myself and build a complete understanding of it. I swear if I asked most engineers at my company to describe their changes recently they would be unable to.

That's a cultural thing. Push back on it and don't make it acceptable behavior. I would argue most people generally are terrible at code review and do this same behavior with their peers as well, but at least their peers are capable of owning some level of responsibility, whereas the LLM is not.

That's what delegation looks like, but it needs a better process.

They could be committing plan files alongside any nontrivial change to application code, and the plan file can have everything you'd care about, like the invariants it held to and why, the rejected ideas and why, the acceptable risks and why, etc.

This is solved by better usage of LLMs, not less.

The divide to me isn't engineering skill vs those who lost it, it's people who care vs. those who don't care. It's a higher level thing now that we're working at a higher level (delegation).

I think LLMs make programmers lazy more than anything. And when programmers stop programming for extended periods, they lose their programming skills. No surprise here. Use it or lose it.

I think a possible solution on both fronts (maintaining software quality, preventing skill atrophy) may be implementation of strict token budgets. Make the individual programmer choose how they are going to spend their limited tokens for the day/week. Provide just enough to use it as a plan/development/review tool, but nowhere near enough to just go full send AI vibe coding software factory slop mode all day long.

There’s certainly an analogue to package managers, which made it easy to pick a random package rather than writing the code.

We survived. Some upsides, some downsides, life continues.

The LLM did not require them to ignore their code. That's a choice they made.

They made choices that made them dumber is what I'm saying.

You could also say the same with desktops. Desktops abstracted CLI commands like mv or ls. People who are taught on desktops will get scared when they see a terminal.

Yet programmers will still know commands. Abstractions can make things easier but it doesn't require losing skills.

You can just ask Claude why it did something in the code and it will tell you

Programmers just moved up a level , not dumber, we are now managers of a team of 'agent' programmers. The deliverable is now a functionality instead of a specific block of code

> Except LLMs actually are making programmers dumber.

And compilers made every software engineer worse at writing Assembly and better at skills higher up the stack. This will be no different.

> Except LLMs actually are making programmers dumber.

Make that some/a lot, but not all.

There is a clear bifurcation. A lot of those that never cared really don't care now, but then you get others that can use it to crank that much harder than ever before.

If you put the same brain effort in but leverage LLMs you really can be dramatically more productive.

They're not dumb. They just don't care. They didn't before either. Now they just have an easy excuse.

I just means I'm gonna be filthy rich in a couple of years when most programmers have lost their proficiency and me never having used Claude or any other A.I. slop tool.

That’s just stupid.

Copyleft licences rely on copyright. If that was the case, companies would not massively avoid gpl licensed code.

Obviously some do it illegally but unenforceable is not the correct word to use.

That might be your intuition but it’s not how the law works for code ownership. It’s very relevant for free software given the whole principle of free software is a copyright hack that protects a set of freedoms by relying on the copyright being recognized and enforceable.

If you drop the copyright claim you drop the protection of free software freedoms.

Software is one of the most derivative types of works ever invented. It's arguably based on copying what other people have already created. The modern world would look a lot more primitive if this wasn't the case.

Corporations like Coca-Cola long ago figured out that begging people not to steal your ideas is a waste of time. If you don't want people using your ideas, then don't share them.

Dunno why so many programmers don't get this and seem perpetually butthurt that other programmers figured out the ultimate way for programmers to rip off each other's code.

Different models have different licensing. Maybe open ai or anthropic doesn't claim ownership of output today, but some companies do. https://www.recraft.ai/docs/trust-and-security/ownership

I imagine few can afford a legal battle...

Free plan

Images generated on the Free plan are public and owned by Recraft

> It kind of is if the company mandates LLM use.

It's not, because you can still quit.

> programmers are suddenly expected to be perfect reviewers of code they didn't write

What? The reviewer (me) caught the injection in the code I didn't write.

Running /code-review and /security-review on your own code before submission is bare minimum, not perfection.

We don’t know yet because that’s an unresolved matter. The question of ownership is currently undefined as far as I understand. It could be that after an actual legal decision the ownership doesn’t end up being one of those 2 cases, for whatever reasons the judge would decide

We are talking about Debian, a free software that cares a lot about the licensing of its packages. The licensing and authorship is an essential element of the project

you completely missed my point, but no matter, it's all ai bot shillers at this point here anyways. enjoy your ai slop.

read my fucking comment again

you naive idealist

Well said. No one should trust an llm without verification/validation. They're just not good enough to do that and they have no sense of responsibility or ability to take it themselves. LLMs are empty.

"Human understanding" is not yet an objectively quantifiable metric that can be applied to code change sets. As it would only ever be self-reported (a claim made by a user submitting to a repo), I see little to no value in it.

> If it doesn't work well then it naturally loses trust

Too late. If it doesn't work well then it has already naturally destroyed trust.

A few people certainly refused to use AI at all, but several actually used AI for programming and agreed it was useful, but stopped due to being conscious of the environmental footprint. (That’s very similar to the last proposal in this Debian debate.) I don’t really agree with them, but I concede it’s a valid opinion.

What does that have to do with it? Debian developers are the audience and most of them are not programmers. And the parent post was speaking even more generally.

You mean the most effective way to enact social and political change is not to stand next to someone at the urinal and tell them you are a vegan?

What is “disconnected from reality” about environmental considerations regarding AI? Growing AI usage = growing data center power draw = higher emissions from any non-renewable sources contributing to that power, as well as increased freshwater consumption which is itself a considerably difficult resource to renew. That’s about as direct of a causal link between point A (power hungry AI being used for Debian development) and point B (the environment) as you can get. On the other hand, please explain what the hell veganism has to do with Debian development? Like what are you talking about.

Yeah it's a bizarre claim. Even better, I've literally taken some of the crappy experimental projects from the pre-Opus 4.6 era, and turned them into real software as models have become smarter.

I would say it's a mixed bag. On the one hand, yes, you can experiment with big changes much more easily, but on the other hand, you can have cruft build up in a big way if you're not actively looking for it and trying to cut it back.

In Debian, often the barrier to change is one or two people actively disagreeing with a change who are in a position to block it through their own action or inaction, so just being able to do more work on the change yourself is not necessarily going to make it easier to change things.

Yeah. We shouldn't have standardized languages either. Everyone was fine with their own regional dialect for hundreds of thousands of years.

Certainly, but if everyone can vibe code their printer drivers then we have free software in the sense of free speech and so users would be developers and the entire need is met. That is wonderful, not awful.

If it had happened early enough, code copyright might never have even been possible and no one can deny you your machine because you can just vibe up stuff.

Yes, I experiment much more. It's easier to justify, and, perhaps more importantly, just WAY psychologically easier to throw away a 20 minute experiment that your robot wrote for you than the same when it took you a week of tedious manual coding.

That's an interesting opinion, and I certainly won't downvote you for sharing it, although it's not a position I would ever support. You are right though, that it would strengthen the voted-on position if there were more options either side of the position.

I have Things To Say about LLM reviews.

They are an endless grind. My biggest source of burnout right now is never being able to finish anything, because the LLM always finds, "Just one more thing" every time I send it back.

It's pure polish. The major issues were dealt with long ago. But there's always one more thing that could be done a little better, there's another niche edge case that needs wrapping up.

When human developer time was the limiting factor, it was easy to draw a line in the sand and say enough is enough.

It's harder to say no when it's just one more prompt and one more go-around.

Demanding LLM reviews on volunteer maintainers sounds like a great way to quickly end up with no maintainers.

Meanwhile there's unfortunately still plenty of maintainers refusing to use version control systems...

Much better at satisfying formal specifications (what they were trained for), but not yet good at long term maintenance.

For long term maintenance you need to throw features out / delete code, which requires a deep understanding of the balance between what the code can survive and what is really needed in reality while not growing the code base too much (which neither LLMs nor humans can handle)

Whoever controls the AI, as per the article we're discussing.

Debian isn't a free-for-all, they don't accept fly-by-night contributions, there needs to be a real and serious person behind every contribution.