DEBATE · PAIR · PLAN→EXECUTE · VERIFY: Dual-Model AI Coding

The premise

Many coding-assistant interactions use one active model response, but current tools also support custom agents, parallel subagents, architect/editor roles, and other multi-agent patterns. JaCode's unshipped proposal is a particular shared two-model role interface, not the first multi-agent coding idea.

JaCode explores whether one human and two models in structured roles can be a useful primitive for selected coding tasks. A second model adds cost and latency, and it can repeat rather than correct the first model's mistakes. The four modes below are hypotheses to test, not evidence that two models outperform one.

Status note (updated August 25, 2026): A local JaCode v1 binary builds and runs, but it has not been publicly released and its v1 code path contains no dual-model implementation. A separate archived DualModelOrchestrator was written but never instantiated: the archived CLI parsed a --dual option and then dropped it, and the dual-model UI components had no importers. No comparative benchmark was run. This post describes the unshipped dual-model design, not the feature set of the local v1 binary.

Why two models, specifically

Three failure modes of single-model coding assistants motivate the design:

Blind-spot compounding. A single model that makes a wrong assumption in step 3 will typically compound that assumption into step 7. The user catches it if they're paying close attention — but the purpose of the assistant was to reduce close-attention load.
Dependent self-review. A model reviewing its own prior output can repeat the same assumptions instead of supplying an independent check. Whether a second model improves that result must be measured rather than assumed.
Role ambiguity. Asking one model to plan, implement, and verify in the same pass can blur which obligation it is satisfying. Whether explicit role separation improves the result is an evaluation question.

Two models do not eliminate these issues. A separately prompted model can provide another perspective, but agreement is not proof of correctness: models can share the same blind spots or reinforce a bad premise. Any benefit needs to be measured against a controlled single-model baseline.

The four modes

DEBATE — Adversarial Review

One model proposes a solution. The second model argues the opposite position — not necessarily because the opposite is correct, but because explicit devil's-advocate framing surfaces assumptions the first model glossed over.

When to use it: Before making architectural decisions. Before committing code that will be hard to revert. When the stakes of being wrong are higher than the cost of an extra minute of discussion.

What it produces: Two distinct positions, each defended in the model's own terms. The user reads both and decides — or asks the models to converge on a reconciled position.

When it's overkill: Routine refactors, straightforward bug fixes, well-specified tasks. DEBATE is slower and more expensive than PAIR; the overhead only pays off when the decision being debated is load-bearing.

PAIR — Pair Programming

Two models would trade driver and navigator roles in a shared buffer, mirroring the classic human-human pair programming pattern. The driver would write code; the navigator would be prompted to inspect it, comment, suggest direction changes, and look for typos or logic errors. Roles would swap periodically or on user command.

When to use it: Implementation work where progress is the primary goal but quality can't regress. Feature implementation on a codebase where the model might miss local conventions.

Intended output: Progress on the task plus continuous cross-checking. The navigator is intended to surface errors before diff review; whether it does so more reliably than a single-model baseline remains unmeasured.

When it's overkill: Single-file trivial changes, code generation from a well-specified schema. PAIR is sized for real work, not one-liners.

PLAN → EXECUTE — Separation of Concerns

A planning model writes a specification (interfaces, data flow, test cases, error conditions). An execution model implements the spec. The planner's output is a structured artifact; the executor treats it as a contract.

The design goal is to exploit the different strengths of different models: some models plan well but implement noisily; some implement cleanly but plan shallowly. Separating the roles lets each model work within its strength.

When to use it: Multi-file refactors. New feature implementation where the API design matters. Any task where "what are we building" and "how is it written" are both non-trivial.

What it produces: A plan document (consumable by humans as the implementation blueprint) plus the implementation itself (which can be reviewed against the plan).

When it's overkill: Simple tasks where planning adds ceremony. The mode is designed for tasks where the planning step would have existed anyway as a comment or README note.

VERIFY — Independent Audit

One model writes code. A second model reviews it against the original intent — as if it were a code reviewer who saw the diff cold, without watching the writing process. Before the code ships to the user, the verifier produces a structured audit: what the code does, whether it matches the stated intent, what the likely failure modes are.

When to use it: Before commits. Before pull requests. Before any state-changing action (deploy, database migration, infrastructure change).

What it produces: A short, structured review. Not a score — a list of concrete observations the user can act on (or dismiss). Verification is the mode closest to "don't let the model YOLO it."

When it's overkill: Local scratch work. Exploratory code where verification's ceremony exceeds the work's risk.

What the proposed dual-model path would do

The archived design proposed:

Multi-model orchestration. Target support included Claude, GPT, Gemini, Ollama, or OpenAI-compatible endpoints. The local v1 binary does not implement this dual-model path.
Hybrid execution. A planned route between local inference and cloud APIs. No automatic-fallback behavior is claimed as implemented.
Developer workflow automation. Planned hooks, permissions, task management, and session persistence.
Agent system. Planned specialized roles for build validation, code review, and verification.
MCP extensibility. Planned Model Context Protocol support for custom tool integrations.

What would count as evidence

Before comparing JaCode with shipping coding assistants, DDG would need a reproducible evaluation: the same repositories and tasks, fixed model versions, matched token budgets, blinded human review, and measurements for correctness, time, cost, and intervention rate. No such comparison is published today.

Where to follow development

JaCode does not have a public release. A local v1 binary exists, but the dual-model modes described here have not shipped in that binary or elsewhere. If you're interested in the design, follow the JaCode product page and DDG's broader communications for any future release evidence.

For related experiments in forkable, content-addressed agent runs, see opentine. An opentine integration is a possible implementation path, not a completed JaCode subsystem.