Provenance for agent-written code: which prompt produced this commit

[vshulcz]

The least exciting idea in this batch and the only one companies pay for. Code written by agents is arriving in repositories faster than anyone can account for it, and there is no answer to "who asked for this, and what were they told". Review will start asking. Compliance will follow.

We are sitting on the answer and doing nothing with it.

Shape

$ deja origin 9c1267a
commit 9c1267a  perf(search): bound how much of one session a query reads
  produced during claude session 2fc1d1ef, 2026-07-29 18:42
  asked for by: "давай дальше по issues, займись #513"
  the agent proposed the bound and measured 61.8 → 26.9 ms
  human approved the ranking trade-off explicitly before it shipped

Then the same thing over a range: deja origin main~20..main — which commits in this release were agent-written, under what instruction, and where a human said yes.

Why us and not a git hook

A hook can stamp "written by an agent" going forward. It cannot reconstruct the last six months, and it cannot show the instruction — the instruction lives in the transcript. Retroactive is the whole point, and it is the thing our corpus is for.

What makes it hard

• Linking a commit to a session. Time proximity plus touched files plus project gets most of the way; it will be ambiguous when two sessions ran at once, and it must say "uncertain" rather than guess. Attributing a commit to the wrong instruction in a compliance context is a serious failure, not a UX wrinkle.
• Squash merges destroy the timing signal we would lean on. This repo squashes; so does most of GitHub.
• The instruction is often several turns, not one line, and picking the wrong turn misrepresents intent.

Why it might matter more than it looks

It is the first thing on this list that an organisation, rather than an individual, has a reason to install — and it needs no server, no key, and no data leaving the machine, which is exactly what makes it acceptable to the kind of company that would otherwise ban a memory tool outright.

Kill condition

Take 30 commits from this repo, attempt attribution, and check by hand. If precision is not near-perfect, ship it as "probably this session" or not at all.

[vshulcz]

Measured the attribution precision this issue makes the gate. High precision, half the recall, and the miss mode is systematic rather than random.

40 commits from this repo, matched against sessions two ways.

Time alone is useless: 0 of 40 attributed uniquely, 35 ambiguous. Several long sessions run in parallel here, so any commit falls inside two or more.

Time plus the files a session actually touched — taken from tool_use inputs, not from prose:

attributed to exactly one session	21 (53%)
ambiguous (a tie between sessions)	0
no candidate at all	19

Zero ties is the number that matters: when this method answers, it answers with one session, and the issue's own bar was "say uncertain rather than guess".

Why the 19 miss, and it is not random

Nearly all of them are commits where the files were edited through the shell — a python3 - <<PY heredoc patching a file, sed -i, a generated file — rather than through an edit tool. No file_path in any tool call, so nothing to match on. My own working style produces this constantly.

Two consequences:

• The honest output is three-valued: this session, unknown, and never probably this one.
• Recall could be raised by parsing paths out of shell commands, and that is exactly the guesswork that made prose-based linkage unusable in Tell the reader when a recalled decision predates the code #531 — I would not do it. Better to answer for half the commits and say nothing for the rest.

Dependency

The file paths this rests on are not in the index; I read them from the raw transcripts. Product-side this needs #558 (paths indexed, +2% of the index), which is now the third feature behind that slice alongside #542 and #531.

Squash merges are the other open question the issue names, and this measurement does not settle it: this repo squashes, and attribution still worked at 53% because the squash timestamp stays close to the work. A repo that merges long-lived branches weeks later would do worse.