AiXapply: Fast and Reliable Full-File Code Integration with Specialized Small Models for IDE Workflows

AiXapply: Fast and Reliable Full-File Code Integration with Specialized Small Models for IDE Workflows Siyuan Jiang∗‡ , Xiang Cai∗‡ , Peixu Wang† , Yu Han∗ , Yihong Dong† , Wei Ning∗ , Xuyuan Guo† , Jincheng Wen† , Dexin Liu∗ , Wei Zhao† , Ge Li†§ ∗ aiXcoder

† Peking University

arXiv:2611.07634v1 [cs.SE] 5 Nov 2026

{jiangsiyuan,caixiang,hangyu,ningwei}@aixcoder.com, ldx@aixcoder.com peixu.wang@u.nus.edu, dongyh@stu.pku.edu.cn, xyguo25@stu.pku.edu.cn 3116127286@qq.com, {zhaowei,lige}@pku.edu.cn

Abstract—Large language models increasingly assist developers by proposing small code edits, yet reliably integrating a partial update snippet into an existing file while preserving unrelated content remains poorly supported by current codegeneration workflows. We formalize the Code Integration (Apply) task as follows: given an original file and an update snippet, the system must produce the complete merged file while preserving all content outside the requested edit. We construct a highquality multi-language dataset from real commits via a structured pipeline that converts code changes into update snippets paired with full-file ground truth and enforces consistency through verification and filtering. We then train a specialized 4B model, aiXapply, using supervised fine-tuning and reinforcement learning (GRPO). The supervised variant achieves 94.4% accuracy under our language-aware comparison, surpassing a strong largemodel (Deepseek-V3.2) baseline (91.6%). Speculative decoding enables aiXapply-RL to reach ∼2700 tokens/s on a single A100 in a decoding subset; on the full benchmark, it achieves roughly 75× lower latency than the API-served Deepseek-V3.2 baseline. We further conduct an industrial deployment of aiXapply-RL in the aiXcoder IDE plugin as a dedicated Apply service, reducing mean Apply latency from 50 seconds to 1.89 seconds by offloading full-file generation from the upstream large model. Under timebased capacity planning, replacing one of five upstream serving instances would save 20% of upstream machine cost before the additional shared A100 service cost. Overall, our results demonstrate that treating code integration as a standalone task enables small models to achieve high accuracy, practical efficiency, and concrete industrial benefits in real-world IDE workflows where latency, cost and privacy are critical. Index Terms—Code Integration, Large Language Model, Reinforcement Learning

I. I NTRODUCTION AI-assisted IDE workflows often generate localized update snippets that must be merged into a source file while preserving unrelated content. In aiXcoder, using the upstream model for full-file Apply took 50 seconds on average within an approximately 240-second editing workflow. We isolate Project repository: https://github.com/aixcoder-plugin/aiXapply-4B. ‡ These authors contributed equally to this work. § Ge Li is the corresponding author.

Fig. 1. Accuracy–latency comparison across three code integration paradigms. Bars show equivalence accuracy for different models, while the line indicates average latency (seconds). For DeepSeek-V3.2, moving from unified diff to search-and-replace and then to full-file Apply consistently improves accuracy (0.560 → 0.749 → 0.916), but also increases latency (14.22s → 28.48s → 108.96s). Across models, full-file Apply achieves the highest accuracy, with Qwen3.5-397B reaching 0.948. Our aiXapplyRL maintains comparable accuracy (0.938) while reducing latency to 1.45s, demonstrating a significantly better accuracy–latency trade-off for one-shot code integration.

this integration stage as the Apply task and offload it to a specialized small model. Unified diff represents edits through hunk headers, line-level changes, and surrounding context. Small errors in headers or context alignment can make a generated patch non-applicable. Search-and-replace avoids diff syntax but requires the intended source fragment to be identified. Unmatched or ambiguous fragments can cause failure, so it is commonly used with iterative retries rather than for one-shot integration. Full-file Apply generates the complete updated file directly, avoiding intermediate representations. However, regenerating unchanged content with a large model incurs substantial latency and token cost. This gap motivates a different perspective. Rather than treating editing as a byproduct of general code generation, we formulate snippet integration as a dedicated software

Fig. 2. Workflow of aiXapply in VS Code. A user submits an editing request through Continue, the LLM then generates an update snippet, which aiXapply applies to the source file to produce a candidate updated file. VS Code displays the resulting diff for user inspection, after which the user decides whether to accept or reject the proposed edit.

engineering task: given a source file and an update snippet, produce the merged file with zero unintended changes outside the target region. This formulation is precise, verifiable, and directly aligned with IDE requirements. In this workflow, the upstream model specifies the intended change as a snippet, while a dedicated Apply model handles full-file reproduction. This offloads the copying of unchanged content from the large model to a smaller model, whose copy-dominant workload can be accelerated with speculative decoding. Our goal is to retain the accuracy of full-file Apply while making it efficient enough for deployment. We study this problem through four research questions. RQ1: What are the advantages and limitations of full-file Apply compared to unified diff and search-and-replace? RQ2: Can a small model achieve high accuracy and robustness on the Apply task across diverse languages and out-of-distribution scenarios? RQ3: Can full-file Apply be made efficient for realistic IDE scenarios? RQ4: What training strategies are effective for the Apply task? We compare the three integration paradigms, train 4B SFT and RL variants on commit-derived data, and evaluate accuracy, robustness, and decoding efficiency across 20 languages. We also report the aiXcoder deployment and its manual Apply assessment on real development tasks. Figure 1 summarizes the accuracy–latency trade-off. Our contributions are: Industrial deployment and practical evidence: We integrate a dedicated Apply service into aiXcoder, report its latency reduction, and evaluate first-output Apply acceptability on 100 real development tasks (91 acceptable with aiXapply-RL versus 88 with GLM-5). • A systematic evaluation of code integration paradigms: We compare full-file Apply with searchand-replace and unified diff across accuracy, efficiency,

•

