arXiv CSopen access

ARIADNE: Agentic Reward-Informed Adaptive Decision Exploration via Blackboard-Driven MCTS for Competitive Program Generation

2026 · arxiv_cs

arXiv CS · Papers · License: Open Access · 2026

software-architecture software-engineering testing

software engineering, software architecture, testing

ARIADNE: Agentic Reward-Informed Adaptive Decision Exploration via Blackboard-Driven MCTS for Competitive Program Generation Minnan Wei a,∗, Xiang Chen a,∗, Xiaoshuai Niu a , Siyu Chen a a School of Artificial Intelligence and Computer Science, Nantong University, Nantong, China

arXiv:2605.02431v1 [cs.SE] 4 May 2026

Abstract Competitive program generation aims to automatically produce correct and efficient solutions for programming-contest problems under strict time and memory constraints. Existing LLM-based approaches often fail to perform explicit algorithmic planning and to handle edge cases robustly, leading to unreliable one-shot generation. Moreover, although execution feedback is essential for iterative debugging and refinement, incorporating such feedback effectively within limited computational budgets remains difficult. To overcome these limitations, we propose ARIADNE, a blackboard-driven Monte Carlo Tree Search (MCTS) framework that models program generation as a sequential decision process. ARIADNE organizes the generation workflow into five coordinated stages (i.e., strategy selection, code generation, test generation, quality evaluation, and code repair) while maintaining a shared blackboard that accumulates structured evidence to guide subsequent decisions. Experiments on four benchmarks (APPS, CodeContests, CodeContests+, and LiveCodeBench) show that ARIADNE consistently achieves the best Pass@1 performance across multiple LLM backends. With GPT-4o, ARIADNE attains Pass@1 scores of 41.30, 46.67, 27.27, and 20.91, surpassing the strongest baseline CodeSim by up to 26.06 points, while further improvements are observed with DeepSeek-V3.2. These results indicate that combining global search through MCTS with persistent evidence accumulation on a shared blackboard enables systematic exploration and effective feedback utilization, substantially enhancing the capability of LLMs in competitive program generation. Keywords: Large Language Models; Competitive Programming; Monte Carlo Tree Search; Blackboard System; Program Generation 1. Introduction Competitive program generation targets the automatic synthesis of correct and efficient solutions to programming-contest problems under strict time/memory constraints and hidden test suites, making it a compelling benchmark for algorithmic reasoning and practical code reliability. Despite strong general coding ability, Large Language Models (LLMs) still struggle in this setting because success often hinges on constructing accurate problem-solving strategies, including multi-step logical reasoning, explicit algorithmic planning, and comprehensive edge-case handling, that go beyond basic functional code generation [1, 2, 3, 4, 5, 6, 7]. Prior work [8, 9, 10, 11, 12, 13, 14, 15] has explored several directions to improve LLMs on competitive program generation, including iterative agent-style refinement, search-based exploration, and shared-workspace designs that externalize intermediate artifacts for better context management. However, when used in isolation, these paradigms still leave critical gaps under contest constraints: agentic pipelines are often driven by pre-fixed workflows that limit adaptive decision-making; MCTSbased generation frequently lacks persistent and structured evidence reuse across branches; and blackboard systems typically ∗ Corresponding authors

Email addresses: [email protected] (Minnan Wei ), [email protected] (Xiang Chen ), [email protected] (Xiaoshuai Niu ), [email protected] (Siyu Chen )

do not incorporate an explicit global planner to allocate search budget effectively and recover from early suboptimal decisions. Existing paradigms leave the following practical gaps under contest constraints: (1) agentic pipelines often rely on prespecified workflows that are brittle when early assumptions are wrong; (2) search-based generation may explore broadly but fails to accumulate and reuse structured evidence across branches; and (3) blackboard-style coordination stores artifacts, yet typically lacks an explicit mechanism to prioritize actions and reallocate budget based on what has been learned so far. To address these gaps, we propose ARIADNE (Agentic RewardInformed Adaptive DecisioN Exploration), a blackboard-driven MCTS framework for competitive program generation. ARIADNE views solution construction as iterative decision making over actions (i.e., strategy selection, code generation, test generation, quality evaluation, and code repair) conditioned on a shared blackboard state. Specifically, Reward-Informed means that backpropagated rewards do not merely rank complete candidates, but actively steer exploration toward decision points that are most likely to yield correctness and efficiency under a limited budget. Meanwhile, Adaptive Decision means that structured diagnostics are written back to the blackboard and reused as persistent state, so subsequent expansions are conditioned on accumulated evidence rather than isolated rollouts. As a result, ARIADNE can (a) deviate from rigid agent workflows when new evidence contradicts earlier plans, (b) reuse failure evidence to avoid repeating unproductive branches, and

