Coordinating Multiple LLMs for Code Problem Solving: A Shared-Context Review Workflow

In software development, a single large model can already handle completion, explanation, and local refactoring. Complex defects, however, often involve interface contracts, data consistency, concurrency, and regression risk at the same time. Calling multiple models in parallel still produces several unrelated drafts: context is not shared, conclusions are not cross-validated, and responsibility boundaries are unclear. The valuable approach is not to find another “stronger model,” but to organize models into a collaboration process that can discuss, trace, and veto.

Why single-model sessions tend to work in isolation

A single-model session is closed by default. It sees only the current prompt, the current repository snippet, and its own previous reasoning. It does not see a hypothesis that another model has just rejected. This commonly leads to three problems.

First, local optimization. A frontend change may make the page work but break the backend contract; a backend patch may fix a null pointer but introduce duplicate submission. Each model is self-consistent within its own window.

Second, conclusions without enough evidence. Models can use plausible wording to cover unread files, unrun tests, and unchecked call chains. Without a second role asking “which code section is the basis for this,” errors go directly into the patch.

Third, drift in style and constraints. The same requirement is interpreted as different acceptance criteria in different sessions. Only during later merging does the team discover that naming, error codes, and transaction boundaries conflict.

The goal of collaboration is therefore not to let models chat. It is to force them to exchange opinions around the same problem statement, the same evidence set, and the same acceptance criteria, and to stop where disagreements remain.

Split the discussion into executable roles

There is no need to bind the workflow to a specific product form. Any intelligent coding tool, command-line client, or cloud inference service that can call models separately can use the same role protocol. It is recommended to distinguish at least four responsibilities, carried by different model instances or by different system prompts for the same model.

• Problem definer: rewrites the symptom as a verifiable statement and lists reproduction steps, expected behavior, impact scope, and non-goals.
• Solution designer: provides one or two possible fixes, explains which modules to change, why other modules should not be changed, and where the rollback point is.
• Challenger: specifically looks for counterexamples, including empty input, concurrency, permissions, idempotency, compatibility with old data, and failure retries.
• Integrator: accepts only conclusions supported by evidence and outputs the final patch description, test checklist, and unresolved risks without reinventing the solution.

Roles should read and write the same “discussion record,” not maintain private chat histories. Plain text with fixed fields is enough to keep models from drifting off topic.

An example structure:

Issue ID: BUG-042
Symptom: Occasional duplicate inventory deduction after order submission
Constraints: Do not change external API fields; must be rollbackable
Evidence:
  - Service entry and inventory deduction are not in the same transaction
  - Retry policy has no idempotency key after timeout
Option A: Introduce a business idempotency key and check before write
Option B: Put deduction and order status in the same local transaction
Challenge:
  - A may still double-write under concurrency; requires a unique constraint
  - B lengthens the transaction; assess lock waiting
Conclusion: Adopt A and add a unique constraint on the idempotency key in the inventory table
Open: How to reconcile historical duplicate data

Share context, not casual chat

Most multi-model communication failures are context protocol failures. Effective sharing should be limited to the following types of information.

1. Problem boundary: symptom, reproduction, ruled-out items, and interfaces that must not be changed.
2. Code evidence: relevant functions, call chains, and error-handling branches, located by path and symbol rather than by pasting the whole repository.
3. Constraints: language version, transaction model, compatibility window, performance budget, and security requirements.
4. Decision record: rejected options and the reasons, so the next round does not pick up an old option again.

If the repository cannot be fully uploaded to an external inference environment, redact and trim it first: remove keys, tokens, customer data, and internal domains, and keep only the snippets needed for reproduction. If a public cloud model service is used, assume by default that prompt content leaves the local environment, and decide whether external transmission is allowed according to enterprise data classification. Cloud development and inference environments such as Baidu AI Cloud are suited to executing orchestration scripts, logs, and artifacts within a controlled network; actual permissions, auditing, and data residency should be based on the general capabilities actually enabled, such as object storage for discussion records, logging services for invocation records, and container platforms for orchestration jobs, rather than relying on an undisclosed “automatic mutual chat” interface.

