PaperlayerView exact revision on arXiv

Source-linked AI summary

How Should Diffusion Language Models Edit Code?

Xijia Tao, Ziru Liu, Shansan Gong, Jiacheng Ye, Kecheng Chen, Zirui Wu, Lin Zheng, Xinyu Fu, Rui Liu, Lingpeng Kong

arXiv:2609.38257v1cs.SEcs.AI

TL;DR

Code-editing interfaces must allocate changes while preserving the rest of an intact program, but diffusion infilling typically assumes locations are known. The paper compares four interfaces and controlled scaffold variants; it finds a gap between supplied and predicted locations, with coverage and boundary precision both mattering. A small sentence-level Wiki probe shows the same qualitative gap beyond code.

  • Problem

    Masked diffusion infilling methods address content and length once sites are supplied, while instructional editing must allocate edit sites in an intact program.

    Source: §1 · p. 1

  • Method

    The study evaluates four code-editing interfaces and uses oracle locations and controlled scaffold perturbations to separate localization from infilling.

    Source: §1 · pp. 1–2

  • Results

    Correct locations enable coordinated multi-region infilling, but much of that capability is lost when regions must be predicted; coverage and boundary precision are separate requirements.

    Source: §8 · p. 10

  • Takeaways & Limitations

    Reliable editing requires interfaces to expose every required change while limiting regeneration of unchanged code.

    Source: §8 · p. 10

    The controlled study centers on Python CanItEdit edits; the 64-example Wiki probe's gap size on the full test set is unknown, and repository-level and multi-file editing remain untested.

    Source: §7 · p. 9

Abstract

from arXiv · show

Code editing requires a model to decide where to make changes, generate the new content, and preserve everything else. We study how masked diffusion language models divide these responsibilities across four editing interfaces: whole-file rewriting, search-and-replace, locate-then-infill, and token-level editing. Experiments on CanItEdit reveal a composition gap: diffusion models can generate coordinated changes when the correct edit locations are supplied, but much of this capability is lost when those locations must be predicted. Access to the intact original code helps the model fill multiple edit regions, yet does not resolve the difficulty of selecting those regions. By varying the editable regions while holding the generation model and decoding procedure fixed, we identify two distinct requirements for successful editing: covering every required change and placing precise boundaries around it. Missing a required region prevents the corresponding change, while widening regions to ensure coverage can sharply reduce success by requiring unchanged code to be regenerated. A sentence-level Wiki editing probe shows the same qualitative gap between supplied and predicted locations beyond code. These findings show why strong infilling capability alone does not ensure reliable editing: the interface must expose all required changes while limiting regeneration of unchanged code.

1 INTRODUCTION

Instructional code editing must make coordinated changes while preserving code outside the request, but diffusion infilling assumes editable locations are already known. This study compares four interfaces and finds that correct locations unlock multi-edit generation that predicted locations fail to preserve.

1 INTRODUCTION

  • Instructional editing asks a model to revise an intact source file while making coordinated changes and preserving behavior outside the request.The interface determines how the revision is expressed.Source: §1 · p. 1
  • Masked diffusion models can condition on both sides of an edit and jointly fill disjoint regions, but editing requests do not supply the masks.The model must decide which valid program regions to expose for generation.Source: §1 · p. 1
  • The four interfaces trade source preservation against structural commitments: rewriting regenerates unchanged code, while sparse interfaces require explicit choices of sites and boundaries.The study asks which interfaces let diffusion models use infilling capability effectively.Source: §1 · p. 1
  • The study finds a composition gap: correct regions enable coordinated edits, but predicted regions lose much of that capability.Missing regions prevent required changes, while broad holes require unchanged code to be reconstructed.Source: §1 · p. 2
  • The paper evaluates four interfaces by the structural decisions assigned to the model and the preservation guarantees assigned to the runtime.It uses implementations of all four interfaces, oracle-location controls, and scaffold perturbations on CanItEdit.Source: §1 · p. 2
  • Source-conditioning controls and composition with a predicted locator establish the gap between known-site infilling and autonomous editing.Matched scaffold interventions isolate coverage and boundary precision as separate requirements.Source: §1 · p. 2

2 RELATED WORK

Prior diffusion work studies denoising and infilling when gaps are supplied, while instructional editing must infer which regions of an intact file to change. The paper distinguishes its file-editing interface from methods that edit generated drafts or corrupted targets.

