Replying to an earlier post

Torvalds was careful to frame this as a correction of language rather than a rejection of the technology itself.

Ok…

A maintainer burden few are talking about

Alongside the productivity gains, Torvalds described a less-discussed cost: a rising flood of low-effort, AI-generated bug and vulnerability reports hitting open source projects, including the kernel’s own security channels. He said it has become common for someone to run an AI tool against a codebase, file a report flagging a “possible” issue, and then vanish when a maintainer follows up asking for more detail or a fix.

Everyone is talking about that and it is surprising to me that he doesn’t recognize that as two side of the same coin. Why are you rejecting the low-effort, Ai generated bug reports, Linus, isn’t AI just a productivity tool? What’s wrong? Is it not being productive?

I say “surprising”, it’s not that surprising. It’s a “guns don’t kill people, people kill people” attitude. It’s willfully excluding the impact that technology has on people, and framing the outcome as coming purely from people and the existence of the technology not affecting the outcome.

Replying to an earlier post

Why are you rejecting the low-effort, Ai generated bug reports, Linus, isn’t AI just a productivity tool?

Because they are low effort. Good software engineering is never low effort, whether you use AI or not.

If you let AI replace people, and let them mess with software or report issues without understanding what’s going on, without putting in the effort to understand what’s going on, you’re not adding any value; just noise.

But if you use AI to find issues, then investigate the issue, reproduce it, document it, etc, then you’ve got something meaningful that someone can do something with.

Replying to an earlier post

But if you use AI to find issues, then investigate the issue, reproduce it, document it, etc, then you’ve got something meaningful that someone can do something with.

In principle that is sound, but LLMs can’t do that, yet, if ever. Sounds like anthropomorphism. The ‘hallucination’ thing is intrinsic. What you can do is point it at easily verifiable problems like searching for security flaws, and then verify them. Whether that’s cost effective in wasted energy and human time is still an open question, especially as token cost ramps up pre IPO.

en

Replying to an earlier post

They can find issues now though. Will they also find non issues due to missing context or not understanding the whole operational picture, well yes, but you can usually filter those ones out quickly. While i wish we had QA back and it be a norm again in software engineering as a whole, without it I’m happy to have something look for ways my code will break in unexpected manners that testers previously handled. Is it the same as having someone sit their and try and break your shit for the sole purpose of finding a spot where something will go completely off the rails, no its not but with a lack of true QA and rushed timelines that leave little room for quality QA yourself. I dont mind having something else that will try to gage my code from all angels and suggest areas that might have bugs I did not intend for or did not catch when I was reviewing my code. Especially considering I can do this without making users of my code the guinea pigs in lieu of an actual QA department. Sometimes you have to make the best of a shitty situation and honestly its an improvement over no QA which has been a norm for a while now so I’ll take the small wins where I can