(c) dynamically concentrate search on the most informative fixes experimental setup, including research questions, datasets, baseand promising strategy alternatives. lines, metrics, and implementation details. Section 5 reports the We first evaluate ARIADNE on four representative competitive- experimental results and key findings on benchmark tasks and programming benchmarks (APPS [16], CodeContests [17], Code- full-contest evaluations. Section 6 further discusses generalizaContests+ [18], and LiveCodeBench [19]), which vary in probtion across different LLM backbones, efficiency statistics (e.g., lem domains, difficulty, and evaluation protocols. We compare token usage and execution cost), and threats to validity. Secagainst three state-of-the-art agentic baselines, including Maption 7 reviews related work and highlights the novelty of our Coder [8], CodeSim [9], and CodeTree [20], and report Pass@1 study. Section 8 concludes the paper and outlines future retogether with runtime statistics. Across all benchmarks, ARIsearch directions. ADNE consistently achieves the best Pass@1 in matched settings. For example, with GPT-4o, it reaches 41.3% in the APPS 2. Research Background and Research Motivation benchmark and reaches 46.67%, 27.27%, and 20.91% in CodeContests, CodeContests+, and LiveCodeBench benchmarks, re2.1. Competitive Program Generation spectively. Competitive program generation seeks to automatically proWe then assess real contest performance using complete duce correct and efficient solutions for algorithmic problems ICPC/CCPC-style multi-problem contest instances collected from drawn from programming contests. Unlike general-purpose code Codeforces, including the 2025 ICPC Asia Shenyang Regional generation, these tasks demand explicit algorithmic strategy seContest and the 2025 CCPC Fujian Invitational. Under the lection, multi-step reasoning, strict time and memory constraints, same contest protocol and submission budgets, ARIADNE imand thorough handling of edge cases. proves pass@k behavior and solved problem numbers over the To support rigorous evaluation, recent benchmarks emphabest baseline from the benchmark comparison; for instance, on size both algorithmic diversity and execution-level correctness. Shenyang Regional Contest, it attains pass@1/3/5 of 3/13, 6/13, ProBench [21] compiles real contest problems annotated with and 7/13 (vs. 1/13, 4/13, and 5/13), and on Fujian Regional algorithm tags and difficulty levels. TACO [22] provides largeContest, it reaches 4/13, 5/13, and 7/13 (vs. 2/13, 2/13, and scale datasets with fine-grained topic and skill annotations. Code5/13). Contests+ [18] enhances evaluation fidelity through high-quality Our results indicate that competitive program generation test-case generation, while COMPASS [23] introduces multibenefits from explicit global planning over heterogeneous dedimensional metrics encompassing correctness, efficiency, and cisions (strategy selection, code synthesis, testing, and repair) code quality. rather than fixed agent pipelines. By coupling a persistent blackboard state with reward-informed MCTS, ARIADNE can accu2.2. Monte Carlo Tree Search for Code Generation mulate and reuse diagnostic evidence to steer exploration toMCTS (Monte Carlo Tree Search) is a search algorithm for ward high-value solution trajectories. sequential decision-making under uncertainty, which balances The main contributions of our study can be summarized as exploration and exploitation through iterative selection, expanfollows: sion, simulation, and backpropagation. Its principled manage• We propose ARIADNE, a blackboard-driven MCTS frame- ment of this trade-off makes MCTS particularly well-suited for work that performs reward-informed, adaptive decision reasoning over large combinatorial decision spaces. exploration for competitive program generation, coordiRecent work has explored integrating MCTS with LLMs nating strategy selection, code generation, quality evaluto enhance reasoning and code generation. TreeMind [12] apation, and code repair within a unified search process. plies MCTS to explore UI interaction sequences for bug reproduction, while VeriGen+MCTS [13] leverages MCTS to guide • We design a structured blackboard system and action space RTL code generation under functional and PPA constraints. These that enable evidence accumulation and reuse, allowing studies illustrate that MCTS can serve as an effective global search to adapt its decisions based on execution feedback. planner for complex software engineering tasks. • We conduct extensive evaluations on diverse benchmarks 2.3. Blackboard System and realistic recent ICPC Regional Contests, demonstrating consistent improvements over strong baselines. Blackboard systems provide a coordination architecture for multi-agent and multi-knowledge-source systems, in which agents Open Science To enable the replication of our research, we interact indirectly through a shared, structured workspace rather share our dataset, source code, and detailed results on GitHub than via direct communication. Rather than functioning as sim(https://github.com/minnanWei/ARIADNE). ple shared memory, a blackboard incrementally accumulates inPaper organization. The remainder of this paper is organized termediate hypotheses, constraints, and partial results, making as follows: Section 2 introduces the background and motivation them available to all agents as a common foundation for subsefor reward-informed agentic search in competitive-program genquent reasoning and action. eration. Section 3 presents ARIADNE, detailing the blackboardThis paradigm has been widely adopted to facilitate coldriven framework, reward modeling, and the adaptive decision laboration among heterogeneous agents in complex decisionexploration procedure based on MCTS. Section 4 describes the making settings. Early work [24] employed a blackboard-based 2

open-tender mechanism for collaborative negotiation, where mul- exploration of alternative solution directions and reducing rotiple agents submit competing proposals and constraints to a bustness on challenging contest problems. shared workspace. In robotics and control systems, blackboard architectures have been used to integrate perception, planning, 3. Our Proposed Framework ARIADNE and execution agents around a shared world model, enabling coordinated behavior without tight coupling between modules. In this section, we present ARIADNE, a blackboard-driven More recently, blackboard systems have been revisited in the MCTS framework for competitive program generation. The context of LLM-based multi-agent systems. Han et al. [14] primary goal of ARIADNE is to systematically explore the sodemonstrate that externalizing intermediate reasoning artifacts lution space and progressively converge to an optimal program to a blackboard mitigates information fragmentation in multifor a given algorithmic problem, by coupling search-based planagent LLM collaboration and supports dynamic selection of ning with modular agent execution and a blackboard system subsequent actions. Similarly, Salemi et al. [15] show that blackboardthat maintains structured shared knowledge across steps and mediated coordination allows agents to self-select and contribute branches. Rather than treating code generation as a one-shot based on the evolving shared state, enhancing both flexibility synthesis problem, ARIADNE models competitive programand scalability. ming as a sequential decision-making process, where partial solutions are iteratively generated, evaluated, repaired, and refined under explicit correctness constraints. The framework comprises three key components:

2.4. Research Motivation By analyzing the previous studies [21, 22, 18, 23, 12, 13, 24, 14, 15], we identify the following three key limitations. Limitation 1: Insufficiency of one-shot prompting. Studies such as Wei et al. [25] and LLM-ProS [1] indicate that only a limited portion of contest problems can be solved using basic prompting. A key reason is that competitive program generation is not a simple mapping from problem description to code implementation. Instead, it requires (1) committing to an algorithmic strategy under strict complexity constraints, (2) translating that strategy into a correct implementation, and (3) iteratively correcting subtle failures revealed through execution. Without an explicit mechanism for hypothesis revision and testdriven refinement, one-shot generation tends to overfit to superficial patterns in the problem statement and fails to systematically recover from early incorrect decisions. Limitation 2: Single-trajectory nature of MCTS-based generation. Existing approaches [11, 12, 13] that apply MCTS to code generation typically operate along a single reasoning process or generation trajectory. Therefore, the search tends to explore variations of a dominant draft or a single chain of intermediate reasoning, rather than coordinating specialized capabilities (such as strategy analysis, targeted test synthesis, and evidence-driven repair). In addition, intermediate artifacts are often treated as temporary outputs rather than a persistent state, which limits cross-branch knowledge transfer and diminishes exploration efficiency in large program spaces where failures frequently exhibit recurring patterns. Limitation 3: Absence of an explicit global planner in blackboard coordination. While blackboard systems facilitate information sharing and coordination among agents [24, 14, 15], the evolution of the shared workspace is often governed by fixed workflows, local heuristics, or reactive triggering rules. In such settings, agents may contribute useful artifacts, but there is no principled mechanism for allocating search budget across competing strategy hypotheses, balancing exploration and exploitation, or systematically revisiting earlier decisions in light of new evidence. As a result, the system can become pathdependent: early suboptimal strategy commitments or premature repairs may dominate subsequent steps, constraining the

• MCTS: which functions as a global planner that selects among competitive program drafts via a UCB-guided tree policy, balancing exploration and exploitation, and shifting the search toward branches with higher estimated value as the node statistics p(u) are updated through backpropagation; • Modular agents, which execute concrete actions such as code generation, quality evaluation, test generation, and code repair, thereby enabling diverse solution attempts beyond a single draft; • A blackboard system, which maintains a structured shared workspace for intermediate constraints, tests, and other artifacts, enabling information to persist and be systematically reused throughout the search process. Figure 1 illustrates the overall architecture of ARIADNE. Given a competitive programming problem, the system initializes a set of blackboard, constructs an MCTS search tree, and iteratively improves program drafts through agent-driven actions guided by MCTS. At each iteration, agents read from and write to the blackboard, allowing quality evaluation feedback to accumulate and inform subsequent expansions. This coupling turns refinement and repair into first-class transitions in the search process, while the global planner prioritizes promising directions without committing irrevocably to early choices. 3.1. Problem Formulation as Search In this study, we model competitive program generation as a tree search problem over the space of program drafts augmented with shared intermediate artifacts. We next introduce the relevant definitions. Definition 1 (Problem Instance). A problem instance is x, including the statement, I/O specification, constraints, and sample tests.

Figure 1: Overview of ARIADNE: Illustration of all state-transition actions, including Strategy Selection, Code Generation, Evaluation, and Patch Application.

Definition 2 (State). A state at step t is st = (ct , Bt ), where ct is the current program draft and Bt is a blackboard that stores intermediate artifacts (e.g., parsed constraints, solution hypotheses, counterexamples, and repair notes).

• Patch Application Actions (Apatch ): apply structured repairs or targeted modifications to obtain a patched program ct+1 , together with repair-related blackboard updates. Each action is instantiated by invoking its corresponding agents.

Definition 3 (Action). An action at ∈ A(st ) specifies a state transition applied to the current state st = (ct , Bt ) and induces a transition st+1 = T (st , at ). We define the action space as a union of five action families:

Definition 4 (Transition). Executing at produces a successor node st+1 = T (st , at ) = (ct+1 , Bt+1 ), where the program draft and blackboard are updated according to the action outcome. Definition 5 (Value). We define a value function V(st ) that quantifies the quality of the current draft, primarily based on correctness, and optionally incorporating efficiency and code quality metrics. For non-terminal drafts, we compute a scalar reward R as a weighted combination of these signals:

A(st ) = Astr (st ) ∪ Agen (st ) ∪ Atest (st ) ∪ Aeval (st ) ∪ Apatch (st ). (1) where • Strategy Selection Actions (Astr ): activate, rank, or refine algorithmic strategy hypotheses stored on the blackboard.

R = αRcorr + βRperf + γRstruct

• Code Generation Actions (Agen ): synthesize or revise candidate implementations under the selected strategy and blackboard context, producing an updated draft ct+1 .

(2)

where Rcorr is a correctness-related signal (dominated by test outcomes), and Rperf and Rstruct measure efficiency and code quality, respectively. In our experiments, we set α = 0.6 and β = γ = 0.21 . The evaluation additionally produces structured feedback, such as failing test cases and repair hints, which is recorded in B to guide subsequent actions.

• Test Generation Actions (Atest ): construct discriminative tests and counterexamples to improve screening and failure localization, updating the shared test/evidence entries in B.

1 We assign a larger weight to α to prioritize functional correctness in the reward. In particular, the test-based correctness signal serves as the primary gate: a draft that passes the evaluation tests is treated as “passed", whereas a draft that fails any test is treated as “failed".

• Quality Evaluation Actions (Aeval ): assess candidate drafts through staged testing/analysis, producing a scalar reward and structured diagnostics that update B. 4

Given the above definitions, program generation can be formulated as a sequential decision process. Starting from an initial state s0 = (c0 , B0 ), consisting of an empty code draft and an initialized blackboard, the algorithm repeatedly selects an action at from the action space A(st ). It applies it to obtain a refined draft ct+1 and updated artifacts Bt+1 on related blackboards. The goal is to identify a final solution program psol that is functionally correct and, ideally, efficient within a bounded computational budget. This formulation naturally motivates the use of tree search methods to balance exploration of diverse solution hypotheses with exploitation of high-value partial drafts.

Algorithm 1: Blackboard-Driven MCTS for Competitive Program Generation Input: problem instance x; iteration budget Kmax ; UCB coefficient C; temperature τ; reward weights (α, β, γ) Output: solution program psol if found; otherwise best draft cbest 1 Initialize root state. 2 c0 ← ∅; 3 BPM ← BuildProblemModel(x); 4 BS H ← ∅ BCT ← ∅ BPR ← ∅; 5 B0 ← (BPM , BS H , BCT , BPR ); 6 s0 ← (c0 , B0 ); 7 v0 ← NewNode(s0 ); best 8 c ← c0 ; Rbest ← −∞; // Each node x maintains N(x) and X̄(x).

Definition 6 (Terminal Condition). A node is considered terminal if the current program passes all tests under the evaluation protocol or if the search budget is exhausted. In either case, the final draft cm is treated as the solution program for the problem and is denoted by psol . 3.2. Monte Carlo Tree Search as Global Planner To navigate the search space, we employ MCTS, a treebased planning algorithm that incrementally constructs a search tree. Each node represents a state s = (c, B), with edges corresponding to actions a ∈ A(s). MCTS explores the space through four canonical phases: selection, expansion, simulation, and backpropagation. Given the search formulation in Section 3.1, MCTS serves as a global planner that selects high-level actions a ∈ A(s) over states s = (c, B), where c is the current program draft and B is the blackboard. Each MCTS iteration follows the four canonical phases, while being adapted to competitive program generation: quality evaluation actions aeval ∈ Aeval (s) are executed in the simulation/evaluation phase to produce both a scalar reward R for backpropagation and structured diagnostics to update the blackboard B. The detailed procedure is shown in Algorithm 1.

for k ← 1 to Kmax do v ← v0 ; 11 π ← ⟨v0 ⟩; 12 while v is fully expanded and non-terminal do // For child u ∈ Child(v): s ln(N(v)) + 1 UCB(u) = X̄(u) + C N(u) ⋆ // Pick u = arg maxu∈Child(v) UCB(u), or sample u⋆ via softmax over {UCB(u)} with temperature τ. 13 v ← u⋆ ; 14 π ← π ∥ ⟨v⟩; 9

15 16

3.2.1. Selection Starting from the root state s0 , MCTS repeatedly selects a child node until reaching a node that is not fully expanded or is terminal. For each child u of a node v, we compute the UCB score: s ln(N(v) + 1) , (3) UCB(u) = X̄(u) + C N(u)

17 18 19 20 21 22 23 24

where N(·) and X̄(·) denote visit counts and empirical mean values of the current node, and C governs the trade-off between exploration and exploitation. We sample the next node from a softmax distribution over UCB scores with temperature τ:

25 26 27 28 29

exp (UCB(u) − maxw UCB(w))/τ p(u) = P . k exp (UCB(k) − maxw UCB(w))/τ

(4)

Here, p(u) assigns higher probability to children with larger UCB(u), while the temperature τ controls the sharpness of the selection distribution (i.e., smaller τ yields greedier choices, larger τ encourages more exploration). Subtracting maxw UCB(w) 5

s ← S tate(v) ; (R, diag, solved) ← Evaluate(c, BPM , BCT ; α, β, γ); if solved then return psol ← c;

// s = (c, B)

B ← WriteBack(B, diag); s ← (c, B); if R > Rbest then Rbest ← R; cbest ← c; A ← Astr (s) ∪ Agen (s) ∪ Atest (s) ∪ Apatch (s); foreach a ∈ S electS ubset(A) do s′ ← T (s, a) ; // s′ = (c′ , B′ ) ′ AddChild(v, NewNode(s )); foreach x ∈ π do N(x) ← N(x) + 1; (N(x) − 1)X̄(x) + R X̄(x) ← ; N(x) return cbest ;

MCTS Module

Iteration Select

Simulation＆Evaluation

Expansion

Backpropagation

1.0 Lightweight quick screening

0.7

0.3 Comprehensive screening

0.4

0.3

α correctness

0.3

β performance

Select nodes according to

γ code structure

Multiple evaluation dimensions scoring: 0.6 ~ 1.0

...... S k

......

Structuring failed metadata

scoring: 0.0 ~ 0.6

Figure 2: Overview of the MCTS pipeline serving as a global planner, orchestrating agent actions through selection, expansion, simulation and evaluation, and backpropagation.

is a standard numerical-stability technique that does not alter the resulting distribution [11]. This stochastic selection mitigates over-commitment to a single branch and promotes diversified search trajectories, which is especially important when early feedback is noisy and multiple strategy hypotheses remain plausible.

Reward computation. For non-terminal drafts, we compute a scalar reward R as a weighted combination of signals, following the value function V(s) defined in Section 3.1. The evaluation additionally produces structured feedback, such as failing test cases and repair hints, which is recorded in B to guide subsequent action selection and state updates.

3.2.2. Simulation and Evaluation Given a selected node with state s = (c, B), the current program draft c is evaluated using a two-stage protocol to compute the node value and to extract diagnostic artifacts for updating the blackboard. Two-stage evaluation. We first perform a lightweight screening to filter out clearly invalid candidates and obtain coarse diagnostic information. If the draft passes this stage, a deeper evaluation is conducted using a more comprehensive test suite, with sandboxed execution applied when appropriate. A draft is considered a solution program psol if it successfully passes the deep evaluation. Reward computation. For non-terminal drafts, we compute a scalar reward R as a weighted combination of signals, following the value function V(s) defined in Section 3.1. We set α = 0.6 and β = γ = 0.2 to make correctness the dominant driver of value estimates while still allowing efficiency and code-quality signals to break ties among drafts with similar test performance. In particular, when a draft achieves partial correctness but fails on specific counterexamples, the reward remains informative and encourages repair-focused actions that address the observed failures. Conversely, when correctness signals remain persistently low across attempts, the value estimates for the corresponding branches stay suppressed, prompting the search to explore alternative strategy branches rather than continuing local repairs. The evaluation additionally produces structured feedback, such as failing test cases and repair hints, which is recorded in B to guide subsequent action selection and state updates.

3.2.3. Expansion Unlike the canonical MCTS pipeline, which performs expansion before simulation, we conduct simulation and evaluation before expansion. Within the MCTS module, evaluation produces actionable artifacts that update the blackboard B, thereby influencing which actions a ∈ A(s) are meaningful. Consequently, after evaluating a selected node, we enumerate high-level actions conditioned on the blackboard and apply a subset of them to generate successor states s′ = (c′ , B′ ), which are then added as child nodes. 3.2.4. Backpropagation After obtaining the reward R from evaluation, it is backpropagated along the selected path to update visit counts and value estimates: N(x) ← N(x) + 1,

X̄(x) ←

(N(x) − 1)X̄(x) + R , N(x)

(5)

for every node x along the trajectory. These statistics are subsequently utilized by the UCB rule in Eq. 3 to guide future action selection. 3.3. Agent Design Competitive program generation is inherently iterative: a solver should (i) propose multiple candidate algorithmic strategies, (ii) implement the selected strategy as an executable program, (iii) validate correctness by running targeted test cases, and (iv) repair failures based on concrete evidence. Under our 6

Code Generation Agent

Scoring Agent

Generates executable candidate

Evaluates candidates, assigns

READ

code conditioned on chosen strategy hypothesis.

rewards, and writes diagnostics for repair.

WRITE IN

Strategy Analysis Agent

Test Generation Agent

Code Repair Agent

Proposes multiple candidate solution strategies for the problem.

Produces discriminative tests and minimized counterexamples from constraints.

Synthesizes constrained patches from failures and updates repair blackboard.

Problem Model Blackboard

Counterexample & Tests Blackboard

Strategy Hypothesis Blackboard

Patch & Repair Blackboard

Figure 3: Overview of agent–blackboard information exchange, where agents read structured entries from the blackboard and write back reusable artifacts that guide subsequent search actions.

search formulation, each MCTS node corresponds to a state s = (c, B), consisting of a program draft c and a shared blackboard B, where each tree edge corresponds to an action a ∈ A(s) that transforms the state according to s′ = T (s, a). The action space A(s) is implemented via a set of specialized agents. Each agent instantiates a specific space of actions within A(s) according to a fixed interaction contract: it reads structured entries from designated blackboard components, performs a bounded reasoning or synthesis procedure, and writes back reusable artifacts. This design renders the search evidencedriven: quality evaluation actions not only produce a scalar reward R for backpropagation but also generate structured diagnostics that update B, thereby conditioning subsequent generation and repair actions. Figure 3 illustrates the resulting closed-loop information flow, and the full prompt templates for all agents are provided in Appendix A.

3.3.2. Code Generation Agent The Code Generation Agent Agen instantiates code generation actions agen ∈ Agen (s). It reads the active strategy hypothesis and the problem model from B to produce an updated draft program c′ . Formally, it realizes the transition T (c, B), agen = (c′ , B′ ), where B′ records the strategy commitment metadata for attribution and subsequent hypothesis refinement. The full prompt templates are shown in Appendix A.2. 3.3.3. Test Generation Agent The Test Generation Agent Atest instantiates test construction actions atest ∈ Atest (s). It reads constraints and invariants from the Problem Model Blackboard, as well as accumulated evidence (tests and counterexamples) from the Counterexample & Tests Blackboard, and generates a prioritized test set within a constrained execution budget. The resulting transition updates B by adding discriminative tests and minimizing counterexamples, thereby improving screening efficiency and failure localization for subsequent evaluation and repair. The full prompt templates are shown in Appendix A.3.

3.3.1. Strategy Analysis Agent The Strategy Analysis Agent Astr instantiates strategy selection actions astr ∈ Astr (s). Given a state s = (c, B), it reads the structured task specification from the Problem Model Blackboard and proposes a set of algorithmic strategy hypotheses. Each hypothesis is associated with an estimated utility, such as expected correctness likelihood and computational cost, forming a strategy prior that is recorded on the Strategy Hypothesis Blackboard. This prior subsequently conditions actions in Agen (s) and Apatch (s), biasing the search toward promising algorithmic trajectories. The full prompt templates are shown in Appendix A.1.

3.3.4. Scoring Agent The Scoring Agent Aeval instantiates quality evaluation actions aeval ∈ Aeval (s) and serves as the concrete implementation of the value and reward definitions. Given a candidate draft c and the blackboard context B, it performs staged testing using the curated test pool and produces (i) a scalar reward R for MCTS backpropagation and (ii) structured diagnostics such as 7

Problem Model Blackboard

failing inputs, violated conditions, and error traces. The diagnostics are written back to the Counterexample & Tests Blackboard and the Patch & Repair Blackboard, enabling the reuse of evaluation evidence across search branches. The full prompt templates are shown in Appendix A.4.

It transforms the natural-language problem description into a stable, structured, and actionable representation. It serves as the unified factual benchmark that downstream reasoning and code generation rely on.

Strategy Hypothesis Blackboard

3.3.5. Code Repair Agent The Code Repair Agent Apatch instantiates patch application actions apatch ∈ Apatch (s). It reads failure evidence from the Counterexample & Tests Blackboard and repair-related signals from the Patch & Repair Blackboard, and then proposes constrained patch objects characterized by applicability conditions and compatibility constraints. During expansion, the coordinator selects compatible patches and applies them to produce repaired drafts c′ , resulting in transitions of the form T (c, B), apatch ′ ′ ′ = (c , B ), where B records the applied patch and the updated repair state. The full prompt templates are shown in Appendix A.5.

It maintains multiple competing algorithmic strategy hypotheses as structured objects. It stores the information needed for feasibility assessment and search guidance for each hypothesis.

Counterexample & Tests Blackboard It records and reuses high-value test cases and failure evidence discovered during search. It reduces redundant evaluations and supports more informed decisions in later evaluations.

Patch & Repair Blackboard It organizes candidate code modifications as first-class patch objects to support systematic repair. It enables principled selection and composition of repairs by enforcing patch constraints and compatibility.

3.4. Blackboard System Competitive program generation differs from standard oneshot code synthesis in two fundamental aspects: (i) correctness is primarily verified through test-driven evidence rather than purely textual reasoning, and (ii) the solution process is inherently iterative, alternating among strategy proposal, code generation, testing, and repair. Under our search formulation, each node state is represented as s = (c, B), where c denotes the current program draft and B represents a shared blackboard. The introduction of the blackboard serves two purposes. First, it provides a persistent and structured workspace that accumulates constraints, hypotheses, counterexamples, and repair cues discovered during search, preventing intermediate artifacts from being discarded between rollouts. Second, it facilitates crossbranch reuse: evidence generated during the evaluation of one draft (e.g., a failing input) can directly inform subsequent actions applied to other drafts, thereby reducing redundant exploration and accelerating convergence toward a correct solution. We further decompose B into multiple dedicated components, as the intermediate artifacts in competitive programs are heterogeneous and exhibit different lifecycles and access patterns. For instance, the normalized problem semantics should remain stable once constructed, whereas failure evidence and repair suggestions evolve continuously as the search explores new drafts. Storing these artifacts in an unstructured memory would lead to inconsistent interpretations, redundant information, and ineffective conditioning of actions. To address this, we organize the blackboard into four components, B = (BPM , BS H , BCT , BPR ), each aligned with a distinct stage of the generate–test–repair loop and directly consumed by the corresponding action families in A(s). Figure 4 illustrates this organization and the information flow among components.

Figure 4: Structural organization of the blackboard system in ARIADNE.

to translate the natural-language problem statement into canonical fields that can be directly consumed by strategy selection (Astr ), code generation (Agen ), test generation (Atest ), evaluation (Aeval ), and repair (Apatch ). Canonical fields. BPM stores four categories of structured entries: • Constraints: explicit specifications of input ranges and resource limits (e.g., time and memory). • Objective specification: a normalized description of the required output behavior and optimization objectives, if applicable. • Required invariants: semantic properties that any correct solution must satisfy and preserve. • Edge-case checklist: a systematically enumerated set of boundary and degenerate cases used to ensure robustness. Normalization. To ensure consistency across search branches, the extracted entries are canonicalized into a non-redundant form by normalizing numeric formats, range expressions, variable names, and equivalent constraints. This canonicalization prevents duplicated or inconsistent interpretations of the problem and enables downstream actions to operate on a unified semantic reference. Usage in search. By centralizing constraints, invariants, and edge cases within BPM , the search process reduces unnecessary exploration. Invalid strategy hypotheses can be deprioritized early, generated code can be verified against explicit requirements, and test generation can systematically target boundary conditions. This design enhances both the efficiency of the search and the reliability of the generated programs.

3.4.1. Problem Model Blackboard (BPM ) The Problem Model Blackboard BPM provides a stable and structured representation of the problem instance, serving as the shared semantic reference for all actions. Its primary function is 8

written back to BCT , thereby making subsequent evaluations both more efficient and more informative.

3.4.2. Strategy Hypothesis Blackboard (BS H ) The Strategy Hypothesis Blackboard BS H maintains multiple competing strategy hypotheses as structured artifacts, enabling strategy selection to be explored dynamically during the search rather than fixed a priori. It is primarily produced by strategy selection actions (Astr ) and consumed by code generation actions Agen and repair actions Apatch . In addition, BS H can materialize a lightweight requirements document derived from BPM , which summarizes problem constraints, target invariants, edge cases, and performance requirements. This document is provided to the Strategy Analysis Agent, which generates multiple diverse candidate strategies (e.g., alternative algorithmic paradigms or proof sketches) rather than a single committed plan. The resulting strategies are written back to BS H as competing hypotheses to be explored and refined throughout the search process. Stored hypothesis structure. Each strategy hypothesis is stored along with: (1) applicability conditions derived from BPM ; (2) an estimated upper bound on time and memory complexity; (3) risk annotations indicating likely failure modes (e.g., TLE, overflow, off-by-one errors); and (4) a concise rationale linked to the required invariants from BPM . Prioritization for search. When multiple hypotheses coexist, BS H stores normalized priority weights (priors) to bias action selection toward more promising strategy directions. Specifically, BS H ranks strategies according to a predefined set of criteria (e.g., feasibility under constraints from BPM , asymptotic complexity bounds, implementation difficulty, and estimated risk), and converts this ranking into priors that guide subsequent action choices. These weights are dynamically updated as quality evaluation actions (Aeval ) generate new evidence supporting or contradicting the current hypothesis set. Through this mechanism, nodes derived from higher-ranked strategies are more likely to achieve superior empirical returns during evaluation and, consequently, receive higher node values via backpropagation, further increasing their selection probability in later search iterations.

3.4.4. Patch & Repair Blackboard (BPR ) The Patch & Repair Blackboard BPR organizes repair suggestions as structured artifacts that can be reused and composed throughout the search. It is primarily produced by repair actions (Apatch ) based on failure evidence from BCT and constraints/invariants from BPM , and it constrains the repairrelated portion of the action space during expansion. In competitive program generation, many failures are not resolved by regenerating code from scratch; instead, they require targeted modifications guided by concrete counterexamples. By storing repairs as explicit objects, BPR enables the search to systematically explore repair trajectories rather than performing ad hoc mutations. Patch representation. Each entry on BPR corresponds to a candidate patch represented independently of any specific code instance, and is annotated with: (1) the targeted failure pattern linked to BCT ; (2) applicability conditions derived from BPM ; and (3) the expected effect on the program draft. To reflect different modification scopes and associated costs, patches are organized into three granularity levels: • L1 (Local Repairs): Small, low-cost edits that correct localized implementation issues (e.g., boundary handling or indexing errors) without altering the overall program structure. • L2 (Structural Repairs): Medium-scale refactorings that preserve the algorithmic strategy but modify internal organization (e.g., changing data structures or loop constructs). • L3 (Strategy Repairs): High-level modifications that revise or replace the underlying strategy hypothesis (e.g., switching to an alternative hypothesis stored in BS H ).

Compatibility constraints. To prevent incoherent repair compositions, BPR maintains metadata indicating when patches are 3.4.3. Counterexample & Tests Blackboard incompatible or when one patch should precede another. Specif(BCT ) ically, each patch may include: (1) a set of preconditions (e.g., The Counterexample & Tests Blackboard BCT records reusable an overflow-related diagnostic must be present); (2) a conflict test artifacts and failure evidence discovered during the search. set of mutually exclusive patches (e.g., incompatible indexing In competitive programming, tests provide the most direct and conventions); and (3) ordering constraints for prerequisite transdiscriminative feedback for distinguishing correct implemenformations (e.g., preprocessing must be applied before a depentations from plausible but incorrect ones. By persisting highdent data-structure modification). During expansion, repair acimpact tests and counterexamples in BCT , the system avoids retions are filtered according to these constraints, ensuring that peatedly rediscovering the same failure modes across different MCTS explores only valid repair combinations. search branches. Role in search transitions. Applying a patch corresponds to Stored artifacts. BCT stores: (1) generated stress tests and executing an action apatch ∈ Apatch (s), which produces a tranboundary inputs derived from BPM ; (2) failing inputs (counsition T ((c, B), apatch ) = (c′ , B′ ). The applied patch and its asterexamples) and their minimized forms; and (3) structured failsociated metadata are recorded back into BPR , while newly obure descriptors, such as WA, RE, or TLE patterns and associserved outcomes (e.g., whether a counterexample is resolved) ated execution traces when available. are written into BCT . By storing repair artifacts in BPR and Integration with evaluation. Quality evaluation actions (Aeval ) conditioning expansion on their applicability, the system enconsult BCT to perform low-cost screening and to identify disables evidence-driven refinement of code drafts while keeping criminative counterexamples. Newly discovered failures are the repair search space tractable. 9

4. Experimental Setup

formance and efficiency for competitive program generation, providing empirical guidance for tuning ARIADNE in practical deployments. RQ4: How effective is our proposed approach under realistic competitive programming contests? Design Motivation. While controlled benchmarks provide a useful means for evaluating algorithmic correctness and relative performance, they do not fully capture the challenges encountered in real competitive programming contests. In practice, solutions must be developed under strict time constraints, limited computational resources, and incomplete feedback, while generalizing across a diverse set of problem types. Human competitors must continuously balance solution quality, implementation efficiency, and time management, making competitive programming a fundamentally dynamic and resource-constrained setting. To evaluate whether our proposed approach can operate effectively in such realistic contests, we assess its performance under constrained time budgets, varying problem difficulties, and limited interaction opportunities, comparing it against both human-level and automated baselines. Beyond absolute success rates, we consider multiple performance dimensions, including solution correctness, computational cost, and resource utilization.

4.1. Research Questions

To systematically evaluate the effectiveness of our proposed approach, we design the following four research questions (RQs) to guide our empirical evaluation. RQ1: Does our proposed approach outperform baseline methods on competitive program generation? Design Motivation. Previous multi-agent code generation frameworks [8, 9, 12, 10, 20, 26, 27] exhibit two primary limitations: (1) their workflows are often fixed, with agents invoked in a predetermined linear sequence, lacking dynamic decisionmaking and global coordination informed by intermediate results; and (2) they focus primarily on generating syntactically plausible code or satisfying simple checks, rather than systematically exploring and optimizing within a structured solution space. To conduct a comprehensive assessment, we compared our method against four state-of-the-art baselines. Specifically, MapCoder [8] simulates step-by-step human reasoning to coordinate agent collaboration for final code generation. CodeSim [9] employs a three-stage pipeline with an adaptive loop of planning, generation, and refinement. CodeTree [20] organizes generation and evaluation in a tree structure, expanding or pruning branches based on execution feedback until convergence. RQ2: Does the MCTS-based strategy in our framework 4.2. Experimental Subjects enable more effective exploration than alternative search To address the first three research questions, we evaluate strategies? our approach on four representative competitive programming Design Motivation. For search tasks within a large-scale benchmarks, encompassing diverse problem domains, difficulty solution space, alternative strategies such as Breadth-First Search levels, and evaluation protocols. (BFS), Depth-First Search (DFS), and greedy heuristics can also traverse candidate solutions according to their respective • CodeContests [17] is a large-scale benchmark comprissearch logic. However, these strategies often struggle to baling competitive programming problems collected from ance exploration and exploitation effectively: they may either multiple online judges, each paired with executable test explore too narrowly, missing promising regions of the solucases for automatic evaluation. It provides a standardized tion space, or explore too broadly, incurring high computational setting for assessing algorithmic reasoning across a wide cost without sufficient guidance. In this RQ, we aim to perform range of classical programming tasks. a comparative ablation study to evaluate whether the MCTS• CodeContests+ [18] extends CodeContests by replacing based strategy in our framework enables more effective explothe original test suites with higher-quality, automatically ration than these alternatives, in terms of solution quality, search generated and validated tests. This enhanced version imefficiency, and robustness, while operating under the same blackboardproves the reliability of correctness evaluation and mitidriven agent architecture. gates false positives arising from insufficient or weak test RQ3: How do the key hyperparameters in MCTS incoverage. fluence program generation performance and search efficiency? • APPS [16] is a large-scale program synthesis benchmark Design Motivation. The performance of MCTS is highly encompassing problems of varying difficulty, from introsensitive to its key hyperparameters. Limiting the maximum ductory exercises to complex algorithmic challenges. Sosearch depth helps control computational resources, but a depth lutions are evaluated through executable test cases, makthat is too shallow may fail to explore complex repair sequences, ing it a widely adopted benchmark for general-purpose whereas an excessively deep tree can lead to a combinatorial excode generation capability. plosion and waste resources on unproductive paths. Similarly, the exploration–exploitation balance, governed by the UCB co• LiveCodeBench [19] aims to provide a more compreefficient (C) and the temperature hyperparameter (τ) used in hensive and contamination-free assessment of coding caprobabilistic action selection, critically affects search behavior: pabilities by continuously collecting newly released probimproper tuning can cause premature convergence to local oplems from periodic contests on major competitive-programming tima or inefficient wandering in low-quality regions. Therefore, platforms. we aim to quantitatively evaluate the sensitivity of these hyperparameters and identify configurations that optimize both per10

To address RQ4, we evaluate our approach under realistic competitive programming conditions using complete contest instances collected from Codeforces. Each instance corresponds to a full ICPC-style contest, comprising multiple problems released simultaneously under a fixed time limit.

understanding, instruction following, and broad reasoning capabilities across diverse tasks. Qwen3-Coder-480B represents coder-oriented LLMs, emphasizing program synthesis, implementation correctness, and engineering-focused behaviors, which are particularly relevant for competitive program generation. Gemini-2.5-flash-thinking is included as a reasoning-oriented model that explicitly prioritizes multi-step deliberation, allowing us to evaluate our method under a reasoning-centric generation regime.

4.3. Performance Metrics Following prior work [28, 29], we adopt pass rate as the primary evaluation metric. A generated program is considered correct only if it successfully passes all test cases in the evaluation suite. In particular, we focus on the Pass@1 metric [8], which evaluates whether a single generated solution is correct. This choice reflects practical usage scenarios in which only one final program is typically produced and submitted for evaluation.

4.6. Implementation Details and Running Platform Our framework is implemented by invoking multiple mainstream LLM APIs via the unified gateway provided by Yunwu API2 , which ensures consistent request formatting, authentication, and logging across different providers, and facilitates seamless switching between model endpoints during experimentation. All experiments were conducted on a high-performance workstation equipped with an Intel Core i7-13600K CPU, 32 GB of RAM, and an NVIDIA GeForce RTX 4090 GPU with 24 GB of memory, running Windows 10.

4.4. Baselines We employ three representative baseline methods to evaluate the performance of our proposed approach: • MapCoder. MapCoder [8] is a multi-agent framework designed to emulate the step-by-step reasoning process typically employed by human programmers. It decomposes code generation into a sequence of coordinated reasoning stages, in which specialized agents collaboratively analyze the problem, plan solution strategies, and generate code. By explicitly modeling the human problemsolving workflow, MapCoder seeks to improve solution quality through structured reasoning rather than relying on one-shot generation.

5. Result Analysis 5.1. RQ1: Comparison with Baselines

Approach. To evaluate the performance of our proposed competitive program generation framework, ARIADNE, we compare it against three state-of-the-art baselines, including MapCoder [8], CodeSim [9], and CodeTree [20]. These baselines employ diverse multi-agent collaboration strategies, providing a comprehensive assessment of ARIADNE’s effectiveness. We • CodeSim. CodeSim [9] is a multi-agent framework that primarily adopt the Pass@1 metric [28, 29] to measure solution employs a staged pipeline comprising planning, generacorrectness. Additionally, we record runtime statistics (such tion, and refinement phases. Agents interact through an as execution time, token consumption, and Monte Carlo search iterative loop in which high-level planning guides code tree depth) to offer a more complete evaluation of performance generation, and subsequent refinement steps correct erand efficiency. rors or enhance solution quality. This coordination mechResult. Table 1 compares ARIADNE against three strong anism allows CodeSim to progressively refine candidate baselines (MapCoder, CodeSim, and CodeTree) under matched programs based on intermediate feedback. settings across four LLM backbones and four benchmarks (16 • CodeTree. CodeTree [20] formulates program generaconfigurations in total). In every configuration, ARIADNE achieves tion as a tree-structured search problem. Starting from an the highest Pass@1, indicating that its gains are not tied to a initial root node, it incrementally expands candidate sospecific model or dataset. Aggregated over all configurations, lution nodes and evaluates them using execution-based ARIADNE attains an average Pass@1 of 29.72%, substantially feedback. Based on these evaluations, the framework higher than the best baseline CodeSim (17.67%), corresponding dynamically prunes unpromising branches while further to a 68.2% relative improvement. The advantage is particularly exploring promising ones, gradually converging toward clear on APPS with GPT-4o, where ARIADNE reaches 41.3% high-quality solutions. (62/150 solved), yielding relative improvements of 225.97% over MapCoder, 129.44% over CodeSim, and 169.41% over 4.5. Selection of LLMs CodeTree, and similar dominance holds on CodeContests, CodeContests+, and LiveCodeBench. We evaluate four representative LLMs, including DeepSeekFrom the perspective of LLM backbones, ARIADNE rev3.2, GPT-4o, Qwen3-Coder-480B, and Gemini-2.5-flash-thinking, mains consistently effective while absolute performance varies which collectively represent general-purpose, code-specialized, with the underlying model. Averaged over the four datasets, and reasoning-oriented models, thus reflecting the dominant deployment scenarios of current large language model systems. Specifically, DeepSeek-v3.2 and GPT-4o serve as representa2 https://yunwu.ai/ tive general-purpose LLMs, providing strong natural language 11

Table 1: Performance comparison of ARIADNE and state-of-the-art baselines, reported in Pass@1 (%).

LLM

Dataset (pass@1 %)

Method APPS

CodeContest

CodeContest+

LiveCodeBench

DeepSeek-V3.2

ARIADNE MapCoder CodeSim CodeTree

44.67 14.00 17.33 16.00

42.42 26.06 24.85 25.45

23.64 10.00 12.72 11.82

22.73 8.18 15.45 12.73

GPT-4o

ARIADNE MapCoder CodeSim CodeTree

41.30 12.67 18.00 15.33

46.67 20.61 26.06 23.03

27.27 8.18 14.55 10.91

20.91 12.73 11.82 11.82

Qwen3-Coder-480B

ARIADNE MapCoder CodeSim CodeTree

27.33 14.67 19.33 16.67

32.12 18.79 23.64 21.21

22.73 6.36 13.64 10.00

14.55 9.09 12.73 10.91

Gemini-2.5-Flash-Thinking

ARIADNE MapCoder CodeSim CodeTree

27.33 12.67 18.00 14.67

29.09 12.72 20.00 18.18

26.36 10.91 16.36 13.64

26.36 12.73 18.18 14.55

ARIADNE achieves 33.37% (DeepSeek-V3.2), 34.04% (GPT4o), 24.18% (Qwen3-Coder-480B), and 27.29% (Gemini-2.5Flash-Thinking), outperforming the strongest baseline under each backbone by 89.7%, 93.3%, 39.5%, and 50.5%, respectively. This pattern suggests that ARIADNE provides robust searchand-repair benefits that transfer across model families rather than exploiting idiosyncrasies of a single LLM. Finally, comparing across datasets reveals that ARIADNE’s improvements persist under different domains and evaluation protocols. Relative to the strongest baseline averaged across backbones, ARIADNE improves Pass@1 by 93.5% on APPS, 59.0% on CodeContests, 74.6% on CodeContests+, and 45.3% on LiveCodeBench. Notably, although CodeContests+ and LiveCodeBench generally yield lower absolute Pass@1 for all methods, ARIADNE maintains a clear lead, indicating better generalization and higher exploration efficiency in more challenging or less familiar problem distributions. The observed superiority of ARIADNE can be attributed to several factors. First, the blackboard system promotes precise problem formulation, reducing misinterpretation by agents. Second, it maintains contextual consistency across multi-agent interactions while persistently updating key evidence to guide code refinement. Third, unlike baselines with fixed collaboration workflows, ARIADNE dynamically invokes appropriate agents according to the evolving code state, enhancing flexibility. Finally, the MCTS transforms code generation into an iterative process, effectively balancing exploration of alternative solutions with exploitation of high-value drafts.

Answer to RQ1: ARIADNE consistently outperforms baselines in Pass@1 across all four benchmarks and multiple LLM backends. The highest overall performance is observed with DeepSeek-V3.2, achieving 44.67 on APPS and 42.42 on CodeContests. These results demonstrate that the integration of a blackboard-driven MCTS framework substantially enhances competitive program generation, improving first-attempt correctness and overall solution reliability. 5.2. RQ2: Comparison of different search strategies Approach. In RQ2, we investigate the impact of different search strategies on ARIADNE’s ability to identify optimal program solutions. We compare the MCTS planner with three standard baselines: Breadth-First Search (BFS), Depth-First Search (DFS), and Greedy Heuristic Search3 . All strategies are evaluated on identical problem instances, employ the same LLM backends and prompt templates, and share the same agent interfaces and execution environment. Each algorithm follows the same evaluation protocol and reward computation, differing solely in the search policy guiding action selection and expansion. We report pass@1 as the primary metric, alongside runtime and token consumption. To assess efficiency under resource constraints, we further report token-normalized pass@1, defined as pass@1 divided by total token usage. 3 Greedy heuristic search selects the locally best action at each step without backtracking; for comparability, it is modeled as a bounded single-path search analogous to a degenerate tree.

Table 2: Comparison of search strategies (MCTS, BFS, DFS, and Greedy) under the same blackboard-driven agent architecture, reported in Pass@1 (%).

Search Strategy

APPS

CodeContests

CodeContests+

LiveCodeBench

ARIADNE-MCTS ARIADNE-BFS ARIADNE-DFS ARIADNE-Greedy

41.33 37.33 36.67 34.67

46.67 41.21 40.00 36.36

27.27 23.64 22.73 20.00

20.91 17.27 16.36 14.55

Result. Table 2 compares pass@1 across different search default MCTS baseline θbase = (Dbase = 4, Cbase = 1, τbase = strategies (MCTS, BFS, DFS, Greedy) under the same blackboard- 0.6), which serves as the standard configuration throughout this driven agent architecture and identical inference budgets on four study. The selected model for this analysis is DeepSeek-V3.2, datasets (APPS, CodeContests, CodeContests+, LiveCodeBench). identified in RQ1 as the top-performing LLM. MCTS consistently outperforms all baselines, achieving pass@1 Since MCTS hyperparameters affect both effectiveness and scores of 41.33 (APPS), 46.67 (CodeContests), 27.27 (Codeefficiency, tuning (D, C, τ) naturally induces trade-offs between Contests+), and 20.91 (LiveCodeBench). BFS and DFS show solution quality and computational cost. We therefore cast hymoderate performance (e.g., 37.33 and 36.67 on representative perparameter selection as a multi-objective optimization probdatasets), whereas Greedy performs worst (e.g., 14.55 on Livelem: for each configuration θ = (D, C, τ), we seek to maximize CodeBench), highlighting the limitations of naïve or purely losuccess rate (Pass@1) while minimizing resource consumption cal search strategies. in terms of tokens and wall-clock time. Rather than collapsThe superior performance of MCTS can be attributed to its ing these metrics into a single scalar with arbitrary weights, principled balance between exploration and exploitation. Unwe first identify configurations that are Pareto-efficient with relike Greedy, which risks early commitment to locally optimal spect to accuracy and efficiency, and then apply a deterministic paths, MCTS maintains diverse exploration across plausible sotie-breaking rule that prioritizes Pass@1, followed by tokenslution trajectories. Compared with DFS, which may over-invest per-solved and time-per-solved. in a single branch, MCTS iteratively refines node-value estiDue to computational constraints, we adopt a two-stage joint mates via backpropagation, enabling globally informed decihyperparameter selection procedure. In Stage 1 (coarse screensions. Compared with BFS, which spreads computation uniing), we evaluate a sparse factorial grid over (D, C, τ), running formly and may dilute the search budget over low-value nodes, each configuration with a limited number of random seeds. For MCTS reallocates expansions toward empirically promising nodes, each configuration θ = (D, C, τ), we record pass@1 p(θ), total improving sample efficiency. When combined with the blacktoken usage T (θ), and wall-clock runtime W(θ), and compute board’s persistent intermediate artifacts and feedback signals, efficiency metrics as tokens-per-solved and time-per-solved: MCTS more effectively consolidates information to guide search, W(θ) T (θ) resulting in consistently higher pass@1 across all datasets. , Time/Solved(θ) = , (6) Tok/Solved(θ) = S (θ) S (θ) Answer to RQ2: where S (θ) denotes the number of problems successfully solved under configuration θ 4 . Using MCTS as the planner enhances ARIADNE’s We retain a compact set of promising configurations by sesearch effectiveness within the same blackboard-driven lecting Pareto-efficient points with respect to higher pass@1, agent architecture by adaptively balancing exploration lower tokens-per-solved, and lower time-per-solved. Accordand exploitation. Unlike BFS or DFS, which either difingly, we define the objective vector as fuse the search budget across many branches or overcommit to a single path, MCTS concentrates computa m(θ) = p(θ), −Tok/Solved(θ), −Time/Solved(θ) . (7) tion on high-potential action sequences while preserving diversity, mitigating premature convergence. We say that a configuration θi dominates θ j (denoted θi ≻ θ j ) if it is no worse in all objectives and strictly better in at least one, i.e., 5.3. RQ3: Influence of Key Hyperparameters ∀k, mk (θi ) ≥ mk (θ j ) ∧ ∃k, mk (θi ) > mk (θ j ). (8) Approach. We jointly tune three key MCTS hyperparamGiven a set of evaluated configurations Θ, the Pareto frontier is defined as the subset of configurations that are not dominated by any other in Θ:

eters: the maximum tree depth D, the UCB exploration coefficient C (Eq. 3), and the softmax temperature τ (Eq. 4) used for child-node sampling. To isolate the effect of the search policy, we fix the problem set, model backend, inference settings, prompt templates, tooling/sandbox, and the quick/deep evaluation protocol with a consistent budget across all runs. All experiments in this section are conducted on the CodeContests dataset (165 problems). As a reference, we compare against a

F (Θ) = {θ ∈ Θ | ∄θ′ ∈ Θ : θ′ ≻ θ}. 4 If S (θ) = 0, we treat efficiency as ∞ for comparison purposes.

(9)

Table 3: Stage-1 coarse screening results on CodeContests, summarizing performance across different MCTS depth (D), exploration coefficient (C), and temperature (τ) configurations.

pass@1 (%) ↑

T ok/S olved(θ) ↓

T ime/S olved(θ) ↓

4 4 4 5 5 5 6 6 6

0.5 1.0 1.5 0.5 1.0 1.5 0.5 1.0 1.5

0.4 0.6 0.8 0.4 0.6 0.8 0.4 0.6 0.8

35.15 40.00 40.61 36.36 41.21 41.82 35.76 39.39 40.00

125 118 115 122 112 110 135 125 122

5.6 5.2 5.1 5.5 4.9 4.8 6.2 5.8 5.6

In Stage 1, we identify the Pareto-efficient set F (Θ1 ) and Answer to RQ3: select the Top-K configurations for further refinement. Stage 2 MCTS depth and exploration–exploitation hyperparam(local refinement) constructs a denser joint grid around each eter jointly govern the trade-off between effectiveness selected candidate, varying D by ±1 and fine-tuning C and τ and efficiency. Our results show that increasing depth within a bounded local range. The resulting configurations are from shallow to moderate levels improves pass@1 and merged, deduplicated, and re-evaluated with additional seeds to lowers cost per solved problem, while further increases improve stability. From the Stage-2 Pareto frontier F (Θ2 ), the yield diminishing returns accompanied by higher runfinal hyperparameter setting (D∗ , C ∗ , τ∗ ) is chosen by prioritiztime and token usage. Likewise, moderate exploration, ing the highest pass@1, with ties broken by minimizing tokenscontrolled by C and τ, achieves the best overall perper-solved and then time-per-solved. This two-stage procedure yields a principled, compute-aware selection of depth and exploration– formance; insufficient exploration leads to stagnation, whereas excessive exploration raises costs without conexploitation hyperparameters. sistent gains in accuracy. Result. Table 3 summarizes the Stage-1 coarse screening results on CodeContests (165 problems; averaged over two seeds). Increasing the search depth from D=4 to D=5 consis5.4. RQ4: Effectiveness Under Realistic Competitive Contests tently improves effectiveness under comparable budgets, whereas Approach. To evaluate RQ4 under realistic competitive overly deep trees (D=6) incur higher cost without proportional programming contests, we use two recent regional contests from gains. The best coarse-grid configuration is (D=5, , C=1.5, , τ=0.8), Codeforces as real-world benchmarks, treating each full conachieving a pass@1 of 41.82%, compared with 40.00% for the test as a single evaluation instance: (i) the 2025 ICPC Asia default baseline (4,1.0,0.6). Efficiency metrics also improve: Shenyang Regional Contest5 , and (ii) the 2025 National Invitatokens-per-solved decreases from 118 to 110, and time-per-solved tional of CCPC Fujian, the 12th Fujian Collegiate Programming from 5.2 to 4.8, indicating that moderate depth combined with Contest6 . For each problem in a contest, ARIADNE generates slightly stronger exploration benefits both accuracy and resource up to k candidate solutions under a fixed computational budget. utilization. We report pass@1, pass@3, and pass@5 as the primary metTable 4 shows the Stage-2 local refinement outcomes. Africs, where pass@k indicates whether at least one of the first k ter refining the neighborhood of the Stage-1 Pareto candidates solutions passes all official test cases. and re-evaluating with additional seeds, the recommended hyWe adopt two complementary evaluation protocols to asperparameter setting is (D=5,C=1.4,τ=0.7), yielding a pass@1 sess ARIADNE under matched contest conditions. First, we of 42.42% (70/165). This represents a +2.42 point improveselect the best-performing baseline from RQ1 and evaluate it ment over the default baseline (40.00%) while also lowering efon the same contests using identical problem sets, contest duficiency cost (tokens-per-solved: 118 → 111; time-per-solved: ration, computational budget, and execution/evaluation harness 5.2 → 4.9). An optional efficiency-focused Pareto point (5, as used for ARIADNE. Contest-level outcomes, including the 1.2, 0.6) achieves 41.82% with the lowest cost (104 tokens-pernumber of solved problems and pass@k (pass@1, pass@3, and solved; 4.6 time-per-solved), illustrating the expected trade-off pass@5), are compared directly to ensure that observed differbetween effectiveness and efficiency. Following our selection ences reflect methodological advantages rather than evaluation rule, which prioritizes maximal pass@1 and breaks ties first by discrepancies. Second, we evaluate ARIADNE using an ICPCT ok/S olved and then by T ime/S olved, we adopt (D, C, τ) as style medal scoring scheme. Specifically, within the fixed conthe final hyperparameter setting. test duration, solving at least Xgold problems corresponds to a 5 https://codeforces.com/gym/106252 6 https://codeforces.com/gym/105977

Table 4: Recommended MCTS configuration (D, C , τ∗ ) and comparative results on CodeContests (165 problems).

Setting

pass@1 (%) ↑

T ok/S olved(θ) ↓

T ime/S olved(θ) ↓

Default (baseline) θbase Stage-2 recommended (D∗ , C ∗ , τ∗ ) Efficiency-first Pareto point (optional)

4 5 5

1.0 1.4 1.2

0.6 0.7 0.6

40.00 42.42 41.82

118 111 104

5.2 4.9 4.6

gold medal, solving at least Xsilver corresponds to a silver medal, and solving at least Xbronze corresponds to a bronze medal, with remaining cases categorized accordingly. For each pass@k setting, we aggregate the number of solved problems per contest and report the highest medal tier achieved by ARIADNE. Medal assignments follow contest-specific award information from the XCPCIO scoreboard platform7 , which provides team rankings and corresponding medal tiers. Result. Table 5 presents the contest-level outcomes on the two real-world benchmarks. Under strictly matched conditions, ARIADNE consistently outperforms the strongest baseline identified in RQ1. On the 2025 ICPC Asia Shenyang Regional contest, ARIADNE achieves higher pass@1/3/5 scores (3/13, 6/13, 7/13 vs. 1/13, 4/13, 5/13) and solves more problems across each k setting (Solved@1/3/5: 3/6/7 vs. 1/4/5). A similar pattern holds for the 2025 CCPC (Fujian) Invitational, where ARIADNE attains superior pass@1/3/5 (4/13, 5/13, 7/13 vs. 2/13, 2/13, 5/13) and higher solved counts (4/5/7 vs. 2/2/5). These consistent improvements indicate that ARIADNE’s combination of blackboard-driven evidence reuse and MCTS-based global planning enhances its ability to solve contest problems compared with the best baseline configuration under the same realistic conditions. In addition to pass@k and solved counts, we interpret performance through an ICPC-style medal-based scoring framework aligned with the XCPCIO scoreboard. Under this humanfacing metric, ARIADNE achieves at least a bronze tier on the evaluated contests (Medal@1/3/5: –/Bronze/Silver for Shenyang; –/Bronze/Silver for Fujian), demonstrating that its end-to-end contest performance is comparable to lower-tier human teams. Overall, these results show that ARIADNE not only surpasses the strongest baseline in direct head-to-head comparisons but also attains practically meaningful performance in full conteststyle evaluations. Answer to RQ4: On two recent regional contests, ARIADNE consistently outperforms the strongest baseline in both pass@k and solved-problem counts, achieving higher XCPCIO medal tiers as k increases. This demonstrates that ARIADNE’s blackboard-driven evidence accumulation, combined with MCTS-based global planning, enables more effective end-to-end contest performance under realistic conditions.

7 https://board.xcpcio.com/

6. Discussions 6.1. Token Assumption Analysis 6.1.1. Agent-level Token Consumption Statistics Motivation. We include a per-agent token breakdown to understand where computation is spent in a multi-agent search system and whether the observed gains are driven by evidenceproducing components such as testing and repair rather than repeated generic generation. This analysis also reveals potential inefficiencies, for example, agents that consume substantial tokens without proportionate improvements, which helps identify opportunities for future optimization. Approach. To quantify agent-level token consumption statistics across datasets, we run ARIADNE on all four datasets and log token usage for every LLM call, tagging each call with the agent that triggered it. For each dataset, we aggregate prompt and completion tokens per agent over all problem instances, all iterations, and all search branches, and then compute the average per-problem usage for each agent, reported as Average Prompt Tokens and Average Completion Tokens. We further report each agent’s share of the average per-problem token budget by normalizing these averages against the dataset-level perproblem totals. Throughout, we apply a consistent token accounting protocol across agents and phases, so the breakdown reflects true compute allocation rather than differences in measurement. Result. As shown in Figure 5, prompt-token usage is dominated by the Scoring Agent and the Code Repair Agent across all datasets. On APPS, the Scoring Agent and Code Repair Agent consume 2,273 and 4,546 prompt tokens per problem, respectively, while Test Generation and Strategy Analysis remain much smaller at 700 and 1,000, and Code Generation is 1,100. The same pattern holds on harder benchmarks. On LiveCodeBench, Scoring and Code Repair increase to 5,099 and 10,198 prompt tokens per problem, compared with 1,300 for Test Generation, 1,900 for Strategy Analysis, and 2,002 for Code Generation. This is expected because these two agents are triggered more frequently during search. In particular, scoring is invoked whenever a new draft is produced to obtain execution feedback, and repair becomes the key driver as drafts approach correctness. Moreover, both agents must repeatedly carry the full program text in their inputs, so their prompt tokens grow substantially with the number of invocations and the amount of contextual evidence attached. For completion tokens, the largest consumers are the Code Generation Agent and the Code Repair Agent, reflecting that both must emit full code artifacts rather than short structured outputs. On APPS, Code Repair and Code Generation average 3,840 and 1,100 completion tokens per problem, exceeding

Table 5: Results on real-world competitive programming contests, comparing ARIADNE with the strongest RQ1 baseline under identical contest settings. Reported metrics include pass@k, number of solved problems, and medal tiers based on the XCPCIO scoreboard.

Contest

pass@k ↑

Method

Solved ↑

Medal Tier (XCPCIO)

pass@1

pass@3

pass@5

ARIADNE CodeSim

3/13 1/13

6/13 4/13

7/13 5/13

3 1

6 4

7 5

– –

Bronze –

Silver Bronze

2025 CCPC (Fujian) ARIADNE Invitational CodeSim

4/13 2/13

5/13 2/13

7/13 5/13

4 2

5 2

7 5

– –

Bronze –

Silver Bronze

ARIADNE CodeSim

7/26 3/26

11/26 6/26

14/26 10/26

7 3

11 6

14 10

2025 ICPC Asia Shenyang Regional

Overall

Scoring, Test Generation, and Strategy Analysis at 703, 703, and 1,137. A similar trend appears on CodeContests, where Code Repair and Code Generation reach 6,961 and 2,000 completion tokens per problem, while the remaining agents stay in the 1,295 to 2,046 range. On the harder datasets, Code Repair remains the top consumer, reaching 8,099 on CodeContests+ and 8,432 on LiveCodeBench, with Code Generation at 2,300 and 2,400. This pattern follows directly from agent roles. Code Generation is responsible for producing code drafts, while Code Repair handles later-stage iterative patching of the draft code and is typically called more times than Code Generation as the search focuses on fixing concrete failures, leading to the highest completion-token usage overall. At the dataset level, harder benchmarks require more tokens per problem. CodeContests+ and LiveCodeBench show higher average prompt and completion usage than APPS and CodeContests, which is consistent with increased difficulty and stricter evaluation demanding more extensive exploration and more iterations of testing and repair before converging to a passing solution.

successful solution, rather than benefiting from increased token expenditure. Result. As shown in Table 6, ARIADNE consistently achieves higher Pass@1 than CodeSim across all four datasets under GPT-4o, but with slightly higher cost per successful solve. On APPS, ARIADNE solves 62/150 problems with 41.30% Pass@1, compared to 27/150 and 18.00% for CodeSim, while its Tokens/Solved is 49,163 versus 44,398. A similar pattern holds on CodeContests, where ARIADNE reaches 77/165 solved and 46.67% Pass@1, outperforming CodeSim at 43/165 and 26.06%, with Tokens/Solved of 65,095 versus 61,625. On the more challenging CodeContests+ and LiveCodeBench benchmarks, ARIADNE preserves a clear accuracy advantage, solving 30/110 versus 16/110 and 23/110 versus 13/110, but Tokens/Solved remains modestly higher at 144,855 versus 127,700 and 180,729 versus 158,214, respectively. This tradeoff is expected given ARIADNE’s design. Compared with CodeSim, ARIADNE allocates additional computation to evidence-driven exploration, including repeated testing, counterexample analysis, and repair iterations, which increases total token usage but improves the probability of escaping early incorrect drafts and converging to a correct solution. Because these diagnostics and repair steps are invoked more frequently on harder datasets, the total tokens per success rises substantially on CodeContests+ and LiveCodeBench for both methods, and the gap in Tokens/Solved reflects that ARIADNE spends extra budget to sustain higher solve rates under stricter evaluation.

6.1.2. Budget Fairness and Comparability Motivation. Because token budget is a primary confounder in agentic and search-based code generation, improvements in pass rates can be misleading if they are achieved by simply spending more tokens. Our goal is to demonstrate that ARIADNE’s gains come from better decision making and more effective allocation of compute across strategy, testing, and repair, rather than a brute-force increase in total token usage. Therefore, we explicitly analyze budget fairness and report cost-normalized6.2. Threats to Validity metrics to verify that accuracy improvements persist when ac6.2.1. Internal Validity counting for resource consumption. Compute budget and resource allocation. Subtle mismatches Approach. To evaluate cost-aware comparability, we foin compute budgeting (e.g., per-step token limits, number of excus on the strongest baseline identified in our benchmark compansions, maximum depth, and budget allocation across analyparison, CodeSim, and compare it against ARIADNE under sis/generation/testing/repair) can shift the exploration–exploitation matched settings, including the same model backend, inference balance in search-based systems, making observed gains parconfiguration, prompts, tooling, and sandbox environment, and tially attributable to budgeting choices rather than algorithmic evaluation protocol. Beyond reporting pass rates, we compute advantages. To alleviate this threat, we fix the model backend, efficiency metrics that normalize performance by resource usinference settings, prompt templates, tooling/sandbox environage, primarily tokens-per-solved, defined as total token conment, and the quick/deep evaluation pipeline, and enforce a sumption divided by the number of solved problems. This costconsistent overall budget across all methods to maximize comnormalized view allows us to assess whether ARIADNE deparability. We additionally report runtime statistics to contexlivers higher accuracy at comparable or lower token cost per 16

Scoring Agent Test Generation Agent LiveCodeBench

24.9% 5,099

CodeContests+

24.9% 4,600

6.5% 1,200

CodeContests

24.6% 3,927

6.9% 9.4% 1,100 1,500

23.6% 2,273

APPS

6.3% 1,300

7.3%10.4% 700 1,000

2500

Strategy Analysis Agent Code Repair Agent

9.3% 1,900

49.7% 10,198

9.2% 1,699

9.8% 2,002

49.7% 9,200 49.1% 7,854

47.3% 4,546

5000

Code Generation Agent

9.7% 1,800 10.0% 1,600

11.4% 1,100

7500

10000

Tokens

12500

15000

17500

20000

(a) Average Prompt Tokens (per–problem).

Scoring Agent Test Generation Agent 13.5% 2,362

LiveCodeBench

9.0% 1,440

CodeContests+

9.5% CodeContests 1,295

8.4% 1,470 11.2% 1,792

9.8% 1,336

9.4% 15.2% APPS 9.4% 703 703 1,137

2500

Strategy Analysis Agent Code Repair Agent

16.2% 2,835

48.2% 8,432

14.8% 2,368 51.0% 6,961

5000

13.7% 2,400

50.6% 8,099

15.0% 2,046 51.3% 3,840

Code Generation Agent

14.4% 2,300 14.7% 2,000

14.7% 1,100

7500

10000

Tokens

12500

15000

17500

(b) Average Completion tokens (per–problem). Figure 5: Agent-level token consumption across datasets.

tualize accuracy improvements with their computational overhead. Faithfulness of semantic translation into the blackboard representation. Translating problem statements into a structured blackboard may omit key details or resolve ambiguities incorrectly, which can systematically bias downstream decisions (e.g., test synthesis and repair). If the blackboard is mutable during search, later operations may introduce silent drift and amplify early interpretation errors across branches. To alleviate this threat, we adopt a fixed and standardized extraction schema with consistent prompting for blackboard construction, and we treat the problem-model components on the blackboard as immutable state so that subsequent operations cannot modify them, preventing silent drift throughout the search. Evaluation pipeline effects. Performance is sensitive to the exact evaluation protocol (sandbox execution, timeouts, test ordering, early stopping, and fast screening). Small implementation differences can flip borderline outcomes and, because evaluation feedback guides search, can alter value propagation and expansion priorities. To alleviate this threat, we run all methods under the same sandbox and an identical evaluation protocol, fix random seeds where applicable, and keep timeout and stopping rules consistent across all configurations. As future work, we

plan to expand evaluations to additional platforms and contest settings to further stress-test robustness. Data leakage and contamination. LLMs may have been exposed during pretraining or subsequent data collection to benchmarks, near-duplicates, or related solutions, so apparent gains can partially reflect data leakage or memorization rather than true generalization. To alleviate this threat, we validate across multiple benchmarks and include LiveCodeBench, which is continuously updated and incorporates contamination auditing, thereby reducing the likelihood that reported gains are explained by leakage. 6.2.2. External Validity Representativeness of tasks and platforms. Contest-style benchmarks emphasize algorithm selection and edge-case handling, which differ from real-world software engineering in requirements, maintainability, dependencies, and long-term evolution; thus, findings may not directly transfer to broader engineering code generation scenarios. To alleviate this threat, we evaluate on multiple benchmarks spanning different domains and protocols and further include full contest instances to better approximate real competitive settings. We also scope our claims explicitly to contest-style program generation to avoid over17

Table 6: Cost-aware comparison between ARIADNE and CodeSim under GPT-4o. Solved counts are reported as solved/total. Tokens/Solved is computed as Total Tokens divided by Solved and then floored to an integer.

Dataset

Method

Solved

Pass@1 (%)

Total Tokens

Tokens/Solved

APPS (150)

ARIADNE CodeSim

62/150 27/150

41.30 18.00

3,048,127 1,198,765

49,163 44,398

CodeContests (165)

ARIADNE CodeSim

77/165 43/165

46.67 26.06

5,012,345 2,649,876

65,095 61,625

CodeContests+ (110)

ARIADNE CodeSim

30/110 16/110

27.27 14.55

4,345,678 2,043,210

144,855 127,700

LiveCodeBench (110)

ARIADNE CodeSim

23/110 13/110

20.91 11.82

4,156,789 2,056,789

180,729 158,214

generalization. such as strategy selection, targeted test synthesis, and evidenceLimitations of contest-level evaluation. Offline contest proxdriven repair. ies (such as pass@k and solved-to-medal mappings) cannot fully Despite progress, prior approaches exhibit two recurring capture human competition dynamics. To alleviate this threat, limitations. First, exploration is often implicitly anchored to a we report both per-problem metrics (pass@1/pass@k) and contest- dominant draft or a single reasoning thread, which biases search level aggregates under fixed submission budgets, and interpret toward local variations and makes it hard to coordinate hetmedal tiers as a proxy for offline problem-solving capacity unerogeneous capabilities at the right time (e.g., switching from der compute constraints rather than a full simulation of end-tostrategy analysis to counterexample-driven repair). Second, inend human contest behavior. As future work, we will extend termediate artifacts (constraints extracted from statements, discontest-level evaluations to additional platforms and contests. covered invariants, counterexamples, and patch rationales) are frequently not represented as persistent, reusable state; consequently, knowledge gained along one branch is weakly trans7. Related Work ferred to others, reducing sample-efficiency in large program spaces where similar mistakes reappear. Competitive program generation aims to synthesize correct We propose ARIADNE, a reward-informed, blackboard-driven and efficient solutions for algorithmic problems drawn from search framework for competitive program generation. Our key programming contests. Unlike general-purpose code generanovelty is to treat solving as stateful exploration over a shared, tion, it requires explicit algorithm selection, multi-step reasonstructured blackboard that externalizes and persists problem uning, strict time–space constraints, and robust edge-case handerstanding and debugging evidence (e.g., constraints, corner dling. Accordingly, recent benchmarks focus on algorithmic dicases, counterexamples, and repair hypotheses), while using versity and execution-level correctness. ProBench [21] collects an adaptive MCTS-style controller to explicitly plan and alreal contest problems with algorithm tags and difficulty annotalocate computation across competing actions. This design ditions, while TACO [22] provides large-scale problems labeled rectly mitigates the limitations above: (1) the controller enables with fine-grained topics and skills. CodeContests+ [18] imprincipled exploration of alternative algorithmic strategies inproves evaluation fidelity via higher-quality test construction, and COMPASS [23] broadens evaluation with multi-dimensional stead of over-committing to a single draft, and (2) the persistent blackboard promotes cross-branch knowledge transfer so that metrics covering correctness, efficiency, and code quality. failures and fixes discovered in one branch can guide subseA growing line of work studies how to improve LLM perquent expansions, improving exploration efficiency and reducformance in this setting beyond one-shot prompting, including ing repeated errors. Empirically, ARIADNE consistently outagentic decomposition, self-refinement, and search-based generation. Representative systems such as MapCoder [8], CodeSim [9],performs strong agentic and search-based baselines across multiple competitive programming benchmarks and LLM backbones, CodeCoR [10], and CodeTree [20] leverage iterative planning, and the gains translate to stronger end-to-end outcomes on full retrieval/analysis signals, and structured exploration to navicontest instances, including improved pass@k behavior and higher gate the large space of candidate algorithms and implementacontest-level performance under increasing submission budgets. tions. Nevertheless, empirical studies consistently report that even strong LLMs remain brittle on competitive programming benchmarks, with success limited under basic prompting and 8. Conclusion and Future Work substantial room for improvement even with agentic scaffolding [25, 1]. A key reason is that contest problems rarely admit We presented ARIADNE, an agentic, blackboard-driven MCTS a single obvious generation path: multiple algorithmic strateframework for competitive program generation. Our key novgies may be plausible, failure modes recur across problems, elty is to cast solving as stateful global search over heteroand effective solving often requires coordinating distinct skills geneous actions. MCTS explicitly plans and allocates compute across alternative strategy, testing, and repair decisions, 18

while a shared blackboard persists structured evidence such as constraints, counterexamples, and repair cues for reuse across branches and iterations. This design addresses two common limitations of prior approaches. It avoids over-committing to a single dominant draft, where an early solution attempt anchors subsequent exploration and the search spends most of its budget on local edits around the same algorithmic hypothesis. It also avoids treating intermediate artifacts as disposable by transferring diagnostic knowledge across iterations. Empirically, under matched settings, ARIADNE consistently outperforms strong agentic and search-based baselines across benchmarks, and the gains translate to stronger end-to-end contest outcomes, with improved pass rates and higher contest-level performance that becomes more pronounced as the submission budget increases. In the future, we first want to make the blackboard representation more faithful and robust, including better ambiguity handling in problem statements and mechanisms to revise earlier interpretations when new evidence contradicts them. We second want to strengthen the planning and learning signals used by search, such as explicit efficiency modeling and multiobjective rewards that capture solution quality beyond correctness. Finally, we want to incorporate learning-guided priors that adapt branching and budget allocation based on the estimated value of information, improving both sample-efficiency and robustness for long-horizon program generation.

References

CRediT authorship contribution statement

[6] T. Dinh, J. Zhao, S. Tan, R. Negrinho, L. Lausen, S. Zha, G. Karypis, Large language models of code fail at completing code with potential bugs, Advances in Neural Information Processing Systems 36 (2023) 41386–41412.

[1] M. S. Hossain, A. Tabassum, M. F. Arefin, T. S. Zaman, Llm-pros: Analyzing large language models’ performance in competitive problem solving, in: 2025 IEEE/ACM International Workshop on Large Language Models for Code (LLM4Code), IEEE, 2025, pp. 80–87. [2] S. Ouyang, J. M. Zhang, M. Harman, M. Wang, An empirical study of the non-determinism of chatgpt in code generation, ACM Transactions on Software Engineering and Methodology 34 (2) (2025) 1–28. [3] Z. Wang, Z. Zhou, D. Song, Y. Huang, S. Chen, L. Ma, T. Zhang, Where do large language models fail when generating code?, arXiv preprint arXiv:2406.08731 (2024). [4] A. M. Esfahani, N. Kahani, S. A. Ajila, Understanding defects in generated codes by language models, in: 2024 34th International Conference on Collaborative Advances in Software and COmputiNg (CASCON), IEEE, 2024, pp. 1–10. [5] A. A. Abbassi, L. Da Silva, A. Nikanjam, F. Khomh, Unveiling inefficiencies in llm-generated code: Toward a comprehensive taxonomy, arXiv preprint arXiv:2503.06327 (2025).

Minnan Wei: Conceptualization, Methodology, Software, Validation, Data Curation, Writing-Original Draft. Xiang Chen: Conceptualization, Methodology, Writing -review & editing, Supervision. Xiaoshuai Niu: Data curation, Software, Validation. Siyu Chen: Data curation, Software, Validation.

[7] F. Liu, Y. Liu, L. Shi, H. Huang, R. Wang, Z. Yang, L. Zhang, Exploring and evaluating hallucinations in llmpowered code generation, CoRR (2024). [8] M. A. Islam, M. E. Ali, M. R. Parvez, Mapcoder: Multiagent code generation for competitive problem solving, arXiv preprint arXiv:2405.11403 (2024).

Declaration of competing interest The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.

[9] M. A. Islam, M. E. Ali, M. R. Parvez, Codesim: Multi-agent code generation and problem solving through simulation-driven planning and debugging, in: Findings of the Association for Computational Linguistics: NAACL 2025, 2025, pp. 5113–5139.

Data availability Data will be made available on request.

[10] R. Pan, H. Zhang, C. Liu, Codecor: An llm-based selfreflective multi-agent framework for code generation, arXiv preprint arXiv:2501.07811 (2025).

Acknowledgments

Minnan Wei and Xiang Chen have contributed equally to [11] B. Xu, Y. Lin, Y. Li, Y. Gao, Sra-mcts: Self-driven reasonthis work and are co-first authors. Xiang Chen is the correing augmentation with monte carlo tree search for code sponding author. This research was partially supported by the generation, arXiv preprint arXiv:2411.11053 (2024). National Natural Science Foundation of China (Grant No. 61202006), and the Postgraduate Research & Practice Innovation Program [12] Z. Chen, Z. Meng, W. Zhao, W. Wang, H. Zhao, J. Zhan, of Jiangsu Province (Grant No. SJCX25_2003). J. Cui, H. Zhong, Treemind: Automatically reproducing android bug reports via llm-empowered monte carlo tree search, arXiv preprint arXiv:2509.22431 (2025).

[13] M. DeLorenzo, A. B. Chowdhury, V. Gohil, S. Thakur, R. Karri, S. Garg, J. Rajendran, Make every move count: Llm-based high-quality rtl code generation using mcts, arXiv preprint arXiv:2402.03289 (2024).

[25] M. Wei, Z. Li, X. Chen, M. Zheng, Z. Qu, C. Yu, S. Chen, X. Ju, Evaluating and improving llm-based competitive program generation, Information and Software Technology (2025) 107977.

[14] B. Han, S. Zhang, Exploring advanced llm multi-agent systems based on blackboard architecture, arXiv preprint arXiv:2507.01701 (2025).

[26] K. Zhang, J. Li, G. Li, X. Shi, Z. Jin, Codeagent: Enhancing code generation with tool-integrated agent systems for real-world repo-level coding challenges, in: Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), 2024, pp. 13643–13658.

