How to Use AI for Linux Kernel Development

Use a computer to... uh... build a computer?

5 Jun 2026

This is about using AI for Linux kernel development, though most tips can apply elsewhere.

I know, I know. AI is quite polarizing in today’s world, to say the least. I will be addressing ethics later. But for now, let’s focus on the tech.

AI is useful because it prototypes fast, multitasks well, and gives you something to work off of instead of making you start from zero. Do I think it replaces people? Not everywhere. For situations where “good enough” is fine (eg. art & writing) there will be a reduction. However, any job that can’t tolerate “good enough” will probably be fine. Nobody wants AI pacemakers.

But in the long term… I have no idea. Maybe electrified silicon will beat electrified carbon one day. We are all statistical algorithms after all. But, that’s a future problem.

If you’re new to Linux kernel development, I suggest you read the postmarketOS mainlining guide. I have made a guide specific to the Pinephone Pro here, which can be useful too.

When AI Can Help

Before using AI, let’s identify in which context AI can be helpful.

If the task involves:

Then I would argue it’s a pretty good fit.

Do not expect AI to discover new things, unless there are tests in which it can iterate itself upon. Just think of AI as an autocorrect on steroids. AI works best on problems similar to the data it was trained on.

This is why kernel development fits very well with AI workflows. Millions of Android devices already have working downstream kernels that are on GitHub. The Linux kernel source code and the Linux kernel mailing list are all open. The hard part is upstreaming them, but through trial and error, you usually can get something working and then clean it up later.

Here are some other areas where I think AI can excel at:

AI probably isn’t that useful if you’re already an expert and actually have to think through a problem. It may be useful if you don’t have enough time and need help multitasking. Experts are usually discovering and implementing things, not translating existing ideas, and they already have a lot of the context that AI would give anyways.

One problem with relying on AI is that you can quickly end up not knowing what changes it is making or even doing. To alleviate this problem, spend some time cleaning up the patches. Another is that once the context window resets, it often loses the information it was working from. If you want a long term maintainer for your code base, it’s better to train up junior engineers so that they one day would become experts on the code base that you or your business is reliant on. But the economy does not usually care about the distant future as much as the now.

Tools

I mostly use Claude Opus 4.6, though model quality seems to shift over time, so use whatever is best in practice.

I also use Handy for local speech-to-text so I type less. Quite handy (Ba dum tss).

How I Use AI

For kernel work, I trim the downstream tree first. If you can identify which files are actually used in the build, delete the rest. Then the AI spends less time grepping garbage and more time touching code that matters. I have a vague post on how I did it here. If I remember correctly, in the top level Makefile I removed rm -f $(depfile); and then built the kernel with the -d flag. The build then outputted .i files and any .c files that didn’t have a corresponding .i files were deleted.

Next, I create a CLAUDE.md file, which contains:

Would highly recommend also installing caveman to cut token use.

Then it’s as simple as telling the AI what I want. Keep it broad enough to explore, but mention dead ends you already know about. With a good model, AI are basically extra hands. Let it run commands automatically if you can, but only in a container, VM, or second machine. Don’t let it trash your real environment. I would recommend using the best model you can, max thinking if available, and the biggest context window you can afford. One strong run is usually cheaper than many weak ones. If the context window is small, use memory files. When the AI gets something wrong but discovers something useful, tell it to save that to the memory file. Don’t paste long logs into the chat window either. Paste it into a file and let AI grep within that file.

I keep a reusable prompt.txt that I can copy from and paste into a chat window at the start of every session. It includes all the stuff the AI tends to forget: /caveman ultra, read CLAUDE.md, here is what is broken or what I want to do, all the features I want to eventually get working, ignore unrelated warnings, checking the previous build log, etc. If your AI can follow rules before every run, I would highly recommend using that instead. You might be able to get rid of your prompt.txt then.

What I have gotten working using AI

My development has significantly been accelerated using AI. You can look at the blog post that I make here as indication on my progress. I usually don’t blog about changes that haven’t reached upstream. For that you can follow this thread.

Someone has even gotten full support for their SOC using AI. It’s crazy how quickly this person was able to get all of these features working for the APQ8060/MSM8260/MSM8660.

Future AI Usage in Linux Kernel Development

I’m very excited about postmarketOS’s CICD hardware. While this is for CI/CD, it also gives a platform for automated development. Give AI a bunch of tests and it can iterate on itself, test whether a feature works or not, and then continue based on feedback from its test. The developer only has to periodically monitor and once complete, clean up the patches to send upstream.

With 500+ devices under postmarketOS’s belt, we can quickly get a better form of mainline working on most of them. A swarm of drones will always beat one expert in terms of productivity. The project is only alive if there are features that serve the user.

Ethics

Oh boy. Alright. Let’s address the elephant in the room.

My view is that copyright is supposed to provide credit and royalties, but in practice it mostly protects whoever already has money. A better systemtic change would be to guarantee people’s basic needs directly instead of pretending copyright does that.

Humans learn from each other constantly. Copyright often fences that off. I don’t see much value in defending a system that mostly preserves power.

AI Uses a Lot of Resources

Don’t confuse the tool with the greed around it.

If AI were trained ethically, ran on cleaner power, and wasn’t threatening people’s livelihoods, I think most people would see it as useful. The current reality, though, is worse, and that deserves criticism. But saying AI itself is inherently bad ignores what it can do for projects like postmarketOS.

AI Used in Warfare

I absolutely hate this one.

AI is like a knife: useful in some contexts, horrifying in others. It absolutely needs structural regulation in warfare. Without oversight it can be devastating, and there needs to be human accountability.

We Need to Ban AI Entirely For Our Project

People lie. If you ban AI in a project, people will still use it. They just won’t tell you.

That also creates legal messes later if laws change and nobody can tell which contributions involved AI anyway.

Unfortunate Reality

Modern life already runs on tolerated harm because for most people the utility out weighs the harm being done.

For example:

Let’s just focus on computers for now. If I told you computers were built on exploitation and deadly extraction, would you stop using them? Probably not, because the utility for you out weights the harm it causes others. Capitalism is a system that prioritize capital over any other resource, including humans. And yes, unfortunately some people see others as just another resource. It’s a systematic feature, not a flaw.

I’m glad there are people that push back on AI’s harms. However, I often feel that I have to use AI because:

If we want our values to matter, we have to ship useful features. Otherwise the only people delivering results will be the ones who do not care about the harms.

That is the part that bothers me most: sometimes the system makes the compromise for you. We all have to tolerate some intolerance just to function inside it. That does not make it good, and it should be criticized. I hope to change that someday.

But regarding AI, maybe the best solution is to create a FOSS counterweight? We could build upon NVIDIA’s Nemotron 3 Super, partner with (F)OSS projects that are okay with their codebases being trained on, train it using renewable power and ethical hardware, and release it to either be run locally or as a payment system to fund FOSS development. We need a systematic change. Something that can actually fight against these proprietary behemoths. But this is a short term solution. A long term solution would be to change the actual fucking system.