The Linux kernel has two written policies for contributions produced with the help of AI tools. Neither adds new rules about code quality. What they regulate is evidence, disclosure and accountability: produce a reproducer, state plainly what you could not test, be able to defend everything you submit. Those requirements are not new. The conditions they now operate under are, and that is what tells you which engineering skills have become cheap and which have become scarce.
The Linux kernel now has two written policies for contributions produced with the help of a tool. I went to them expecting rules about code. There are almost none, and what is there instead is the more useful part.
Read them alongside how cheap producing code has become, and they answer a question that matters more than whether AI replaces engineers: which of the things you are good at have lost value, and which have gained it. If you have spent years getting good at producing code, some of this will be uncomfortable reading. I will come to what you keep.
What the kernel actually wrote down
The documents are AI Coding Assistants and Kernel Guidelines for Tool-Generated Content, both in Documentation/process/. Neither adds new rules about how to write better C. Both point at the rules that already exist — the coding style document, checkpatch.pl, no new build warnings — and then address something else entirely.
An assistant used to find and fix bugs must “verify that it looks real by attempting to create a reproducer to demonstrate it”. It must build the fix and show it works. And step eight is explicit: “Indicate what could not be done” — because “maintainers currently waste too much time analyzing unverified reports and untested fixes.” The rules are addressed to the tool, but read them as a description of what a person must be able to do to be answerable for a result.
The second document explains why. These tools “can increase the volume of contributions” while “reviewer and maintainer bandwidth is a scarce resource.” So contributors must disclose what was generated and how it was tested, and “expect additional scrutiny in proportion to how much of it was generated.” The governing standard is one sentence: “You are expected to understand and to be able to defend everything you submit.”
The requirements are old. The conditions are new.
Here is the objection I would raise if someone else had written that. None of it is new. Test before you send, produce a reproducer, say what you could not verify, sign your own work — all of that has been in submitting-patches.rst for a very long time.
True, and it is the point rather than an objection to it. The claim is not that a new standard was invented. The claim is about what the old standard is now worth. The same requirement now applies to a stream of contributions whose supply side became far cheaper while the reviewing side did not change at all, and a requirement that was routine when both sides were expensive becomes the entire difficulty when only one side gets cheap.
A project does not write down what matters most. It writes down what has newly become contestable.
What genuinely got cheaper
An honest account has to start here. Work that was genuinely difficult, and that people built careers on, is now available in seconds:
- Driver skeletons, probe paths, and the Kconfig, Makefile and device tree scaffolding around them.
- Recalling API signatures, structure members, and which header declares a symbol.
- Explaining an unfamiliar subsystem at the depth of a good tutorial.
- Summarising a large codebase well enough to know where to start.
- First-draft commit messages, documentation, and boilerplate refactoring.
These were real skills. An engineer who could produce a working character driver from memory was more useful than one who could not. That advantage has largely gone, and it is not coming back. If you spent years acquiring it, that is a genuine loss, and I would rather say so than pretend otherwise.
What has not gone is what you learned while acquiring it. You understood how the driver model binds, why probe fails, and where a datasheet is simply wrong. That understanding was a by-product at the time. It is now the thing that lets you tell whether a generated driver is correct.
One entry on that list needs a qualification. A tool can summarise a codebase in minutes, which is useful, because it tells you where to begin. Reading it yourself is a different activity, and it did not get cheaper at all. You cannot review what you cannot read.
What got cheap is the overview. The reading is now the job.
What did not get cheaper, and why
These tools are built from what people have already written down. Where the answer exists in writing somewhere, they assemble it for your situation very well. Two categories of work do not have that property.
A commitment cannot be generated
Some work produces a commitment rather than a description. A sign-off. A safety claim. A decision that a CVE does not affect your product. An assurance to a customer that a fix resolves the fault. These are not statements about code; they are undertakings by a person who can be held responsible for them. No improvement in generated text changes that, because the difficulty was never the text. It is why the kernel reserves Signed-off-by for a human while allowing the code itself to be assisted.
Physical evidence cannot be inferred
Other work takes an input that is not text at all. The timing on your board under real load. A supply rail that sags when the radio transmits. The thermal behaviour inside a sealed enclosure. The way a silicon revision departs from its own datasheet. Some of that is written down — errata sheets exist — but not in the material these tools learned from: it is in a PDF under an agreement, in somebody’s lab notebook, or it was never recorded at all. It has to be obtained by contact with the physical system, and obtaining it is an engineering skill in itself.
The durable work either produces new information about a specific system, or carries a commitment someone can be held responsible for.
The four skills that got more expensive
Verifying work you did not write. Review used to be something senior engineers fitted around their own development work. It is becoming the main activity, because producing a patch became far faster while reading one carefully takes as long as it ever did. A fair objection: verification has been automated for years — syzbot, KASAN, kunit, the 0-day bot, board farms. But each of those checks a property somebody decided in advance was worth checking. The mechanical half was automated a decade ago. What remained scarce is the judgement before and after it: what to check, and what an unclear result means for a product shipping next month.
Producing evidence. Reproducing a failure on demand, instrumenting a system, measuring rather than estimating. When generating a candidate fix costs nothing, the value moves to determining whether the fix is real — which is why the kernel requires the reproducer before the fix. The career version of this is the failure portfolio.
Specifying precisely. When production is free, output quality is set almost entirely by the statement of what is required. Vague specification used to be concealed by the slowness of implementation, because the person writing the code noticed the gaps while writing. That check is gone. The guidelines recognise this: a maintainer may respond to a generated patch by suggesting “a better prompt instead of suggesting specific code changes”.
Saying what you do not know. A model does not signal the limits of its own confidence; it produces a fluent answer regardless. An engineer who reports “tested on two boards, untested on the third revision” supplies information the tool structurally cannot. This is not only a scarce skill. It is also, more simply, honesty.
Reporting what you did not verify is not a missed opportunity to look competent. It is the difference between a colleague planning with good information and planning with bad.
| Became cheap | Became scarce |
|---|---|
| Writing a first draft of code | Deciding whether a draft is correct |
| Summarising how a subsystem works | Reading it closely enough to review it |
| Recalling APIs and structure members | Explaining why this board behaves differently |
| Producing a plausible answer quickly | Stating the limits of what you verified |
| Describing what a change does | Undertaking that it is correct |
The mispricing
Most preparation has not moved with the value. Students are still taught to memorise API details and finish tutorials, then to present the finished tutorial as evidence of skill. That advice is a decade out of date, and the student following it is doing nothing wrong except trusting it.
Interviews deserve a more precise statement than the usual one. Early rounds still test recall that an assistant supplies instantly, and they still filter, so they still have to be cleared. But in embedded and kernel hiring, the round that decides the offer has always been the one that asks you to describe a failure you found yourself — and that is where most candidates have nothing to say. The cheap column is the filter. The scarce column is the decision.
Do not delegate the apprenticeship too early
There is a problem here I cannot solve for you, and I would rather name it than pretend the advice is complete. Every engineer who can judge a patch developed that judgement by writing patches badly first, under review, for years. The cheap work was the apprenticeship. Removing it does not remove the need for it, and nobody has yet shown how review judgement can be acquired without having been reviewed.
So handing the cheap work to a tool is a good trade for a skill you have already built, and a poor trade for one you are still building. If you have never written a probe path, writing it yourself is not inefficiency. It is the repetition that builds the model you will use on the next ten drivers.
One thing worth saying to engineers starting out in India, because it works in your favour and few people mention it. The work juniors are actually given here — validation, log triage, board bring-up, sustaining, integration — sits on the scarce side of that table, not the cheap side. It is contact with a physical system, and it produces evidence. If you feel that work is lesser than the code you would rather be writing, reconsider.
What this does not mean
It does not mean avoiding these tools. Refusing on principle means spending expensive hours on work that is now worth very little, and you remain answerable for the output either way. The caution above is about sequence, not abstinence. Nor is the boundary permanent: some of what is scarce today will get cheaper, and I would not predict where it will sit in three years. What is unlikely to change soon is the structural part — a tool built from what has been written down has no independent access to your board, and a tool that cannot be held responsible cannot certify anything.
These documents are not a statement about what machines can do. They are a statement about what a project still needs a person to do.
None of this is a prediction about machines. It is a question about where your next year goes. The work that became cheap is the work you are already good at, which is exactly why leaving it is difficult — but it is no longer where your value is decided.
— Raghu Bharadwaj
Key takeaways
- The kernel’s two documents on tool-generated contributions add no new rules about code quality. They regulate evidence, disclosure and accountability instead.
- Those requirements are not new. What changed is the ratio: the same standard, applied to a supply side that became far cheaper while review did not.
- Work that rearranges written information became cheap. Work whose output is a commitment, or whose input is a physical system, did not. Reading code did not get cheaper either — summarising it did.
- Four skills became more valuable: verifying work you did not write, producing evidence, specifying precisely, and stating what you did not verify.
- Early in a career, handing the cheap work to a tool is a poor trade, because that work is how the judgement gets built.
Frequently asked questions
Does the Linux kernel accept AI-generated patches?
There is no blanket acceptance. The kernel has written down expectations rather than a permission: contributors must disclose which tools were used and how the result was tested, and individual maintainers keep discretion over how to handle such a contribution, up to rejecting it outright. An AI agent may not add a Signed-off-by tag, because only a human can certify the Developer Certificate of Origin; assistance is credited with a separate Assisted-by tag.
Will AI replace embedded and kernel engineers?
It replaces particular activities rather than the role. Work that rearranges written information — boilerplate, API recall, subsystem summaries — is now cheap. Work whose input is a specific physical system, or whose output is a commitment a person can be held responsible for, is not, because there is no written source for the first and no way to assign responsibility to a tool for the second.
Which engineering skills became more valuable because of AI?
Verifying and reviewing code you did not write, producing evidence such as a reproducer or a measurement, specifying requirements precisely enough that a correct result is possible, and reporting honestly what you were unable to test.
Further reading
- AI Coding Assistants — Linux kernel documentation.
- Kernel Guidelines for Tool-Generated Content — Linux kernel documentation.
- AI Can Write Kernel Code. Only a Human Can Sign It Off. — TECH VEDA.
- Kernel Patch Review Is the Scarce Skill Now, Not Code — TECH VEDA.
- Information Is Free. Skill Is Not. — TECH VEDA.
