Who is responsible for the code an AI coding agent wrote?

Short answer: you are, and git already says so. In the repository behind this website, all 251 non merge commits made between July 18 and August 10, 2026 carry a single human name in git's author field, while 69.8% of the lines alive in that code today were written inside an AI coding agent session. Git records who ran the commit, never who produced the text, so responsibility does not split with the tool. What you can still decide is whether a record of what the agent did exists at all, because that record cannot be reconstructed after the fact.

What does git actually record about who wrote the code?

Git stores two identities on every commit, the author and the committer, and both are people. The git commit-tree documentation lists them as separate fields, the author name, email and date on one side, the committer name, email and commit time on the other. It does not say why the split exists, so the usual explanation is ours and not the manual's: the two fields diverge when someone applies a patch written by somebody else, which is the closest thing git has to the situation you are in with an AI coding agent. Neither field has a slot for a tool.

What git does offer is the trailer, a Key: value line at the end of the commit message, parsed by git interpret-trailers. The convention most people have seen is Co-authored-by, which GitHub reads to show a second face on a commit, documented as a way to credit more than one person. Some agent tooling adds its own trailer: in this repository, commits made inside an agent session carry a Claude-Session line pointing at the session that produced them.

The important part is that none of this happens by itself. A trailer exists only if something wrote it at commit time, and a commit made without it is indistinguishable, forever, from a commit typed by hand. Check what your own repository records before assuming it records anything: git log -1 --format='%(trailers)' prints the trailers of your last commit, and an empty answer is the answer.

How much of the code running right now came out of an AI agent session?

We measured it on this website's repository on August 12, 2026. This is an extreme sample and that is what makes it useful: the site is written by AI coding agents working in parallel git worktrees, with one human operator reviewing and committing. The method is to blame every line alive at HEAD, resolve each line to the commit that last touched it, and ask whether that commit carries a session trailer.

Of 90,456 lines alive across 641 tracked files, binaries excluded, 63,166 lines, or 69.8%, come from commits made inside an agent session. Restricted to PHP and Blade files, which is where the application itself lives, the share is 87.2% of 58,849 lines. The gap between those two figures has two sources of similar weight and neither of them is application code: composer.lock holds 12,631 lines that a package installer wrote, only 10% of them from a session, and the project's Markdown documentation holds another 13,547 lines, 55% of them from sessions.

The command is three steps and it only reads. Excluding binaries is not cosmetic: git blame will happily treat a favicon as 1,790 lines of authorship and inflate the result.

git log --format=%H --grep='^Claude-Session:' | sort > agent.txt

git ls-files -z ':!:*.png' ':!:*.ico' ':!:*.jpg' ':!:*.webp' ':!:*.woff2' ':!:*.pdf' \
  | xargs -0 -n1 git blame --line-porcelain -w HEAD -- 2>/dev/null \
  | grep -aE '^[0-9a-f]{40} [0-9]+ [0-9]+' | cut -c1-40 | sort | uniq -c \
  | awk '{print $2, $1}' | sort > lines.txt

join agent.txt lines.txt | awk '{s+=$2} END{print s}'

The second file also gives you the total, with awk '{s+=$2} END{print s}' lines.txt. Swap the trailer name for whatever your tooling writes, and extend the exclusion list to the binary formats your project actually has. If your repository has no trailer at all, the first file comes out empty and the honest reading is that the share is unmeasurable rather than zero.

Why doesn't "the agent wrote it" survive an incident review?

Because the questions asked during an incident are not about typing. They are who approved this, who can explain the decision behind it, and who is fixing it in the next hour. An AI coding agent answers none of the three, which is our reading of why the phrase collapses so fast in practice rather than a legal claim.

The numbers make the shape of the problem concrete. In this repository, 214 of the 251 commits carry a session trailer, and those 214 commits came from only 24 distinct sessions, a median of 7 commits per session, with the largest single session signing 37 commits on its own. So the trailer tells you which conversation a change belongs to, not which decision produced it. Knowing that 37 commits share a session is close to knowing nothing about any one of them.

This is also why "the agent did it" and "I did it" are the same answer in a review, differing only in tone. The person who started the session chose the task, read the result, and pressed commit. Everything the tool contributed passed through that gate, and the gate has a name in the author field.

What can you recover months later, and what is gone for good?

What survives is the chain from line to commit: git blame gives you the commit, the commit message gives you the trailer, the trailer gives you a session identifier. That chain is enough to answer "was this line produced in an agent session" long after everyone has forgotten the week it happened.

What does not survive is everything that made the change what it is. The prompt that started it, the alternatives the agent proposed and you rejected, the test you ran before accepting, the part you skimmed because it looked obvious: none of that is in git unless you wrote it there. A session identifier is a pointer, and a pointer is only worth as much as the store it points into, which may not be readable by whoever investigates six months from now.

The practical consequence is uncomfortable and worth saying plainly: the traceability you will want during an incident has to be created before the incident, by a habit, and no amount of tooling added later can recover a week that nobody recorded.

Which record tells you what?

How do you make agent work traceable before you need it?

Start by finding out what you already have, since many people are recording more than they think. Run git log -20 --format='%h %s%n%(trailers)' and look for any tool written line. If something is already stamping your commits, the job is to not lose it, which mostly means not squashing away the messages and not rewriting history for tidiness.

If nothing is stamping them, the cheapest useful habit is writing one line in the commit message yourself: which tool produced the change and what you verified before accepting it. That single sentence is worth more in an incident than any automatic marker, because it records the human decision rather than the machine event.

Then keep the unit of change small enough that the record means something. A session that signs 37 commits, as ours did, is a session nobody will audit; the same work split across days of small commits with honest messages is auditable by a stranger. Our measurement cannot prove that smaller is safer, and we are not claiming it does, but a record whose smallest unit is one huge session is a record that answers "when" and refuses to answer "what".

Does telling people an agent wrote it change who answers for it?

No. Disclosure changes what a reviewer looks at first, and it is the cheaper mistake when a project has no stated policy, but it does not move responsibility anywhere. The person who submits the change still owns it. That is a different question from whether a project will accept agent written code at all, which we covered separately in why projects are disabling pull requests for AI generated code, where the door is being closed from the outside. This article is about the code that already got in, into a repository you own.

The two situations pull in the same direction anyway. Whatever makes a change reviewable by a maintainer who does not trust you also makes it auditable by a colleague who inherits it, and both come down to size, message quality, and a test that fails when the change is wrong.

What this measurement does not prove

One repository is one repository. This site is an extreme case by design, so the 69.8% says what an agent heavy project looks like, not what yours looks like. Run the command on your own history before assuming any of it transfers.

The session trailer marks the session, not the line. A human started that session, read the output and committed it, so a line counted as "from an agent session" is not a line no person ever saw. In the other direction, the 37 commits without a trailer are not proof of hand typed code: a commit made outside a session, or with the marker missing for any reason, looks identical to one typed from scratch. That 37 is arithmetic, 251 minus 214, and has nothing to do with the 37 commits of the largest session mentioned earlier; the two numbers coincide and mean different things.

Two more limits worth stating. We ran git blame -w, which ignores whitespace only changes, and blame always attributes a surviving line to the commit that last touched it, so a later refactor moves authorship even when it moved nothing meaningful. And if you compare this 69.8% with the share we published earlier in the article on disabled pull requests, note that they answer different questions: that one measures the change as it happened across history, including code that has since been deleted, and this one measures only what is still standing today.