2 RELATED WORK

  • Masked diffusion language models use bidirectional context, and known-gap methods address infilling after sites are supplied.FIM fixes a contiguous gap, while DreamOn, FlexMDM, and PILL adapt gap length.Source: §2 · p. 2
  • Instructional editing instead receives an intact file and must infer which regions to change, potentially at several disjoint sites.EditPackFT and CanItEdit provide the paper's training and evaluation setting.Source: §2 · p. 3
  • Unlike methods that revise generated drafts or diffusion blocks, this token-level interface selects instruction-conditioned edits throughout a supplied program.Prior edit-based methods include insertion, deletion, and substitution; a small LLaDA2.2 trace census found mask filling more common than revision of existing canvas tokens.Source: §2 · p. 3

3 EDITING INTERFACES

The interfaces differ in what structure the model predicts and what the runtime preserves. Sparse interfaces fix the regions generation may change, so omitted regions remain unchanged.

3 EDITING INTERFACES

  • The runtime applies the model's output to source code, and interfaces differ in the structure supplied to that runtime.Evaluation scores the reconstructed file, not exact agreement with a reference serialization, because different plans can implement the same instruction.Source: §3 · p. 3
  • Whole-file rewriting makes the model emit the complete edited file, leaving localization and preservation implicit in generation.The runtime acts as the identity.Source: §3 · p. 3
  • Search-and-replace emits old/new substring pairs; the runtime preserves untouched source but requires uniquely matching, non-overlapping anchors.Missing, ambiguous, or overlapping matches fail, and replacement length remains implicit in the generated text.Source: §3 · p. 3
  • Locate-then-infill predicts line-based replace, delete, or insert headers, which a deterministic parser converts into a scaffold with masked holes.The runtime does not infer missing edits or widen predicted ranges; omitted source lines remain observed.Source: §3 · p. 3
  • Stage 2 jointly denoises the scaffold's holes with bidirectional context, while omitted sites remain fixed source.Training uses line-diff coordinates for locator supervision, and inference predicts headers from the instruction and numbered source alone.Source: §3 · pp. 3–4
  • The old-visible variant supplies intact source, including removed text, as read-only context while gold locations fix edit count, sites, and boundaries.Its block-decision procedure allocates variable output length independently for each hole while retaining bidirectional attention.Source: §3 · p. 4
  • Token-level editing predicts keep, substitute, delete, or expand operations at individual source-token positions to allocate edits across the supplied file.This differs from draft-refinement methods that apply operations within generated diffusion blocks.Source: §3 · p. 4

4 EXPERIMENTAL SETUP

The experiments fine-tune a diffusion code model on Python edits and evaluate reconstructed programs with hidden tests. Oracle scaffolds and controlled perturbations separate autonomous interface results from diagnostics of the infiller's structural sensitivity.

4 EXPERIMENTAL SETUP

  • The study fine-tunes DiffuCoder-Instruct on 20,602 Python EditPackFT examples and evaluates 210 instruction instances from 105 CanItEdit problems using hidden-test pass@1.Gold diffs divide the instances into 68 single-span and 142 multi-span edits.Source: §4 · p. 4
  • Autonomous interfaces are distinct from oracle diagnostics, which supply gold edit structure while leaving content and variable length to the filler.Controlled scaffold perturbations hold the filler fixed to test missing regions, boundary errors, and false-positive holes; interface fine-tuning recipes are not fully matched.Source: §4 · p. 4

5 MAIN RESULTS

With gold edit regions, old-visible infilling achieves stronger multi-span performance than direct search-and-replace, but that capability largely disappears with predicted regions. Autonomous interfaces and simpler alternatives retain localization and reconstruction gaps.

5.1 AUTONOMOUS INTERFACES AND ORACLE GAPS

  • Search-and-replace performs best overall and on multi-span edits among the autonomous interfaces, though their scores are operating points rather than a causal interface ranking.The available DiffuCoder-family recipes differ; Table 1 reports pass@1 and syntax-error and exception rates.Source: §5.1 · p. 4, Table 1 · p. 5
  • Search-and-replace parse and apply rates are 89% and 75%, respectively, reflecting failures distinct from Python syntax errors.Source: §5.1 · p. 5
  • 25.4% multi-span pass@1 with gold-region old-visible infilling falls to 10.6% in Hybrid-multi with predicted regions, versus 11.3% for direct search-and-replace.The gold scaffold supplies structural information unavailable to the separately trained autonomous editor.Source: §5.1 · p. 5
  • Only 53/142 multi-span examples enter Hybrid-multi’s infill branch; predicted single edits and failed or non-unique matches retain direct search-and-replace reconstruction.Source: §5.1 · p. 6
  • Autonomous token-level editing reaches 5.2% pass@1 versus 30.0% with oracle positions, while syntax errors remain 37.6% even with oracle positions.The oracle token-level and line-level rows use different training and decoding procedures.Source: §5.1 · p. 6

