GitLens taught a generation of VS Code users that git history is a navigation surface, not just a forensic tool. Hover-to-blame, inline diffs, file-history sidebar, commit graph — all of it in one extension that became muscle memory. AI sessions need the same UX, against a different data shape. Here is what carries over from the GitLens pattern, what does not, and what an Insight Graph adds.
Why GitLens works as a model
GitLens did not invent git blame. The CLI had blame for two decades before GitLens shipped. What GitLens did was move the data from "subcommand I run when I am stuck" to "ambient information I see while reading code." That shift in surface — from on-demand to ambient — is what made it useful.
The mechanics that produced the shift:
- Inline annotations in the gutter, on every line, showing the author and date of the most recent edit.
- Hover panels that expand to the full commit message and a link to the commit itself.
- File-history sidebar that lists every commit that ever touched the current file, chronologically.
- Quick comparison between any two points in the file's history with one click.
- Bidirectional navigation — from a line to its commit, from a commit to its file, from a file's history to the related branch.
None of these are conceptually new. All of them existed as CLI invocations. The GitLens shift was making them ambient enough that developers used them without thinking — which is when the data started informing every code-reading session, not just the debugging ones.
Mapping the pattern to AI sessions
The data layer underneath GitLens is git's commit graph. The data layer underneath an AI-session navigation extension is the corpus of JSONL transcripts in ~/.claude/projects/. The structural correspondence between them:
| GitLens concept | AI-session analogue |
|---|---|
| Commit | Tool call (Edit, Write, MultiEdit) that modified the file |
| Commit message | User prompt that drove the turn |
| Commit author | Model that answered the turn |
| Commit hash | Session ID + turn index |
| Commit date | Wall-clock time of the turn |
| Branch | (No direct analogue — sessions are linear) |
| File history | Per-file edit log derived from the session corpus |
| Blame | Per-line attribution to the most recent AI tool call |
What's the same
The features that translate one-to-one from GitLens to an AI-session extension:
- Inline gutter annotations. "Last edited 4 days ago by opus session #fix-auth." The same one-line surface that GitLens uses for git authorship.
- Hover expansion. Hover the annotation, see the full user prompt that drove the edit, plus the model's text response, plus links to open the session transcript.
- File-history sidebar. Every AI session that ever touched this file, chronologically. Click any entry to scroll the transcript to the relevant turn.
- Quick comparison. Two clicks to diff the file at the start of a session against the file at the end of that session. Useful for "what did this Claude session change in this file?"
- CodeLens above functions. "Last AI edit: 2 days ago, opus session, 3 turns." A summary view above each top-level symbol in the file.
All five have direct GitLens analogues. The implementation patterns are similar — file watcher, derived index, hover provider, sidebar contribution. The visual language can be the same so that developers who already know GitLens know how to use the AI-session version without re-learning the UX.
What's different
The features that need rethinking:
- No branches. Sessions are linear. Sub-agents are siblings, not branches. The UI cannot borrow git's branch visualization wholesale.
- The "author" axis is multi-dimensional. Git has one author per commit. An AI tool call has a model, an account, a session, and a user prompt — four different attribution axes. The UI has to surface the relevant one per query. "Who wrote this" can mean "which model" or "which user prompt" or "which account" depending on what the developer is trying to find out.
- Sessions are conversations, not commits. A git commit is atomic. An AI session can span hours, include dozens of turns, and touch hundreds of files. Treating the session as the atom (like a commit) loses important within-session structure. Treating each turn as the atom (each
tool_useblock) is the more useful granularity. - Cost is a first-class axis. Git commits do not have a dollar cost. AI turns do. A history view that surfaces the cost of each AI session next to its date and outcome is information GitLens does not need to render.
- The corpus is not shared by default. Git history is committed and shared. JSONL transcripts are per-machine. Cross-developer attribution requires a shared store. GitLens did not need to solve this; an AI-session extension does, for teams.
The Insight Graph — what it adds
The productized AI-session extension we ship is called the Insight Graph. Its job is exactly the GitLens shift, applied to JSONL transcripts: move session metadata from "subcommand I run when stuck" to ambient information you see while reading code. It ships in Power Claude, which is free to download and try with no credit card needed.
If you want the Insight Graph on a real project without building the index yourself, the 14-day Premium Trial is $0 today and you can cancel anytime before day 15 — or install Power Claude Free and see the gutter blame in your own editor first, no credit card required.
The surfaces it contributes:
- Gutter blame for AI edits. Per-line attribution to the session and turn that produced the line. Hover for the prompt, the model, the cost, the related files in the same turn.
- Session timeline in the VS Code Timeline view. AI sessions interleaved with git commits, one unified file history.
- Insight Graph sidebar. A panel showing every session for this project, with filters by date, model, cost, outcome, and a free-text search across all transcripts.
- Per-turn detail panel. Click any turn in a session; see the prompt, the response, the tool calls, the files touched, the cost, the account.
- Account-aware view. When you have multiple Claude.ai accounts pooled, sessions are attributed to the specific account they ran on. Useful when reconstructing "which of my accounts ran the autonomous loop last night."
The pattern under all of these is the same: surface the data that already exists in the JSONL, in the editor surface where the developer is already looking. Nothing requires opening a new tool. The data was always there; making it ambient is the work.
Coexisting on the same gutter
The natural question is whether AI-session blame and git blame fight for the gutter. They do not have to. The gutter can show both, layered or toggled.
Two implementation patterns that work:
- Layered annotation. GitLens shows the git author by default; an AI-session indicator (a small icon or color marker) signals that the line was AI-edited. Hovering shows both attributions stacked — git on top, AI session beneath.
- Toggle modes. A status-bar toggle switches the gutter between "show git blame" and "show AI session blame." Users pick the view appropriate to the current debugging question.
In practice most teams prefer the layered approach because the question "is this AI-edited" matters less often than the underlying data. When the answer is yes, the additional metadata becomes the navigation path. When the answer is no, the gutter is just GitLens.
Frequently asked questions
Does this replace GitLens?
No. AI-session blame is additive. It tells you which Claude session produced a line and which prompt drove the edit. GitLens still tells you who committed it and when. Both surfaces answer different questions, and the most useful UX runs them side by side.
What happens to AI-session blame after I refactor the file manually?
The per-line attribution becomes stale for lines you edit manually. A working AI-blame implementation tracks the "most recent AI edit" per line, and clearly distinguishes "AI-edited and unchanged since" from "AI-edited then human-edited." Both states are useful to surface.
Can I see AI-session history for code my teammates' AI agents wrote?
Not by default. The JSONL transcripts are per-machine. Cross-developer attribution requires publishing session metadata to a shared store — a team Insight Graph instance. The single-developer version of the extension is local-only; the team version is a separate deployment.
Will my team's code review process care about AI-session attribution?
It depends on your organization's review policies. Teams that allow AI assistance generally do not require disclosure beyond Co-Authored-By: Claude in commit messages. Teams that audit AI contributions for quality assurance increasingly do want richer attribution — which model, which prompt, what reasoning. The Insight Graph data is what they want; how they consume it depends on their workflow.
Can the gutter annotations be turned off entirely?
Yes. The extension contributes annotations as opt-in providers. Users who want git-only blame can disable the AI-session contribution; users who want AI-only blame can disable GitLens; users who want both can run them layered. The defaults are conservative — annotations are off until the developer explicitly enables the surfaces they want.
Closing
GitLens taught us that history is a navigation surface, not just a forensic tool. AI sessions are history too — they just live in a different file format. What we ship as the Insight Graph is what happens when the GitLens pattern is applied to the JSONL corpus that has been accumulating in ~/.claude/projects/ without a UI to navigate it.
The Insight Graph is a Pro feature. To run it on a real project, the 14-day Premium Trial is $0 today — it adds gutter blame, the per-line attribution index, and the unified session timeline out of the box; cancel anytime before day 15. Not ready for a trial? Install Power Claude Free and see the GitLens-style navigation in your own editor first — free download, 7-day trial, no credit card required.