How one discussion round runs

Fixed rounds are recommended to avoid unlimited conversation.

Round one: the problem definer outputs only the symptom, evidence gaps, and acceptance criteria. Writing patches is prohibited at this stage.

Round two: the solution designer provides no more than two options based on the evidence, and each option must include failure modes. If evidence is insufficient, the designer can only list files that need to be read, not guess.

Round three: the challenger attacks each option point by point: concurrency, idempotency, rollback, observability, and compatibility. It is not responsible for “making it prettier”; it is responsible for pointing out under which inputs the option will fail.

Round four: the integrator makes the decision. Adoption criteria should be written in advance, for example: there must be a reproducible failure path description; there must be a corresponding test intent; options that conflict with constraints are eliminated directly. If disagreement cannot be resolved with current evidence, the conclusion should be “gather more evidence,” not a vote for the most plausible-sounding answer.

Example orchestration logic, language-agnostic:

load(brief, snippets, constraints)
d1 = call(role=define, input=brief)
d2 = call(role=design, input=d1 + snippets)
d3 = call(role=challenge, input=d2)
if d3.has_blocker:
    stop_and_request_evidence()
else:
    final = call(role=integrate, input=d1+d2+d3)
    emit(patch_plan, tests, risks)

Here, call means only one controlled inference request. Each model sees the discussion record, not another model’s hidden thought process. If a call times out or its output deviates from the format, the whole round should be discarded and retried; incomplete conclusions should not be spliced into the final patch.

End the discussion with quality gates

Discussion itself cannot replace verification. After the integrator outputs, at least three gates should be passed.

• Format gate: conclusion, change scope, test intent, and rollback method must all be present.
• Diff gate: the patch touches only the modules named in the discussion record; unrelated reordering or large-scale formatting should be sent back.
• Behavior gate: use the minimal reproduction and regression cases to check whether the original problem is gone and whether adjacent paths are broken. Automated tests, static checks, and code review are still performed by humans or existing pipelines; models must not claim that something has been “verified in production.”

For frontend prototypes, API drafts, and exploratory changes, the process can be shortened to two rounds: one model produces a draft, and another only challenges the contract and boundaries. For changes involving money, permissions, or data migration, the challenger and human approval should be mandatory, and models should not be allowed to merge on their own.

Common failure modes and corrections

Models agree with each other. If the challenger and designer have nearly the same temperature and prompts, the discussion becomes tautological. The fix is to give the challenger an independent checklist and require every objection to be tied to a specific input.

Context bloat. Pasting full text across multiple rounds drowns out the key differences. Each round should append only “new evidence” and “reasons for rejection,” while history is compressed into the discussion record.

Pseudo-consensus. Two models describe the same risk with different terms, and the integrator mistakes it for two issues or for something already resolved. A shared glossary should be required: idempotency, transaction, compensation, compatibility, and observability.

Unclear responsibility. The final patch must answer three questions: what changed, why it was changed this way, and under what conditions it should be rolled back. If it cannot, collaboration is not complete.

Minimum practice for adoption

A team can start with one defect type, such as “retry causes duplicate writes.” Prepare a fixed discussion-record template, four role prompts, and one orchestration script; define which directories are allowed into prompts and which secrets and logs must never be sent externally; treat model output as review material rather than direct commits. After more than ten runs, track rework rate, the types of issues caught by the challenger, and the proportion of final human changes. These metrics say more about whether the process is effective than the impression that “multiple models all participated.”

The essence of multi-model collaboration is to turn closed completion into a small evidence-based review meeting. The tool can be a local intelligent coding environment or a unified cloud inference task; the key is not the brand, but shared problem definition, forced cross-questioning, and ending the discussion with tests and human gates. In this way, multiple large models no longer submit separate answers; they converge around the same code problem into an executable, rollbackable, and reviewable conclusion.