October 19, 2026 · Kealu Vector Team · Engineering
Detectors of AI-generated code score near a coin toss on code outside their training data. A provenance record made at the time answers the question, and acceptance is the decision that matters; one public pull request shows both.
Reading the code does not tell you whether an AI wrote it. Published evaluations put detectors built for prose near 0.5 in accuracy on code, show detectors trained on code failing outside their training data, and find every detector catching far fewer positives once false alarms are held low. What answers the question is a provenance record made at the time: who or what produced the change, disclosed in the commit, with the review and the tests that followed. The decision that matters is whether the change is accepted, by whom and on what evidence, and that decision is the same whatever produced the code.
The question "how to tell if code is AI-generated" has been measured, and the measurements point away from detection.
Pan and colleagues ran five detectors over 5,069 programming problems with human-written Python solutions and the solutions a chatbot wrote for the same problems, under thirteen prompt variants (ICSE-SEET 2024). The detectors had been built for prose. Their conclusion: "Existing AIGC Detectors perform poorly in distinguishing between human-written code and AI-generated code, indicating the inherent weaknesses of current detectors." On the baseline variant, four of the five detectors scored between 0.4893 and 0.5043 in accuracy, and the paper says of two of them that their results "hover around 0.5"; the fifth reached 0.6056. One widely used detector labeled almost nothing as machine-written: its rate of catching AI-generated code was 0.0016 on the baseline and never rose above 0.1721 across the thirteen variants.
Suh and colleagues repeated the exercise with four code-generating models, three languages and a detector trained on code rather than prose (ICSE 2025). The prose detectors again scored "mostly less than 0.6" in accuracy. The code detector, fine-tuned on Java written by one chatbot, "fails to generalize effectively across different programming languages, programming tasks, and generative LLMs": on Java from a different dataset, by the same chatbot, it reached an accuracy of 32.26 percent.
CodeMirage tested ten detectors on about 210,000 samples across ten languages and ten production models, with paraphrased variants (Guo and colleagues, 2025). Its last finding: "despite decent F1 scores, all detectors suffer a dramatic drop in true-positive rate once the false-positive rate is constrained, showing that they fail to catch enough positives under realistic, low-alarm requirements and are therefore impractical." AICD Bench, with two million examples from 77 models in nine languages, measured the average macro F1 across detectors at 0.63 when the domain and the language matched the training data, and 0.21 when neither did (Orel and colleagues, 2026).
Provenance records origin when the artifact is made, so nothing has to be inferred later. The SLSA framework, used for build integrity in the software supply chain, states the purpose of its provenance format as to "Describe how an artifact or set of artifacts was produced" (SLSA v1.0). For a change written with an AI tool, the record is far simpler, and open-source projects have converged on a form: a trailer in the commit message, next to the line that names the author. Three large projects now ask for or recommend one, each with its own wording.
The Linux kernel's guidance for coding assistants asks for "Assisted-by: LLM TOOL1] [TOOL2]" and draws the line on responsibility: "AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO)." ([kernel documentation) Its companion page on generated content adds a warning to contributors: "If tools permit you to generate a contribution automatically, expect additional scrutiny in proportion to how much of it was generated."
LLVM's policy names who is accountable: "The contributor is always the author and is fully accountable for their contributions." It puts the disclosure next to the authorship: "Contributors should note tool usage in their pull request description, commit message, or wherever authorship is normally indicated for the work. For instance, use a commit message trailer like Assisted-by: <name of code assistant>." (LLVM AI Tool Use Policy) The Apache Software Foundation recommends "Generated-by: <Name of Tool> <Version>" in the commit message, so that release tooling can later gather the trailers into "a machine parsable Tooling-Provenance file" (ASF guidance).
Our white paper The Agentic Engineering Assurance Layer places this kind of evidence where it belongs: "Provenance is necessary evidence. It does not by itself establish fitness for intended use. An artifact can be authentic, untampered, and wrong for its requirement." The record says who made the change and with what. Whether the change should ship is a separate decision, with its own evidence.
Take one public change in the LLVM compiler, a project with the policy quoted above. Pull request 229088 fixed an out-of-bounds read: a format string that ended in a lone percent sign tripped an assertion in the GPU printf code. The fix to the production source is one condition on one line. The description ends with the trailer the policy asks for, naming the assistant and its version, and each commit carries the author's Signed-off-by line.

