The first release candidate for Linux 7.4 came out at the weekend, and the announcement had a line in it that anyone paying for software should read. A lot of this release is fixes for problems that AI found. The interesting bit isn't that AI is finding bugs. It's where in the process those fixes turned up.
This time the AI-triggered work landed in the merge window, the two weeks where new code goes in, rather than arriving as a pile of extra fixes during the stabilisation weeks that follow. The announcement calls that "a much healthier model", and hopes AI fixes are becoming part of normal development rather than a late flood.
That's a lesson that works just as well for a twenty screen business app as it does for one of the biggest open source projects there is.
What actually happened
The 7.4 merge window was big: almost 20,000 commits against a usual figure of roughly 15,000. The announcement is careful not to pin all of that on AI. People are expecting 7.4 to be the next long-term support release, which tends to pull more work in, and about a third of the changes are AMD graphics register definitions. But a good chunk is fixes for issues AI tools found.
There's another detail worth noting. AI is increasingly suggesting the patches as well as finding the problems, but those patches "often get rewritten" before they go in. So the AI is good at pointing at the problem. A human who knows the code still decides what the fix should look like.
Finding bugs is cheap now. Fixing them well isn't
This is the shift that's happened over the last year or so. Point a decent AI model at a codebase and it will come back with a list of things that look wrong. Some are real, some are noise, and someone has to work out which is which. Then someone has to fix the real ones without breaking anything else.
The kernel's experience is that when that list arrives late (just before a release, when everyone is trying to stabilise things) it causes pain. When it arrives early, as part of the normal flow of work, it's just more work to get through. Same bugs, very different stress levels.
Most small business software works the same way. If the first time anyone runs an AI review over your app is the week before launch, or the week after a scare, you'll get a long list at the worst possible moment. If it runs on every change as it's made, each finding is small, fresh and fixed by the person who just wrote the code.
Someone has to own every change
The kernel also has written rules for AI coding assistants, and they're refreshingly blunt. "AI agents MUST NOT add Signed-off-by tags." Only a human can certify where the code came from. The human submitting the change is responsible for reviewing all AI-generated code, checking licensing, and taking full responsibility for the contribution.
The assistant must also say which steps it couldn't complete, such as building or testing the fix, and it must never send anything itself. A person reviews it and decides.
That's a sensible rulebook for any business letting AI near its code. It's close to how we work too. We use AI every day to read, write and test code, but a developer directs it and every change is reviewed and tested before it goes live. There's more on that on our how we use AI page. AI is a brilliant typist. It shouldn't be the one signing things off.
If you're working with a developer or agency, it's a fair question to ask. Who reviews the AI's changes, and whose name is against them?
If your app was built with AI, you may already have the late flood
Here's the awkward bit. If your app was built quickly with Lovable, Bolt or Cursor, and nobody ran a review as it went, then the first proper look at the code is the late flood the kernel just managed to avoid.
That's not a disaster. It just means doing the review once, properly, sorting real problems from noise, and fixing the ones that matter in a sensible order. After that, keep the review running as part of normal changes so you never end up there again. My guide on whether an AI-built app is safe to launch covers the security gaps worth checking first, and our AI-built app rescue page explains how we take these projects on.
The server side of it
For anyone who looks after their own Linux servers, there's a practical footnote. If 7.4 does become the next long-term support kernel, it's the one that will get fixes backported for years. That doesn't mean rushing a release candidate onto a production box. Most servers run whatever kernel their distribution ships, and that's usually the right call.
What it does mean is that more AI-found fixes are going to keep flowing into the kernel and everything around it, which means more updates to apply. Patching isn't glamorous, but it's where a lot of real security comes from. I wrote about patching around 100 sites overnight with AI helping, and the same point applies: AI made it faster, but someone who knew the servers still had to drive.
What I'd do this week
- Find out whether anyone is running AI or automated review on your code, and when. On every change is good. Once a year is a list waiting to happen.
- Ask who signs off AI-written changes before they go live. There should be a name, not a shrug.
- Check your servers are actually getting kernel and package updates, not just your app.
If you'd like a second pair of eyes, our code audit is £250 + VAT for one system. You get a plain-English report on the code, security, hosting and backups, plus a fixed price for each fix we recommend. If you'd rather hand the ongoing work over, Look after it starts from £355 a month + VAT and covers updates, hosting, backups and fixes for software we've built or taken on.
Either way, the kernel has shown the sensible order: find problems early, have a human fix them properly, and keep doing it.
Cheers, Rob