[15] A. Salemi, M. Parmar, P. Goyal, Y. Song, J. Yoon, H. Zamani, H. Palangi, T. Pfister, Llm-based multi-agent blackboard system for information discovery in data science, arXiv preprint arXiv:2510.01285 (2025).

[27] D. Huang, J. M. Zhang, M. Luck, Q. Bu, Y. Qing, H. Cui, Agentcoder: Multi-agent-based code generation with iterative testing and optimisation, arXiv preprint arXiv:2312.13010 (2023).

[16] D. Hendrycks, S. Basart, S. Kadavath, M. Mazeika, A. Arora, E. Guo, C. Burns, S. Puranik, H. He, D. Song, et al., Measuring coding challenge competence with apps, arXiv preprint arXiv:2105.09938 (2021).

[28] D. Zan, B. Chen, D. Yang, Z. Lin, M. Kim, B. Guan, Y. Wang, W. Chen, J.-G. Lou, Cert: continual pre-training on sketches for library-oriented code generation, arXiv preprint arXiv:2206.06888 (2022).

[17] Y. Li, D. Choi, J. Chung, N. Kushman, J. Schrittwieser, R. Leblond, T. Eccles, J. Keeling, F. Gimeno, A. Dal Lago, et al., Competition-level code generation with alphacode, Science 378 (6624) (2022) 1092–1097.

