Don't Ask, Don't Tell

Posted Aug 8, 2025 9:15 UTC (Fri) by rgb (guest, #57129)
Parent article: On the use of LLM assistants for kernel development

At this point in time I think the only reasonable stance is a don't ask, don't tell policy, which is also basically the status quo anyhow.
At the end of the day, a human is the author of the patch. He or she is responsible for the content and also the point of trust that can hold or break.
How they came up with the code, what tools they used, might be interesting, but not more than what school they went to or what other projects they are working on. It's tangential in the end.

Don't Ask, Don't Tell

Posted Aug 10, 2025 11:16 UTC (Sun) by abelloni (subscriber, #89904) [Link]

This is not true, there is a difference between a patch made to silence a static checker and one for an issue that was actually seen in the field.

Don't Ask, Don't Tell

Posted Aug 10, 2025 14:45 UTC (Sun) by Wol (subscriber, #4433) [Link] (1 responses)

> How they came up with the code, what tools they used, might be interesting, but not more than what school they went to or what other projects they are working on. It's tangential in the end.

Not if it affects the TYPE of bug that is in the code! As I think someone else pointed out, AIs and humans make different sorts of bugs. And if you don't know whether it was an AI or a human, it either (a) makes review much harder, or (b) makes missing things much more likely.

Having seen some AI code (that I was given) I wasn't impressed. It did the job, but it wasn't what I would have expected from someone who knew our coding style.

At the end of the day, I'm all for "no surprises". Who cares if it's an AI or a person. What matters is that it's declared, so the next guy knows what he's getting.

Cheers,
Wol

Don't Ask, Don't Tell

Posted Aug 11, 2025 7:47 UTC (Mon) by kleptog (subscriber, #1183) [Link]

> Having seen some AI code (that I was given) I wasn't impressed. It did the job, but it wasn't what I would have expected from someone who knew our coding style.

But then it's easy right? "Doesn't match our coding style" is a perfectly valid reason to reject a patch.

I believe I got it from the PostgreSQL lists: after your patch the code should look like it's always been there.

Arguably, if new code doesn't follow the coding style (which is much broader than just where to put whitespace) then the author has not yet understood the code we'll enough to be submitting. Which covers the LLM case perfectly.