and generalization benchmarks, and analyze SFT/RL trade-offs across languages and challenging settings. • An accurate and efficient small model: We provide aiXapply, a specialized 4B model trained with supervised fine-tuning and reinforcement learning, achieving high equivalence accuracy while enabling fast inference with speculative decoding. • A high-quality dataset for code Apply: We provide a multi-language dataset from real-world commits via a structured pipeline that converts code changes into update snippets paired with full-file ground truth, with strict verification to ensure correctness and reproducibility. II. R ELATED W ORK Large language models have been widely applied to code editing tasks conditioned on natural language instructions or surrounding context [1]–[3]. Benchmarks such as CodeEditorBench [4] and EDIT-Bench [5] evaluate how well models follow editing instructions. Unlike these efforts, our work assumes an update snippet has already been provided and focuses on the downstream integration step: faithfully merging that snippet into the original file while preserving all unchanged content. This shifts the emphasis from creative generation to deterministic, low-latency integration with zero side effects. The choice of edit representation critically affects reliability. Unified diffs [6] are precise but brittle; search-and-replace formats [7] depend on source-fragment matching. Industrial tools like Aider [8] and Cursor’s Instant Apply [9] have adopted various strategies and even trained specialized apply models. Most related to our work is FuseApplyBench [10], which benchmarks trustworthy code edit applying, and the FastApply pipeline [7]. Diff-XYZ [11] evaluates diff understanding. Our contribution is an open 4B implementation, a commit-derived dataset, and empirical evidence on editing representations, training trade-offs, and enterprise deployment.

Learning from version control history is a long-standing approach. CommitPack [12] provides large-scale real-world commits; CodeEditor [13] and Coeditor [14] learn edit patterns from diffs. However, these methods focus on generating the edit itself, whereas we tackle the distinct problem of integration. Furthermore, end-to-end software engineering agents (e.g., SWE-bench [15], SWE-agent [16], Agentless [17]) address the full pipeline from issue localization to patch generation. Our work complements them by isolating and optimizing the final, often brittle, apply step—a necessary component for any agent that must operate safely in an IDE. Finally, efficient inference is crucial for interactive use. Speculative decoding [18], [19] accelerates general generation, while methods such as REST [20] and Medusa [21] further improve decoding efficiency. More recently, EfficientEdit [22] leverages the copy-dominant nature of code editing to accelerate editing-specific workloads. In contrast, our work focuses on the full-file Apply setting, where most tokens are preserved from the source file, and explores lightweight proposal strategies tailored to this structured editing scenario. III. DATA C ONSTRUCTION We construct training examples for the Apply task, where each example is a triple <source_file, update_snippet, update_file> that satisfies a strong causality requirement: the full update must be recoverable from the snippet alone. To do so, we start from real-world commits and convert them into Apply-style examples through a multi-stage pipeline. The pipeline is designed to preserve realistic edit intent while filtering out ambiguous, low-quality, or non-reproducible samples. A. Task Definition a) Formalization: We define the Apply task as follows. Given: x = (L, S, U ), where L is the programming language or file type, S is the original full file, and U is an update snippet, the goal is to produce: Y = S′, the updated full file. We adopt a structured I/O format to reduce ambiguity: • Input: <language>{L}</language> <source_file>{S}</source_file> <update_snippet>{U}</update_snippet> • Output: <update_file>{S’}</update_file> b) Core constraints: The task has two target constraints: ′ • Non-side-effect constraint: Outside the patch region, S must be identical to S at the lexical level (including comments, ordering). • Deterministic full-file output: The model must output a complete file that can be directly written back to disk, without omissions or explanatory text.

Fig. 3. Overview of the dataset construction pipeline. Starting from 57.7M raw commits in CommitPack, rule-based sampling produces 24,460 candidate samples. Consistency verification removes 12.1% of samples, followed by solvability filtering that removes an additional 2.4%, resulting in 20,984 highquality examples. The final dataset is split into 19,347 training samples and 1,637 test samples.

c) Update snippet semantics: The update snippet U is a partial view of the modified code, with the following semantics: • Placeholders: Tokens such as // ... existing code ... indicate that the corresponding content must be copied exactly from S into S ′ , and must not appear in the final output. • Deletion: Deletions can be expressed implicitly by omitting blocks or via explicit markers (e.g., // remove ...). • Anchor uniqueness: Context anchors extracted from U must match a unique location in S. If no unique match exists, the model should fail safely. d) Decomposition of correctness: We decompose Apply into three verifiable steps: 1) Context Matching: Locate a unique region in S using anchors from U ; 2) Code Merging: Replace the corresponding region with updated content from U ; 3) Expansion: Resolve placeholders by copying exact content from S. B. Dataset pipeline To construct training data that satisfies the task constraints, we design a multi-stage pipeline that converts raw commits into well-formed Apply examples. Starting from real-world version control data, the pipeline progressively refines each sample by making edit intent explicit, enforcing locality and determinism, and filtering out ambiguous or non-reproducible cases. Figure 3 illustrates the overall data flow and sample reduction across stages. 1) Source Data and Sampling: We use the CommitPack dataset from HuggingFace as the data source, which provides real-world code edits extracted from version control histories. Each record contains the file content before and after a commit (old_contents, new_contents) along with commit metadata, enabling direct supervision of code changes at the file level. To align the data with the snippet integration task, we apply rule-based filtering and sampling. We focus on single-file edits

and control file length, edit size, and line-change ratio to ensure localized modifications. We also filter commits based on basic quality criteria (e.g., commit message length) and perform language-balanced sampling to ensure broad coverage across programming languages and structured file types. After this stage, the dataset is reduced from 57.7M raw commits to 24,460 high-quality candidate samples. 2) From Commit to Explicit Change Description: A raw commit provides before/after code and a short commit message, but this is not yet an Apply example. In the first generation stage, we use an LLM to convert each commit into an explicit change_description. The input includes the language, original code, changed code, and commit message, and the output is a concise description of what changed, where it changed, and how the change should be interpreted. This stage serves two purposes. First, it makes the edit intent more explicit than a short commit message. Second, it simulates the upstream setting in which another model or developer has already identified the desired modification before the Apply model is invoked. The description is treated as an intermediate specification rather than final supervision. 3) Synthesizing the Update Snippet and Ground Truth: Given the original file and the generated description, we use a second LLM stage to produce a training pair: an update_snippet and the corresponding full final_code. The update_snippet is a localized code fragment centered on the modified region. It contains updated code near the change location, while unchanged content outside the region is replaced with placeholders such as // ... existing code .... These placeholders preserve sufficient context for locating the correct position in the original file. For deletions, the snippet retains surrounding code and omits the removed block. The final_code is the complete ground-truth file obtained by applying the snippet semantics to the original file. It must contain the entire file with no placeholders and reflect only the intended change. Unchanged regions must remain identical at the lexical level, including formatting and comments. This stage converts commit-level supervision into the exact input-output format required by the Apply task: a localized snippet paired with its deterministic full-file result. The editing intent is grounded in real commits; synthesis emulates the partial-update snippets produced by upstream coding models. The target is the full file obtained by applying the generated snippet, not necessarily the original commit’s after-file. Consistency verification checks that the snippet explains the resulting file changes. 4) Consistency Verification: A generated snippet is useful only if it fully explains the resulting file change. We therefore introduce a verification stage that checks whether the pair (update_snippet, final_code) is causally consistent with the original file. The LLM-based verifier receives the original code, the final code, the deterministic diff between them, and the snippet, and judges whether the diff can be

