DocsGuidesComparePricingQuestions Русский
← All guides

Run several AI coding agents on one project without conflicts

Two agents in one folder will sooner or later edit the same file and break each other's work. The fix is simple: each one gets its own copy of the project, and only reviewed work reaches the shared code.

Why agents get in each other’s way

An agent reads a file, thinks for a minute and writes an edit. If a second agent changed that file during the minute, one edit is lost or lands on top of the other. Worse, an agent runs the tests, they fail on its neighbour’s half-written code, and it starts “fixing” what it never broke.

That gives two rules for parallel work:

  • every agent has its own working folder;
  • the parts of a task do not edit the same files.

For a developer the first rule usually means git worktree: a second working copy of the same repository on its own branch. It is reliable, but you have to remember the commands and merge the branches by hand later.

Give every session its own project copy

In Hedoq a copy is one checkbox, without the words “branch” or “commit”:

  1. “New session” (⌘N), choose the agent and the project.
  2. Turn on “Separate copy of the project”.
  3. The session starts in its own copy. In the sidebar it has a branch icon to the right of its name.

The option appears when the project is under git and has at least one commit. The copy lives outside the project folder; .env files from the project root are carried over. Two sessions without a copy in one folder see the same changes: that is not a bug, it is one folder for two.

Review the result before you take it

An agent working in a copy does not touch your project until you decide. To see what it did:

  • right-click the session in the sidebar and choose “Changes”;
  • or press the Git button in the window header, which shows the number of changed files.

Files on the left, the diff on the right. Then one of two:

  • “Apply to project”: the copy’s changes are merged into the project;
  • “Discard all”: the copy is thrown away, the project stays as it was.

If the changes do not apply cleanly, Hedoq leaves the project untouched and shows an error. Then the easy way is to ask the agent to pull in the fresh project and resolve the conflict inside its copy.

Split a big task into independent parts

Separate copies solve file conflicts, not decision conflicts: two agents may name the same API field differently. So you need a shared contract before the start.

Hedoq has the ⚡ command “Split the task into parts” for this. The session where you call it becomes the lead and does not write the task code itself:

  1. It splits the task into two to four parts so that no two parts edit the same files. If that is not possible, it tells you and does the task alone.
  2. It pins down what is shared: API contracts, names, folder structure. It writes this to a file in the repository.
  3. It starts a new session for each part in its own project copy and gives the task: what to do, which files may be touched, where the contract is, when the work counts as done.
  4. It does not wait in a loop. Each part replies once: what was done, which files, what was checked.
  5. It checks the result and tells you what is ready and where things diverge.

You apply the parts yourself, in the “Changes” window. If a worker is stuck, or replied but nobody took its work for a while, Hedoq wakes the lead once, once more five minutes later, and then stays quiet: reminders cost tokens too.

Sometimes parallel sessions just need to talk. The frontend session wants to know what the backend session decided. In Hedoq that goes through ⚡:

  • “See what another session is doing”: it sends a short summary;
  • “Give a task to another session”: it does the task and replies here;
  • “Show another session screen”: this session reads the other screen and tells you what is there;
  • “Break the link with a session”: the sessions stop messaging each other.

The answer comes once, not as a stream of status reports, so the limit is not wasted.

Helpers inside one session

Claude Code can start helpers (subagents) on its own for code search or checks. That is parallel work too, just inside one conversation. In the Hedoq feed such a batch is one line, “Helpers: N of M working”, each with a spinner, a check mark or a cross. When they finish, the line stays in the history with the result.

What to use when:

  • quick search and checks, no edits: helpers inside the session;
  • independent parts with edits: separate sessions in their own copies;
  • a disputed decision: a model council.