How to tell which code an AI wrote — and prove it later

Somewhere in your codebase there is a function no human typed. Maybe several thousand. If someone asked you today which lines those were, could you answer? Most teams cannot, and the reason is structural rather than careless: git has exactly one author field, it holds a free-text string, and nothing distinguishes a person from an agent committing under that person's credentials.

That was fine when the question never came up. It comes up now — in security review, in due diligence, in procurement questionnaires, and increasingly in contracts that specify what may or may not be machine-generated. This is a practical look at the approaches teams are using, including the ones that have nothing to do with us.

Why git can't answer the question

A git commit stores a tree, one or more parents, a committer, an author, a timestamp and a message. The author field is a name and an email, written by whoever configured the client. When Copilot suggests a block and you accept it, the commit says you wrote it — which is true in the sense that you are accountable for it, and false in the sense that matters for an audit.

You can bolt conventions on top. Some teams add commit trailers such as Co-authored-by: Copilot. It works exactly as far as everyone's discipline extends, which in practice means it captures some commits, from some people, some of the time. Worse, it operates at commit granularity: a commit that mixes hand-written and generated code is either mislabelled or unlabelled, and there is no way to recover the split afterwards.

The four approaches that actually exist

1. Commit trailers and conventions

Cheapest to adopt, weakest guarantees. Free, works with your existing tooling, survives GitHub. But it's opt-in, commit-level, trivially forgotten and trivially removed. Fine for internal curiosity, insufficient the moment somebody needs to rely on the answer.

2. IDE and editor telemetry

Your AI coding tool knows what it suggested and what you accepted, and several vendors expose that as dashboards. The data is genuinely good at the moment of authorship. The problems are that it lives in a vendor's system rather than your repository, it rarely survives refactoring, and if you change tools the history doesn't come with you. It answers "how much did we accept last month," not "which lines in this release."

3. Dedicated provenance tools

A category has formed here, and it's worth knowing about regardless of what you pick. Tools like LineageLens, AgentDiff and various git-native taggers record which assistant produced which lines, some with cryptographic signing, most storing the record in or alongside git history. If you intend to stay on git and simply need the provenance layer, look at these seriously.

Their shared constraint is that they are reconstructing information after the fact, into a data model that was not designed to hold it. Provenance ends up beside the history rather than inside it, which means it can drift, be stripped, or be missing for any commit made before the tool was installed.

4. Version control that records it natively

The alternative is to capture authorship as structured data at the moment of the commit, because that is the only moment the truth is known for free. This is the approach kal takes: every snapshot stores an author as {name, kind: human|ai, model, session} rather than a string, sealed inside the content-addressed object. Nothing is inferred later because nothing needs to be.

The trade-off is honest and worth stating: it means adopting a second tool. kal mitigates that by running alongside git rather than replacing it — kal git sync mirrors snapshots into ordinary git commits with the metadata in trailers, so GitHub, your CI and your reviewers see a normal repository.

What "proving it" actually requires

Tracking and proving are different problems. A dashboard showing 38% AI-generated satisfies curiosity. An auditor, an acquirer or an insurer will ask three further questions:

• Can this record be altered after the fact? If the provenance lives in a mutable database or a file anyone can edit, the answer is yes, and its evidentiary value is close to zero.
• Which of the AI-authored changes were verified by anything? The interesting number is not how much a model wrote — it is how much a model wrote that no test and no human ever checked.
• Is the underlying history intact? A provenance report is only as trustworthy as the commit graph it describes.

Those three questions are why kal ships kal attest: it produces a report of the AI-written share of a revision, broken down by model, with verification coverage and the explicit list of unverified AI changes, carrying a SHA-256 digest of its own canonical form and an optional HMAC signature. Edit any number in the report and both checks fail. Recompute the digest to cover the edit and the signature still fails.

A concrete starting point

Whatever you choose, do these three things this quarter:

1. Decide what granularity you need. Commit-level is much cheaper than line-level and sufficient for many policies. Don't buy line-level rigor you won't use.
2. Make attribution automatic, not disciplinary. Anything relying on engineers remembering to tag their commits will be incomplete, and incomplete provenance is arguably worse than none because it looks authoritative.
3. Record verification alongside authorship. "An agent wrote this and the test suite passed on it" is a fundamentally different risk statement from "an agent wrote this," and only one of them survives a review meeting.

The teams that will handle the next two years well are not the ones using the least AI. They are the ones who can say precisely what it wrote, and show their work.