| What the record says | What a detector would see |
|---|---|
| Who takes responsibility: a Signed-off-by trailer from a named engineer, on each commit of the pull request and on the merged commit | Nothing about responsibility |
| What tool helped: an Assisted-by trailer with the assistant's name and version, in the description and the merged commit | A guess about origin, from one changed line and the test around it |
| What the humans changed: reviewers asked for the test to move into an existing file and for its checks to be generated by script; the second commit of the pull request did that, without an Assisted-by trailer | Nothing about who changed what, or why |
| Who accepted: three approvals on October 5 and 6, 2026; the fourth reviewer agreed that the refactor suggested in review could follow; the author merged on October 12 | Nothing about acceptance |
| What was left open: the loop refactor, logged as a follow-up patch | Nothing |
The record took the contributor one line to write, and the trailer is in the merged commit on the main branch. The two commits were squashed into one at merge, so the split between the assisted fix and the human rework lives on the pull request page; a team that wants it in the branch history has to merge differently. A detector's answer, on a one-line condition in C++, would be a score, with no way to check it.
The checklist below is written for a change that an AI tool produced or helped produce, from a completion assistant to an autonomous coding agent, the four categories of AI coder. It pairs with the review checklist for agent-written changes, which asks what the change was for and who accepts it.
| Question | Where the answer should already be |
|---|---|
| Which tool helped, and which version? | A trailer in the commit message, in the form the project's policy names |
| Who takes responsibility for the whole contribution? | A Signed-off-by line, or the author field, from a person who can be asked |
| For an agent that acted on its own, which session produced the change? | A link to the session log in the commit, or a stored transcript the reviewer can open |
| Which parts did a person change after the tool, and why? | Separate commits kept through the merge, or a note in the description, so the two are not blended |
| Did the tool also write the tests? | The commit that added them, with the same trailer if so |
| What did the reviewers see, and when? | The review thread, with approvals in the order they happened |
| Did the author read and understand every line? | The policy's own words: in LLVM, "The contributor is always the author and is fully accountable" |
| Where will the record live in a year? | The repository history, and for consequential software, an evidence store that survives the hosting service |
NIST's secure development profile for generative AI declines to treat machine-written code as a category of its own: "Practices and tasks in this Profile do not distinguish between human-written and AI-generated source code, because it is assumed that all source code should be evaluated for vulnerabilities and other issues before use." (SP 800-218A)
The origin of a change is one input to the acceptance decision. Our white paper AI Has Moved the Bottleneck lists what that decision rests on: "Evidence supporting a consequential decision should travel with the outcome. It should identify the intent, subject, methods, environment, results, limitations, provenance, applicable policy, residual risk, and decision authority associated with the work." Provenance is one word in that list. An acceptance decision in software whose failure has consequences needs the other nine, held together in an assurance case, and none of them changes when the author was a person, a person with an assistant, or an agent working alone. The acceptance question is the one an organization has to answer anyway, to a customer, an assessor or an incident review, and our article on agentic engineering takes it up.
The Agentic Engineering Assurance Layer is the proposed category for the layer that governs how agentic engineering work is performed and evidenced, so that humans can trust and accept the resulting work. The white paper The Agentic Engineering Assurance Layer develops it as a vendor-neutral category, and the questions raised here hold whatever tools a team uses to answer them. Kealu Vector, currently designated Vector Assurance Assist, is our early-access implementation of that category.
By the record. Published evaluations report detectors built for prose scoring near 0.5 in accuracy on code and detectors trained on code failing beyond their training data. A provenance record made at the time, an Assisted-by or Co-authored-by trailer in the commit message with the author's Signed-off-by line, answers the question reliably; the Linux kernel, LLVM and the Apache Software Foundation already ask for or recommend one.
Not well enough to rely on. The ICSE-SEET 2024 study by Pan and colleagues found four of five prose detectors scoring between 0.4893 and 0.5043 in accuracy on code; the ICSE 2025 study by Suh and colleagues found that a detector trained on code "fails to generalize effectively across different programming languages, programming tasks, and generative LLMs"; the 2025 CodeMirage benchmark found all ten detectors it tested "impractical" under realistic false-alarm limits.
A statement of who and what produced a change, made at the time and attached to the change itself: a commit trailer naming the tool and version, the responsible person's sign-off, a link to the agent session where one exists, and a separation between what the tool wrote and what a person changed afterward. For built artifacts, SLSA and in-toto define signed attestations that carry the same idea through the build.
The answer depends on the acceptance decision behind it, and that decision is the same for code of any origin. NIST SP 800-218A states that its practices "do not distinguish between human-written and AI-generated source code", because all code is evaluated before use. That decision needs the intent the change answers, tests kept apart from the producer, a reviewer with time and authority, and a record that survives the session. A provenance record is one input to it.