This here might hit the nail on the head exactly in terms of what the biggest FOSSes gripe with LLMs with might be: not the fact people use it but rather how it hinders the communication.

If you use it to help the write code, but you explain things in your own words or, at very least, redact and trim LLMs output, it's fine.

If you, however, just drop a wall of text at someone and expect they act on its b/s, this is lazy to the point it borders with microagression.

You wouldn't expect a distinguished professor explain basic maths to a student, and we shouldn't expect actual developers address Copilot's stupid, unredacted hallucinations or otherwise unrelated remarks.

This works for patches submission, too: you should be outright banned for submitting stuff you didn't bother to double check and properly document.

This is what I fear will push its way into every part of society soon, too.

"We're not forcing you to do your banking through our AI interface instead of a normal one, you're free to opt out, but multiple functions will be missing and we'll charge you a monthly fee."

"You don't have to have an LLM grade your exam, but beware that the human grader will be overworked and grumpy for the extra task."

But to upload to debian new's queue you already need to have pre-approval, it's a different situation from e.g. a public git repository that anyone can push to.

While I'm perfectly on the same page with the critics of the LLM generated summaries, I'm a bit torn on the issue.

For anyone not familiar with Debian ecosystem, there's a helper tool called Lintian. Lintian does all kinds of checks from package formatting, licenses to dependency management (which can detect both unnecessary yet included and necessary but missing dependencies via static analysis of your tool if necessary).

It's expected that your package to be "Lintian clean" to be able to included in Debian with minimum friction and wait. Even though it's Lintian clean, your package also checked by teams which are severely understaffed, and composed solely of voluntary people.

NEW queue also receives tremendous influx of packages (which can be considered a torrent, even). Since noon, there are 10 more ITP (intention to package) bugs open in my inbox.

As a result, at one hand, these people need every help they can get because getting new trainees and getting them to learn the intricacies is hard, on the other hand LLM generated text rightfully generate negative reactions from people. However, giving developers an automated check of what looks right and what looks wrong is helpful, in my perspective.

I wonder what people would have said it was a deterministic tool generating these reports and sending people these summaries as a "hey consider this feedback until a human has time to see your package".

This is a hard question and we need to think before impulsive reactions. I even don't have all or any of the answers, but at least I have some insight why this is there.

Sure LLMs are not nearly as rigorous about their output but that doesn't mean it's entirely not useful.

At a minimum you can have your LLM summarize the other LLMs output and go from there.

> Nitpicks on style, not substance

> Async waiting for review or re-review after making changes, harder to stay in what passes for a "flow state" nowadays

> A lot of a ceremony around straightforward changes

Those aren't great, but you what I like even less?

- Wall of nondeterministic bot text spam that may or may not be correct.

- Bot output has not been verified for correctness by the person who set up this bot output pipeline.

- Bot output has not even necessarily been read by the person who set it up.

- You have 24 hours to respond to this 5 page wall of text which may or may not be correct, or even make sense, or you will be penalized.

An appropriate response to this might be a reply flatly claiming that, actually, there aren't any problems after all, but that nobody has checked that that is true, and it is incumbent upon a human reviewer to verify your claims, like it was incumbent upon you to verify their bot's.

Can an LLM catch some errors? Absolutely. Can it be trusted to be correct absent review of the output? Absolutely not. So the simple solution seems to be, a human reviewer is free to run an LLM against code to review, on their own computer, and then they review the output, and they post the output only after verifying its correctness, taking personal responsibility for any issues with their posted output.

Github copilot review is s great example of the worst possible way this can be misused. It is the worst waste of tokens there is.

Instead we use a process we created ourselves that runs opus or sonet (depending on complexity) to do a review (taking into account pr description and comments - copilot ignored those) and then to re-review the issues found to cut out BS.

This has been working very well mainly thanks to the prompts and docs we made it read, as well as us having lots of example code that shows how things should and should not be done.

One crappy thing Github does is that it doesn't allow our workflow based review's tokens to be accounted to individual PR authors like "copilot review" does, but accounts tokens to the organisation. It is obvious they are trying to herd people to using gh copilot review instead. But the quality difference is like night and day. So we are staying.

