Multi-Agent Parallel Refactoring in Practice: Why Merge Conflict Costs Outweigh Parallel Gains

Introduction

Multi-agent parallel processing has been seen as a promising approach in AI-assisted programming. However, a developer recently shared their real-world experience using four parallel agents for a code refactoring task — the cost of resolving merge conflicts far outweighed the speed gains from parallelism, and serial execution turned out to be faster. This case provides valuable empirical data for understanding the practical limits of multi-agent collaboration.

Experiment Design: A Task Partition That Looked Ideal for Parallelism

The Refactoring Task and Work Distribution

The refactoring involved 41 call sites, with the goal of migrating legacy code that passed plain dicts to a new architecture using typed state objects. On the surface, this looked like a textbook parallel task:

• Modification points were scattered across different directories
• Each modification followed a similar pattern
• It appeared highly decomposable

The developer used verdant's parallel agent capability to partition the task by directory, assigning it to four independent agents, each working on its own Git branch. The divide-and-conquer strategy was conceptually clean — split a large task into independent subtasks and process them in parallel.

Core Finding: How Merge Conflicts Consumed the Parallel Gains

Although the agents completed their coding tasks quickly, the subsequent branch merging revealed serious problems.

Shared Dependencies Triggered a Chain of Conflicts

Three of the four branches modified the same shared state module — type definitions had to be updated before compilation, and this dependency was overlooked during task assignment. When three agents simultaneously modified the same file, Git could not auto-merge, leaving the developer to resolve conflicts manually.

Inconsistent Naming Conventions

Two agents renamed the same field but used different naming conventions. Without centralized coordination, even relatively deterministic refactoring operations can produce semantic-level conflicts.

A Direct Comparison of Time Costs

Execution Mode	Agent Execution Time	Manual Merge Time	Total Time	Extra Overhead
Parallel (4 agents)	Faster	~2 hours	Over 2 hours	One branch fully discarded
Serial (1 agent)	—	No merge needed	Slightly under 2 hours	None

The parallel agents did execute faster, but manually merging the branches took about 2 hours, and one branch was discarded entirely due to excessive conflicts. The serial approach, where a single agent processed all 41 sites sequentially, ended up taking less total time — with no merging required at all.

Key Insight: The Difference Between Surface Independence and True Independence

The most valuable lesson from this case is the gap between surface independence and true independence:

• Surface independence: Modification points are physically scattered across different directories and files
• True independence: Modifications have no shared types, interfaces, or global state dependencies between them

In this refactoring, all modification points fundamentally depended on the evolution of the same type system. Although the 41 call sites were spread across the codebase, their type definitions were concentrated in a single module. This kind of coupling is difficult to fully identify before execution.

As the author put it: "If your partition isn't truly independent, you may not be able to tell that before you run it."

Practical Guidelines: When to Use Parallel Agents

Scenarios Suited for Parallelism

Based on this experiment, multi-agent parallel processing works well when:

1. Architectural isolation: Independent microservices or modules, each with their own complete type definitions
2. Zero shared state: Different branches won't modify the same config files, type definitions, or global constants
3. Verifiable partitioning: Independence can be confirmed via dependency analysis tools before execution

Scenarios Better Suited for Serial Execution

The following tasks are better handled by a single agent running sequentially:

• Tasks involving global type system refactoring
• Cross-module interface changes
• Modification points that share a common config or state definition
• Large-scale changes requiring consistent naming and style throughout

What This Reveals About verdant

This experiment also highlights an advantage of tools like verdant: low cost of experimentation. The execution cost of parallel agents is low enough that developers can try it first and evaluate afterward, rather than performing complex dependency analysis upfront. The author used "rework" as an evaluation metric, quantifying the efficiency of different strategies through actual time comparisons — this data-driven engineering decision-making approach is itself worth adopting.

Conclusion

This multi-agent parallel refactoring experiment delivers a clear verdict: parallel is not always faster. When tasks have hidden shared dependencies, the cost of merge conflicts and semantic coordination can completely negate the speed advantage of parallelism.

For developers, multi-agent parallelism should be treated as a conditional optimization strategy — not a default. Before committing to a parallel approach, examine the task's dependency graph. If modification points share type definitions, config files, or global state, serial execution is often more efficient and more reliable. This lesson carries strong practical value for development teams that are increasingly relying on AI-powered programming tools.