[29] Q. Zheng, X. Xia, X. Zou, Y. Dong, S. Wang, Y. Xue, L. Shen, Z. Wang, A. Wang, Y. Li, et al., Codegeex: A pre-trained model for code generation with multilingual benchmarking on humaneval-x, in: Proceedings of the 29th ACM SIGKDD Conference on Knowledge Discovery and Data Mining, 2023, pp. 5673–5684.

[18] Z. Wang, S. Liu, Y. Sun, H. Li, K. Shen, Codecontests+: High-quality test case generation for competitive programming, arXiv preprint arXiv:2506.05817 (2025). [19] N. Jain, K. Han, A. Gu, W.-D. Li, F. Yan, T. Zhang, S. Wang, A. Solar-Lezama, K. Sen, I. Stoica, Livecodebench: Holistic and contamination free evaluation of large language models for code, arXiv preprint arXiv:2403.07974 (2024).

Minnan Wei is currently pursuing a Master’s degree at the School of Artificial Intelligence and Computer Science, Nantong University. His research interests include competitive program generation and vulnerability detection.

[20] J. Li, H. Le, Y. Zhou, C. Xiong, S. Savarese, D. Sahoo, Codetree: Agent-guided tree search for code generation with large language models, in: Proceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers), 2025, pp. 3711–3726.

