Debugging with branches: try three fixes without losing the thread

The bug only shows up under load, the stack trace points at the wrong layer, and you're 40 messages into teaching an AI why the obvious fix won't work here. It finally gets it. It restates the problem better than the ticket did. Then it offers three plausible ways out: rework the locking, batch the writes, or move the whole job off the request path.

In a linear chat, this is the moment things go wrong. You pick one, it fails, and the failure becomes part of the conversation. The model keeps glancing back at it. Ask about the second approach and you get an answer contaminated by the first, or worse, a cheerful attempt to rescue it. You can try steering around the wreckage, prefacing every message with "ignore the batching idea from before," which works about as well as it sounds. Or you open a fresh tab and paste in whatever context you remember, which is never all of it. The context that made the model useful is the exact thing a new tab throws away.

Branch at the last good message

Here's the same afternoon in GPTree. Scroll back to the message where the model restated the bug correctly. That's your anchor: everything above it is context worth keeping, everything after is exploration. Hover that response, click the Branch icon, and a new branch opens in a pane beside the one you're in, carrying the whole thread up to that point. Do it twice more from the same message. Three branches, one per candidate fix, all starting from the same clean understanding of the problem.

Each conversation now gets to be about one idea.

In the locking branch, the model never hears about batching. In the batching branch, nobody is defending a mutex. The tree sidebar on the left shows all three hanging off the main thread, and you click between them as results come back from your terminal. When a fix needs restating for a colleague, you ask in its branch, and the explanation stays with the approach it belongs to.

One honest note about pace: GPTree keeps one assistant reply in flight per conversation, so the branches take turns rather than racing. In practice you're pasting test output into one branch while reading another anyway, so it rarely slows you down. But if you were picturing three fixes streaming simultaneously, that's not what happens.

Dead ends stay where you can see them

The batching branch dies first. The model's fix was elegant and wrong, and your test run says so. In a normal chat you'd feel the pull to keep arguing with it, because abandoning the thread means losing everything around it. Here you just stop. The branch stays in the tree, holding the full story of why batching didn't work, which is exactly what your teammate will ask about in code review.

The locking branch wins. Not because GPTree said so. It can't run your suite and it won't rank your fixes; the branch won because you ran the tests against all three and one came back green. What GPTree did was keep three lines of reasoning from bleeding into each other while you did the judging.

Bringing it home is the Merge button in the winning pane's header. Pick the main thread as the target, use the AI-Assisted strategy so the fix gets reconciled into the parent instead of pasted onto the end, check the preview diff (removals in red, additions in green), and confirm. The main thread ends with a working fix and none of the noise. (Branching and merging are on every plan; the Free plan includes 3 merges a month, and Pro and Team lift that to unlimited. The side-by-side compare is a Pro and Team feature.)

Sooner or later somebody asks why you didn't just batch the writes. You don't reconstruct the argument from memory. You open the tree and point at the branch where batching lost.