Developer-Guided Planning (DevPlan)

• Developer-Guided Planning (DevPlan) is a paradigm where developers specify high-level abstractions, constraints, and validation criteria while automated planners synthesize the detailed execution strategy.
• It spans diverse applications such as dialogue systems, code repair, feature engineering, and UI prototyping by balancing human input with machine-driven orchestration.
• The approach emphasizes iterative execution, repair loops, and controlled planning to improve efficiency, scalability, and reliability across complex, multi-agent systems.

Searching arXiv for the papers on arXiv to ground the article and citations. Developer-Guided Planning (DevPlan) denotes a recurrent systems pattern in which developers or domain experts specify the task abstractions, workflow constraints, intermediate plans, validation criteria, or execution topology, while an automated planner, search procedure, or guided generative mechanism synthesizes the contingent orchestration needed to complete the task. Across the literature, the label itself is usually absent, but the pattern appears in enterprise dialogue synthesis, repository-level code editing, planner-guided multi-agent software production, diffusion-based long-horizon planning, tool-graph generation, and iterative UI prototyping. In this pattern, the central design question is not whether planning exists, but where control resides: what is fixed by humans, what is inferred automatically, and how execution is validated, repaired, or exposed for inspection (Muise et al., 2019, Bairi et al., 2023, Thakur et al., 15 Jan 2026, Li et al., 4 Jun 2026).

1. Conceptual scope and representative formulations

A useful way to understand DevPlan is as a mixed-initiative planning regime. The developer does not script every branch, token, or artifact, but also does not surrender behavior to an unconstrained end-to-end learner. Instead, the developer supplies a planning prior: a declarative process model, a task list, a constrained workflow graph, a seed edit set, a verifier, a tool subset prior, or an explicit intermediate plan. Automated planning then expands that prior into an executable controller, a chain of repository edits, a tool graph, a guided decoding trajectory, or a long-horizon trajectory sample.

This framing spans several distinct technical families. In dialogue systems, the developer defines variables, action preconditions, outcomes, and updates, and a FOND planner synthesizes the contingent dialogue controller (Muise et al., 2019). In repository-level coding, seed edit specifications and a dependency-aware plan graph drive multi-step repository repair (Bairi et al., 2023). In production ML feature engineering, the planner routes execution over a developer-specified constrained-topology actor graph and can request human intervention at critical steps (Thakur et al., 15 Jan 2026). In diffusion-based planning, guidance enters through developer-chosen modular decomposition, overlap structure, search budget, and feasibility filtering rather than through monolithic long-horizon training (Mishra et al., 31 Dec 2025). In tool planning, a diffusion proposer explores tool subsets and an autoregressive refiner predicts dependencies, which creates separate intervention points for subset control and graph construction (Li et al., 4 Jun 2026).

Domain	Representative system	Developer-guided element
Goal-oriented dialogue	D3WA + Hovor (Muise et al., 2019)	Variables, actions, outcomes, business rules
Repository coding	CodePlan (Bairi et al., 2023)	Seed edits, oracle, dependency-aware obligations
Feature engineering	Constrained-topology planner (Thakur et al., 15 Jan 2026)	Workflow graph, actor contracts, HITL escalation
UI prototyping	DIDUP (Ma et al., 2024)	Editable task plan, rollback, code injection
Tool-graph planning	DiG-Plan (Li et al., 4 Jun 2026)	Candidate tool-set search and graph selection
Long-horizon diffusion planning	CDGS (Mishra et al., 31 Dec 2025)	Segment decomposition, pruning, endpoint constraints

This suggests that DevPlan is best treated not as a single algorithmic class, but as a family of architectures organized around explicit human control over planning abstractions.

2. What developers specify and what planners synthesize

The defining property of DevPlan is the asymmetry between local human specification and global machine synthesis. The most explicit instance is the dialogue architecture of "Planning for Goal-Oriented Dialogue Systems" (Muise et al., 2019). There, the dialogue designer, working with subject matter experts and developers, specifies variables and actions through D3WA, using the action schema of “Needs,” “Outcomes,” and “Updates.” The interface supports dialogue actions, web actions (“cloudfunctions”), and system actions, while the planner synthesizes the full contingent dialogue graph. The developer fixes the state variables, action repertoire, preconditions, outcomes, variable updates, external API actions, goal-achieving outcomes, forced followups, designated first actions, utterances, endpoint formats, and system-action conditions; the planner composes these into a global policy that reaches the auxiliary fluent Goal under all modeled outcomes.

