This is true but I find it almost entirely irrelevant. Everyone’s code review practices are skewed by their incentives. Therefore “code review” is not one thing and very little of it is objective.
When accepting the code from a human-submitted patch set, Linus loses none of his own productivity when rejecting the code. One of his super powers is having almost no specific productivity goals for the kernel code. He has plenty of productivity goals related to the kernel development process and he would certainly see a change-less release cycle as unproductive. However there has been no lack of supply on the change side for 30 years. When he is reviewing the code of an LLM, in the pursuit of some code production goal of his own, the quality bar for him accepting the code is lower. How much lower is an open question. However I think it is beyond debate that the demands of code review for others is drastically different than code review for our own ends.
Critically, rejecting a human-submitted patch has a long term productivity benefit in many cases. Each of those rejections is a chance for Linus to not just make the engineer better informed about the kernel but also more familiar with the processes and values of the kernel project. I think it is safe to say that no one has become a subsystem maintainer without having many patches rejected. When Linus rejects a code generation from an LLM there is barely even a signal of positive intent to discard it. The code just goes unused.
This is true but I find it almost entirely irrelevant. Everyone’s code review practices are skewed by their incentives. Therefore “code review” is not one thing and very little of it is objective.
When accepting the code from a human-submitted patch set, Linus loses none of his own productivity when rejecting the code. One of his super powers is having almost no specific productivity goals for the kernel code. He has plenty of productivity goals related to the kernel development process and he would certainly see a change-less release cycle as unproductive. However there has been no lack of supply on the change side for 30 years. When he is reviewing the code of an LLM, in the pursuit of some code production goal of his own, the quality bar for him accepting the code is lower. How much lower is an open question. However I think it is beyond debate that the demands of code review for others is drastically different than code review for our own ends.
Critically, rejecting a human-submitted patch has a long term productivity benefit in many cases. Each of those rejections is a chance for Linus to not just make the engineer better informed about the kernel but also more familiar with the processes and values of the kernel project. I think it is safe to say that no one has become a subsystem maintainer without having many patches rejected. When Linus rejects a code generation from an LLM there is barely even a signal of positive intent to discard it. The code just goes unused.
score 1 · canonical