explained completely and only by the snippet. Samples that fail this check are discarded. This stage checks for strict causality: every change in the diff must be supported by the snippet, and the snippet must not imply additional changes. Placeholders are treated as keep-original directives rather than free-form omissions. This step removes 2,960 samples (12.1%), resulting in 21,500 consistency-verified examples. 5) Solvability Filtering: After consistency verification, we further filter examples based on solvability. For each sample, Qwen3.5-397B-A17B, DeepSeek-V3.2, and GLM-5 each perform the Apply task twice, giving six attempts from (source_file, update_snippet). Each predicted full file is compared with the ground truth using token-level equivalence. The failure-count distribution showed a sharp drop in the number of samples with five or six failures. Manual spot checks found data-quality problems in most inspected samples from these groups, so we discard samples that fail five or all six attempts. This step removes 516 samples (2.4%), yielding 20,984 retained examples. This model-dependent filter may also exclude valid but difficult edits, biasing the retained samples toward cases that these models can solve; it does not require every model or attempt to succeed. Finally, the dataset is randomly split at the commit level into 19,347 training samples and 1,637 test samples, forming a high-quality benchmark for the Apply task. C. Error Taxonomy To support diagnosis and training, we categorize failures into six types: OUTPUT_INVALID: Invalid format (e.g., missing wrapper, truncation, placeholder leakage, or unparsable structure). • PATCH_NOT_APPLIED: No effective change applied. • PATCH_INCOMPLETE: Partial update with missing lines or blocks. • PATCH_INCORRECT: Incorrect modification within the patch region. • WRONG_POSITION: Correct content applied to the wrong location. • OUT_OF_PATCH_SIDE_EFFECT: Unintended modifications outside the patch region. •

This taxonomy captures both hard failures (non-writable outputs) and semantic errors (misplacement, incompleteness, side effects), enabling fine-grained analysis and alignment. IV. M ETHOD We study full-file Apply as a deterministic code integration task and explore two training paradigms: supervised finetuning and reinforcement learning. Both approaches are trained independently. At inference time, we further improve efficiency using speculative decoding.

A. Model and Prompting We conduct training on the Qwen3-4B [23] model with a maximum context length of 64k. The model is trained as a deterministic patching engine: given an original file and an update snippet, it directly generates the final merged file. Each input consists of: (1) the original file (old_contents), and (2) the update snippet (update_snippet). The prompt instructs the model to apply the snippet to the original file. B. Supervised Fine-tuning The SFT model is trained with standard next-token crossentropy over the complete target file. Supervising unchanged regions encourages identity copying and discourages unintended modifications. The released SFT configuration (artifact revision 24c4e3) defaults to a learning rate of 10−5 , a perdevice batch size of 1, 64 gradient-accumulation steps, and two epochs. For long-context training, we concatenate the structured input (source_file, update_snippet) with the target update_file and truncate sequences to the maximum length (32k tokens for the concatenated sequence in the released SFT configuration). No partial loss masking is applied on the output, ensuring that every generated token contributes to the training signal. C. Reinforcement Learning We train a separate model using Group Relative Policy Optimization (GRPO) [24]. For each input, sampled outputs are scored using the rewards below, and group-normalized advantages drive a clipped policy objective with KL regularization to a reference policy. This allows task-level penalties for incomplete edits and side effects without a separate value function. The released GRPO configuration defaults to a learning rate of 5 × 10−7 , a training batch of 128 prompts, eight rollouts per prompt, a KL-loss coefficient of 0.01, and three epochs. D. Reward Design We design a reward function that directly reflects the core requirement of the Apply task: exact integration with zero unintended side effects. Unlike general code generation, Apply admits a deterministic notion of correctness—namely, whether the generated full file is equivalent to the ground truth under a precise lexical or structural criterion. a) Equivalence-Based Reward.: Given a model prediction ŷ and ground truth y, we define a binary reward: ( 1, if ŷ ≡ y r(ŷ, y) = (1) 0, otherwise The equivalence relation ≡ is implemented via a languageaware comparison: • Code files: We apply token-level equivalence using lexical analysis (Pygments). Both ŷ and y are tokenized, ignoring whitespace-only tokens, and compared for exact match at the token sequence level.

Structured formats (e.g., JSON, YAML, XML): We parse both outputs into canonical structures and compare their semantic representations. • Text-like formats (e.g., Markdown, SQL): We apply the format-specific normalization in the released evaluator before exact string comparison. This design tolerates formatting differences while requiring exact agreement under the above language-aware comparison rules. b) Error-Aware Dense Reward.: While the binary reward provides a clear correctness signal, it is sparse and does not distinguish between different failure modes. To provide more informative feedback, we introduce a dense reward that explicitly accounts for error types. Given a prediction that is not equivalent to the ground truth, we analyze two types of errors: (1) patch errors, defined as the number of incorrect lines within the target modification region, and (2) side effects, defined as the number of unintended modified lines outside the target region. The reward is defined as: •

r(ŷ, y) = max (0, 1 − α · patch_errors − β · side_effects) , (2) where α = 0.25 and β = 0.35 in the dense reward used by the released and deployed RL model, with a larger penalty assigned to side effects. This design emphasizes a key principle of the Apply task: errors outside the target region are more harmful than imperfect edits within the patch. By distinguishing error types and measuring them at the line level, the reward provides finergrained guidance and encourages models to produce correct edits while preserving unchanged regions. E. Speculative Decoding Full-file Apply is copy-dominant. We use speculative decoding to propose token blocks and verify them in parallel [18], comparing the following model-free proposal mechanisms. N-gram-based. We first employ an n-gram prompt-lookup strategy as a lightweight proposal mechanism. An n-gram dictionary is constructed from the prompt and previously generated tokens, mapping fixed-length suffixes to observed continuations. At each decoding step, the current suffix is used to retrieve candidate continuations, which are merged into a prefix tree and verified in a single forward pass. This approach is efficient and works well when local token patterns repeat frequently. Suffix-based. In parallel, we employ a suffix-based, modelfree speculative mechanism that indexes previously generated token sequences in a suffix structure and, at each step, retrieves continuations by finding the longest suffix match of the current context. Longer matches imply higher confidence, so the method adaptively proposes longer candidate continuations when strong matches are found and shorter ones otherwise. These candidates are organized into a small, frequency-prioritized speculation tree and verified in a single forward pass of the target model, enabling efficient multi-token validation without relying on auxiliary draft models.