The same division appears in code-generation settings, but with different plan objects. "Self-planning Code Generation with LLMs" separates a planning phase from an implementation phase, with the plan represented as a numbered natural-language list of concise, imperative steps (Jiang et al., 2023). The model normally generates that plan itself, so the paper is not a developer-guided system in the strict sense; however, its formal factorization, $$\mathcal{P}(z \mid x, C) \approx \mathcal{P}(z \mid y, x)\,\mathcal{P}(y \mid x, C)$$, makes clear that the implementation stage could accept an externally supplied plan. The paper’s “Ground-truth Planning” condition functions as a proxy for that substitution and shows the importance of plan quality.

In "Towards Reliable ML Feature Engineering via Planning in Constrained-Topology of LLM Agents," the developer-specified object is neither a symbolic action theory nor a free-form plan, but an environment graph $G=(V,\hat{E})$ whose nodes correspond to workflow steps associated with actors and whose edges encode permissible transitions (Thakur et al., 15 Jan 2026). The planner can select only graph-successors of the previously completed actor, and it builds actor-specific planner_input strings from short-term memory, encountered errors, and prior outputs. Human intervention is available as a callable tool for ambiguity, repeated failure, or domain-specific clarification.

DIDUP adopts a more interactive version of the same principle. Its planning artifact is an editable task list in which each task is the “next-smallest testable iteration” of the previous task, and the user can regenerate, modify, approve, add, update, or remove tasks continuously during project development (Ma et al., 2024). This is mixed-initiative planning with strong developer guidance rather than autonomous decomposition.

A frequent misconception is that developer-guided planning means developers must script the entire solution. The literature points in the opposite direction. In the strongest examples, the developer constrains the plan space or supplies the intermediate representation, while the planner fills in contingent structure, propagates edits, chooses actors within a constrained topology, or explores candidate subsets under guided search (Muise et al., 2019, Bairi et al., 2023, Thakur et al., 15 Jan 2026).

3. Planning substrates, representations, and inference regimes

DevPlan is substrate-agnostic. The planning object may be symbolic, graph-based, token-level, diffusion-based, or grounded in predicted observations, provided that human guidance shapes the search space or execution structure.

The dialogue formulation of (Muise et al., 2019) is classical in representation but dialogue-specific in encoding. It uses Fully Observable Non-Deterministic planning with a richer action semantics than standard flat FOND. A problem consists of fluents $F$, an initial state $I \subseteq F$, actions $A$, and a goal $G \subseteq F$, but action effects are built recursively from conjunction and mutually exclusive disjunction. Realizations of an action are obtained by traversing an and-or effect tree, and the synthesized contingent plan is a controller graph $P=(N,E)$ whose nodes are actions and whose edges are labeled by realizations. Dialogue-specific abstractions include knowledge-level state fluents such as (have_user_location), contextual entity extraction compiled into nested oneof branches, forced followups via enablement fluents, and a 3-valued logic extension for “maybe known.”

Repository-level coding in CodePlan uses a different formal substrate. The repository is modeled through a dependency graph $D=(N,E)$ over code blocks and a plan graph $P=(O,C)$ whose obligations are triples $(B,I,status)$, where $G=(V,\hat{E})$0 is a block, $G=(V,\hat{E})$1 is an instruction, and status is pending or completed (Bairi et al., 2023). Change may-impact analysis applies relation queries of the form $G=(V,\hat{E})$2 to infer derived obligations after each edit. Planning here is adaptive obligation propagation rather than classical search over action schemas.

Planning-Guided Transformer Decoding formulates code generation as an MDP in which the state is the problem description concatenated with a partial program, the action is a token, the transition is deterministic concatenation, and terminal reward is public-test pass rate (Zhang et al., 2023). The planner uses a P-UCB rule to guide lookahead over token prefixes, integrating Transformer priors with execution-grounded subtree values. This is developer-guided planning in a reward-shaping sense: externally specified tests or modified rewards for concise or highly-commented code influence token selection during decoding rather than only after candidate completion.

Diffusion-based variants extend the idea from prefix search to iterative denoising. CDGS factorizes a long-horizon trajectory $G=(V,\hat{E})$3 into overlapping local segments and approximates the global distribution by a Bethe-style composition of local factors (Mishra et al., 31 Dec 2025). Its guided-search transition,

$G=(V,\hat{E})$4

makes the planning signal explicit: candidate trajectories are ranked and pruned inside denoising by a feasibility-oriented objective. DiG-Plan applies a related separation to tool-graph planning, using

$G=(V,\hat{E})$5

so that unordered combinatorial tool-set exploration is handled by a diffusion proposer and graph dependency prediction by an AR refiner (Li et al., 4 Jun 2026).