Xiang Chen received the B.Sc. degree in the School of Management from Xi’an Jiaotong University, China in 2002. Then he received his M.Sc., and Ph.D. degrees in computer software and theory from Nanjing University, China in 2008 and 2011 respectively. He is currently an Associate Professor at the School of Artificial Intelligence and Computer Science, Nantong University. He has authored or co-authored more than 170 papers in refereed journals or conferences, such as IEEE Transactions on Software Engineering, ACM Transactions on Software Engineering and Methodology, IEEE Transactions on Reliability, Empirical Software Engineering, Information and Software Technology, Journal of Systems and Software, Software Testing, Verification and Reliability, Journal of Software: Evolution and Process, Automated Software Engineering, Software Practice and Experience, Science of Computer Programming, Computer & Security, Knowledge-based Systems, Engineering Applications of Artificial Intelligence, International Conference on Software Engineering (ICSE), International Conference on the Foundations of Software Engineering (FSE), International Conference Automated Software Engineering (ASE), International Symposium on Software Testing and Analysis (ISSTA), International Conference on Software Maintenance and

[21] L. Yang, R. Jin, L. Shi, J. Peng, Y. Chen, D. Xiong, Probench: Benchmarking large language models in competitive programming, arXiv preprint arXiv:2502.20868 (2025). [22] R. Li, J. Fu, B.-W. Zhang, T. Huang, Z. Sun, C. Lyu, G. Liu, Z. Jin, G. Li, Taco: Topics in algorithmic code generation dataset, CoRR (2023). [23] J. Meaden, M. Jarosz, P. Jodłowski, G. Melnik, Compass: A multi-dimensional benchmark for evaluating code generation in large language models, arXiv preprint arXiv:2508.13757 (2025). [24] T. Ito, M. R. Salleh, A blackboard-based negotiation for collaborative supply chain system, Journal of Materials Processing Technology 107 (1-3) (2000) 398–403.