Evaluation Metrics. We report mean and P95 request latency, and throughput as generated tokens divided by total execution time. The inference-speed experiments use aiXapplyRL with a single concurrent request, measuring latency end to end for each request. V. E XPERIMENTS A. Experimental Setup 1) Task, Metrics, and Baselines: For full-file Apply, all models use the same structured input format: <language> + <source file> + <update snippet> -> <updated file>. The target output is always the full merged file. For RQ1, search-and-replace edits are executed by the OpenCode-style tool, including its whitespace- and indentation-tolerant matching, and unified diffs by our custom executor. Both implementations are released with our artifact. All three paradigms use the same language-aware correctness comparison on the resulting full file. Equivalence accuracy (Avg/Overall) is total correct predictions divided by total samples; code files use Pygments-token equivalence, while structured and text-like formats use parsing when appropriate. An output is counted as correct when it matches the reference under the rules in Section IV-D, rather than requiring bytefor-byte equality. Normalization can hide meaningful changes, and behavior-preserving rewrites may fail the comparison. We compare against: (1) Qwen3-4B (4B base model), (2) DeepSeek-V3.2 (strong large-model baseline [25]), (3) Qwen3.5-397B-A17B (strong large-model baseline [26]), (4) GLM-5 (strong large-model baseline [27]), (5) Fast-Apply7B (a recent code apply model baseline [7]), (6) aiXapplySFT (our supervised model), (7) aiXapply-RL (our RL-aligned model) . 2) Datasets: The main aiXapply test set contains 1,637 examples covering 20 languages / file types. The groups are Java and JavaScript (200 each), Python (195), C (130), C++ (128), Go (80), and JSON (54), with 50 examples in each of the remaining 13 languages / file types. To evaluate robustness, we construct additional generalization dataset which include Long Context, Random Placeholders, Chunk File, and Untrained Languages covering PHP, CSS, SystemVerilog, and CSharp. The Long Context and Untrained Languages sets contain 51 and 647 examples, respectively. We also report transfer results on Diff-XYZ [11]. B. RQ1: Advantages and Limitations of Full-File Apply We first compare three code integration paradigms: unified diff, search-and-replace, and full-file Apply. Table I shows that full-file Apply consistently achieves the highest accuracy. On DeepSeek-v3.2, accuracy improves from 0.560 (diff) and 0.749 (search-replace) to 0.916 (Apply), a gain of 16.7 percentage points over search-and-replace. This trend is consistent across all models, indicating that the advantage mainly comes from the representation rather than model scale. The weakness of unified diff may lie in structural brittleness. Our qualitative analysis identified malformed diff headers and incorrect hunk line numbers or line counts among the observed

failures. Its strict format requirements make it sensitive to small errors in hunk headers or context alignment, which can render the entire patch invalid. These failures are largely independent of the actual edit semantics. Search-and-replace improves robustness by removing patch syntax, but it still relies on matching source fragments. Even with whitespace and indentation tolerance, unmatched or ambiguous fragments can cause replacement failure, limiting its reliability in one-shot generation. This makes it more suitable for iterative agent workflows than for deterministic integration. TABLE I OVERALL ACCURACY COMPARISON OF THREE CODE INTEGRATION PARADIGMS .

Model DeepSeek-v3.2 GLM-5 Qwen-3.5-397B

Unified diff Search-and-replace Full-file Apply 0.560 0.649 0.644

0.916 0.921 0.948

0.749 0.905 0.866

TABLE II AVERAGE OUTPUT LENGTH AND LATENCY ACROSS THE THREE PARADIGMS . Diff

Search & Replace

Apply

Model

Tokens Latency (s) Tokens Latency (s) Tokens Latency (s)

DeepSeek-v3.2 GLM-5 Qwen-3.5-397B-A17B aiXapply-RL

462 437 460 –

14.22 12.98 5.82 –

926 512 902 –

28.48 13.38 11.21 –

3684 3646 3674 3734

108.96 51.33 35.90 1.45

Full-file Apply achieves the best performance by eliminating both syntax and matching constraints. The model only needs to generate the final file, which aligns naturally with autoregressive training and leads to consistently higher accuracy. The main limitation of full-file Apply is efficiency. As shown in Table II, it requires around 3684 tokens and 108.96 seconds on DeepSeek-v3.2, compared to 462 tokens and 14.22 seconds for unified diff. This overhead comes from regenerating unchanged content. This cost is largely due to the copy-dominant nature of the task. By leveraging speculative decoding, our system reduces latency to 1.45 seconds while maintaining the same output length, showing that the efficiency gap can be largely mitigated. Overall, unified diff is compact but too brittle for direct generation. Search-and-replace improves robustness but still depends on source-fragment matching. Full-file Apply provides the highest one-shot accuracy by removing fragile intermediate representations, with higher decoding cost that can be effectively optimized in practice. C. RQ2: Effectiveness Across Languages and Generalization Table III reports the main multi-language results. Taskspecific training substantially improves a 4B model. The untrained 4B baseline achieves 0.651 average accuracy, while strong large-model baselines such as DeepSeek-V3.2, GLM5, and Qwen3.5-397B reach 0.916, 0.921, and 0.948, respectively.

TABLE III M AIN RESULTS ACCURACY ON THE AI X APPLY TEST DATASET. Model/Language

C

C++ Docker

Qwen3-4B 0.66 0.66 DeepSeek-v3.2 0.915 0.914 Qwen3.5-397B-A17B 0.946 0.977 GLM-5 0.931 0.945 Fast-Apply-7B 0.546 0.539 aiXapply-RL 0.96 0.92 aiXapply-SFT 0.93 0.945

0.68 0.94 1.00 0.96 0.74 1.00 1.00

Go

HTML INI Java

0.65 0.937 0.95 0.963 0.65 0.93 0.912

0.64 0.84 0.96 0.92 0.60 0.86 0.96

JS

JSON Make MD Python RST Rust Shell SQL Text TS XML YAML Avg

0.50 0.71 0.71 0.81 0.88 0.955 0.934 0.944 0.94 0.945 0.96 1.00 0.98 0.95 0.93 0.944 0.64 0.545 0.73 0.814 0.92 0.95 0.97 0.96 0.96 0.93 0.965 1.00

Accuracy

Qwen3-4B-Baseline DeepSeek-V3.2 aiXapply-RL aiXapply-SFT

0.2353 0.588 0.6471 0.843

TABLE V ACCURACY ON UNTRAINED PROGRAMMING LANGUAGES . Model Qwen DeepSeek aiXapply-RL aiXapply-SFT

C#

CSS

PHP

SV

Avg

0.6356 0.889 0.89 0.924

0.623 0.963 0.958 0.937

0.6409 0.927 0.936 0.946

