Exploring chat forking

I have found this extremely useful in a few cases, and I wanted to share those here. My request for you dear reader is that if you find these useful or most importantly you have other ideas on what we could do with this feature: please share.

The place where I started (so maybe the most obvious place? I guess at least it was the most obvious to me) was times when I wanted to ask the agent about something tangentially related to the work we are doing, but didn’t really want to burn context window on my random side idea.

This is especially useful when you know the agent has already deeply researched some element of your codebase or some framework, and you are interested in how you might be able to use the new software in the future.

I’ve used this probably 20 times in the last week. Most of the examples are a bit too specific to my world but I’ll try to pull something specifically from Ness development:

The existence of the separate command line tool lochy came literally from a forked chat. I was talking to the agent about building a feature that basically “Sends Worktree to a remote machine” which will copy all of your work & Claude Code chats related to the work to a remote computer. As part of that discussion I realized we don’t really have a standardized way of manipulating JSONL chat logs (the data layer behind most of the code harnesses today). The prototype lochy was started in the fork of the chat I made when I realized the work we had to build to transfer chats to a remote machine should be baked into its own CLI utility, rather than being baked into the node monstrosity that is Ness’ server runtime.

The other hugely useful situation I figured out for forking was “Forking chats to start new worktrees”. This is best explained by talking through how things worked before, and how forking is so much better.

Ness is built around the idea that every change to your codebase should happen in its own worktree.

A very common use-pattern in Ness is to have agent chats in your main (the artist previously known as master) branch where you discuss issues you are seeing, the agent will research the issue for you, and then spin up a worktree on your behalf. (This is one of the awesome things that the Ness MCP server gives you, the agent itself can spin up a new worktree right in Ness). This is very useful because the agent can turn something like “hey for some reason this page won’t load when I am logged in as mike” into a fully researched ticket, and spin up a worktree immediately.

This, however, breaks down when the conversation to figure out a bug or to scope out a new feature grows far longer than a message or two. In the same pattern I will find myself speccing out entire PRDs or running a bunch of devops queries against Datadog or the database, collecting a ton of context that is useful to a bug. When it finally comes time to spin up the worktree (or worktrees) the agent does its best to write a prompt, but will often fail to collect all of the information necessary.

That’s where forking comes in. In the 2.14 launch of Ness we added the ability for the create_worktree command to bring with it a conversation fork. Now instead of starting a worktree from a single prompt, you can just copy the entire past conversation into the new worktree. Agents will have the full context of what they are working on, instead of trying to play a game of telephone to figure out what exactly they are supposed to be doing.

If you talked to me anytime in the last year (and you were a software engineer, and you specifically cared about devex, and I was a little tipsy) I would have talked your ear off about how exciting it is to explore what software engineering is becoming.

We are all trying to figure out how to still build good software in an era where you don’t even really have to read the code much anymore. Ness is one of many projects that is on the forefront of figuring out what it even means to be a software engineer anymore. If you are interested in helping me find out: download the app, come by the GitHub repo, or join the Slack, or shoot me an email at mdl0394@gmail.com. I’d love to chat.