Originally published on jonattan.in.
Sometime in the next twelve months, someone outside your engineering team is going to ask a question your git history cannot answer: which parts of this codebase were written by AI?
It might be a customer running vendor due diligence. It might be a SOC 2 or ISO 27001 auditor who has added AI usage to their questionnaire. It might be your own legal team after reading the U.S. Copyright Office's position that purely AI-generated work is not copyrightable, and that AI-generated portions must be identified and disclaimed to protect what the humans actually authored. Whoever asks first, the honest answer at most companies today is the same: we don't know, and we have no way to reconstruct it.
That answer was fine in 2024, when AI wrote autocomplete suggestions. It is not fine in 2026, when agents open pull requests, refactor entire modules overnight, and, in a lot of teams, produce the majority of merged lines. The tooling rolled out faster than the governance, and the gap between the two is now a real liability.
Why This Got Urgent in 2026
Three separate pressures converged this year, and none of them are going away.
The EU AI Act's transparency rules go live on August 2, 2026. Article 50 takes effect that day, requiring machine-readable marking of AI-generated content across modalities, with a Code of Practice on transparency whose signatories get listed publicly this month. To be precise, Article 50 targets content presented to people (chatbots, synthetic media, deepfakes), not your source code. But regulation works by ripple effect. Once a company has to prove provenance for AI-generated marketing copy, its procurement team starts asking the same question about the software it buys. "Sufficiently obvious AI interaction" is a defense for a chatbot. It is not a defense in a due-diligence questionnaire.
Copyright is a spectrum problem, not a yes/no problem. Code authorship in an agentic workflow runs from "human typed every character" through "human wrote the prompt and edited the output" to "agent planned and executed the change while the human slept." The Copyright Office cares where each file falls on that spectrum. Your git log, as it stands, records none of it. A commit authored by jonattan tells you who ran git commit, not who reasoned about the change.
Auditors caught up. Security reviews and enterprise customer assessments are starting to ask about AI usage in codebases directly, and "we estimate around 60%" is not an answer that survives an audit. The teams that can answer with data will close enterprise deals faster than the teams that answer with vibes.
If you run an engineering org, this is the same governance lesson the ops world learned when agents started holding the pager: autonomy without an audit trail is a loan against your future self.
What "Provenance" Actually Means for Code
A useful provenance record answers four questions for any given change:
- Origin: was this change human-typed, AI-suggested, AI-authored with human review, or fully autonomous?
- Instrument: which tool and model produced it (Claude Code, Codex, Cursor, an internal agent), and under what version?
- Intent: what prompt or task description caused it? A diff without its prompt is an effect without a cause.
- Oversight: which human reviewed it, and how substantially?
Notice that question 3 is really a context problem. The prompt, the files the agent read, and the instructions it operated under are the actual explanation of the code. That is the same argument I made about context engineering: what an agent knew when it acted is the most valuable and most discarded artifact in the whole workflow. Provenance is context engineering pointed backwards in time.
The Practical Playbook
You can get from "no idea" to "audit-ready" without buying an enterprise platform. Here is the stack, cheapest first.
1. Commit trailers, today
Git already has the mechanism. Claude Code appends a Co-Authored-By: Claude trailer by default; most teams delete it because it feels like noise. Stop deleting it. Standardize it instead, and extend it:
feat: rate-limit the webhook endpoint
Co-Authored-By: Claude <noreply@anthropic.com>
AI-Origin: agent-authored, human-reviewed
AI-Tool: claude-code/2.x (claude-fable-5)
Trailers are machine-readable (git log --format='%(trailers)'), survive rebases better than commit-body prose, and cost nothing. A one-page convention doc plus a CI lint that rejects unlabeled commits gets you 80% of the value.
2. Keep the agent sessions
Every coding agent produces a session transcript: the prompts, the files it read, the commands it ran. Most teams let these evaporate on the laptop where they happened. Archive them. Even a dumb S3 bucket keyed by commit SHA turns "we think an agent wrote this" into "here is the exact conversation that produced this diff."
3. Link commits to prompts automatically
This is the layer where new tooling is showing up fast. brain0, released this month, is the most interesting one I've found: it passively ingests Claude Code and Codex sessions, builds a decision graph linking every commit to the agent prompts behind it, and runs offline by default with signed provenance attestations. One command, Node 20, no egress. There is a growing category of provenance tools around it, but the pattern matters more than the vendor: capture the prompt-to-commit link at the moment it happens, because it cannot be reconstructed later.
4. Put origin in the PR template
Add one required field to your pull request template: AI involvement (none / assisted / agent-authored) and reviewing human. Reviewers already know the answer at review time. Recording it costs ten seconds; recovering it eighteen months later costs a forensic project.
5. Do not bother with AI code detectors
The tempting shortcut is to run a classifier over the repo and label code after the fact. The research is clear that attribution lives on a spectrum a detector cannot recover: heavily edited AI output and idiomatic human code converge fast. Detection is a probabilistic guess. Provenance captured at write time is a record. Auditors accept records.
The Uncomfortable Part
The reason to do this is not compliance theater. It is that provenance changes incentives inside the team.
When AI-authored code is labeled, review effort goes where risk actually lives. When prompts are archived, debugging a bad change starts from the reasoning that produced it instead of from archaeology. And when a customer asks "how much of this did AI write," you get to answer with a number and a methodology while your competitor schedules a follow-up call to buy time.
Every previous wave of engineering governance (version control itself, code review, CI, SBOMs) looked like bureaucratic overhead right up until it became table stakes. AI code provenance is at that exact inflection point now, with a regulatory date circled on the calendar for August 2. The teams that can answer "who wrote this code" will not be the ones that typed the most of it themselves. They will be the ones that wrote it down.
Top comments (5)
This is a great post with a timely insight. I think most teams are going to find themselves at the position of trying to understand how their AI/ML models are built and what data was used to train them. Especially now that audits and enterprise due diligence are starting to come into play.
I like how you've tied provenance back to how we do development today. The connection between prompts, tools and human input back to each change in the system is critical for debugging and reviewing changes. I agree that it's about enabling your processes rather than just compliance.
I think you hit on something really important about detection versus recording in the context of prompts. Especially how challenging it is to reason about prompts once they've been used. The ability to capture this information at the time of change is going to be critical.
Would be interested to see how you start to think about these concepts in practice. I'm working on similar concepts around agents that also have to deal with understanding impact, but would love to see how you'd structure it without impacting developer productivity.
Thanks, glad the detection vs recording point landed. It was the part I rewrote the most.
On productivity: provenance has to ride on checkpoints developers already pass through. Commits and PRs exist, so trailers and a PR template field cost basically nothing. Session capture should be a background process nobody thinks about. The moment someone has to fill in a form after the fact, data quality collapses and you're back to guessing.
Also worth separating the write path from the read path. Capture needs to be passive and lossless, even if the raw data is ugly. The structure you're describing (decision graphs, impact) can be built later on top, as long as the prompt-to-commit link was recorded when it happened. That's the one thing you can't reconstruct.
Impact for agents is the harder half of this. Curious what you end up with.
I completely agree. The point about provenance being part of the existing workflow rather than an additional burden is really important.
And that's where the difference between passive capture and analysis comes in, right? Capturing the raw context at the moment of creation is straightforward, but the analysis of impact, risk, and traceability is a process that evolves with time.
The challenge with agent impact also seems fascinating - as agents become more autonomous, understanding their impact on the system requires consideration of both immediate effects and long-term consequences.
Looking forward to seeing how this space develops. There's clearly potential for tools to emerge around agent workflows and developer provenance.
Yeah, the long-term consequences part is what makes it interesting. Once agents start building on top of code other agents wrote, provenance stops being a flat log and becomes a chain. A bad assumption in one prompt can propagate through three generations of changes before anyone notices, and without the records you can't trace it back to the source.
Thanks for the thoughtful comments on this one. Keep me posted on what you build.
That is a nice phrasing, turning the flat log of operations into a chained lineage fundamentally changes the nature of the problem. As soon as agents operating on each other’s outputs begin to assume responsibility for their outputs, even minor assumptions may snowball into critical ones that require non-trivial reasoning to untangle.
I think you’re right to highlight that with regards to provenance: it transforms from an auditable trail of compliance into something more akin to a logic of dependency, and the ability to reason about evolution of decision making capabilities across iterations of such a system becomes critical.
Your thoughts on this topic are greatly appreciated, as always - I hope to see further developments in the future and intend to keep track of your progress in this field.