Too many conversations with coding agents

Every conversation with a coding agent holds a slightly different version of the project.

One chat knows why you rejected a database change. Another knows about the customer who needs the old behavior. A third has started implementing an idea you abandoned elsewhere.

If all three remain active, you have to keep their decisions aligned yourself.

I find that a useful way to think about the cost of parallel work. The number of agents working isn’t the only thing to count. You also need to count the conversations that can still change what you’re building.

A small example

Imagine adding an archive feature to a reading app.

You discuss the behavior in one chat. Archived articles should disappear from the ordinary list but remain searchable through a separate archive page.

Then you open another chat to implement the search changes. You describe the feature as “hide archived articles.” The second agent removes them from every search result, including the archive page.

Nothing mysterious happened. The second chat received a shorter requirement with a different meaning.

Now you have to notice the mismatch, explain the earlier decision, and check which code already depends on the new interpretation.

The figure starts with separate conversations holding conflicting archive rules. A shared written decision gives the implementation and review the same behavior to check.

One place for the current task

I would keep the active product decision in one conversation until it is settled. Then I would record the result in the project.

For the reading app, a few sentences are enough. Ordinary search excludes archived articles. Archive search includes them. Restoring an article returns it to the ordinary list.

The next session can read those sentences and inspect the current code. I don’t need to paste a long transcript or remember precisely which chat contained the correction.

This doesn’t require keeping everything in one enormous thread forever. Long conversations can accumulate discarded plans too. A fresh conversation with a clear task and a short current project record can be easier to follow.

The important part is knowing where the accepted decision lives.

Parallel work needs a return path

A separate chat can investigate how the existing search works without making product decisions. Another can review the archive implementation against the written behavior.

Those jobs have a useful place to return their findings. I can read them in the conversation where I’m finishing the feature.

I would be more cautious about starting several implementation chats that all have permission to reinterpret the same behavior. Separate files don’t guarantee separate decisions. The archive button and search page still share a definition of “archived.”

When a worker discovers a missing decision, it should bring that question back before building around an assumption.

Fewer unresolved choices

Sometimes adding another agent feels like a way to get unstuck. It can also postpone choosing what to finish.

If a feature is waiting for my review, I would review it before starting another implementation. If it is blocked on a decision, I would make that decision or pause the work explicitly.

The practical test is smaller. Can I explain what each active conversation is doing, and what I will do with its result?

If the answer is unclear, I would close or pause one of them after saving its useful findings. Then I would finish the task whose next step is already known.

Want me to talk about your product? You can sponsor this site.