I keep running into the same dumb little gap with agentic coding: the repo knows what changed, but it usually has no idea why.
You open a diff three weeks later and find a weird little abstraction. It passed review. It has tests. git blame points to a commit. The PR says "refactor session handling" or something equally useless. What you need is the moment before the line existed: the prompt that asked for it, the model that wrote it, the failed tool call that boxed the agent in, the review comment that made it keep the abstraction instead of deleting it.
Git can tell you who committed a line and when. A PR can tell you the final shape of the change. CI can tell you whether the tests passed. None of that tells you what the agent was asked to do, which model wrote the line, what alternatives it considered, what instruction it was obeying, or which part of the prompt made it choose the weird abstraction you are now staring at.
That missing join is starting to feel load-bearing.
Small caveat before this gets stupid: traces do not magically expose model intent. They are not mind-reading. They give you evidence for why a change happened: inputs, constraints, tool outputs, review decisions, and surrounding context. Still a lot better than archaeological guessing.
The what is not enough anymore
For human-written code, git blame is already a pretty lossy instrument. It points at a commit and a person, then politely pretends that is the answer. Sometimes that works. The commit message is good, or the PR thread has the missing context. Other times you are just out of luck and now you are doing archaeology with a shovel made of vibes.
Agent-written code makes that worse. Not because agents are uniquely mysterious, but because the actual decision surface is bigger. A line might be downstream of:
- the user's original request
- repo instructions in
AGENTS.md - a model-specific system prompt
- tool output from a failed attempt
- a review comment from another agent
- a memory or previous session summary
- a safety constraint the model half-followed
The code is only the artifact left behind. The interesting part is the trail that produced it.
Git AI attaches authorship to the repo
git-ai is interesting because it treats AI authorship as a git-native problem instead of a vibes problem.
The repo describes it as a git extension for tracking AI-generated code. The important bit is that it does not try to "detect" AI code after the fact. Detection is the wrong primitive. Git AI records AI-authored lines and links them to the agent, model, and transcript behind the change.
That matters because it turns a dumb question into a better one.
The dumb question asks whether this was AI-generated.
The better question asks which agent, model, prompt, and session produced this line, and what that context said.
Git AI stores attribution in Git Notes, with pointers out to transcript storage. It also exposes commands like git-ai blame and git-ai stats, so the repo can answer questions like "how much of this commit was AI-authored?" or "which model/session wrote this block?" without shoving all of that metadata into source files or commit messages.
That is the right direction. The attribution layer should sit next to git, not inside every future prompt as a giant haunted transcript.
It is also cooperative provenance, not forensic truth. If an unsupported tool edits the repo, or an agent fails to report cleanly, or a human rewrites half the hunk afterward, the trace can get lossy. Fine. Lossy provenance is still better than pretending after-the-fact AI detection is science.
Agentlytics gives you the session side
Agentlytics comes at the same problem from the other end.
Instead of starting with lines of code, it starts with the scattered mess of AI coding sessions across tools: Cursor, Windsurf, Claude Code, VS Code Copilot, Zed, OpenCode, Codex, Gemini CLI, and a bunch more. It pulls sessions, models, costs, tools, token use, projects, and chat history into one local place.
That sounds like dashboard fluff until you have more than one agent in the loop. Then it becomes the difference between asking the repo what happened and digging through five app histories like a raccoon in a dumpster.
Which model is doing the expensive work? Which editor is generating the longest sessions? Where is the context going? Which tools show up in the sessions you keep regretting? Which agent produced the plan that later turned into the PR?
Git history cannot answer those questions. It was not built to. Session analytics can.
The missing part is the join
Git AI and Agentlytics are only useful together at the join.
Git AI can map a line back to an agent session.
Agentlytics can map a session to the model, cost, tools, project, and larger pattern of work.
These two may not integrate cleanly end-to-end yet. But they expose the two halves of the primitive that is missing.
Put those together and the repo can finally answer why a line exists. The code points back to the process that made it, and the process points forward to the code it changed.
The result is a richer map than commit history alone:
- line → agent → model → session → prompt
- PR → plan → review → tool trace → final diff
- repository → recurring agent habits → code durability
- model choice → accepted lines → rewrites during review
- failed run → repeated tool pattern → future rule or eval
The review piece matters. Git AI and Agentlytics cover provenance and session telemetry. Review outcomes have to come from PR systems, review comments, CI, reverts, follow-up rewrites, and whatever acceptance gate the team uses. Without that outcome layer, you only know who wrote the line and what session produced it. You still do not know whether the work survived contact with review.
This is the part I care about. Agentic coding needs traceability because otherwise the engineering team cannot learn from the system it is building with. Managers will absolutely try to turn it into a dashboard for yelling at people, because of course they will, but that is the failure mode.
Why is the debugging surface
The first payoff is debugging.
A weird line of code without a trace is just a weird line of code. You can infer intent from surrounding code, tests, and commit messages, but you are guessing. A weird line with traceability gives you the original instruction, the failed attempts, the tool output, the model, and sometimes the exact sentence that caused the agent to go sideways.
That changes the review question from "what does this do?" to "why did the system produce this?"
Those ask different things. "What" gets you local comprehension. "Why" gets you process improvement.
If the model misunderstood an instruction, fix the instruction. If it copied a pattern from stale repo docs, fix the docs. If it failed after a tool error and improvised, fix the tool contract. If the reviewer kept rubber-stamping the same kind of abstraction, fix the review rubric. Without traces, all of those collapse into one useless complaint about the agent writing weird code.
Where this gets ugly
This is where the clean diagram starts bleeding.
Attribution has to survive squash merges, rebases, cherry-picks, generated files, copied snippets, partial-line edits, human rewrites after agent drafts, and multiple agents in one diff. Some of that will be messy. Some of it will be probabilistic. Some of it will be wrong enough that the UI needs to admit uncertainty instead of cosplaying perfect lineage.
Transcripts are also sensitive artifacts. They can contain secrets from tool output, customer data, security notes, roadmap context, and private reasoning that should not get sprayed into every PR because someone wanted a cute hover card.
So the boring product requirements matter:
- keep raw transcripts local or self-hosted by default
- store pointers and metadata separately from transcript bodies
- redact secrets and obvious PII before anything syncs
- apply retention windows instead of hoarding forever
- make transcript sharing explicit, not ambient
- aggregate by workflow when possible, not by individual as the default view
Traceability without access control is just a liability with charts.
The trap is surveillance cosplay
There is an ugly version of this where every AI-authored line becomes a scoreboard and every session becomes evidence in some productivity theater. That version sucks and will make the whole thing worse.
The point is not to shame engineers for using agents, or to pretend AI percentage is a quality metric. A repo that is 80% AI-authored is not automatically good, bad, fast, risky, or cheap. It is just 80% AI-authored. Cool. Congratulations on discovering a denominator.
The useful metrics are downstream:
- how much AI-authored code survives review?
- where does it get rewritten?
- which prompts create durable code?
- which models fail on which task types?
- which tools produce repeated dead ends?
- which repo rules improve outcomes?
Even those need definitions. Durable might mean "survived review and avoided revert/rewrite for 30 days." Or it might mean "passed the eval that matters for this subsystem." Pick the signal for the risk you care about. Do not worship the chart because it has gradients.
The line is simple: if the data helps the team fix the system, keep it. If it just gives someone a prettier stick, burn it.
If you are building this into a team workflow
The Monday-morning version is not complicated, which is rude because now we have no excuse.
- Give every agent-authored change a stable session id.
- Preserve the prompt/model/tool trace somewhere private enough to be honest.
- Attach line-level provenance to git instead of burying it in commit prose.
- Join PR review outcomes back to the session and line provenance.
- Track rewrites, reverts, and repeated failure patterns as feedback signals.
- Ban individual productivity scoreboards before some manager discovers the dashboard and starts acting haunted.
That last one is not a joke. The fastest way to ruin this layer is to turn it into "who used the most AI this week." Ask which workflows produce code that survives review, debugging, and time.
What I want from this layer
The ideal shape is boring:
- Every agent-authored line can point back to a session.
- Every session has model, tool, prompt, and project metadata.
- Every PR can show the path from request to plan to implementation to review.
- Every durable lesson can cite the trace that earned it.
- Every team can keep sensitive transcripts local or self-hosted instead of spraying prompts into random SaaS just to get a chart.
Git AI is already pushing on the line-level provenance side. Agentlytics is already pushing on the local session analytics side. Review systems own acceptance and quality gates. The missing product layer is the join: code provenance plus session telemetry plus review outcomes.
That is the difference between a repo that merely contains agent-written code and a repo that can explain how that code happened.
Notes
I do not think this should all live in one mega-tool. Please no. That is how good primitives go to die under a React admin panel.
Git should keep owning the durable code history. Session tools should keep owning raw traces and local analytics. Review systems should own acceptance and quality gates. The join layer should make those things queryable across boundaries without pretending they are the same object.
The future I want is not "AI wrote 37% of this repo." That is trivia.
The useful future is opening a line of code and asking: what problem was this solving, what did the agent try, what survived review, and what should we learn before the next agent touches it?