5.2 SIMPLE ALTERNATIVES RETAIN THE GAP

  • After five rounds of repeated replacement, multi-span pass@1 remains 11.3%, while single-span pass@1 drops from 48.5% to 36.8%.Source: §5.2 · p. 6
  • Matched Stage 1 backbones achieve similar functional scores, but the DiffuCoder locator has 2.4% exact line-operation agreement and predicts 1.89 edits on average against 2.78 gold edits.The three pairings reach 13.3%, 13.8%, and 11.9% pass@1; their multi-span scores are 12.0%, 11.3%, and 10.6%.Source: §5.2 · p. 6

6 WHY DOES THE ORACLE ADVANTAGE DISAPPEAR?

Known-site infilling can coordinate multiple edits, but predicted locations lose much of that capability. Missing regions and imprecise boundaries both contribute, and a sentence-level Wiki probe shows the same qualitative gap beyond code.

6.1 KNOWN-SITE INFILLING IS A USEFUL PRIMITIVE

  • With gold locations, old-visible source context raised multi-span pass@1 from 14.1% to 25.4%, while single-span scores were 33.8% without and 30.9% with context.The reported gain is concentrated in multi-span editing; the scaffold still determines which parts may change.Source: §6.1 · p. 6, Figure 3 · p. 7

6.2 STRUCTURE ALLOCATION IS THE BOTTLENECK

  • 21.8% multi-span pass@1 with both repairs approached the 25.4% gold-scaffold result, while either repair alone reached only 13.4% or 14.1%.The predicted-hole baseline was 10.6%; locator outputs also commonly omitted gold regions or selected incorrect ranges.Source: §6.2 · p. 7

6.3 COVERAGE IS NECESSARY BUT NOT SUFFICIENT

  • Dropping one required span yielded 6.3% multi-span pass@1, while expanding every hole one line yielded 7.7% despite 100% gold-span coverage.A single tight false-positive hole reached 20.4%, but two reduced pass@1 to 8.5%; wider holes require regenerating additional correct context.Source: §6.3 · p. 7, Figure 4 · p. 8, Table 2 · p. 8

6.4 BEYOND CODE: TARGETED PROSE EDITING

  • On 64 FineEdit Wiki examples, gold-location infilling scored 0.927 edit F1 and 0.597 SARI, versus 0.376 and 0.437 with predicted locations.This probe reproduces the qualitative location gap, but cannot establish its size on the full test set.Source: §6.4 · pp. 8–9, Table 3 · p. 8

7 DISCUSSION: PRESERVATION, GENERATION, AND COST

Editing interfaces differ in how much unchanged source they preserve and how much they ask the model to generate. Output-token savings are not runtime measurements, and evaluation should assess the locator and generator together.

7 DISCUSSION: PRESERVATION, GENERATION, AND COST

  • Sparse interfaces can reduce generated text when edits are small relative to the file, but wider holes spend more generation on previously correct code.Rewrite reproduces unchanged code; locate-then-infill generates a plan and replacement content, while token-level editing predicts operations across the source.Source: §7 · p. 9
  • Fewer generated tokens do not establish faster decoding, which also depends on canvas length, denoising rounds, structural prediction, and cache policies.A speed comparison would require matched hardware, decoding budgets, context handling, and cache policies.Source: §7 · p. 9
  • Evaluation should pair oracle-location infilling with autonomous performance and report parseability, overlap recall, and pass@1 to inspect different parts of the interaction.The study centers on Python file edits on CanItEdit; repository-level and multi-file editing remain untested.Source: §7 · p. 9

8 CONCLUSION

Across four interfaces, the study finds that diffusion models can coordinate edits when given correct regions but lose much of this capability when locations must be predicted. The appendices probe localization, length allocation, and training variants, with results indicating that known locations do not eliminate generation errors.

8 CONCLUSION

  • Coverage and boundary precision are separate requirements: omitting required sites or widening holes can each erase the infilling advantage.A small sentence-level Wiki probe shows the same qualitative location gap beyond code.Source: §8 · pp. 9–10

