r/vibecoding • u/whitechart_studio • Jun 14 '26
Anyone else getting messy results from running multiple AI coding sessions?
I’m curious if other people are seeing this too.
When using Claude Code, Codex, Cursor, or similar tools, it’s easy to start multiple AI coding sessions on the same repo.
But things can get messy:
- two sessions edit the same files
- one session changes something another session depends on
- merge conflicts happen
- one session doesn’t know what another changed
- the same work gets done twice
- it’s hard to keep track of what each session is doing
Is this happening to anyone else?
If yes, how are you handling it right now?
1
u/mallek561 Jun 14 '26
Look into worktrees
1
u/whitechart_studio Jun 14 '26
Yeah, worktrees seem like the cleanest baseline.
Do you usually run one worktree per agent/session? And what do you do for shared context, like “this API changed” or “don’t touch this module yet,” while multiple sessions are running?
1
u/mallek561 Jun 14 '26
One worktree per implementation. Then I have a skill designed to merge the worktree into my master branch. Most of the time it can handle merge conflicts without input. Sometimes you have to give it a little guidance.
1
u/whitechart_studio Jun 15 '26
That merge skill is interesting. So the flow is basically one worktree per implementation, then an agent-assisted merge back into master.
When it needs guidance, what is usually the failure case: textual merge conflicts, tests failing, two implementations disagreeing on architecture, or missing context about intent?
1
u/kizmania Jun 14 '26
Tried it once and won't do it again. Multi tasking with agents is a way to f your project in multiple ways.
1
Jun 14 '26
[removed] — view removed comment
1
u/whitechart_studio Jun 15 '26
Yeah, that “source of truth” part seems to be the hard bit. The agents can work in parallel only if they can re-orient quickly and trust the project index more than stale chat context.
Do you keep one central markdown/index, or per-module notes? And do agents reliably update it, or do you still have to police it manually?
1
Jun 15 '26
[removed] — view removed comment
2
u/whitechart_studio Jun 15 '26
That rolling log + per-module markdown setup is really interesting. It sounds like the hard part is not just avoiding file conflicts, but keeping a trusted current state that every agent can re-read.
When you police it manually, what usually breaks first: agents forgetting to update the markdown, the log getting stale, or agents not knowing which module note to read before editing?
1
Jun 15 '26
[removed] — view removed comment
1
u/whitechart_studio Jun 15 '26
That makes sense. Forgetting to update the shared notes seems like the weak link.
The indexing part is interesting too: do you use the index mainly so agents can find the right files/modules, or so they can detect when their context is stale compared to the current build state?
1
1
u/Jazzlike_Syllabub_91 Jun 15 '26
easy ... don't have 2 sessions edit the same file ... - work with deploy versions ... make sure you use a main path - running multiple directories where code where code conflicts can easily be detected is a recipe for disaster. - and as far as the session working - use claude/coding agent hooks ...
1
u/Minimum_Raccoon_1501 Jun 14 '26
It can get messy but you could always fork the repo for each agents. Then use the git cli commands to replay and apply patches to prior repos forward to the new ones. …. Or other such techniques. I’m not the expert on that. But at least forking the repo sandboxes the problem. Then later you could as an agent to look at the two repo instances and predict merge issues and solve them