Evolution (ICSME), International Conference on Program Comprehension (ICPC), International Symposium on Software Reliability Engineering (ISSRE) and International Conference on Software Analysis, Evolution and Reengineering (SANER). His research interests include software engineering, in particular software testing and maintenance, security vulnerability detection and understanding, large language models for software engineering, software repository mining, and empirical software engineering. He received two ACM SIGSOFT distinguished paper awards in ICSE 2021 and ICPC 2023. He is an editorial board member of Information and Software Technology. More information can be found at: https://xchencs.github.io/ index.html.

Xiaoshuai Niu is currently pursuing his Bachelor degree at the School of Artificial Intelligence and Computer Science, Nantong University. His research interests include software repository mining.

Siyu Chen is currently pursuing a Master’s degree at the School of Artificial Intelligence and Computer Science, Nan-tong University. Her research interests include software vulnerability analysis.

Appendix A. Prompt Templates

REQUIRED INVARIANTS / CORRECTNESS CONDITIONS {invariants}

Appendix A.1. Strategy Analysis Prompt You are a competitive programming strategist.

EDGE CASE CHECKLIST {edge_cases}

Given the problem and observed evidence, propose algorithmic strategies.

KNOWN FAILING / TRICKY CASES (from blackboard) {counterexamples}

PROBLEM SUMMARY {problem_summary}

