Narrative Version Control

A speculative exploration of version control as narrative medium

Watch the video introduction here

The Ground is Shifting

Coding with AI has made individuals more productive. It has also made teamwork harder.

The more code we produce through prompts the harder it is for the author - or anyone else for that matter - to follow.

Companies like Cognition and Linear have started to recognize this. They are rebuilding how we think about the pull request. They see that the diff is broken, They understand that reviewing LLM-created code is burning people out.

But they are still building for a world where everyone in the codebase is technical.

That world is no more.The moat around coding is largely gone, and this has meant an influx of all sorts of players into technical spaces. Code is being produced by everyone. A codebase is now a shared space for people with drastically different conceptions of what code (and coding), means. The barrier dissolved faster than the tools could adapt.

We’ve stagnated because we still treat commits as the core versioning unit. Maybe, a better unit is the prompt.

Traditional version control treats commits as discrete snapshots. You see what changed. You see the diff. But you do not see a “why”. You do not see the conversation that led to the change. You do not see the intent. And intent, in a world where the vehicle into code is prose, is everything.

Before code, there is always a conversation. A prompt. A response. A refinement. Another prompt. This sequence is where the work happens. The code is more and more a byproduct.

We think the point of entry should be intent.

What This Looks Like

The Timeline View

Instead of a list of commits, you see a narrative thread. Changes are connected by the conversations that produced them. You can trace the evolution of an idea from its first articulation to its current implementation. Our interface builds on the premise that a codebase, at first glance, should be seen through a narrative lens.

Multi-Level Abstraction

Current version control visualization fails at abstraction. You get commits, pull requests, raw diffs - all at the same level of detail. In the age of LLMs, this has become untenable: the sheer volume of changes and the opaqueness of the process that produced them make raw data nearly impossible to parse. The solution is top-down, not bottom-up.The encounter with code should be progressive disclosure, not initial overwhelm.

The top-level timeline shows key milestones - abstract enough that anyone, technical or not, can understand what features are being developed and who owns what. Zoom in and more is revealed. Each level matches a different stakeholder: executives see feature ownership and velocity, managers see what engineers are working on and why, engineers dig down to the non-abstracted truth of the repo.

The Branch Entry Point

Clicking on a branch reveals not just commits, but key moments in the LLM sessions that led to them. By default, you see the latest commit with a non-technical explanation of what the branch is implementing, as well as how many prompts and responses were exchanged with the LLM.

We also surface intent: derived from both the diffs and the conversation between engineer and LLM. This isn't a retroactive explanation of what happened, but a summary of the ideas as they were crafted in dialogue. You see the most important session excerpts, the files changed, and the corresponding diffs.

AI-Session Highlight

Clicking on any of the other points along a branch brings up what we call an AI session highlight - a step along the way to the final commit. We surface these steps based on signals that indicate a particular part of the conversation between engineer and LLM was meaningful to the work being done.

In this interface, we provide not only the diffs, but a view of the conversation between engineer and LLM as they worked on the feature. For every file affected, we include a link to the diff for that file. We also include an intent section based on the user prompts, summarizing what the engineer was trying to accomplish. This section shows additional context: whether tests failed if they were run in proximity to the session, and the volume of prompts and responses exchanged.

Intermediate points between these “highlight” snapshots show a clear breakdown of the prompting story - we can quickly get a glimpse of the story behind a more specific point in feature development, as well as files that have been touched along the way.

This is the core of the idea. You are no longer limited to seeing the final product of hours of work with an LLM—now you can see the key moments in the collaboration that led there. This makes AI-assisted development auditable and introspectable in a way that isn't possible today. It gives insight into how a developer is working, enables more effective management, and fosters better understanding between engineers.

Use Cases

Onboarding

A new team member joins. Instead of reading documentation that may be outdated, they see the story of the codebase. They understand why things are built the way they are. They see the decisions, the trade-offs, the reasoning. They onboard through narrative.

Cross-functional Collaboration

A designer wants to understand how a feature works. They do not need to read code. They see the intent, the conversation that shaped it, the progression from idea to implementation. They can participate in the codebase without needing to parse syntax.

Decision Archaeology

Six months later, someone asks: why was this built this way? The answer is not buried in Slack or lost in someone's memory. It is attached to the change itself. The context is preserved.

Engineer to Engineer

A developer has been tasked to work on a new feature, owned by another team. They soon realize their own prompting is not up to par: they're having to wrestle far too much with the model in order to get decent results. The new developer digs through the branch, looking at the specific language and abstractions his teammates have used, and is able to quickly adapt.

High-Level Monitoring

An executive wants to get a grasp on the status of technical work—they can dig into the codebase at a high-level, without requiring any technical knowledge. Soon, they spot a feature that seems to have been halted. They can quickly identify the owner, and the intent so far, in order to explore further.

Context Beyond Code

A codebase does not exist in isolation. Decisions happen in meetings. Requirements live in Google Docs. Discussions happen in Slack. Feedback comes through email.

All of this context is already being captured. Meeting transcripts are generated automatically. Chat histories are searchable. Documents are versioned.

The question is whether we bundle this context as part of changes, or whether we continue to treat code as separate from the conversations that produce it.

We think the context should travel with the code.

In an enterprise environment, this is increasingly possible. Organization accounts connect to Google Workspace, to Slack, to project management tools. The infrastructure for unified context exists. What is missing is the interface that brings it together at the moment of production.

The Timeline Future

As language models improve, each percentage point of capability compounds. The trajectory suggests that in the near future, models will handle complexity we currently cannot imagine delegating. Under that premise, the question changes. You are not going to review every diff line by line. You might send an agent to do it.

But then where is the surface area for actually thinking about what you are building?

If you can see the narrative history of a codebase, you can also model its future. You could plot a change and see what it might mean across thirty pull requests in that direction. You could explore different paths before committing to one.

Software development becomes less like construction and more like writing. You draft. You revise. You see how a change flows through the whole. You make decisions with awareness of their downstream effects.

This is narrative foresight. The codebase as a living document that you can read forward as well as backward.

Finally…

This is a speculative project. We have a working prototype that we are developing in the open.

The interface treats prompt and response as first-class citizens in version control. It surfaces the narrative thread that connects changes. It provides progressive disclosure from intent to implementation. We are exploring how context from outside the codebase can be integrated, how timelines can be projected forward, and how collaboration can happen across levels of technical fluency.

Code used to be for engineers. Now it is for everyone who can prompt. The artifacts need to reflect that.

If this resonates, we would like to hear from you.

Follow Us

PS: How It Works

Local Ops

The application runs as a local service, monitoring the repository and session logs from terminal-based LLM tools like Claude Code and Codex. When a commit occurs, a post-commit hook captures the logs, normalizes them, and analyzes them with a smaller LLM to extract summaries and intent. Session-to-commit linking uses git trailers, git notes, or metadata files—with heuristic matching on timestamps and file overlap as a fallback. Everything is stored in a hidden .narrative/ folder: an SQLite database for indexed data, and a committable subfolder for shareable metadata that teams can sync through normal git workflows.

Github Integration

For organization-wide deployment, the tool integrates with GitHub via webhooks and the GitHub API—push events and PR merges trigger the same indexing and summarization pipeline, syncing to a shared backend with role-based access. It's compatible with local LLM models and can be configured to be as privacy-aware as a team requires. The core principle remains: it sits as a layer above the repo, never touching the files themselves. Its goal is introspection, not action.