AI for Kernel Development: Explore, Test, and Review Patches

AI for kernel development can help you trace code, organize an investigation, and prepare a small patch, but the result needs human review and tests against the exact target tree. For Linux work, start with a source commit, configuration, architecture, and observable problem before asking an assistant to change anything.

Tools like fenbs preserve version constraints, design decisions, and the investigation’s next step between sessions. Keep source code and test logs in their appropriate repositories or storage; save the explanation that lets the next assistant understand what that evidence means.

How should you structure an AI-assisted investigation?

1. Identify the target tree and commit. Record the architecture, relevant configuration, toolchain, and environment where the behavior appears.
2. Describe the observable problem and attempt a reproducer: a repeatable way to trigger it. Distinguish a confirmed failure from a suspicion based on reading code.
3. Ask the assistant to trace the relevant paths before editing. Require references to functions and callers in that checkout, plus explicit unknowns.
4. Prepare the smallest plausible fix with a test plan. Include the failure path, cleanup behavior, and any concurrency assumptions affected by the change.
5. Build, test, and inspect the patch. Keep failed attempts and missing checks visible; a person decides whether the evidence supports submission.

Linux is the focus here; another kernel has its own development rules. Even within Linux, the right base may be a subsystem maintainer’s tree. The kernel’s patch submission guide↗ (opens in a new tab) explains tree selection, focused patches, and the need to describe the problem and its effects.

What context does the assistant need before reading code?

“The latest kernel” is not a reproducible starting point. Give the exact commit and the relevant environment. An explanation based on a newer helper function or different configuration can sound convincing while describing code your target does not contain.

Describe constraints that code alone may not explain. Perhaps an external interface must remain unchanged, a particular device is unavailable, or a maintainer requested a different approach. Attribute that request and link to it when you can. Do not turn a tentative investigation theory into a design decision.

Keep those distinctions in fenbs Decisions and rules and project context: people choose the constraints; assistants record the evidence and open questions. Recheck the source commit whenever work resumes.

How can AI help trace a kernel path?

Ask it to build a small map around the suspected failure: the entry point, relevant callers, data ownership, and cleanup path. Require a source location for each important claim. Then inspect those locations, especially where the explanation moves from one function or subsystem to another.

For an error-path investigation, make the question concrete: after this allocation fails, which resources already exist, and who releases each one? For concurrent code, ask which lock or lifetime rule protects the object. A lock controls access between competing operations; knowing its name is less useful than proving where it is held.

Investigate this symptom in the exact checkout provided. Do not edit yet.
State the commit and relevant configuration.
Trace the entry point, object ownership, error exits, and synchronization.
Cite file locations for each important statement.
Separate observed evidence from hypotheses.
Propose the smallest reproducer and the checks needed to disprove your theory.
List anything you cannot verify from this environment.

If the assistant cannot find the alleged caller or reproduce the claimed lifetime, stop expanding the theory. A useful investigation can conclude that the suspected bug is not supported. That is better evidence than a patch that merely makes an uncertain explanation look complete.

Which tests make a proposed patch more credible?

Start with the original failure. If possible, run the same reproducer before and after the patch under the same conditions. Inspect build warnings and relevant logs as well as the test’s final status. A successful exit code should not hide a new warning or a failure that the script ignored.

Choose tests that fit the change. KUnit↗ (opens in a new tab) supports tests inside the kernel, including checks of internal functions. Its tooling can run tests using supported virtualized environments. A small isolated behavior may suit a unit test; hardware behavior or a broader system interaction needs evidence appropriate to that path.

• Build the relevant configuration and inspect new warnings; check other affected configurations when the patch changes conditional code.
• Exercise success and failure paths, including cleanup after a partially completed operation.
• For concurrency changes, identify the competing operations and what the test actually exercises.
• Record unavailable hardware, untested architectures, and other gaps as remaining checks.

Use a controlled test environment with a recovery path. Do not let an assistant boot an experimental kernel on a production machine as a routine verification step. A virtual machine result is useful evidence for what it exercises, but it cannot stand in for a device test the environment cannot perform.

What must a person review before submission?

Read the entire diff and its explanation together. Check that the patch fixes one supported problem, preserves the relevant interfaces, and follows the subsystem’s conventions. A style checker can highlight issues, but it cannot establish that ownership, locking, or error behavior is correct.

Follow the kernel’s AI coding assistant guidance↗ (opens in a new tab) when preparing AI-assisted contributions. It puts responsibility on the human submitter, says assistants must not add Signed-off-by tags, and describes Assisted-by attribution. Read the current instructions rather than inventing tags or having an assistant certify a human’s contribution.

Write the patch description from observed evidence: what failed, why it failed, what changed, and what was tested. Avoid claiming performance improvements without measurements. If investigation suggests a security issue, have a person review the appropriate reporting process before sharing details publicly.

How to do this with fenbs

1. Create a free account and add a project for the kernel investigation.
2. Add a task with the symptom, target commit, relevant configuration, reproducer status, and links to evidence. Mark hypotheses as hypotheses.
3. Record the constraints and design decisions a person approved, with their reasons. Keep unanswered questions open rather than letting an assistant settle them.
4. Connect a supported assistant through Integrations. Have it read context before working and save actual check results, missing tests, and the next step before stopping.

fenbs does not build kernels, run virtual machines, or validate a patch’s safety. A self-contained investigation may need only local notes. The shared record helps when source versions, review decisions, and unfinished tests must remain understandable across longer work.

When is the investigation ready to hand off?

Another person should be able to identify the exact source, find the reproducer and logs, explain the proposed fix, and see which checks remain. Ask the next assistant to restate those facts before taking action. If the source or configuration changed, establish a new baseline rather than silently carrying the old result forward.

See what an AI brain keeps and how to use AI at work for the surrounding workflow. Application server work has a different scope, covered in AI for backend development; related guides appear in the AI at work hub.