A DATASET DETAILS

  • The EditPackFT Python training set contains 20,602 pairs, and its appendix reports token-length and raw-source character and line-count distributions.Token-level edit-operation counts are derived by Levenshtein alignment and describe the data, not the headline methods’ training operations.Source: Table 5 · p. 12, Table 6 · p. 12, Table 7 · p. 12

A.2 EDIT OPERATION STATISTICS

  • Appendix tables report token-level edit-operation distributions and example profiles by change type.Insert-group statistics are also reported; the earlier four-type accounting is separate from the Stage-1/2 and str_replace recipes.Source: §A.2 · p. 12, §A.3 · p. 12, Table 8 · p. 13

B TOKEN-LEVEL LEVENSHTEIN FAMILIES

  • The token-level interface aligns source and target with Levenshtein dynamic programming and trains keep, substitute, insert, and delete predictions in place.Its nine training families include precomputed and online-resampled examples; rare operations receive inverse-frequency weighting, whose materiality to CanItEdit pass@1 is not claimed.Source: B TOKEN-LEVEL LEVENSHTEIN FAMILIES · p. 13
  • 30.0% oracle-position pass@1 contrasts with 5.2% autonomous token-level pass@1, while SyntaxError remains 37.6% and 50.0%, respectively.The oracle-position result shows localization explains a large part of the gap, but known positions do not remove generation errors.Source: B TOKEN-LEVEL LEVENSHTEIN FAMILIES · p. 13

C DECODE SETTINGS

  • Headline CanItEdit cells use distinct Stage-1 and Stage-2 confidence settings, and report str_replace parse/apply failures separately from SyntaxError.The appendix also clarifies that block-decision and block-append are length-and-stop harnesses, not block-causal attention ablations.Source: C DECODE SETTINGS · p. 13

D ADDITIONAL FAILED-INTERVENTION DETAILS

  • Gold-location length-harness variants differed by 2–7 points, far less than the drop from oracle-location results to autonomous 12.9% pass@1.A trajectory-matched Stage-2 sampler was insufficient under its recipe; teacher-forced continue accuracy moved only from 57.3% to 58.8%.Source: D ADDITIONAL FAILED-INTERVENTION DETAILS · pp. 14–15

E OLD-VISIBLE OCCUPANCY AND LENGTH DIAGNOSTICS

  • Among aligned unlocked completions, exact token length was 45.1% for Pass examples and 0.0% for SyntaxError examples; SyntaxError examples all under-generated at least one span.The appendix cautions that malformed programs may complicate inferred under-allocation; exact-length examples had zero SyntaxErrors.Source: E OLD-VISIBLE OCCUPANCY AND LENGTH… · p. 17

F HUMANEVAL-INFILLING PLACEMENT PROBE

The placement probe compares known-gap infilling layouts, while the related-work discussion distinguishes supplied gap locations from instructional editing, where sites must be inferred. Results favor in-place infilling in some settings, but do not establish success on multi-span autonomous editing.

F HUMANEVAL-INFILLING PLACEMENT PROBE

  • Exact-match and pass@1 disagree: 175/1033 end-prompted completions match after stripping yet fail tests, while 149 middle completions pass with a different surface string.Many end-prompted failures involve a missing trailing newline; exact-match is not treated as a tighter functional metric.Source: F HUMANEVAL-INFILLING PLACEMENT PROBE · p. 19
  • With a known span, in-place middle infilling strongly outperforms prompted end generation off the shelf, but this probe does not test joint multi-span infilling or variable-length control.Both layouts retain visible suffix tokens; the comparison therefore is not a test of suffix access.Source: F HUMANEVAL-INFILLING PLACEMENT PROBE · p. 19
  • Matched SFT nearly ties single_line pass@1 at 94.6% versus 94.3%, but middle retains a multi_line advantage at 61.9% versus 55.2%.Both arms share a backbone, serialization, and five-epoch training setup; the CanItEdit 47.0% result is limited to 66 canonical single-span oracle-length fills.Source: F HUMANEVAL-INFILLING PLACEMENT PROBE · p. 19, Table 22 · p. 20, Table 23 · p. 20

G EXPANDED RELATED-WORK DISTINCTIONS

  • In a 20-trace LLaDA2.2 census, 94.9% of writes filled masks; structural edits varied by task, so these traces do not characterize source-file localization.The code-editing prompts generated from masks rather than locating changes in supplied source.Source: G EXPANDED RELATED-WORK DISTINCTIONS · p. 21, Table 24 · p. 21
  • FIM supplies gap locations through markers, whereas instructional editing must infer sites from an instruction and intact file; adaptive-length methods address span length, not site prediction.Block-decision and block-append allocate length while retaining bidirectional attention; they are not block-causal attention patterns.Source: G EXPANDED RELATED-WORK DISTINCTIONS · pp. 21–22

