So how do they gatekeep the vibecoders out then? FOSS need to change and develop new quality control systems.
Stop complaining about vibecode, just review it before you use it. Why can’t you do it?
Limit lines of code or diff size. Limit scope. Limit PR per user per month. No bots, obviously. New users don’t get to send anything, they can comment and vote, at best. And bring in negative ratings for contributors: low quality, suspicious code, bad PRs.
This is another way of saying deceleration, a word that accelerationists hate.
There is no way I could possibly review my coworkers’ 1000s of lines of code he posts daily. I just blindly approve it because fuggggit we don’t care about quality only velocity.
This is different from before because before he would normally post 2 or 3 small code changes per week. Also, he would have tested it himself so starting off it would already be in a good state. Also, since he tested himself, we could talk about the change since he still had the context.
Now it’s just ship, ship, ship. We literally can’t “review it” like we did before. That world is gone.
Because the pace of code production has officially overwhelmed the human capacity to review it. As it was discussed recently. Linus answer was to use more AI, with the implementation of code review tools that gobble up code and spew out summaries.
For the time being, humans reading the summaries count as human reviewed. But at some point in time this system will crack. The current zeitgeist is to restrict who can contribute. Which leads to the obvious follow up question of who decides based on what, and how to decide who deserves to contribute.
You just witnessed the first steps into the philosophical and political erosion of the open source movement. Not just on the kernel but it is also affecting almost all popular FOSS projects.
But of course, that doesnt matter because Linux is not and has never been political. /s
So how do they gatekeep the vibecoders out then? FOSS need to change and develop new quality control systems. Stop complaining about vibecode, just review it before you use it. Why can’t you do it?
rationing:
Limit lines of code or diff size. Limit scope. Limit PR per user per month. No bots, obviously. New users don’t get to send anything, they can comment and vote, at best. And bring in negative ratings for contributors: low quality, suspicious code, bad PRs.
This is another way of saying deceleration, a word that accelerationists hate.
Hahaha. Not a developer, huh?
There is no way I could possibly review my coworkers’ 1000s of lines of code he posts daily. I just blindly approve it because fuggggit we don’t care about quality only velocity.
This is different from before because before he would normally post 2 or 3 small code changes per week. Also, he would have tested it himself so starting off it would already be in a good state. Also, since he tested himself, we could talk about the change since he still had the context.
Now it’s just ship, ship, ship. We literally can’t “review it” like we did before. That world is gone.
Because the pace of code production has officially overwhelmed the human capacity to review it. As it was discussed recently. Linus answer was to use more AI, with the implementation of code review tools that gobble up code and spew out summaries.
For the time being, humans reading the summaries count as human reviewed. But at some point in time this system will crack. The current zeitgeist is to restrict who can contribute. Which leads to the obvious follow up question of who decides based on what, and how to decide who deserves to contribute.
You just witnessed the first steps into the philosophical and political erosion of the open source movement. Not just on the kernel but it is also affecting almost all popular FOSS projects.
But of course, that doesnt matter because Linux is not and has never been political. /s