What about false negatives? [LWN.net]

What about false negatives?

Posted Oct 18, 2025 17:27 UTC (Sat) by alx.manpages (subscriber, #145117)
In reply to: What about false negatives? by ojeda
Parent article: Large language models for patch review

> It is a broken assumption, and a counterexample is trivial: someone runs a tool that finds an issue with a patch, and the author fixes it before submitting.

I remain unconvinced. Here are a few counter-counterexamples:

Someone runs an AI tool that finds a false positive. The AI fools the programmer to believe it is valid, and results in the introduction of a bug instead of a fix. AI tools can fool humans easier than regular tools.

> Of course, there are costs to running many tools, diminishing returns, etc. But that is a different discussion.

I think it's part of the same discussion. Let's go bad to my first post: what about false negatives? Running an AI tool might lead a programmer to be more convinced that the patch is good, and thus less prone to running other tools, or asking other humans to review a patch. Those other tools or humans would probably do a better job.

Should one run 10 regular tools vs 5 regular tools and an AI tool?

It would only make sense to run the AI tool if you've already run *all* of the existing regular tools *and* also asked all of the humans that could help. But at that point, we're deep into diminishing returns.

And there's still the possibility that the AI tool might fool you into breaking a good patch, breaking what those humans had reviewed.

to post comments

What about false negatives?

Posted Oct 18, 2025 19:06 UTC (Sat) by ojeda (subscriber, #143370) [Link] (8 responses)

> Here are a few counter-counterexamples

Those are not counterexamples -- you said "always", not "sometimes".

And even if you meant "most of the time", if there is a tool so bad that it is wrong often enough and, on top of that, manages to misdirect authors often enough, then it will simply stop being used sooner or later. That applies to all tools, not just AI-based ones. We could be talking about a bad compiler warning that gets disabled, for instance.

> Running an AI tool might lead a programmer to be more convinced that the patch is good, and thus less prone to running other tools, or asking other humans to review a patch. Those other tools or humans would probably do a better job.

You could argue the same about running `checkpatch.pl`, or a static analyzer, or even warnings in your compiler, or even using a safer language...

That doesn't mean every reviewing tool should be banned.

> *and* also asked all of the humans that could help

That doesn't apply in the case I mentioned: someone reviewing their patch before submitting it.

And your policy bans even that.

> But at that point, we're deep into diminishing returns.

Not really. Tools are fairly different from one another, even in the "regular" set you mention, and LLMs are quite different from the "usual" tools. It doesn't even need to be about reviewing code.

What about false negatives?

Posted Oct 18, 2025 19:45 UTC (Sat) by alx.manpages (subscriber, #145117) [Link] (7 responses)

> Those are not counterexamples -- you said "always", not "sometimes".

A liar may sometimes tell the truth. The problem is that if it sometimes can be a lie, you need to consider it *always* as if it were a lie. The quality of a contribution doesn't exist in a vacuum, and the possibility of it being a hallucination is already lowering the quality, even if a given instance is actually good.

What about false negatives?

Posted Oct 18, 2025 20:03 UTC (Sat) by mb (subscriber, #50428) [Link] (5 responses)

>if it sometimes can be a lie, you need to consider it *always* as if it were a lie

I think that this conclusion doesn't make any sense at all.
By the same reasoning you would have to make compiler warnings being 100% correct all the time or ban the use of the compiler that gives you false warnings (every compiler).

What about false negatives?

Posted Oct 18, 2025 21:06 UTC (Sat) by alx.manpages (subscriber, #145117) [Link] (4 responses)

There's a big difference between false positives or negatives in a compiler, which are deterministic. You can reproduce them, and know when the compiler has you covered or not. Also those false Ps and Ns almost always decrease, with regressions being rare (but again, when they exist, at least you can reproduce them and file a bug).

With an AI tool, there are no rules. You may have the same exact chat with the tool twice, with different results.

I'm amazed by how few people seem to value determinism in tools.

What about false negatives?

Posted Oct 18, 2025 21:09 UTC (Sat) by mb (subscriber, #50428) [Link] (3 responses)

You are moving the goal posts.

What about false negatives?

Posted Oct 18, 2025 21:34 UTC (Sat) by alx.manpages (subscriber, #145117) [Link] (2 responses)

> You are moving the goal posts.

I don't think so. I've consistently meant that it's because you don't know when AI lies to you that you must assume it always lies to you. If I know when you're going to lie to me, I know when to ignore you, and thus you're going to have a hard work lying to me.

Maybe I wasn't explicit enough here (I tend to not repeat _everything_ every time I discuss a topic; I assume people can follow links, and also use common sense), but I've said this before in the mailing list where the policy is being worked on. I've also argued this point elsewhere when debating AI tools.

And that was the rationale for the following paragraph in the policy, in the first place:

+ AI tools should be considered adversarial, as if they
+ were a black box with Jia Tan inside them.

What about false negatives?

Posted Oct 18, 2025 21:42 UTC (Sat) by mb (subscriber, #50428) [Link] (1 responses)

>you don't know when AI lies to you that you must assume it always lies to you

Therefore, you must assume any classic tool lies to you.
A compiler gives you false positive warnings so you can't know whether a warning is real or not.

What about false negatives?

Posted Oct 20, 2025 8:45 UTC (Mon) by taladar (subscriber, #68407) [Link]

But the compiler or other classic analysis tool always gives you the false positives for the same type of edge case, the AI tool is completely random in when it hallucinates.

What about false negatives?

Posted Oct 18, 2025 21:01 UTC (Sat) by ojeda (subscriber, #143370) [Link]

A reviewing tool being wrong sometimes (AI or not) doesn't mean a patch gets always automatically modified. Even if a patch gets modified in a wrong way at some points, it doesn't follow that on average it is all a net negative. What usually happens is that tools get disabled if they are not worth it, but you haven't shown that.

And even if you are talking about second order effects like "it wasted time I could have used in a better reviewing tool", you would still need to show which ones are the better tools. And even if one tool is way better than another, it doesn't automatically follow that it isn't worth it to run both. And so on and so forth.

So, no, your logic doesn't follow, sorry.

And it is not just reviewing that your policy bans. The policy casts such a wide net (banning even tools "in the contributing process" that do not generate code) that people cannot even report bugs found with those tools when applied over the codebase. So, for instance, an external team that runs such tools for other projects will need to skip your repository, even if they manually curate the results and so on.