One AI can plan the program while another writes the code

An AI model that struggles to write a correct program may still provide a useful plan for another model. That distinction is central to a November 3, 2026 arXiv preprint by Wentao Wang and colleagues, titled Planning-Coding Separation in LLM-Based Code Generation: An Empirical Study.

The researchers investigate whether planning and coding must stay within one language model. Their results support considerable separation under the conditions tested: models often use plans from other models effectively, and some smaller coders perform competitively when given guidance from a strong planner. These are benchmark findings from a preprint, not a demonstration that interchangeable AI teams will work equally well across software development.

A controlled handoff

The workflow has two stages. A planner receives a programming problem and produces ordered solution steps. These can specify constraints, data structures, edge cases and key operations, but are intended to exclude code, alternative solutions and exploratory reasoning. A coder then receives both the original problem and that plan.

The evaluation covers 175 Python problems from LiveCodeBench v6, requiring complete programs, and 217 strongly constrained Python function tasks from Code2Bench. The former uses predefined tests; the latter uses property-based testing against reference implementations.

For every planner and problem, the researchers generate three plans and keep all three without revision or performance-based selection. Each plan produces one coding attempt, and the reported plan-assisted score averages the three evaluation runs. This is not a best-of-three selection process. Coding uses greedy decoding, with no repair or regeneration, and optional thinking modes are disabled during both stages where available.

The main metric, Pass@1, measures the share of tasks whose generated solutions pass the benchmark evaluation.

Sharing plans often works—but planning is not always better

Within five model groups, the researchers compare every planner–coder pairing. Across the two benchmarks, 27 of 44 cross-model comparisons match or exceed the corresponding same-model pairing for the same coder. The highest-scoring pairing uses different models in seven of ten group-and-benchmark settings.

Planner rankings are also fairly stable: in nine of those ten settings, one planner achieves the highest score for every coder in its group. This suggests that useful planning ability can carry across model boundaries rather than depend entirely on a particular partner.

However, outperforming a same-model planning setup does not necessarily mean outperforming direct coding without a plan. On LiveCodeBench, Qwen3-8B planning for Ministral-3-8B scores 28.95, better than Ministral planning for itself at 25.90, but slightly below Ministral’s direct score of 29.14. The study therefore supports choosing the two roles separately, not adding a planning stage indiscriminately.

A strong planner can support a smaller coder

Some of the clearest results involve the model identified in the paper as GPT-5.6-Sol. With it providing plans, Qwen3.5-27B and Qwen3.8-27B reach LiveCodeBench scores of 68.00 and 71.05, respectively. Using GPT-5.6-Sol for both stages scores 66.86.

That comparison is benchmark-dependent. On Code2Bench, the same two 27-billion-parameter coders score 38.10 and 38.40 with GPT-5.6-Sol plans, below the 41.17 achieved when GPT-5.6-Sol handles both roles.

The authors call this configuration Large-Planner-Small-Coder. Their argument concerns how model capacity can be distributed: retaining a strong planner may reduce the capacity needed for implementation. These accuracy comparisons alone do not establish a particular cost or latency saving.

Training gains can transfer across planners

The team also fine-tunes three small coders on one million standard code instruction examples, without planner-specific adaptation. It then evaluates the original and trained versions using identical plans.

In the five coder–benchmark settings where direct generation improves, 19 of the corresponding 20 plan-assisted settings also improve; one is unchanged. Training is not universally helpful, however. Gemma-3-4B loses direct-generation performance on LiveCodeBench and declines with three of four planners, while improving on Code2Bench.

The scope remains narrow: two Python benchmarks, one-way plan handoffs and training experiments on three small coders. Finite tests can miss errors, property-based testing can introduce randomness, and generation variability remains. Repository development, debugging and workflows that revise plans after execution may behave differently. Within those limits, the study makes a practical case for evaluating planning and implementation as distinct capabilities rather than assuming one model must excel at both.