0.6695 0.932 0.958 0.958

0.6399 0.932 0.938 0.941

Our task-specialized 4B models achieve 0.938 (aiXapplyRL) and 0.944 (aiXapply-SFT), demonstrating that a small model can close most of the gap to large models and approach state-of-the-art performance on this task. Notably, the SFT model performs competitively with the strongest baseline (0.944 vs. 0.948), while significantly outperforming both the untrained baseline and prior Apply-specific models. Across the evaluated languages, both aiXapply variants are competitive with large-model baselines under the languageaware comparison. These results support transfer within the tested settings, rather than general language independence or repository-disjoint generalization. a) Generalization: To evaluate whether the model truly learns the Apply task—rather than overfitting to a fixed prompt format—we construct four out-of-distribution (OOD) settings that stress different aspects of robustness: long-context reasoning, placeholder variability, cross-language transfer, and partial-file editing. Long Context: Inputs exceed 32k tokens. Models often fail by truncating outputs or losing global consistency. This setting tests whether the model can preserve fullfile integrity under long-context conditions. • Randomized Placeholders: We vary placeholder patterns (e.g., // ... existing code ...) into diverse formats. This evaluates whether the model relies on superficial pattern matching or truly understands structural insertion points. • Untrained Languages: We evaluate on languages not

•

0.54 0.82 0.90 0.88 0.66 0.90 0.88

0.69 0.928 0.933 0.897 0.626 0.91 0.933

0.52 0.88 0.86 0.86 0.64 0.88 0.90

0.48 0.90 0.90 0.82 0.46 0.90 0.90

0.58 0.92 0.98 0.92 0.66 0.98 0.92

0.60 0.84 0.94 0.92 0.60 0.96 0.96

0.54 0.90 0.88 0.86 0.64 1.00 0.96

0.62 0.96 0.92 0.94 0.48 0.88 0.98

0.76 0.86 1.00 0.78 0.62 0.98 0.98

0.54 0.92 0.96 0.90 0.76 0.96 0.98

0.651 0.916 0.948 0.921 0.620 0.938 0.944

included in Apply training (e.g., CSharp, CSS, PHP, SystemVerilog) to measure cross-language generalization. • Chunk File: Instead of full files, inputs are truncated to syntactic units (e.g., functions or classes) or contiguous code spans. This simulates IDE scenarios where users select a code region and apply modifications locally.

TABLE IV ACCURACY ON L ONG C ONTEXT SETTING . Model

0.62 0.92 0.98 0.98 0.56 0.92 0.94

Long-context editing is the most challenging setting among all OOD evaluations (Table IV). All models exhibit significant performance degradation, with the baseline collapsing to 0.2353, indicating severe failure in maintaining global consistency. While DeepSeek-V3.2 drops to 0.588, the RLbased model shows only limited gains (0.6471), suggesting that it struggles to preserve long-range structure. In contrast, aiXapply-SFT maintains a substantially higher accuracy (0.843), indicating stronger robustness in long-context scenarios. As shown in Table VI, both apply models are robust to placeholder variations, in some scenarios, there are even performance improvements (Deepseek V3.2-C ,C++). This indicates that the models learn structural alignment well rather than relying on fixed placeholder tokens. Results in Table V show that the aiXapply models maintain strong performance on languages not seen during training, remaining competitive with a strong large-model baseline. The performance gap between seen and unseen languages is small, indicating that the model does not rely heavily on languagespecific patterns. This suggests that the Apply task is largely language-agnostic and primarily depends on structural editing behaviors—such as locating the target region and preserving unchanged content—rather than detailed knowledge of a particular programming language. Chunk-level editing is substantially more challenging than the full-file setting. Compared with the main benchmark (Table III), all models experience a noticeable drop in accuracy (Table VI), indicating that removing global context makes localization and integration more difficult. This degradation is consistent across models, but the impact varies. The baseline drops sharply, while DeepSeek-V3.2 also shows a clear decline. In contrast, the Apply models remain relatively stable and significantly outperform the baseline. Notably, aiXapplySFT still achieves an average accuracy of 0.900, despite the reduced context. This suggests that the model has learned a robust local integration behavior, allowing it to correctly apply edits even when only partial code is available.

TABLE VI ACCURACY UNDER RANDOMIZED PLACEHOLDERS AND CHUNKED - FILE EDITING . Random Placeholder

Model C

JS

Chunk File

C++

Docker

Go

HTML

Java

JSON

Python XML

Qwen3-4B 0.6615 0.6328 DeepSeek 0.9462 0.9297 RL 0.9538 0.9375 SFT 0.939 0.945

0.76 0.98 1.00 1.00

0.675 0.975 0.925 0.913

0.60 0.90 0.90 0.980

0.715 0.68 0.7963 0.7128 0.945 0.9397 0.9259 0.9179 0.935 0.955 1.00 0.9179 0.930 0.965 1.00 0.944

0.70 0.88 0.96 0.94

TABLE VII E RROR TYPE DISTRIBUTION (%) AMONG CLASSIFIED ERRORS ACROSS STANDARD AND LONG - CONTEXT SETTINGS .

Avg

C

C++

Docker

Go

HTML

Java

0.696 0.5692 0.625 0.932 0.885 0.898 0.948 0.892 0.906 0.951 0.908 0.922

0.64 0.90 1.00 0.92

0.575 0.912 0.863 0.875

0.46 0.80 0.80 0.88

0.385 0.565 0.4815 0.6308 0.885 0.885 0.796 0.923 0.915 0.91 0.815 0.862 0.910 0.935 1.00 0.887

Long Context

Error Type

Qwen DeepSeek

SFT

RL

SFT

RL

Output Invalid Patch Not Applied Patch Incomplete Patch Incorrect Wrong Position Out-of-Patch Side Effect

12.35 8.29 12.87 4.06 5.64 56.79

3.30 8.79 30.77 9.89 5.49 41.75

4.76 0.00 9.52 0.00 27.61 0.00 11.43 12.50 10.48 0.00 36.19 87.50

0.00 0.00 6.25 0.00 6.25 87.50

10.22 5.11 18.98 8.03 3.65 54.01

b) Error Analysis.: We analyze model failures across both standard and long-context settings. Table VII summarizes the error distributions. Overall patterns. On the aix-apply test set, both SFT and RL models exhibit similar error distributions, with failures primarily concentrated in O UT O F PATCH S IDE E FFECT and PATCH I NCOMPLETE. This indicates that the core challenge of the Apply task lies in maintaining strict locality while ensuring full patch application. Effect of training paradigm. Compared to baseline models (Qwen and DeepSeek), both SFT and RL have lower shares of O UT O F PATCH S IDE E FFECT among classified errors. In particular, RL achieves the lowest share (36.19%), which does not alone establish fewer side effects or a causal effect of our error-aware reward design that explicitly penalizes unintended edits outside the target region. By assigning higher penalties to side effects, RL is encouraged to enforce strict locality and avoid out-of-patch modifications. These differences lead to distinct editing behaviors. While both SFT and RL show relatively high PATCH I NCOMPLETE shares (30.77% and 27.61%), these conditional percentages do not establish that RL produces fewer incomplete edits. RL also shows higher shares of W RONG P OSITION and PATCH I N CORRECT, suggesting a more aggressive editing strategy under ambiguous contexts. Overall, RL is designed to prioritize correct and localized edits, reflecting the optimization of error-aware rewards, whereas SFT favors stable token-level alignment with the target output. Long-context degradation. In long-context scenarios, the error distribution shifts dramatically and becomes highly concentrated, with both SFT and RL overwhelmingly dominated by O UT O F PATCH S IDE E FFECT (87.50%). This indicates that preserving strict locality is the primary challenge in large contexts. Compared to the standard setting, the differences between SFT and RL largely diminish in error composition,

