There appears to be a few bad actors in the Lemmy community spreading ragebait for personal gain
In fact, the same mechanisms added at the beginning to catch bad human written code are the exact same that catch bad AI code
- No, the Linux kernel DOES NOT use AI to automatically approve code for inclusion. As far as I can tell, there are no plans to do so
- The Kernel actually has a huge number of maintainers. As part of the process, all patches are reviewed by a human who provide feedback as part of the process, and patches get bounced back and forth multiple time.
- Patches don’t just magically go straight to master. The maintainers generally have their own branches where it goes to, then it goes to staging trees like Linux-Next. It goes through many eyes, and many tests by the end. The idea that AI code is overrunning the kernel is rediculous
- Maintainers also check that the code meets coding guidelines and is written properly, and solves the problem they are trying to solve. Yes, they also ensure the code isn’t slop
- LLM’s though might be used to identify obvious problems with the code (which they are VERY good at), or even identify code that doesn’t follow coding guidelines.
- The only thing that matters is the human who submitted the code, as they should be checking the code submitted anyway (including LLM generated code)
Writing bad code isn’t something new, and isn’t unique to LLM’s. Coders (and it seems some “journalists”) have been writing slop since computers were invented.
The process hasn’t gotten less stringent (probably even MORE stringent as there is an additional set of robotic eyes that can also check), and the same mechanisms that were put in place to catch badly written code 10 years ago, are still there now… With no changes.
Code linters have existed for decades, that doesn’t require LLMs
That’s how I feel about autocompletion and scaffolding, we’ve had LSPs and code generators for years, and they’re exponentially less wasteful
AI code review finds a lot more bugs (such as logic bugs). But yes linters can be used for that specific case
Not all guidelines are enforceable with linters. For example one of our code bases at work defines when to avoid mock tests, how integration tests should look like, how a module’s architecture is supposed to be, how the naming convention for components of the different layers are, etc.
Those are super ugly to formalize into a linter but super easy to check with an LLM.
Huh. Really? How is the LLM checking it? Is it writing code to check those specs, or are you just along it directly if the code matches the specs?
Normal text based analysis; which LLMs are pretty good at. So our coding agents can follow the rules during development and the review agent can follow it during review. Only static code checks are enforced in the CI pipeline; the review agent only leaves remarks. If we decide to not give a damn, we can still merge it. But its hit-rate is relatively high; so typically when it finds something, it’s valid and its recommendations for fixes are also often pretty good. This helps already iterating on a PR on your own before you pull human reviewers in.