{"id":"95f0eaad-8c52-438b-b142-389f988d0b11","arxiv_id":"2508.19532","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"StructureCoder constructs fine-grained DPO pairs by filling in AST-extracted code blocks with FIM prompts and curriculum training, improving code generation pass@1 over standard DPO.","lead":"This paper presents StructureCoder, a training method that breaks code into small blocks and uses fill-in-the-middle prompts to build fine-grained preference pairs for Direct Preference Optimization (DPO). The authors report consistent pass@1 gains over DPO and KTO across several code benchmarks and model sizes. If the results hold up, it offers a data-efficient way to align code models without needing more labeled test cases.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"No ablation isolates the FIM-DPO loss from simply having more FIM training examples: the 'Data Equal' control adds epochs, not distinct pairs, and no SFT-only baseline is run.","rationale":"The reader's weakest assumption was the independence claim in Section 2.3, which is a legitimate theoretical soft spot but not the most load-bearing issue for the empirical central claim. Even if the independence assumption is imperfect, the method could still work because AST-selected blocks are often reasonably self-contained and the empirical gains might be robust to that assumption. The missing controls are more direct: the paper never separates the effect of having more or different training examples from the effect of the DPO-on-middle loss. The 'w/ DPO (Data Equal)' ablation is described as equalizing total samples via extra epochs, but increasing epochs over a fixed 5,000-problem DPO set does not reproduce StructureCoder's expanded pair diversity; the resulting HumanEval drop to 66.5 is consistent with overfitting, not with data equality. A plain SFT control is absent, so the improvement over DPO could come from additional FIM-style supervised exposure to golden code blocks rather than from preference optimization. The paper deserves credit for multiple model sizes, benchmarks, significance markers, and several honest ablations, and there is no basis for questioning the integrity of the results. However, the central claim about the DPO formulation requires the two proposed controls to be tested. This concern supports keeping the reader's CONDITIONAL verdict rather than changing it.","tokens_in":20510,"tokens_out":8093,"duration_ms":80777,"concrete_test":"On Qwen2.5-Coder-1.5B-Instruct, run two ablations with the exact StructureCoder data-generation pipeline. (a) SFT-only: replace the DPO loss with cross-entropy on the preferred middle completions g+ only, keeping FIM/chat format mixing (alpha=0.5), curriculum sorting, 3 epochs, and all other hyperparameters identical; report pass@1 on HumanEval+, MBPP+, LiveCodeBench, and BigCodeBench. (b) Data-matched DPO: build a standard full-response DPO dataset from the same APPS training cases by sampling enough responses so the number of distinct preference pairs matches StructureCoder's total, then train DPO for 3 epochs and report the same metrics. If either ablation matches StructureCoder within noise, the FIM-DPO loss formulation is not the driver; if both are clearly worse, the central claim is supported.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim is that applying DPO only to AST-selected FIM middle segments is what drives the gains, as stated in Sections 3.1 and 4.3.1. The ablations in Table 2 do not establish this for two reasons. First, there is no SFT-only baseline: training on the preferred middle completions with plain cross-entropy, using the same FIM/chat formats, curriculum, and epochs, would test whether the preference contrast is needed at all. If SFT-only matches StructureCoder, the improvement is FIM data augmentation, not DPO alignment. Second, the 'w/ DPO (Data Equal)' row is not data-equal: it trains more epochs over the same original full-response DPO pairs, whereas StructureCoder creates multiple distinct FIM pairs per problem (5 completions per block, with several AST blocks per solution). More epochs over a small fixed set is not equivalent to having more diverse pairs; the drop to 66.5 on HumanEval is consistent with overfitting rather than a valid data-quantity control. The larger, more diverse pair count alone could explain the reported 1.5 to 1.6 point gains. This matters because the title and abstract credit the DPO-on-middle loss formulation as the source of improvement; if the effect is simply more FIM training data, the central claim is unsupported even though the method may still improve pass@1.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes StructureCoder, a DPO-based alignment method for code LLMs. The method parses golden solutions into an AST, extracts blocks (if/for/while/function), uses fill-in-the-middle prompts to generate several completions for each block, verifies full reconstructed programs against test cases, and constructs preference pairs between a correct and an incorrect middle completion. The DPO loss is applied only to the middle segment, with the training data randomly presented in either a FIM format or a chat format, and the samples are ordered by snippet length as a curriculum. Experiments on Qwen2.5-Coder-Instruct 1.5B/3B/7B report pass@1 gains over standard DPO, KTO, and Focused-DPO on HumanEval(+), MBPP(+), APPS, LiveCodeBench, and BigCodeBench, with average improvements of 1.5 to 1.6 points over DPO.","tokens_in":20774,"tokens_out":5156,"duration_ms":44708,"significance":"If the central claim holds, the paper offers a data-efficient way to improve code generation alignment without generating synthetic test cases, by re-using a small verified dataset to create many fine-grained preference pairs. The evaluation uses held-out benchmarks that are separate from the APPS training set, and the authors state that code and data will be released, which are strengths. However, the attribution of the gains to the FIM-DPO loss formulation rather than to the increased diversity of FIM-style training examples is not yet established, because the ablation suite lacks an SFT-only control and the reported data-equal control is not actually data-equal.","major_comments":[{"comment":"The ablation suite does not include an SFT-only baseline trained on the preferred middle completions with the same FIM/chat formats, curriculum, and epoch count. Such a control would test whether the DPO preference contrast contributes at all, as opposed to the gains arising from the larger and more diverse set of FIM-style training examples. Without it, the central claim that the FIM-DPO loss formulation drives the improvement is not established.","section":"§4.3.1, Table 2"},{"comment":"The 'Data Equal' control is not data-equal. It trains additional epochs over the same original full-response DPO pairs, whereas StructureCoder creates multiple distinct FIM pairs per problem (five completions per AST block, several blocks per solution). Increasing epochs over a fixed small set cannot reproduce the diversity of distinct pairs; the sharp drop to 66.5 on HumanEval is consistent with overfitting rather than with a controlled comparison of data quantity. A proper control should match the number of distinct training pairs, for example by using the same FIM-generated pairs with a cross-entropy loss on the preferred completions.","section":"§4.3.1, Table 2 (w/ DPO (Data Equal))"},{"comment":"The theoretical motivation rests on the assertion that 'a prior error is unrelated to the rest segment.' This is too strong: in real code, an error in an earlier block can change control flow, variable definitions, or function behavior, so the correct suffix may depend on the erroneous block. The derivation in §2.3 assumes the suffix is identical and independent in the preferred and dispreferred responses. The authors should either weaken the theoretical claim or test the assumption directly, for example by constructing preference pairs where the correct suffix changes when the middle is erroneous and measuring whether excluding suffix loss still helps.","section":"§2.3"},{"comment":"The significance markers (*, †, ‡) are not accompanied by any description of the statistical test, number of independent runs, variance, or error bars. Given that the reported average gains over DPO are 1.5 to 1.6 pass@1 points, the paper should report at least the variance across seeds or bootstrap confidence intervals and specify the test used for the 0.05 level.","section":"§4.2, Table 1"}],"minor_comments":[{"comment":"The curriculum is described as ordering by 'depth of the target block' in the introduction but by 'number of lines' in §3.3 and Algorithm 1; please unify the description.","section":"§3.3 and Introduction"},{"comment":"The sentence 'w/o suf remove suffix in the whole pipeline, a.k.a.,, we only use...' contains a typo and should be rewritten.","section":"Table 2, w/o suf row"},{"comment":"The phrase 'we omit the previous function' should be 'we omit the preceding function.'","section":"Figure 5 caption"},{"comment":"The ethics statement cites 'Li et al., 2023' as the source for Qwen2.5-Coder; Qwen2.5-Coder is from Hui et al., 2024, while Li et al. 2023 is StarCoder, so the citation should be corrected.","section":"Ethics Statement"},{"comment":"The batch size and max sequence length are given, but the number of preference pairs retained after test-case filtering is not reported; reporting this number would aid reproducibility.","section":"§4.1"},{"comment":"The heading 'FIM Evaluaion' should be 'FIM Evaluation.'","section":"Appendix C.1"}],"recommendation":"major_revision","confidential_remarks":"The main issue is the missing SFT-only control and the invalid data-equal control; these are fixable with additional experiments. If the authors can show that the DPO contrast matters beyond FIM data augmentation and provide statistical details, the paper could be acceptable. The paper fits the journal's scope, and the planned code/data release is a strength."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Needed to know: this is the first paper I've seen that pairs fill-in-the-middle with DPO for code alignment, using AST block segmentation to turn each solution into multiple preference pairs and curriculum ordering by block length. That's a real idea. Focused-DPO (concurrent) only handles common prefixes/suffixes; it doesn't generate FIM-style middle completions. The experiments are broad: three Qwen2.5-Coder sizes, five benchmark families, and ablations for each component. The gains over standard DPO are modest but consistent, around 1.5-1.6 pass@1 points average. The loss-on-suffix analysis is interesting and the LiveCodeBench result (w/ suf loss drops to 7.4 vs 10.8 for StructureCoder) is at least suggestive.\n\nThe main soft spot is the one the stress-test flags: no SFT-only baseline. Training on the preferred middle completions with cross-entropy, using the same FIM/chat formats and curriculum, would tell you whether the preference contrast is doing anything at all. The 'Data Equal' control doesn't answer it—it adds epochs over the same fixed DPO pairs, while StructureCoder creates many distinct FIM pairs per problem. So the improvement could be mostly FIM data augmentation, not the DPO-on-middle loss. That's a legit attribution gap, not a fatal one; the method still works, but the title's claim that the loss formulation is the driver is not pinned down.\n\nOther issues, in decreasing importance: the significance markers (∗, †, ‡) claim level 0.05 but no test or variance is reported; PLUM and CodeDPO are cited but not compared, which is awkward given they're the closest DPO-for-code baselines; the code/data link has no commit hash. The Section 2.3 independence assumption ('a prior error is unrelated to the rest segment') is overstated—later code often depends on earlier blocks—but the empirical results partly buffer this.\n\nBottom line: solid, honest empirical work with a real novel component, and the limitations are stated. It deserves serious reviewing. I'd ask the authors for an SFT-only control, a proper data-matched comparison (same number of distinct pairs), and error bars before accepting. The paper is conditionally acceptable, not desk-rejectable.","headline":"A genuinely novel FIM+DPO recipe for code alignment with consistent modest gains, but the attribution of gains to the loss formulation is not fully isolated because the key control is missing.","tokens_in":21341,"tokens_out":4721,"would_cite":true,"duration_ms":40260,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"StructureCoder aligns code LLMs by applying DPO only to the filled-in middle of AST-split blocks, beating standard DPO by 1.5–1.6 pass@1 points.","keywords":["StructureCoder","fill-in-the-middle","direct preference optimization","code generation alignment","abstract syntax tree","curriculum learning","pass@1","code LLM"],"falsifier":"Build a controlled dataset of preference pairs in which the earlier block defines or changes a variable the suffix uses, so the correct suffix differs between a good and a bad earlier block, then train with suffix loss included versus excluded; if including the suffix helps on those pairs, the independence premise fails and the claimed benefit of excluding suffix loss is not general.","tokens_in":20287,"feed_emoji":"🧩","tokens_out":5532,"duration_ms":45606,"temperature":0.7,"pith_summary":"StructureCoder is a data-efficient alignment method for code LLMs. It claims that applying direct preference optimization (DPO) to entire generated programs wastes most of the training signal, because correct and incorrect programs differ in only a few lines and the DPO loss penalises correct suffix tokens that follow an earlier mistake. The paper's solution is to split a reference solution into blocks at Abstract Syntax Tree (AST) boundaries, use the fill-in-the-middle capability to complete one block at a time, verify each completion against test cases, and train DPO only on the generated middle block. On HumanEval (+), MBPP (+), APPS, LiveCodeBench, and BigCodeBench, the paper reports average pass@1 gains of 1.5 to 1.6 points over standard DPO across Qwen2.5-Coder 1.5B, 3B, and 7B. A sympathetic reader would care because the method makes scarce, test-case-verified data go further than whole-program DPO does.","feed_headline":"Training on filled-in code blocks beats standard DPO by 1.5 points","feed_subtitle":"Splitting solutions into AST blocks creates finer, verifiable preference pairs; gains hold across 1.5B, 3B, and 7B code models.","key_machinery":"The central mechanism is FIM-enhanced DPO with AST block segmentation. Fill-in-the-middle (FIM) rearranges code as (pre, suf, mid) so the model predicts a missing middle given both surrounding context; the paper exploits this to control which tokens enter the DPO loss, keeping only the middle block. The AST segmentation restricts targets to four syntactic node types—if, for, while, and function definitions—so each middle segment is syntactically whole and independent. This machinery converts one test-case-verified solution into many verifiable preference pairs, which is what makes the limited APPS training set more usable.","core_discovery":"The paper establishes that the DPO loss decomposes into a middle-segment term and a suffix term when the preferred and dispreferred responses share the same prefix and suffix. It argues the suffix term is not just uninformative but actively harmful: a prior error is unrelated to the rest segment, so requiring the model to reduce probability of the suffix given an incorrect middle wrongly penalises correct tokens. StructureCoder therefore uses the fill-in-the-middle format—prefix and suffix as context, middle as the response—and restricts the DPO loss to the middle segment. To choose good middle segments, it parses the reference solution into an AST and targets only if, for, while, and function blocks; completions are verified against test cases, matched into preferred/dispreferred pairs by edit distance, and trained with a curriculum that orders blocks from short to long. The paper reports that this consistently outperforms standard DPO and KTO across all tested model sizes, with average gains of 1.5 to 1.6 pass@1 points over DPO.","pith_inferences":["If the suffix-independence premise generalises, the same trick could apply to any verifiable stepwise task where later steps are insensitive to earlier errors, not just code; the paper itself does not test this.","AST block selection is likely not the only viable segmentation; a testable extension is whether random blocks with equal structural diversity close the gap, which would separate segmentation from loss formulation.","The method's dependence on strong FIM capability implies that models without FIM pretraining may need FIM fine-tuning first; comparing FIM-strong and FIM-weak bases would bound the method's applicability.","Because the best variant on HumanEval used no curriculum, the curriculum may help hardest benchmarks but slightly hurt distributionally different ones; tuning curriculum by target distribution is an unexplored lever."],"forward_implications":["Restricting the DPO loss to the filled-in middle avoids rewarding or punishing the shared prefix and suffix, so correct tokens in unchanged code are not driven down.","One reference solution with test cases yields many distinct preference pairs, one per AST block, making DPO effective on the 5,000-sample APPS training set without generating extra test cases.","Curriculum ordering by block length lets the model learn token-level rewards on simpler blocks first, and the ablations attribute part of the final pass@1 gain to this ordering.","The gains replicate across model sizes (1.5B, 3B, 7B) and across benchmarks of varying difficulty, including LiveCodeBench and BigCodeBench.","Because training happens on middle completions, the model's fill-in-the-middle ability also improves, as measured by the appendix's FIM evaluation."],"supporting_citations":[{"why":"Supplies the fill-in-the-middle formulation used to construct middle-block training and inference.","marker":"Bavarian et al., 2022"},{"why":"Supplies the DPO objective that StructureCoder modifies by restricting the loss to the middle segment.","marker":"Rafailov et al., 2023"},{"why":"Provides the token-level reward interpretation of DPO that motivates the suffix-loss critique.","marker":"Rafailov et al., 2024"},{"why":"Supplies the APPS training set with test cases, the limited data source the method aims to use efficiently.","marker":"Hendrycks et al., 2021"},{"why":"Supplies the Qwen2.5-Coder base models on which all experiments are run.","marker":"Hui et al., 2024"},{"why":"Inspires the AST-based structure-aware segmentation used to choose coherent middle blocks.","marker":"Gong et al., 2024"},{"why":"Focused-DPO is the concurrent baseline that also targets common prefixes and suffixes, which StructureCoder is compared against.","marker":"Zhang et al., 2025"},{"why":"Supplies the HumanEval benchmark used in the evaluation of pass@1 accuracy.","marker":"Chen et al., 2021"}],"fun_headline_variants":["DPO on AST blocks with FIM improves code generation","Fill-in-the-middle DPO: better code generation from AST splits","Training on code middles with DPO beats standard DPO","AST-based DPO with FIM yields 1.5-point code gains"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that an error in one earlier code block is unrelated to the rest of the program, so the correct suffix does not depend on the mistaken block; if earlier bugs change what later code should be, dropping the suffix from the DPO loss throws away real signal.","fun_headline_variants_meta":{"raw":{"variants":["DPO on AST blocks with FIM improves code generation","Fill-in-the-middle DPO: better code generation from AST splits","Training on code middles with DPO beats standard DPO","AST-based DPO with FIM yields 1.5-point code gains"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000213,"raw_usage":{"total_tokens":1409,"prompt_tokens":922,"completion_tokens":487,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":538,"completion_tokens_details":{"reasoning_tokens":413}},"tokens_in":538,"tokens_out":487,"duration_ms":4941,"temperature":1.0,"reasoning_tokens":413,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T16:50:00.406868+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Build a controlled dataset of preference pairs in which the earlier block defines or changes a variable the suffix uses, so the correct suffix differs between a good and a bad earlier block, then train with suffix loss included versus excluded; if including the suffix helps on those pairs, the independence premise fails and the claimed benefit of excluding suffix loss is not general.","supporting_citations":[],"review_version":2}