H INTERFACE IMPLEMENTATION DETAILS

The implementation assigns different structural commitments to model outputs and runtimes. Sparse interfaces preserve unnamed source regions, while parsers and scaffold construction determine which regions can be regenerated.

H INTERFACE IMPLEMENTATION DETAILS

  • Search-and-replace serializes old/new substring pairs; its runtime substitutes only uniquely matching anchors, preserving untouched source but making anchors and boundaries explicit commitments.The parser does not normalize whitespace or use fuzzy matching.Source: H INTERFACE IMPLEMENTATION DETAILS · p. 22, Table 25 · p. 22
  • Locate-then-infill Stage 1 emits operation-and-coordinate headers that a deterministic parser converts into a scaffold; unnamed source lines remain observed and omitted sites stay unchanged.Plans cannot paste replacement code, and the runtime does not guess missing hunks or widen ranges for recall.Source: H INTERFACE IMPLEMENTATION DETAILS · p. 23
  • Integrated gold scaffolds keep unchanged lines as source, pair replacements with read-only old text and editable holes, and represent deletions without holes.A glue-fix makes minus records newline-terminated so gold reconstruction round-trips; minimal-edit canonicalization is checked against apply(x, canonicalized) = y.Source: H INTERFACE IMPLEMENTATION DETAILS · p. 23
  • Block-decision seeds each hole with masks, denoises a block, then uses a control slot to append another block or stop while retaining full-sequence bidirectional attention.It is a length-allocation harness rather than a block-causal attention pattern.Source: H INTERFACE IMPLEMENTATION DETAILS · p. 23

I.1 MATCHED STAGE 1 BACKBONE CHECK

The matched-backbone check compares Stage-1 locators while holding the old-visible Stage-2 filler fixed. Locator outputs show that parseable or partly correct plans often fail to specify complete edit operations, and localization errors dominate failures.

I.1 MATCHED STAGE 1 BACKBONE CHECK

  • The matched locator runs use the same 21,661 training examples and checkpoint step, but fixed-length plan decoding does not establish accurate plan-length stopping.483/500 iLLaDA and 493/500 LLaDA validation plans are 158 tokens after stripping EOS.Source: §I.1 · pp. 23–24
  • DiffuCoder, iLLaDA, and LLaDA locator pairings reach 14.3%, 10.5%, and 9.5% lazy pass@1, respectively, with the fixed DiffuCoder old-visible filler.Their single-span and descriptive pass@1 values differ, and DiffuCoder’s exact anchor agreement is 52.4%; only 2.4% of its outputs have exact line-operation agreement.Source: §I.1 · p. 24, Table 26 · p. 24
  • Locate-then-infill failures concentrate in wrong localization (112/210), not unparseable plans (9/210).str_replace also loses 89/210 cases to semantic or runtime failures after parsing and applying, besides format and apply errors.Source: §I.1 · p. 24

J ADDITIONAL LOCATE-THEN-INFILL DIAGNOSTICS

K INTEGRATED GOLD-SCAFFOLD CONSTRUCTION

The integrated gold-scaffold diagnostic first corrected a serialization bug that prevented some gold reconstructions, then tested tighter scaffold boundaries. Glue-fix raised pass@1 on the affected slice, and minimal-edit canonicalization produced a further limited gain.

K INTEGRATED GOLD-SCAFFOLD CONSTRUCTION

  • The glue-fix comparison held the integrated-diff filler fixed and changed scaffold construction, so the checkpoints were not being compared.The diagnostic used one step-1610 filler; D, D′, and D′′ were scaffold variants, not separate checkpoints.Source: K INTEGRATED GOLD-SCAFFOLD CONSTRUCTION · p. 25
  • 43/105 programs failed gold reconstruction when the terminal source line was glued to the following mask, and that slice scored 0% pass@1.All 105 CanItEdit sources lacked a final newline; keep-line audits do not support interpreting this as the filler overwriting immutable tokens.Source: K INTEGRATED GOLD-SCAFFOLD CONSTRUCTION · p. 25
  • 20.5→26.2% overall pass@1 came entirely from the glue-fixed affected slice rising from 0.0% to 14.0%.Unaffected evaluations remained at 34.7%; minus records were newline-terminated so reconstruction matched all 105 sources.Source: K INTEGRATED GOLD-SCAFFOLD CONSTRUCTION · p. 25
  • Minimal-edit canonicalization added 1.9 pass@1 points, with gains confined to the 43-source EOF/no-newline slice.18/43 replacements became insertions; two prompts gained successes, while 10_csv_parser still failed, so tighter scaffolding was not sufficient.Source: K INTEGRATED GOLD-SCAFFOLD CONSTRUCTION · p. 25
  • Inference-time oracle length scored below canonicalized variable-length decoding and is not a Stage-2 upper bound.The checkpoint was trained for variable-length block generation, making gold occupancy both extra oracle information and a decode mismatch.Source: K INTEGRATED GOLD-SCAFFOLD CONSTRUCTION · p. 26