See-PP represents a further shift in substrate. A fine-tuned GPT-2 maps a high-level instruction to an ordered list of language subgoals, and a language-conditioned video predictor rolls these subgoals forward in observation space rather than action space (Attarian et al., 2022). The system predicts future observations $G=(V,\hat{E})$6, so its “planning” is explicit in language decomposition but implicit in imagined future-state progression.

4. Execution, validation, and repair loops

A DevPlan system is typically defined as much by its repair machinery as by its planner. Execution is rarely a single pass from plan to artifact; it is a loop over state updates, validation signals, and revisions.

The dialogue executor Hovor makes this explicit. It maintains planner-level state $G=(V,\hat{E})$7, context $G=(V,\hat{E})$8, and current plan node $G=(V,\hat{E})$9, then repeatedly invokes the current action, determines which realization occurred, updates state and context, and moves to the successor node (Muise et al., 2019). A technically important distinction is drawn between action execution and outcome determination. The former performs the real-world effect; the latter selects the branch of the nested effect tree through determiners associated with oneof nodes. State update follows $F$0, while context stores the concrete values abstracted away from the planning state.

CodePlan uses a different repair loop. After each LLM-produced edit, it merges the new fragment, classifies the change, updates the dependency graph incrementally, infers affected blocks, extends the plan graph with derived obligations, and only after the current plan is exhausted invokes an oracle such as a build or type checker (Bairi et al., 2023). If the oracle reports errors, those errors become new seed changes for another round. This allows propagation of changes that do not immediately surface as diagnostics, which is one reason it outperforms purely oracle-guided repair.

The constrained-topology planner of (Thakur et al., 15 Jan 2026) integrates routing, prompt construction, and retroactive correction. The state includes actor statuses, prior inputs and outputs, encountered errors, and proposed or applied fixes, all stored in short-term memory. Downstream failures can cause the planner to revisit upstream actors, and actors themselves can emit ReAct-style failure analyses or TERMINATE signals. Human help is explicitly callable through an interface that asks one atomic question at a time.

DIDUP operationalizes repair through developer-visible mechanisms rather than formal propagation analysis. Adaptive planning keeps the task list editable, code injection limits perturbation by writing minimal snippets into appropriate lines rather than rewriting files, and lightweight state management saves code state after every task so the user can revert to a prior working state (Ma et al., 2024). This makes rollback a first-class repair primitive.

A plausible implication is that DevPlan systems require explicit execution-state models and failure surfaces. Without such structures, planning devolves into one-shot generation followed by opaque debugging; with them, failures can be localized as branch errors, upstream artifact defects, missing obligations, or plan-level mismatches.

5. Empirical evidence across application domains

The empirical record supports the practical value of developer-guided planning, but the evidence is heterogeneous because the domains, metrics, and planning substrates differ substantially.

In goal-oriented dialogue, the strongest evidence concerns controllable synthesis and scalability. In the Car Inspection domain, increasing inspected parts from 1 to 4 grows the specification only from 4 to 7 actions and 5 to 8 variables, while the generated graph grows from 7 nodes / 14 edges to 63 nodes / 272 edges; planning time rises only from 0.005s to 0.023s (Muise et al., 2019). In the Credit Card Recommendation domain, moving from 1 to 3 cards grows the specification from 15 to 17 actions and 24 to 28 variables, while the plan graph expands from 36 nodes / 127 edges to 482 nodes / 1857 edges and planning time from 0.037s to 0.963s. This directly illustrates the DevPlan premise that developer effort can grow slowly while synthesized contingency structure grows rapidly.

In code generation, explicit planning consistently improves execution-based metrics. Self-planning code generation reports relative Pass@1 improvement of up to 25.4% over direct code generation and up to 11.9% over Chain-of-Thought, with HumanEval Pass@1 moving from 48.1 for direct generation to 60.3 for self-planning and 74.4 for Ground-truth Planning (Jiang et al., 2023). Planning-Guided Transformer Decoding improves APPS and CodeContests pass rates over beam search, sampling + filtering, and SMCG-TD, and reduces compilation errors from 5.58% to 1.93% and runtime errors from 32.95% to 19.5% on APPS introductory problems (Zhang et al., 2023).

Repository-level planning shows an even sharper contrast because localization and propagation are central. CodePlan is able to get 5/6 repositories to pass validity checks, whereas baselines without planning but with the same type of contextual information cannot get any of the repositories to pass them (Bairi et al., 2023). Its advantage is especially clear on temporal edits that require consistency updates even when static analysis produces no immediate error.