The way I see it the devs that put that in place are saying, listen before even reading your contribution I am going to feed it to a LLM with these instructions and see what it spits out. Now I will extricate my self from being the LLM proxy so you deal with this output and when it's okay I will look at it.

Same as "listen bud until it passes linting I won't even look at it." Just a much more flexible and fuzzy linter.

So we setup llm based reviews that catch 99% of simple problems saving us 7 out of 8 rounds of PR reviews.

Seriously. Even as simple rules as: - if you submit a PR with new X, put a link to a successful run of said X to proove it's working. - if you choose not to reuse Y, but create a new one explain why.

Those are 100% ignored by people (or their crappy LLMs more likely - so I have to teach them how to prompt, or tell them which models to use for what).

Instead of loosing sanity responding for the 10th time to someone in time zone 12h away that he tries to merge reimplementation of what we already have with no description and no test run I have an automatic llm review that tells them that exact thing 2min after they create the PR.

But with the very latest models (like, Opus 5.5 class and up), I am now of the opinion that the output, in non-creative situations like code review and most software development, is fine. Great, even. Better than the reviews a lot of humans generate.

Honestly, if you’re at all open minded about this, get a $20 Claude Pro subscription for a month (they are easy to cancel) and ask Claude Code with Opus 5.5 to review your codebase or a PR or two. I was very (pleasantly? unpleasantly?) surprised.

I have complex emotions about this (‘sad’ on balance I think - although it’s definitely not all simply in that direction), but I can’t deny it to myself.

I still bristle at reading articles and even documentation that’s not just ‘reference’ documentation written by it - and even that can get a bit weird and circuitous. But for review and coding? It’s great.

What will it be like in 6-12 months?

Opus 4.8 came out in May of 2026, 5 months ago.

/* @code-review ignore */ [...] /* @code-review endignore */

I mean you shouldn't have to, but I'm wondering if you can.

https://www.debian.org/devel/constitution

It sounds like in this case someone is not following an agreed-upon policy. And of course, even with governance like this one, the rest of the maintainers can move in a direction you don't agree with.

https://marc.info/?l=openbsd-tech&m=177411620801633

With AI, creating the tasteless thing became easy.

If you give people the ability to select a font, they will select Comic Sans.

That AI image is pretty baffling though. Setting aside the pointlessness of displaying an image in the context menu, it even looks like it was made with ancient stable diffusion from 2024 or something, modern image generators are "better" than that. I wonder when it was put in.

Then they proceed to summon a million infernal imps.

I've never considered updating iTerm. Apparently that lazieness was the right call?

Jesus. What the hell. What does that sudden AI image even offer? I guess it would make some sense in a "docs page" context (even though there it would too be slop), but as a tooltip of a menu option?

Gotta say though.. that is so unhinged, one has to respect the human ingenuity behind it. No LLM can come up with an idea so batshit insane. They're too mid for that.

Yes all the BSD's, and i think with the best explanation, since one cannot proof what license the llm's output has, one cannot legally implement the output under the BSD-License.

But what about Linux? They just dont care, they have the money, corporate backing and with that, all the power.

The question is not even about the setup in terms of hardware/software. The question is about organizational structuring of its processes.

The problem would be better solved with an opt-in.

> I will not upload anything to NEW unless there is a way for me to opt out of this. I would prefer if the default was "no LLM review" and that developers have to explicitly opt-in to receive an auto-generated review.

I was migrating cicd from Jenkins to gh workflows for some 70-80 apps each in its own repository and support team in a random timezone. I had to open 2-3 PRs in each repo and a day or two before someone enabled "copilot reviews" in our github org.

Not only did copilot eat up all my bloody llm credits (thankfully it was almost end of the month) it created few silly comments on each of those PRs I had to respond to.

So I used an llm to write a script to respond to each of those and close them.

Also the same script wrote emails to all the teams asking for approvals, sent reminders to those that ignored it over next few days and finally merged everything in the right order.

Overall I'm a big fan of properly used LLMs.

> I will not upload anything to NEW unless there is a way for me to opt out of this. I would prefer if the default was "no LLM review" and that developers have to explicitly opt-in to receive an auto-generated review.

But as the system stands he only has those 2 options. Which is why he will not use the system until they add a 3rd one.