L COMPOSITION DIAGNOSTIC: PREDICTED <OLD> →OLD-VISIBLE INFILL

The section tests predicted edit regions, sequential search-and-replace, and sentence-level Wiki editing. Combined coverage and boundary repairs improve supported comparisons, but fully covering gold edits is not sufficient; the Wiki probe likewise reports a gap between supplied and perturbed locations.

L COMPOSITION DIAGNOSTIC: PREDICTED <OLD> →OLD-VISIBLE INFILL

  • Hybrid-multi routes uniquely matched predicted <old> spans to old-visible Stage 2 for K≥2, otherwise retaining the str_replace reconstruction.The generated <new> text is discarded for routed examples; hybrid-all is reported only as a control.Source: L COMPOSITION DIAGNOSTIC: PREDICTED… · p. 26
  • On 94/142 examples, combined coverage and boundary repairs produced the exact gold span list; their paired 95% bootstrap interval was +4.9 to +17.6 pass@1 points.The individual repair intervals include zero, while the combined improvement is better supported by the paired comparison.Source: L COMPOSITION DIAGNOSTIC: PREDICTED… · p. 26, Table 44 · p. 31
  • Even among 31 multi-span cases whose predicted spans covered every gold hunk, gold-location Stage 2 had 13/31 successes versus 8/31 for Hybrid-multi, with overlapping example-resample CIs.Only 19/31 fully covered cases were routed to Stage 2; the authors treat this as supporting evidence that coverage is not sufficient, not a second major bottleneck.Source: L COMPOSITION DIAGNOSTIC: PREDICTED… · p. 27, Table 46 · p. 32

M SEQUENTIAL S T R_R E P LACE CONTROL

  • The one-edit-per-round prompt caused a protocol mismatch: 52.9% of trajectories died after proposing more than one replacement, and mean accepted edits was 1.04.The first-valid executor instead commits the first uniquely applicable non-noop edit and replans on the updated file.Source: M SEQUENTIAL S T R_R E P LACE CONTROL · p. 28
  • First-valid max 5 recovered 16 multi-span successes (11.3%), 14/16 after more than one accepted edit, while Round 1 damaged syntax or increased gold hunks in 34.5%.Single-span pass@1 fell from 48.5% to 36.8% from max 1 to max 5, while multi-span pass@1 rose from 5.6% to 11.3%.Source: M SEQUENTIAL S T R_R E P LACE CONTROL · p. 28, Table 50 · p. 34

N FINEEDIT WIKI TARGETED-EDITING PROBE

  • The FineEdit probe used 8,024 Wiki examples, with a median of seven edited sentences among 37 and at least three edited sentences in 84.1%.On the first 64 test examples, locator plans parsed on 57.8% and completely covered gold regions on 48.4%; the locator predicted 6.0 regions on average versus 3.56 gold regions.Source: N FINEEDIT WIKI TARGETED-EDITING PROBE · p. 28
  • In the sentence-level Wiki probe, local one-boundary errors were often survivable, while expanding ranges hurt more and translating the whole scaffold was catastrophic.Figure 6 reports gold-scaffold Stage-2 pass@1 by perturbation family, not autonomous performance.Source: Figure 6 · p. 29

L COMPOSITION DIAGNOSTIC: PREDICTED <OLD> →OLD-VISIBLE INFILL

  • Gold-scaffold diagnostics show missing spans collapse performance, one extra hole is comparatively cheap, and widening ranges hurts; whole-scaffold translation is catastrophic.The perturbation figures are diagnostics, not autonomous performance; Figure 7’s overall rates mix cases where some corruptions could not be applied.Source: Figure 6 · p. 29, Figure 7 · p. 32, Table 48 · p. 33
Loading 2609.38257v1…