JSON

Python XML 0.32 0.60 0.84 0.80

Avg 0.527 0.850 0.881 0.900

TABLE VIII K EY EFFICIENCY RESULTS ACROSS DECODING STRATEGIES . Method

Standard

JS

Baseline (no speculation) Suffix (default) N-gram (default) N-gram (best, n=7, k=128)

Avg Latency (s)

P95 (s)

Throughput (tokens/s)

28.83 5.75 2.17 1.06

90.23 20.74 6.94 3.38

102.04 509.54 1343.99 2692.01

and both models exhibit similar error patterns, suggesting that long-context editing introduces a common failure mode that dominates behavior regardless of the training paradigm. Summary: Except for very long code files, aiXapply maintains stable, high accuracy across the OOD settings (Tables IV–VI). Performance under placeholder variation and cross-language transfer indicates that the model learns structural integration patterns rather than superficial formatting. Chunk-level editing remains effective, while very long files remain a limitation, particularly for RL. D. RQ3: Efficiency and Cost A central question is whether full-file Apply—despite requiring full-file generation—can meet practical latency and cost constraints. Table VIII compares decoding strategies on 165 examples sampled by language from the main benchmark (seed=42), whereas Table II uses all 1,637 examples. Table VIII shows that speculative decoding fundamentally changes the efficiency profile of full-file Apply. Compared to the baseline (28.83s average latency), suffix decoding reduces latency to 5.75s, while n-gram further reduces it to 2.17s. The best configuration (n=7, k=128) achieves 1.06s latency and 2692.01 tokens/s throughput, corresponding to an overall ∼26× speedup over baseline. a) Why n-gram dominates.: Even under optimal tuning, suffix decoding remains significantly slower than n-gram, with a ∼2.6× gap in both latency and throughput. This difference aligns with the task structure: full-file Apply requires copying long spans from the input, and n-gram directly exploits exact substring reuse, making it better suited than suffix-based continuation heuristics. b) Absolute efficiency.: On the decoding subset, the best configuration achieves 1.06s mean latency, 3.38s P95, and 2692.01 tokens/s; the full-benchmark mean is 1.45s with 3734 output tokens per request. Together with the small model, these decoding gains support interactive deployment.

TABLE IX P ERFORMANCE ON D IFF -XYZ BENCHMARK .

Model

Overall

Java

JS

Kotlin

Python

Rust

Qwen3-4B aiXapply-SFT aiXapply-RL

0.596 0.479 0.664

0.630 0.510 0.680

0.610 0.470 0.715

0.620 0.490 0.655

0.590 0.425 0.645

0.530 0.500 0.625

Summary: RQ3 is answered affirmatively, although fullfile Apply involves longer outputs, it can be made efficient in practice through task-aligned model design and speculative decoding. The proposed approach achieves substantial reductions in latency and cost while maintaining strong performance, making full-file Apply viable for interactive use.

E. RQ4: Training Paradigm To better understand the differences between training paradigms, we further evaluate cross-format generalization on the Diff-XYZ benchmark, which requires models to apply unified diff inputs to source files. Compared with full-file Apply, this setting is more sensitive to formatting and alignment errors, since models must correctly interpret hunk headers, context lines, and line-level changes. As shown in Table IX, aiXapply-RL achieves the best performance on Diff-XYZ, outperforming both Qwen3-4B and aiXapply-SFT overall and across every language. This suggests that RL improves robustness to alternative edit representations even without explicit diff-format training, whereas SFT specializes more strongly to the full-file Apply format. This contrasts with the full-file Apply results. On the main benchmark (Table III), SFT slightly outperforms RL (0.944 vs. 0.938). The same pattern holds across Random Placeholders and Chunk File (Table VI) and Untrained Languages (Table V). The largest difference appears in Long Context (Table IV), where SFT is substantially stronger than RL (0.843 vs. 0.6471), indicating better preservation of global file structure. Overall, these results suggest different inductive biases: SFT provides stronger token-level fidelity and structural preservation within the full-file Apply paradigm, while RL offers better flexibility under distribution shifts such as diffbased editing. a) Error distribution comparison.: The error distributions in Table VII complement these results. Both models are dominated by out-of-patch side effects and incomplete edits, and both reach an 87.50% side-effect share among long-context errors. These conditional shares do not establish absolute error reductions. SFT’s token-level supervision may help preserve unchanged regions, whereas RL’s outcome-level feedback may allow greater flexibility across edit representations.

