Build1 publisher3 min readPublished
The kernel's Assisted-by trailer makes AI help a signed line, not a rumour
Linux now has trailer keywords for AI-assisted patches. The interesting part is not the tag, it is that a human has to put it there and existing scripts already parse the field.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Greg Kroah-Hartman pushed a handful of new trailer keywords into the Linux kernel's sign-off conventions, including Assisted-by, Inspired-by, Referenced-by, and Reviewed-by and Acked-by variants.
- In mid-2025, kernel maintainers updated Documentation/process/submitting-patches.rst and the scripts/get_maintainer.pl infrastructure to recognize a new class of trailer tags.
- Previously, git commit messages in the kernel could include Reported-by, Tested-by, Reviewed-by, Suggested-by, Acked-by and Signed-off-by.
- The Assisted-by tag does not require disclosure of which tool was used, but it does require human accountability: the tag is placed by a person, not generated autonomously.
- Assisted-by mirrors how Reviewed-by and Acked-by already function: they are social contracts, not machine outputs.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
Greg Kroah-Hartman pushed a set of new trailer keywords into the Linux kernel's sign-off conventions, including `Assisted-by` and `Inspired-by` [1]. The consequence is narrow and real: AI involvement in a patch becomes a line of structured text that a named human attaches, in the same commit-message field that kernel tooling already reads [4][7].
According to the dev.to write-up by Tamizuddin, the change landed in mid-2025 as an update to `Documentation/process/submitting-patches.rst` and to `scripts/get_maintainer.pl` [2]. The pre-existing vocabulary was `Reported-by`, `Tested-by`, `Reviewed-by`, `Suggested-by`, `Acked-by` and `Signed-off-by` [3]. One caution before you quote the list back to anyone: the same article names `Reviewed-by` and `Acked-by` variants among the new additions while also listing both as already available, so the exact boundary of what is new should be checked against the documentation rather than the summary [2].
The design decision worth copying is what `Assisted-by` does not do. It does not require disclosure of which tool was used, and it is placed by a person rather than emitted autonomously [4]. That puts it in the same category as `Reviewed-by` and `Acked-by`, which the article describes as social contracts rather than machine outputs [5]. Torvalds did not champion it; it came up through the maintainer chain as a practical acknowledgment that developers were already using AI and the existing trailers described the contribution badly [6].
This is cheap to adopt precisely because the plumbing exists. `checkpatch.pl`, `git log` and maintainer scripts already parse trailers for filtering and statistics [7], so a new keyword costs nothing on the parsing side and everything on the norm side. The article expects `Assisted-by` entries to eventually reach code intelligence dashboards, blame views and license or compliance audits [12], and expects corporate contribution guidelines to follow the kernel's tone [13]. Both are the author's forecast, not documented policy.
The line that will get argued about in review is the liability split. `Signed-off-by` certifies that you vouch for the code; `Assisted-by` records where help came from and does not transfer that responsibility [8][9]. The article's own advice is that if you accept AI output without review, only `Signed-off-by` is appropriate, and that you should reconsider the workflow [10]. That is the honest reading: the trailer is a provenance note, not a shared-blame clause.
Anyone planning to mandate this internally should note the gap. The form that names the model and the editor, such as `Assisted-by: Claude (Anthropic) via Cursor`, is not official kernel policy by the article's own admission [11]. Because the official tag requires no tool disclosure [4], a compliance process that reads only trailers cannot tell from the commit which model or vendor touched the code [1]. If that identification is what your auditors want, the kernel convention does not supply it and a local convention on top will not be portable.
What to watch: whether `checkpatch.pl` gains an enforcement or warning path for the new keywords, whether the tool-naming form is ever written into `submitting-patches.rst`, and whether maintainers outside the kernel copy the human-signed design or reach for something machine-generated instead. The second one decides whether provenance data is comparable across repos or just locally true.