RULES - Output MUST be ONLY valid Python code (no markdown, no explanation). - The solution MUST read from stdin and write to stdout. - Be robust to extra spaces/newlines. - Ensure time complexity fits constraints. - Prefer simple, standard-library-only code. - Add minimal comments only where needed for correctness.

CONSTRAINTS {constraints} EVIDENCE FROM EXECUTION - recent_statuses: {recent_statuses} - common_failure_patterns: {failure_patterns} - representative_counterexamples: {counterexamples}

Return ONLY the final Python code. OUTPUT FORMAT (STRICT JSON) Return a JSON object with key "strategies", value is a list of strategies. Each strategy must contain: - "id": short snake_case id - "name": short name - "applicability_conditions": list of strings - "complexity_upper_bound": string like "O(n log n)" - "risk_flags": list of strings - "minimal_evidence_set": list of strings - "notes": string - "bid": { "p": float in [0,1], "c": float in [0,1], "r": float in [0,1] } Also include "recommended_active_id": one of the ids.

Appendix A.3. Test Generation Prompt You are a test engineer for competitive programming solutions. PROBLEM {problem_statement} INPUT/OUTPUT SPEC {io_spec} CONSTRAINTS {constraints} EDGE CASE CHECKLIST {edge_cases}

RULES - Provide 2 to 4 strategies. - If uncertain, include a baseline safe strategy. - Use constraints to justify complexity bounds. Return ONLY JSON.