Summary: SFT and RL exhibit complementary strengths. SFT is more effective for in-distribution performance and long-context robustness, benefiting from token-level supervision and precise structural preservation. In contrast, RL demonstrates stronger cross-format generalization, suggesting better adaptability to alternative editing representations. These results indicate that the choice of training paradigm should depend on the target deployment setting, as neither approach is universally superior. VI. I NDUSTRIAL D EPLOYMENT AND L ESSONS L EARNED Deployment setup. We further deployed aiXapply in the aiXcoder [28] IDE plugin as a dedicated Apply service. In this deployment, the upstream large model first generates an update snippet, and aiXapply then produces the full updated file, which is rendered as an editor diff for user inspection before acceptance. The previous workflow used the upstream large model itself to perform full-file Apply. In contrast, aiXapply-4B-RL is served on a single A100 40GB GPU and is invoked only for the Apply stage, without replacing the main planning or code-generation model. We selected RL following internal validation that favored RL over SFT on proprietary naming conventions, code structures, and project domains; this observation is specific to the deployment setting. We reused otherwise-idle A100 capacity because the available H-series GPUs were allocated to large-model serving. Operational safeguards. Very large single files are rare in production. Training includes no-op examples, allowing the model to predict an empty edit and leave the source file unchanged. Developers can also undo Apply in the IDE and switch to the upstream model. Production latency. We compared end-to-end workflow latency before and after enabling aiXapply-RL over a oneweek window in an enterprise deployment serving 200 internal users and averaging 8,000 model API calls per hour, as recorded by the New API middleware. Timing excluded queuing and included multiple rounds of tool calls. Before deploying aiXapply, an average IDE editing task took about 240 seconds, where the Apply stage contributed 50 seconds on average and 89 seconds at P95. After offloading Apply to aiXapply, the Apply latency drops to 1.89 seconds on average and 3.78 seconds at P95, corresponding to a 26.5× reduction in mean Apply latency and a 23.5× reduction in P95 Apply latency. We cannot report a precise measured postdeployment end-to-end mean. Holding the other workflow stages fixed gives an estimated average end-to-end latency of 240 − 50 + 1.89 = 191.89 seconds. Serving capacity and cost. Offloading full-file generation motivates a capacity-planning scenario. If the estimated reduction in workflow time translates proportionally into capacity under comparable workload and utilization, five upstream 8×H200 serving instances of a 600B model could be replaced by four, plus one shared A100 40GB aiXapply service. One aiXapply instance can serve the Apply workload generated by approximately eight upstream IDE model services, so

the additional Apply cost is amortized across multiple largemodel services. In normalized machine-cost terms, this scenario changes 5C8H200 to 4C8H200 + CA100 : a 20% reduction in upstream machine cost before the A100 cost. Workflow elapsed time is not GPU service time; this scenario requires capacity validation and cost allocation, rather than establishing a measured net saving. Human evaluation in real development tasks. We evaluated the Apply module in 100 development tasks across approximately 40 internal aiXcoder projects, mainly in TypeScript, Java, and Python. Each task concerned a feature or bug fix; we evaluated one Apply invocation per task. Tasks were selected from accumulated project requirements, mainly in backend development, for their clear descriptions and representativeness. The update snippets were generated by GLM-5 during normal development, rather than synthesized specifically for evaluation. Within these tasks, aiXapply-RL and the upstream GLM-5 model performed Apply using the same source files and update snippets. We evaluated only the first outputs, without retries or manual repairs. The 100 cases were divided among five testing-team members, with one assessor per case, and their results were aggregated. Acceptance required applying the upstream-generated snippet at the correct location, preserving unrelated source content, and faithfully integrating its core logic without semantic errors. Apply was judged acceptable in 91 of 100 cases for aiXapplyRL and 88 of 100 for GLM-5. These are descriptive singleApply acceptance rates, not end-to-end task success rates. Following this internal evaluation, the RL service was rolled out to aiXcoder enterprise users, reaching thousands of users. Open-source integration. To make the deployment reusable, our open-source artifact provides a Continue adapter and an OpenAI-compatible endpoint, supporting both local and remote deployment. Developers can therefore keep the original upstream model for planning and snippet generation while routing Apply requests to aiXapply as a specialized backend. The same service can also be exposed as an agent tool, providing an alternative to search-and-replace for snippet integration in broader agent workflows, with the aim of improving accuracy and reducing latency. Lessons learned. This deployment illustrates three practical choices: separate snippet generation from copy-dominant integration; select the Apply model using internal project validation as well as public benchmarks; and retain the editor diff for user inspection before acceptance. The observed latency gains and single-Apply manual assessments support this deployment, while broader agent use remains an integration opportunity rather than an evaluated outcome. VII. T HREATS TO VALIDITY Internal validity. We compare SFT and RL under the same backbone and evaluation protocol, but differences in optimization and reward design may still affect results. RL may also introduce variance from reward quality and sampling. External validity. Our experiments use the aiXapply and Diff-XYZ datasets, covering multiple languages, structured-

text formats, and OOD settings. However, they may not represent all real-world codebases or interactive IDE workflows, so generalization to all deployment settings is not guaranteed. The shared snippet-generation pipeline may introduce synthesis bias, and LLM verification may accept underspecified snippets. The commit-level random split does not guarantee repository-disjoint generalization. The real-development evaluation provides complementary evidence of practical applicability, but does not eliminate this bias. Our training experiments use only Qwen3-4B, so transfer to other backbones remains unverified. Evaluation is limited to single-file Apply; multi-file workflows could invoke it per file, but cross-file coordination must be handled by the surrounding agent. Conclusion validity. The main trends are consistent across settings, but some subsets, such as long-context evaluation, are relatively small. Thus, the exact magnitude of differences between SFT and RL should be interpreted cautiously. VIII. C ONCLUSION We study snippet integration as a standalone task: merging an update snippet into a source file while preserving all other content unchanged. We analyze common editing paradigms, including unified diff and search-and-replace, and show that their patch-structure and source-matching constraints lead to unreliable one-shot performance. We propose aiXapply, a specialized approach that directly generates the full updated file. By constructing a dataset from real commits and training a 4B model with supervised finetuning and reinforcement learning, we obtain a system that is designed to produce deterministic and side-effect–free edits. The benchmarks show competitive reference-agreement accuracy, while the aiXcoder deployment demonstrates lower Apply latency and acceptable first outputs in the evaluated internal tasks. More broadly, our findings suggest that code editing should be treated as a distinct and well-defined problem rather than a byproduct of general code generation. Specializing models for such tasks enables a better balance between accuracy, efficiency, and deployability. In future work, we plan to extend Apply to more complex editing scenarios, such as multi-file changes, interactive editing workflows, and tighter integration with development tools. IX. DATA AVAILABILITY S TATEMENT The code is available in the https://github.com/ aixcoder-plugin/aiXapply-4B repository. The test set and SFT/RL weights are available on Hugging Face.

