Editor Blame for AI-Edited Code: Who Changed What and When

Git blame is the most-used code-archaeology tool a developer owns. It tells you who changed a line and when. It does not tell you which Claude session produced it, what prompt drove it, what model answered, or what reasoning the agent gave for the change. For AI-edited code, that gap is structural — and increasingly the gap that matters.

The git blame analogy

A developer looking at a confusing line of code reaches for git blame. The information returned is precise and well-known:

• The commit hash that introduced the line.
• The author of the commit.
• The date of the commit.
• The commit message — usually a sentence or two of context.

For human-authored code this is usually enough. The commit message captures the why. The author's name resolves any remaining ambiguity in a Slack DM. The commit history gives you the surrounding context.

For AI-edited code, every one of those fields collapses to less useful information:

• The commit hash is often Co-Authored-By: Claude — useful as a flag, not as an investigation path.
• The author is usually you. Claude did the work; you committed it.
• The date is the date you committed, not the date the AI session that produced the change ran.
• The commit message is whatever you typed at commit time — sometimes a summary of the AI's work, sometimes "wip" or "claude session".

The fields exist. They no longer answer the questions that matter for AI-edited code.

What AI blame would answer

The questions that come up when looking at a confusing AI-edited line are different from the questions for human-edited code. The honest list:

• Which Claude session produced this line? Out of the hundreds of sessions in ~/.claude/projects/, which one's transcript should I open to see the conversation that produced this?
• Which model answered the turn that wrote this line? Was this Opus reasoning, Sonnet quick edit, Haiku tool-call? The quality, completeness, and likely correctness of the change depends on which.
• What was I asking for when this was written? The user prompt that drove the turn is the closest thing to a "commit message" for AI-edited code, and it is captured verbatim in the JSONL transcript.
• What other files did the same turn touch? A single AI turn can edit ten files. Knowing the other nine is often the difference between "this change makes sense in isolation" and "this change is part of a bigger refactor I forgot about."
• Did the model give a reason in the text response? The assistant block adjacent to a tool call often contains explanation. The explanation is useful context that the commit message rarely captures.

None of these are derivable from git blame alone. All of them are derivable from the JSONL transcripts plus a mapping from "which file, which line" to "which session's tool call." That mapping is the missing layer.

Gutter annotation UX

The conventional surface for blame information is the gutter — the narrow strip to the left of the editor's line numbers. GitLens uses it. The VS Code timeline view uses it for file history. The natural place for AI-edited blame is the same surface, layered or alternated with git blame.

The information design for an AI-blame gutter entry, when hovered:

Session: claude-session-2026-04-12T14:23-fix-auth-bug
Date: 2026-04-12 14:31:18
Model: claude-opus-4-7-1m
Account: alex (Pro)
Cost: $0.12 (this turn) / $1.47 (this session)
Tool: Edit
Other files touched this turn: src/Auth/Login.php, src/Auth/Logout.php
User prompt: "fix the JWT validation in src/Auth/ — the refresh token logic
              is double-encoding the timestamp"
Model response: "I see the issue. The Iso8601 conversion was being applied
                twice because the Database column was already storing the
                timestamp in Iso8601 format. Removing the second conversion
                in the refresh handler."

That is the information the developer wants when they hover the line. The size budget is generous — gutter hover panes in VS Code can be substantial. The key property is that all of this data is already in the JSONL transcript; the UI just needs to surface it in the gutter.

The surfacing requires three pieces:

1. A per-file edit log — when each AI tool call modifies a file, record the line range affected. This produces a "blame" for AI edits without needing to read every JSONL on demand.
2. A per-line attribution index — given a file and a line number, return the most recent AI edit that touched that line. Cheap to build, cheap to query.
3. A hover handler in the editor — when the developer hovers a line, look up the attribution, fetch the rest of the metadata from the source JSONL, render the panel.

The VS Code Timeline integration

