Hmmm
As long as they're valid fixes, I guess you can't argue, but I wouldn't want to be the one testing a whole bunch of probably unrelated fixes - also likely a bunch of duplicates.
Linux kernel boss Linus Torvalds thinks the project has reached a new normal of supersized updates, thanks to AI. Torvalds posts a weekly state of the kernel update, and last week’s message opened with his observation that “This rc is huge.” “Even by the ‘new normal’ standards this is a big rc, and I think it's the biggest rc6 …
Trust me, I can ...
How do you define valid ?
How do you know this is not a flood of *AI* generated fixes to hide a bug that can be triggered to create a backdoor ?
Or even if you can, a few 100 AI generated commits are a maintenance nightmare.
And of course, AI ruins the planet.
As long as they're valid fixes
Because there is a limited number of bugs so if there's a flood of valid fixes that will have to die down over time as there are fewer bugs for AI (or humans) to find. If you assume that each Linux point version includes fixes for 1% of outstanding bugs then you'd see a similar size of updates for each version. If AI now allows including fixes for say 4% of outstanding bugs you'd have much larger updates.
Now obviously in both cases you are also ADDING new bugs, so let's say you added 1% new bugs previously so you were in a kind of steady state that could go on forever. But if you now fix 4% of outstanding bugs if you're still only adding 1% new bugs it won't be long before you see a decline in the number of fixes because there will be fewer bugs to fix - and also the remaining bugs will be harder to find.
The only way this could become the "new normal" would be if a much higher rate of bugs fixed per update was balanced by a much higher rate of new bugs introduced.
Even if such an exploit is not intentional, I don’t think this bodes well.
At best, over time it is going to make Linux a shit-show of crappy code. At worse, it’s going to royally mess something up that’s going to take an awful lot of work to undo
This doesn’t just go for the Linux kernel of coarse. There’s a whole heap of projects out there that are being slowly screwed over by allowing LLM slop into them. And it’s only going to get worse and the pace is going to pick up
... but the volume of new code being submitted that has been generated by AI.
Not in the sense that "AI written code is bad" - the chances are it is every bit as good as human-crafted code, since the models have been trained on millions [if not billions] of lines from open source projects.
But in the sense that up until now, Linus and the Linux maintainers have had an opportunity to get to know contributors over time, had an opportunity to review their code in low volumes, to meet them in person at conferences and to get an assurance that the developer making the submission is both genuine and competent.
In the "age of AI coding", it's going to be much easier for two different threats to Linux to emerge:-
1. Vibe Coded Contributions
There are going to be thousands of moderately technical people who lack both the necessary coding skills and the deep historic knowledge of the kernel, who will turn to AI and get it to write a patch that adds a feature they believe is useful. So there's a risk that Linus and major subsystem maintainers start to receive orders of magnitude more enhancement-style patches to "add this" or "improve that". In many cases these could be genuinely useful submissions... but it's going to massively increase the workload on maintainers - and it seems at least possible [if not likely] that we're going to be talking soon about the trade-off between features and bloat. Well, even more than current levels.
2. Well Hidden Malware
We've already had a few instances of unknown developers trying to push malicious code in to the Linux kernel and associated utilities in ways that would have rendered systems vulnerable to compromise... With the benefit of AI tooling, I suspect that it's going to become easier to obfuscate these sorts of patches - and as a result I'd be concerned of the risk of malicious compromise driven by the sheer volume of submissions and the potential for those submissions to contain obfuscated and malicious code.
Short of adding much more highly skilled human eyeballs to review submitted code ("Many eyes make all bugs shallow")... I'm not sure what else we can do.
1. We are beginning to see hallucinations moving back from the AIs to the human vibers.
2. Set an AI to catch an AI.
What Linus needs is to pass all the incoming patches through an AI agent which catches the shit, red-flags it and merely suggests fixes. Being Linus, he'll probably code the agent himself and call it something silly.
"What Linus needs is to pass all the incoming patches through an AI agent which catches the shit, red-flags it and merely suggests fixes. Being Linus, he'll probably code the agent himself and call it something silly."
Actually, if there was a model that Linus had coded I would probably be tempted to trust it... but I think it may be more likely [in the short term, at least] to expect submissions to be passed through existing commercial products. That would concern me, because a well-resourced attacker - say a nation state - has the funds to subscribe to all the latest models... Which means that they could not only use the models to write malicious code in the first place, they could then test their code against other models to see if it is detected or whether their obfuscation is sufficiently robust.
Bearing in mind that the tsunami of vulnerability reports and patches we're seeing at the moment have in most cases come from people using AI models to scan the source... [either their own code because they have access to the tools, or code in general because they're trying to earn a reputation for being good at finding vulnerabilities] and there's no guarantee that thoughtfully concealed code will be detected. At least... not right away.
It has been mis-attributed to Einstein, but the old saying, "We cannot solve our problems with the same thinking we used when we created them" comes in to play here...
...Because this is exactly how the insanity starts with all the tests I've done with Claude on throwaway projects. First, the review volume starts to exceed your capacity, second, the weird stuff happens unnoticed around the edges of the patches, and finally the whole thing collapses under it's weight.
He's a smarter guy than I, and has clearly got superhuman stamina for reviews, but I worry there's a breaking point he hasn't seen.
The last thing the FOSS community needs is a kernel running on empty fumes and burnout.
Oh well. Let the churn begin I guess.
This is something that I'd like to help on - even though I'm probably the problem and not a solution.
For context I am a self taught coder who's spent decades being the techie in the mostly privately owned companies I've worked for.
I've built websites and apps and know my way around ruby, python and javascript but aren't a professional by any means. I never considered a software career track mainly because I was slow at coding and not confident in what I made.
AI tools have changed that and I'm now doing websites and web apps at a speed that I would never have been able to do previously.
AI has helped me create the social media site I dreamed up 15 years ago but could never build because I wasn't good or fast enough to do it back then.
I've now got to the point where I've learned to spin up agents and get them really whirling and I even took to time to get anthropic and google AI certifications but hands deep in actual serious code bases that actually run the world's software would frighten me. (Linus is a scary guy!)
So I would like to help - but would I just get in the way? Would my AI assisted contributions be useless because I'm noob or didn't follow the right disciplines? Is there a way I can contribute with my skills? I would argue that more and more, thanks to AI, devs and especially juniors like me are becoming more and more Managers overseeing AI agents. If there's a way to integrate that into a flow where people like me can contribute would that be something worth considering?
I don't know the answer to that question.
I would observe the Linux kernel is almost all C with a smidgin of assembly and with a small but slowly increasing Rust component. C is a very sharp but unforgiving tool and in comparison with Ruby and Python very low level.
It seems to me a fairly large part of kernel programming is dealing with potentially quite high levels of concurrency by using kernel supplied services. I recall Robert Love's text Linux Kernel Development discussed this (although that text must be pretty dated now.)
Many years ago a talented manager said to me that an effective manager must be able to do the job of each of his† subordinates as competently as he expected them to.
The implication here is that anyone managing a team of AI agents assigned a particular goal ought to know how to reach that goal without the assistance of AI. Otherwise who is managing whom ?
Of course in the dismally real world in which we are confined, management finds a toilet roll a serious challenge.
† I would have understood he implicitly meant "or her" at that time.
I strongly disagree with your talented manager. Managing people is an entirely different skill to writing software (or writing documentation, or testing). An effective manager must have some idea of what each of their subordinates does, but they absolutely don't need to be able to do the job as well.
How well this carries over to AI is an entirely different question. An effective manager is not going to be reviewing the changes their subordinates make, line by line but an AI user _absolutely_ needs to be doing that.
I don't think you should disagree, at least not that _strongly_.
It's not that much about "managing people" here, it at least this was the OP idea.
I suppose we talk about a first line or a fairly hands-on manager, otherwise your "different skill to writing software" didn't make much sense.
But yes, the manager doesn't necessarily need to be better than all of their SW developers.
I less strongly disagree with you. Managing people is a skill that managers need to have, but it isn't the only one. They also need a sufficient knowledge of the things their subordinates are doing to know how to direct them. In proper teams, there should be relatively little need to actively manage interpersonal stuff. It will happen at times, so it can't be ignored, but the manager will spend a lot more time understanding progress, determining priorities, assigning tasks, and coordinating with other teams. If they don't have the skills to understand what work the subordinates are doing, they'll be unable to do those things effectively or at all. In my experience, it is difficult for someone to understand what people are doing if they can't also at least sort of do it themselves.
I think it's probably best to steer clear of the kernel itself- that's probably one of the most complex of all open source projects, and extremely difficult to land a patch into, no matter how talented and experienced you are- this is scaling Everest before learning to climb a step-ladder. The Linux kernel is widely-considered God-tier development.
But one thing I'd say is - use AI to gain a deeper understanding of the tooling and ways to do things that you haven't been exposed to, sure- but you really do need to struggle, not because us old commentards had to walk uphill both ways to the coal pit and it's character building, but because as Bebu points out- LLMs are sneaky bastards and will slip through all kinds of terrible ideas past even seasoned professionals. Without the sweat and pain of getting there yourself, you're more likely to be a victim of this.
I'd suggest finding a few projects you think you can be passionate about, hang around the irc / slack / discord and actually get to know the contributors. You will learn more by working with humans and writing the code yourself far quicker than you will osmose through an agentic coder, and feedback from real humans will raise your confidence and skill rapidly. There's often also a lot of chore issues with 'good-first-pr' tags, and these really make a difference while the old hands are battling stubborn bugs.
Also- anecdotally, the good managers I've met in software engineering are few and far between, but the truly excellent ones tend to be those who've got decades of frontline experience behind them. The same is going to be true of managing AI agents- they can solve hard, small algorithmic bugs or single file fixes, but have zero concept of how to actually architect code reliably, and that is the only thing that can prevent things going titsup down the line. You have to allow yourself space to cock things up, we all have, and that's how you actually refine your craft.
So, by your own admission, you are the problem:
* Self taught "coder" (as opposed to aspiring to learn to engineer software)
* Built websites, as an amateur/meddler
* Thinks that Eh? Aye! can compensate for lack of skill ("wasn't good or fast enough to do it back then")
* Thinks manipulation around the edges of the technology is sufficient ("spin up agents and get them really whirling")
* Is a web programmer (did I already say that?)
The world of real, hard software (which to your credit, you know enough to stay away from) doesn't need a bunch of hack dilettantes flinging insufficient, bordering on random, prompts at the latest shiny-du-jour. It needs engineers with serious analytical skills who can accurately and intelligently separate the few kernels of wheat from the tons/tonnes of AI-generated chaff. As is duly noted in other comments in this forum, that is not a job for the faint of heart, or faint of skill. And what it doesn't need is a me-too'er that has an over-inflated assessment of their under-inflated skillset. So to answer your question: Yes, with all due respect, you would just get in the way.
And Gawd save us form junior coders who have Manager aspirations!
Self taught "coder"
The first programmers were self-taught, they were very much older than me but I was originally self-taught because my school had no computers. Given your comment I assume that you've learned nothing since leaving education.
"Self-taught" coders such as:
Donald Knuth - maths
Edsger Dijksta - physics
John McCarthy - maths
Grace Hopper - maths
Brian Kernighan - engineering physics
Dennis RItchie - physics
C. A. R. Hoare - classics
John Backus - failed chemist, failed medic
"Self taught "coder" (as opposed to aspiring to learn to engineer software)"
Oh dear. So you're of the view that everyone should learn to program by sitting in dull lectures while the tutor talks you through trivial programs line by line?
Yes, that can be useful, if the class can stay awake, and the theory lectures impart important information too. But you really learn to do it by getting your hands dirty and writing code.
I've long ago lost count of how many programming books I've read, just out of interest, and have picked up useful information that was never mentioned at university, or, in the case of some languages, didn't exist when I was at uni.
Back in those long ago days, there were people on my course who had never written a line of code in their lives, sitting alongside others who had been playing wth code since their early teens. Guess who found it easier? Which is not to say that some of the newbies didn't go on to be good, but they did it by taking the basics they learned in the lecture and playing around wth it until they understood it.
In that respect, they were self taught, as are we all - it's the only real way to learn.
I think there's a mistake people are making in this discussion regarding my initial post about "managing." I see the future of coding less about learning to code in the traditional sense — more about learning how to run an LLM properly and effectively.
Personally I've found the best way to write code with AI is to use a whole team of them, each handling a specific part, tied together with specification papers, roadmaps and feedback loops. And lots and lots of QA.
So I think developers in the future will look more managerial: running a team of AI agents, spending their time carefully communicating what they need. That's exactly what a manager does — which is why I keep using that word. Not a manager of people, an AI manager.
And let me be clear - I certainly do not have management aspirations.
One thing worth flagging about your response: dismissing people who are exploring these workflows or assuming there's only one "correct" way to write code doesn't hold up well as the field keeps moving this fast. Worth staying open to it. People trying to help can be pointed toward areas where they're actually useful — I'm not proposing anyone hand a noob like me a kernel-level system to use AI to sort out - the idea is rightly laughable - but going through low-level work, separating wheat from chaff, passing the good stuff up the line — that's more the thing I was looking at.
And also what I believe a good engineering team would be looking - division of labour and all that - have noobs doing the easy stuff whilst the experts do hard stuff! Good organisational discipline and not gate-keeping!
You know I'm gonna cheer the AI on this one. Bug finding - esp nasty stuff like stack overflow/underflow, buffer over/under run, incorrect bit field usage, use after delete and a myriad other problems are really tedious to find and setting the unblinking eye of AI to go look for these is not a bad idea. The operations required to do it are fairly mathematical and the patterns well established. Often times the problem with humans is we are more interested in algorithms and edge cases are a pain - and, frankly, we do have a tendency to say "ahhh! that'll never happen!"
If the bots want to agonise over every line of code then let them. They'll find all sorts of stuff. I won't go into what I've had the bots find but they're demonic good at disassembling stuff and pulling it apart. Plenty of training data too.
I suspect a lot of what they're finding is fairly easy for a human to miss but also easy for a human to validate (literally out-by-1 type problems).
Combined with better programming languages and techniques (Rust - I'm looking at you) we should just end up with better, tougher, stronger code bases and, frankly, I'm all for that. Gives me an attack of the screaming heebie geebies whenever I publish a server because they're all built on so much "invisible" code (from my perspective) from the firmware through the OS and drivers, network layers, interpreters, compilers, libraries and so on. Just about any of that could add a vulnerability. *eesh*
Could be a good use for AI
I know not to roll my own logging library because concurrency is complicated.
So I include some massive standard logger ultimately derived from some Java lib with 20 years of crud added. Later discover it has a remote access 'feature' with a well known default password. Or it installed sendmail as a dependency
Or I ask Claude to write a simple logger with the ability to only write to a local file. It gets all the locking and singleton boilerplate correct and doesn't add a mailserver
Or I ask Claude to write a simple logger with the ability to only write to a local file. It gets all the locking and singleton boilerplate correct and doesn't add a mailserver
...but adds a clever, obfuscated mechanism to hack into some other mailserver. Because, you know, every simple logger requires a mailserver....
You know I'm gonna cheer the AI on this one. Bug finding
Absolutely agree and also that people need to find and fix some bugs before others exploit them. The ongoing heist of Bitcoin from Coinkite's Coldcard hardware wallets has reportedly reached $130 million courtesy of a trivial but impactful fuck-up with firmware builds which has been there for years. AI is suspected of having identified the flaw - though Coinkite may simply be trying to cover their own backsides.
The problem seems to me that most don't have a good strategy for dealing with the tsunami of AI submissions, legitimate, useful, and not. I hate to have to say it but AI may be the solution there.
There are 2 different AI-enabled problems.
People who want to have code in Linux (for the fame, glory, money, girls, etc). This used to involve having several years of C experience, learning a lot about the Kernel and the moderation culture by which time you give up or decide your module to flash "Happy Birthday" in Morse on the keyboard LED once a year is probably not what the world really needs. Now you simply ask AI to write the code and submit it for you while. Multiply this by 1000s of people who have just heard about AI and Linux.
People who have found a genuine bug (whether by AI or accident) and get an AI to write a "fix" which works but touches 1000s of source files in ways nobody understands and would require Greg Kroah-Hartman to spend a year checking.
> I hate to have to say it but AI may be the solution there.
Probably true. Or require submitters to defeat an Emperor Penguin in hand-flipper combat as the ultimate CAPTCHA
I guess it is time to move away from Linux. Since using a.i slop is never ever going to improve anything. It is going to allow massive security problems into the Linux kernel and those security problems are going to remain hidden for years.
I guess FreeBSD is maybe a usable option.
"Torvalds was looking for something fun and sympathetic to associate with Linux, and he felt that a slightly fat penguin sitting down after having eaten a great meal perfectly fit the bill"
https://en.wikipedia.org/wiki/Tux_(mascot)
let's hope the penguin isn't subjected to too bigger meals, that a bit like Winnie the Pooh, it can't get out the door