@bekkaboo@girlcock.club Linux itself is heavily using AI models. Therefore, every Linux distribution moving to recent kernel versions is heavily built on top of using AI models. Creating a Linux distribution not heavily using it would require a hard fork of the Linux kernel and many other projects.
It's unclear what would be accomplished by banning AI for a tiny portion of the code while continuing to use Linux, AOSP, Chromium and hundreds of other projects heavily using it. We'd still be benefiting from it.
GrapheneOS is currently defending its use of AI coding tools on Mastodon against complaints by various accounts claiming to be users.
We do not understand where you’re coming from or why you’re so incredibly angry with us. It’s not justified and does not make sense.
There’s a difference between vibe coding and the hundred other ways to “use AI” on a project.
I am not talking about the Linux kernel or the Rust project - they have stabdards way above average commercial projects - but generally “using ai” in practice means to use it for code generation. Then, programmers are expected to review the output but are not given extra time for it. This creates an extremely slippery slope leading to mostly unsupervised code creation. Also because reading and understanding buggy third party code means more effort than writing new code.
Then there is the idea to get rid of the bugs by “debugging”, but debugging is frankly not a software engineering strategy, because you can always just recognize a fraction of the bugs that your process created in the first place. Debugging is also more expensive tha writing good code.
Then, what makes the process between product managers and software developers very often a bit friction-loaded is that good developers always want to have clear specifications what they are supposed to build.
LLM code generation largely replaces clear specifications with plausible assumptions. That appears to make the process fast, but the result is often wrong. At times obviously wrong, and at times subtly and catastrophically wrong.
I am not talking about the Linux kernel or the Rust project - they have stabdards way above average commercial projects - but generally “using ai” in practice means to use it for code generation. Then, programmers are expected to review the output but are not given extra time for it. This creates an extremely slippery slope leading to mostly unsupervised code creation. Also because reading and understanding buggy third party code means more effort than writing new code.
Then there is the idea to get rid of the bugs by “debugging”, but debugging is frankly not a software engineering strategy, because you can always just recognize a fraction of the bugs that your process created in the first place. Debugging is also more expensive tha writing good code.
Then, what makes the process between product managers and software developers very often a bit friction-loaded is that good developers always want to have clear specifications what they are supposed to build.
LLM code generation largely replaces clear specifications with plausible assumptions. That appears to make the process fast, but the result is often wrong. At times obviously wrong, and at times subtly and catastrophically wrong.