In application code, “it builds and it runs” is reasonable evidence that something works. In kernel and embedded work it is almost no evidence at all. A model can produce a driver that compiles cleanly, runs in a demo, and still holds a lock in the wrong order or calls a function that does not exist in your tree.
This is not just an opinion. In December 2025 the Linux kernel community published official rules for AI coding assistants, and they draw a hard line: AI may write the code, but only a human can review it, sign off on it, and take responsibility for it. The skill that matters now is not generating the code; it is the judgment to tell plausible code from correct code.
Ask an AI assistant for a piece of kernel code and you will usually get something that looks right. The function names are familiar, the structure matches what you have seen in the tree, and it compiles without complaint. That surface correctness is exactly the problem, because the distance between code that looks right and code that is right is where the system hangs.
In kernel space, “it compiles and runs” is not evidence that the code is correct. It is evidence that the code is plausible.
The failures are specific and they are quiet. You might get a function that looks perfect and simply does not exist in your kernel version. You might get one that does exist but takes the lock in the wrong order, so it compiles, passes your quick test, and then deadlocks under load on one board out of fifty at two in the morning.
None of that shows up in the build log. The build log was never testing for it.
Plausible and correct are different words here
Think about what the tool is actually doing. It is a very good pattern engine: it reproduces text that resembles correct kernel code, drawn from the enormous amount of code it has seen. What it never does is hold your specific system in mind — your execution context, the hardware you are targeting, and the exact shared state with all the ways it can be reached at once.
The model has read a great deal of code that looks like kernel code. It has not reasoned about your locking, your context, or your concurrency.
In user-space application code, the runtime tends to catch you. A bad pointer segfaults, an exception fires, the process dies loudly and you fix it.
In the kernel there is no such safety net. A wrong lock order does not announce itself. A missing memory barrier does not throw. The code runs, and the fault surfaces later, somewhere else, as a symptom that looks unrelated to the line that caused it.
Why this matters more as AI gets better
It is tempting to think that as models improve, this concern fades. It does the opposite. The better the generated code looks, the more confidently wrong it can be, and the less likely you are to stop and check it. Obviously broken code protects you, because you reject it on sight. Code that looks right quietly removes that protection.
The kernel maintainers have watched this shift happen in real time. Greg Kroah-Hartman, who maintains the stable kernel, described how AI-generated security reports changed over 2025 and 2026:
“Months ago, we were getting what we called ‘AI slop,’ AI-generated security reports that were obviously wrong or low quality. It was kind of funny. It didn’t really worry us. Something happened a month ago, and the world switched. Now we have real reports.”
— Greg Kroah-Hartman, stable Linux kernel maintainer (March 2026)
That is the important trend for every engineer. The output stopped looking like obvious slop and started looking real. When the wrong answer and the right answer both look convincing, you can no longer tell them apart by glancing at them. The only thing that separates them is understanding you already hold.
Fluent, almost-correct kernel code is more dangerous than obviously broken code. The broken code gets rejected on sight.
This is why the valuable skill has shifted. Producing a plausible driver is now cheap and getting cheaper.
What stays scarce, and what actually decides whether a product ships or a system deadlocks in the field, is the judgment to look at plausible code and see the one assumption your hardware will break. That judgment does not come from the model. It comes from understanding the tree, the datasheet, and the machine well enough to hold them in your own head.
The kernel community already drew the line
This is not a fringe worry. In December 2025, after discussion at the Maintainers Summit, the Linux kernel added official documentation for AI coding assistants. It is worth reading carefully, because the people who accept the most safety-critical patches in the world decided exactly where the tool stops and the human begins.
“AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO).”
— Linux kernel, AI Coding Assistants documentation (December 2025)
The kernel’s Signed-off-by line is the sign that a real person stands behind a patch. The documentation places four duties on the human, not the tool:
- reviewing all AI-generated code;
- ensuring it meets the licensing rules;
- adding their own Signed-off-by;
- taking full responsibility for the contribution.
An AI contribution may be marked with an Assisted-by: tag, but the accountability never moves. The model helped; the human is answerable.
None of this is anti-AI, and it is worth being clear about that. Linus Torvalds, writing on the kernel mailing list in July 2026, insisted that Linux is “not one of those anti-AI projects” and called AI “a tool” and “clearly a useful one.” That is the right framing. The tool is genuinely useful. It is also not the thing that signs its name to the result.
How to use the tool without getting burned
None of this is an argument against using AI. It is an argument for keeping the authority in the right place: the source tree and the hardware decide what is correct. A few habits keep you on the right side of that line:
- Treat every suggested call as a claim to verify. Check it against the actual code in your kernel version. A function that exists in one release may be gone or changed in yours, and the model does not know which tree you are on.
- Reason through the locking and context yourself. Before you accept generated code that touches shared state, walk the worst-case interleaving by hand. If you cannot, you do not yet understand the code well enough to merge it.
- Do not accept code you could not debug alone. If a generated solution is more intricate than your ability to fix it at three in the morning with no help, it is a liability, not progress.
- Test on the real target, under real load. A demo on the happy path proves almost nothing about concurrency and timing. The bench is the honest reviewer; the build passing is not.
- Sign off only on what you understand. The kernel rule is a good rule for any codebase: put your name on generated code only after you have reviewed it well enough to take responsibility for it.
At TECH VEDA this is exactly what the kernel and embedded training is built around: not memorising APIs, but building the mental model of locking, context, and hardware that lets you tell correct from merely plausible. That model is what the tool cannot supply, and it is the thing that keeps you employable as the tool gets better.
The source tree is the authority. The model is a guess. When they disagree, the tree wins.
So when the generated driver compiles on the first try, treat that as the beginning of your work, not the end of it. The compiler checked the grammar. Whether the code is correct for your system is still your call — and the kernel community has now written down, in its own rules, that the call was always yours to make.
Further reading: AI Coding Assistants — The Linux Kernel documentation; Greg Kroah-Hartman on AI bug reports, The Register (March 2026); Linus Torvalds on AI in the kernel, Tom’s Hardware (July 2026).
— Raghu Bharadwaj