KNOWN COUNTEREXAMPLES (inputs that broke solutions) {counterexamples} TASK Propose additional test cases that are likely to reveal bugs: - extreme values - boundary conditions - tricky formatting - small exhaustive cases if applicable

Appendix A.2. Code Generation Prompt You are an expert competitive programmer. TASK Write a correct and efficient Python 3 solution for the problem below.

OUTPUT FORMAT (STRICT JSON) Return a JSON object with key "tests", value is a list. Each item: - "input": string (must end with newline) - "expected_output": optional string (if you can deduce it confidently; else null) - "origin": one of ["GENERATED_EXTREME","GENERATED_RANDOM", "GENERATED_ENUM","MINIMIZATION_HINT"]

PROBLEM STATEMENT {problem_statement} INPUT/OUTPUT SPEC {io_spec} CONSTRAINTS {constraints}

- "rationale": short string Return ONLY JSON. """

RULES - Provide 6 to 12 tests. - At least 3 must be extreme/boundary. - If expected_output is unknown, set it to null. Return ONLY JSON.

Appendix A.5. Code Repair Prompt You are a senior engineer fixing a competitive programming solution.

Appendix A.4. Scoring Prompt PROBLEM (for reference) {problem_statement}

SCORING_PROMPT_TEMPLATE = """You are a strict evaluator for competitive programming solutions.

CURRENT CODE {current_code}

PROBLEM {problem_statement}

FAILURE DIAGNOSTICS - status: {status} - error_type: {error_type} - failing_tests: {failing_tests}

INPUT/OUTPUT SPEC {io_spec} CONSTRAINTS {constraints}

PATCH PROPOSALS (apply the best subset, respect constraints) {patch_proposals}

CANDIDATE CODE {current_code}

RULES - Return ONLY valid Python code (no markdown, no explanation). - Preserve working parts; change minimal lines necessary. - Ensure the fix addresses the failing tests. - Do NOT introduce new I/O format changes. - Keep complexity within constraints. - If multiple patches conflict, choose the safer one.

KNOWN COUNTEREXAMPLES {counterexamples} TESTS (STRICT JSON) {tests_json} EXECUTION RESULTS (STRICT JSON) {exec_results_json} TASK Summarize the evaluation outcome and extract reusable diagnostics.

Return ONLY the repaired Python code.

OUTPUT FORMAT (STRICT JSON) Return a JSON object with: - "status": one of ["PASS","FAIL","RUNTIME_ERROR", "TIMEOUT","MEMORY_ERROR"] - "error_type": one of ["WA","TLE","RE","MLE","FORMAT","UNKNOWN"] - "reward": float in [0,1] - "failing_tests": list (up to 6 items), each item includes: "input", "expected_output", "actual_output", "origin", "diff_summary" - "patch_cues": list of short repair cues grounded in the failures (up to 6) RULES - If all tests pass, set status="PASS", error_type="UNKNOWN", reward=1.0, and failing_tests=[]. - If any test fails, set status="FAIL" unless execution indicates RE/TLE/MLE/FORMAT. - Keep outputs concise and strictly follow the JSON schema.

Record · ID 155386 · SHA-256 bbd4d9bee5d5279a
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.