R EFERENCES [1] M. Chen, J. Tworek, H. Jun, Q. Yuan, H. P. D. O. Pinto, J. Kaplan, H. Edwards, Y. Burda, N. Joseph, G. Brockman et al., “Evaluating large language models trained on code,” arXiv preprint arXiv:2107.03374, 2021. [2] F. Cassano, L. Li, A. Sethi, N. Shinn, A. Brennan-Jones, J. Ginesin, E. Berman, G. Chakhnashvili, A. Lozhkov, C. J. Anderson et al., “Can it edit? evaluating the ability of large language models to follow code editing instructions,” arXiv preprint arXiv:2312.12450, 2023. [3] K. Li, Q. Hu, J. X. Zhao, H. Chen, Y. Xie, T. Liu, M. Shieh, and J. He, “Instructcoder: Instruction tuning large language models for code editing,” in Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 4: Student Research Workshop), 2024, pp. 473–493. [4] J. Guo, Z. Li, X. Liu, K. Ma, T. Zheng, Z. Yu, D. Pan, Y. Li, R. Liu, Y. Wang et al., “Codeeditorbench: Evaluating code editing capability of large language models,” arXiv preprint arXiv:2404.03543, 2024. [5] W. Chi, V. Chen, R. Shar, A. Mittal, J. Liang, W.-L. Chiang, A. N. Angelopoulos, I. Stoica, G. Neubig, A. Talwalkar et al., “Edit-bench: Evaluating llm abilities to perform real-world instructed code edits,” arXiv preprint arXiv:2511.04486, 2025. [6] C. Le Goues, T. Nguyen, S. Forrest, and W. Weimer, “Genprog: A generic method for automatic software repair,” Ieee transactions on software engineering, vol. 38, no. 1, pp. 54–72, 2011. [7] Kortix AI. (2025) Fast apply: Pipeline for data generation & fine-tuning qwen2.5 coder models. Accessed: 2026-04-28. [Online]. Available: https://github.com/kortix-ai/fast-apply [8] Aider. (2026) Aider: Ai pair programming in your terminal. Accessed: 2026-04-30. [Online]. Available: https://aider.chat/ [9] A. Sanger. (2024) Editing files at 1000 tokens per second. Cursor official blog; accessed 2026-04-30. [Online]. Available: https://cursor.com/blog/instant-apply [10] M. Liang, Q. Zhang, Z. Zuo, S. Zheng, D. Chen, W. Jiang, and Y. Li, “Fuseapplybench: Multilingual benchmark for trustworthy code edit applying task,” in Proceedings of the 34th ACM SIGSOFT International Symposium on Software Testing and Analysis, 2025, pp. 183–189. [11] E. Glukhov, M. Conti, E. Bogomolov, Y. Golubev, and A. Bezzubov, “Diff-xyz: A benchmark for evaluating diff understanding,” arXiv preprint arXiv:2510.12487, 2025. [12] N. Muennighoff, Q. Liu, A. Zebaze, Q. Zheng, B. Hui, T. Y. Zhuo, S. Singh, X. Tang, L. Von Werra, and S. Longpre, “Octopack: Instruction tuning code large language models,” in NeurIPS 2023 workshop on instruction tuning and instruction following, 2023. [13] J. Li, G. Li, Z. Li, Z. Jin, X. Hu, K. Zhang, and Z. Fu, “Codeeditor: Learning to edit source code with pre-trained models,” ACM Transactions on Software Engineering and Methodology, vol. 32, no. 6, pp. 1–22, 2023. [14] J. Wei, G. Durrett, and I. Dillig, “Coeditor: Leveraging repo-level diffs for code auto-editing,” in The Twelfth International Conference on Learning Representations, 2024. [15] C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. Narasimhan, “Swe-bench: Can language models resolve real-world github issues?” arXiv preprint arXiv:2310.06770, 2023. [16] J. Yang, C. E. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, and O. Press, “Swe-agent: Agent-computer interfaces enable automated software engineering,” Advances in Neural Information Processing Systems, vol. 37, pp. 50 528–50 652, 2024. [17] C. S. Xia, Y. Deng, S. Dunn, and L. Zhang, “Agentless: Demystifying llm-based software engineering agents,” arXiv preprint arXiv:2407.01489, 2024. [18] Y. Leviathan, M. Kalman, and Y. Matias, “Fast inference from transformers via speculative decoding,” in International Conference on Machine Learning. PMLR, 2023, pp. 19 274–19 286. [19] C. Chen, S. Borgeaud, G. Irving, J.-B. Lespiau, L. Sifre, and J. Jumper, “Accelerating large language model decoding with speculative sampling,” arXiv preprint arXiv:2302.01318, 2023. [20] Z. He, Z. Zhong, T. Cai, J. Lee, and D. He, “Rest: Retrieval-based speculative decoding,” in Proceedings of the 2024 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers), 2024, pp. 1582–1595.

[21] T. Cai, Y. Li, Z. Geng, H. Peng, J. D. Lee, D. Chen, and T. Dao, “Medusa: Simple llm inference acceleration framework with multiple decoding heads,” arXiv preprint arXiv:2401.10774, 2024. [22] P. Wang, L. Zhang, F. Liu, Y. Zhu, W. Xu, L. Shi, X. Lian, M. Li, B. Shen, and A. Fu, “Efficientedit: Accelerating code editing via editoriented speculative decoding,” arXiv preprint arXiv:2506.02780, 2025. [23] A. Yang, A. Li, B. Yang, B. Zhang, B. Hui, B. Zheng, B. Yu, C. Gao, C. Huang, C. Lv et al., “Qwen3 technical report,” arXiv preprint arXiv:2505.09388, 2025. [24] Z. Shao, P. Wang, Q. Zhu, R. Xu, J. Song, X. Bi, H. Zhang, M. Zhang, Y. Li, Y. Wu et al., “Deepseekmath: Pushing the limits of mathematical reasoning in open language models,” arXiv preprint arXiv:2402.03300, 2024. [25] A. Liu, A. Mei, B. Lin, B. Xue, B. Wang, B. Xu, B. Wu, B. Zhang, C. Lin, C. Dong et al., “Deepseek-v3. 2: Pushing the frontier of open large language models,” arXiv preprint arXiv:2512.02556, 2025. [26] Qwen Team, “Qwen3.5: Towards native multimodal agents,” February 2026. [Online]. Available: https://qwen.ai/blog?id=qwen3.5 [27] A. Zeng, X. Lv, Z. Hou, Z. Du, Q. Zheng, B. Chen, D. Yin, C. Ge, C. Huang, C. Xie et al., “Glm-5: from vibe coding to agentic engineering,” arXiv preprint arXiv:2602.15763, 2026. [28] J. Li, H. Zhu, H. Liu, X. Shi, H. Zong, Y. Dong, K. Zhang, S. Jiang, Z. Jin, and G. Li, “aixcoder-7b-v2: Training llms to fully utilize the long context in repository-level code completion,” arXiv preprint arXiv:2503.15301, 2025.

Related documents

• FeatX: Editing Software by Editing Features for Repository-Level Code Evolution#324970
• LintEval: Benchmarking LLMs on Linter-Guided File Refactoring#1354707
• LintEval: Benchmarking LLMs on Linter-Guided File Refactoring#1336052
• If It's Not Buggy, Don't Fix It: On the Dynamics of Iterative Bug-fixing with LLMs#997036
• No One-Size-Fits-All: Adaptive Code Editing with Feature-Based Strategy Selection#1387170