Planner-guided repository-scale feature engineering reports a pass@3 of 0.833 for Planner-Guided Actor Execution, compared with 0.600 for Sequential Actor Selection and 0.333 for Graph-Constrained Random Actor Selection, corresponding to about 38% and 150% relative improvements (Thakur et al., 15 Jan 2026). The same system is reported to reduce feature engineering cycles from three weeks to a single day when building features for recommendation models serving over 120 million users.

In long-horizon generative planning, the central gains arise from guided inference rather than developer-authored symbolic models. CDGS matches oracle performance on seven robot manipulation tasks and reports, for example, success rates of 84 on PointMaze Giant and 84 on AntMaze Giant, while also supporting coherent panorama and long-video generation (Mishra et al., 31 Dec 2025). DiG-Plan shows in a controlled study that masked denoising raises Pass@10 solution coverage from 0.320 to 0.943 over AR sampling under matched compute, and on TaskBench improves over AR baselines by a 10% relative margin (Li et al., 4 Jun 2026).

See-PP provides narrower but conceptually relevant evidence for language-guided plan grounding. Its planner achieves an action-level success rate of 93.72% and a task-level success rate of 86.99% on 442 unique four-letter words, while the full system attains the best PVQA score, 72.91, among the reported baselines (Attarian et al., 2022). DIDUP, by contrast, offers qualitative rather than benchmark-style evidence: in a small user comparison against GPT Pilot, both users were reported to create working UI prototypes easily and to add new features and backtrack to make major adjustments (Ma et al., 2024).

6. Limitations, misconceptions, and open directions

The literature also makes clear that DevPlan is not a solved design pattern. Its main burden is often shifted rather than removed: from writing every branch by hand to choosing the right abstractions, constraints, and validation surfaces.

One recurring misconception is that any explicit intermediate plan qualifies as developer-guided planning. The code-generation literature shows otherwise. Self-planning produces plans at inference time from few-shot exemplars, so its planning signal is model-generated rather than developer-supplied for the current task (Jiang et al., 2023). It is therefore closer to self-planning with prompt-authored exemplars than to a true developer-guided system, even though its implementation phase is directly reusable in one.

Another misconception is that more explicit planning automatically guarantees reliability. The dialogue work notes that FOND fairness assumptions can be unrealistic and must be guarded by the developer; repeatedly asking the same question does not make success fair in the dialogue sense (Muise et al., 2019). CodePlan depends on static dependency analysis and misses richer dynamic dependencies such as dataflow, dynamic dispatch, multithreading, or external configuration effects (Bairi et al., 2023). DiG-Plan improves tool-set coverage, yet still reports missing edges in 82.9% of cases and missing tools in 76.9% of value-selected outputs, with no explicit support for hard developer constraints or typed argument grounding (Li et al., 4 Jun 2026).

Human collaboration is also less thoroughly evaluated than many system designs imply. The constrained-topology feature-engineering planner includes a human-help tool, but benchmarking answered requests with a default unavailable response, so the benefit of actual human guidance is architecturally clear but empirically limited (Thakur et al., 15 Jan 2026). DIDUP’s claims rest on a small user study with two users (Ma et al., 2024). See-PP demonstrates language-guided decomposition and grounding, but it does not perform plan search, plan ranking, grounded replanning, or low-level control, and its OCR-based semantic completion numbers remain low in absolute terms (Attarian et al., 2022).

The computational tradeoffs are similarly nontrivial. CDGS is roughly 10–12x wall-clock over GSC in OGBench and scales with population size, resampling count, and DDIM inversion used for pruning (Mishra et al., 31 Dec 2025). PG-TD is more expensive than plain beam search because it repeatedly invokes completion and execution inside tree search (Zhang et al., 2023). DevPlan therefore introduces a recurrent systems tradeoff: better controllability and verifiability typically require more explicit state, more validators, and more search-time computation.

Open directions are already visible inside the papers. The dialogue work mentions “constraint driven dialogue” as a future feature (Muise et al., 2019). Self-planning points to hierarchical lists as a better representation for multi-level decompositions (Jiang et al., 2023). DIDUP identifies full plan regeneration and tree-structured lightweight version control as future extensions (Ma et al., 2024). The feature-engineering framework points to planner fine-tuning and long-term memory (Thakur et al., 15 Jan 2026). Across these systems, a common unresolved problem is how to combine explicit developer constraints, rich execution feedback, and scalable search without reverting either to brittle hand-authored workflows or to opaque end-to-end generation.

Taken together, these works indicate that DevPlan is best understood as an architectural stance: developers specify the planning vocabulary, workflow topology, intermediate objectives, or verification interface; planning machinery synthesizes global structure; execution remains inspectable and repairable. The technical challenge is not merely to plan, but to expose the right control surfaces so that planning remains both automatable and governable.