VS Code already has a Timeline surface for file history. By default it shows git history per file: commits, dates, authors. The Timeline is extensible — extensions can contribute custom entries.

AI-edited code can contribute Timeline entries the same way git does. Each entry represents one AI tool call that modified the file. Clicking the entry opens the source session's transcript, scrolled to the relevant turn. The Timeline becomes a unified history view: git commits and AI sessions interleaved chronologically, each pointing at its source artifact.

The user-visible benefit is that the file's full editing history — human commits and AI sessions — lives in one place. You stop having to switch between git log and grepping ~/.claude/projects/ to reconstruct what happened to a file last Tuesday.

Power Claude ships this Timeline integration as part of its Session Trail — if you work across long Claude Code sessions and want the attribution index without building it yourself, the 14-day Premium Trial is $0 today; cancel anytime before day 15.

The implementation note: VS Code's Timeline contribution API is straightforward. The harder part is keeping the contributed entries in sync with ~/.claude/projects/ as new sessions land. A file-watcher plus an incremental indexer keeps the Timeline current without rescanning the whole corpus on every change.

Hover cards everywhere

Once the per-line attribution exists, the same metadata can power additional surfaces beyond the gutter:

• CodeLens above function definitions. "Last AI edit: 4 days ago by opus session #fix-auth-bug. 3 turns. $0.41."
• Commit comparison view. When reviewing a PR, see which lines were AI-edited and from which session. This is increasingly important for code review at organizations that allow AI assistance.
• Search-result enrichment. When the search panel shows a match, show whether the surrounding code was AI-edited and link to the source session.
• Inline reasoning panel. Click a line; see the assistant text block adjacent to the tool call that wrote it. The model's explanation, in its own words, available without leaving the file.

The unifying property is that every one of these surfaces is reading the same per-line attribution index. The data structure is small and cheap. The user-facing utility compounds across surfaces.

Frequently asked questions

Doesn't `Co-Authored-By: Claude` in commit messages solve this already?

It signals that Claude was involved. It does not tell you which session, which model, which prompt, or which other files were touched in the same turn. The Co-Authored-By line is a flag, not an investigation path. AI blame extends what the commit message can offer — it does not replace it.

What if I commit AI work after substantial manual edits — is the AI blame still accurate?

Per-line attribution can become stale if you edit the same line manually after the AI edit. A working AI-blame system handles this by tracking the most recent AI edit per line, and clearly distinguishing "AI-edited and unchanged since" from "AI-edited then human-edited." Both states are useful to know.

Will this work across multiple developers on a team?

The JSONL transcripts are per-machine. If your teammate's Claude session edited a file, their machine has the transcript and yours does not. Cross-machine attribution requires a shared store — a team Insight Graph instance that each developer's extension publishes to. That is a different architecture than the single-developer version.

Does AI blame slow down the editor?

The per-line attribution index is small — typically less than 1MB for a year of AI sessions on a single project. Hover lookups are sub-millisecond. The cost is in keeping the index updated as new sessions land, which is incremental work the file watcher does without user-visible impact.

Can I see this for code that was AI-edited before I installed the extension?

A retroactive scan of ~/.claude/projects/ can build the attribution index for historical sessions, subject to whether the JSONL transcripts still exist (sometimes users prune old projects). The result is a one-time backfill that produces blame for everything in the corpus, plus ongoing incremental updates for new sessions.

Closing

Git blame answered the right questions for human-authored code. AI-edited code needs a layer above git blame — one that points at the session, the model, the prompt, and the reasoning. The data exists. The Insight Graph we ship surfaces it in the gutter and the Timeline, where the editor already looks.

Session Trail is a Pro feature. If you want to try it on a real project, the 14-day Premium Trial is $0 today — it adds Session Trail, the per-line attribution index, and the Timeline integration out of the box; cancel anytime before day 15. Not ready for a trial? Install Power Claude Free and see what the extension looks like in your editor first — free download, 7-day trial, no credit card required.