← Overview

Summary: LLM File Editing — Research State, Reasoning & Recommendations

1. State of Research

Emerging Field: Edit Representation for LLMs

The research field of Edit Representation for LLMs (also: LLM Code Editing) is nascent and rapidly evolving. It covers how changes to documents — not just source code — are best represented for language model generation.

Key Publications

| Paper | Venue | Core Finding | |---|---|---| | To Diff or Not to Diff? Structure-Aware and Adaptive Output Formats for Efficient LLM-based Code Editing | ACL Findings 2026 | Adaptive format selection cuts token cost & latency by >30 % without quality loss; classic Git diffs are surprisingly unnatural for LLMs | | Coeditor: Leveraging Repo-level Diffs for Code Auto-editing | ICLR 2024 | Training models on changes (commit history) rather than full files improves edit quality | | Can It Edit? Evaluating the Ability of Large Language Models to Follow Code Editing Instructions | OpenReview | Standard benchmark covering replace, insert, delete, multi-file edits; enables objective format comparison | | Cascaded Code Editing | arXiv 2026 | Large model generates only edit sketches; small model writes the file — avoids regenerating unchanged tokens | | EfficientEdit | arXiv 2025 | Reusing existing text at decoding time achieves up to 10× faster edit throughput | | Let the Code LLM Edit Itself When You Edit the Code | arXiv 2024 | Incremental inference: small edits require >85 % less compute by not reprocessing the full context | | Beyond Synthetic Benchmarks | arXiv 2025 | Gap between isolated function generation (84–89 % correctness) and real-world class-level modification (24–35 % correctness) |

Format Comparison Table (synthesised from all sources)

| Edit Format | Token Cost | Quality | Robustness | Research Coverage | Primary Error Source | |---|---|---|---|---|---| | Full file regeneration | Very high | Very high | Very high | Baseline in most benchmarks | Attention loss in large contexts (Lost in the Middle) | | Character / byte offsets | Minimal | Unknown | Very low | Barely studied | Near-zero semantic information for the model | | Line-based replace / insert | Low | Medium | Medium | Partially benchmarked | Exact match failure on minor source deviations | | Unified Diff | Low | Medium–high | Medium | Well studied; not optimal | Hallucinated line numbers, wrong hunk metadata | | Git Patch | Low | Medium | Medium | Similar to Unified Diff | Same as Unified Diff | | Search / replace blocks (merge syntax) | High efficiency | 70–80 % | Medium | Aider leaderboard; good for large models | Exact search-string match fragile | | Structured Block Diff (BLOCKDIFF / FUNCDIFF) | Low | High | High | Best current approach | Requires pre-training or AST parsing | | Function / section replacement | Medium | Very high | High | Strong results across multiple papers | — | | AST Rewrite | Very low | Potentially very high | Very high | Promising; little empirical data | Requires AST tooling; DSL pre-training |

Key pattern: The optimal format is not "smallest tokens wins". Below a certain semantic granularity, the model loses orientation. Byte offsets are cheap but almost useless for LLMs trained on coherent language.

2. Arguments & Reasoning

The core reasoning in the dialogue can be reconstructed as a three-step argument:

Step 1 — Diagnosis

"The topic is so new that LLMs have no specialisation in this area."

This is confirmed by the research: no single format has been shown to universally dominate. Training data contains very little explicit edit-representation signal, so models generalise from general language patterns rather than from edit-specific training.

Step 2 — Implication

"Therefore the most efficient approach is to allow the LLM to choose from all options and support the model's intuition."

If no format is universally best, and the model lacks deep specialisation, then forcing a single output format (e.g., always producing a Unified Diff) introduces avoidable errors. The model's generative prior should be respected — it naturally gravitates toward semantically coherent units.

Step 3 — Tool-use framing

This is further sharpened, which implicitly accepts: edit operations can be conceived as a toolset. The LLM does not produce a diff; it calls a tool — append, replace range, replace block, full rewrite — and selects the tool that offers the best trade-off between semantic expressiveness and token economy for the current situation.

This reframing connects two otherwise separate research streams:

3. Recommendation: Adaptive Toolset Based on Model Intuition

Core Principle

Design the edit interface as a vocabulary of edit operations, not as a fixed output schema. The model chooses the operation; the system executes it.

Recommended Tool Set

| Tool / Operation | When to use | Semantic unit | |---|---|---| | append(content) | Pure additions at end of file/section | File or section | | replace_block(anchor, content) | Replace a named, semantically coherent block | Heading, function, paragraph | | replace_lines(start, end, content) | Medium-granularity changes where lines are stable | Line range | | insert_after(anchor, content) | Add content relative to a semantic landmark | Named element | | rewrite_file(content) | Small files or wholesale restructuring | Full file | | apply_diff(patch) | Large codebases where line precision is controlled externally | Line-accurate patch |

Byte-level and character-offset operations are not recommended as primary tools: they provide near-zero semantic context and produce high error rates.

Design Principles

  1. Semantic anchoring over positional indexing — Identify edit targets by name (heading, function name, section ID), not by line or byte offset. This matches LLM training distribution and reduces hallucination.
  1. Let the model decide — Do not instruct the model to use a specific format unless forced by external constraints (e.g., a very large file where full rewrite is prohibitively expensive). Adaptive choice outperforms fixed schemas (To Diff or Not to Diff?).
  1. Validate semantically, not syntactically — Acceptance criteria should be "does the result mean what was intended?", not "did the patch apply cleanly?". This avoids discarding correct outputs due to whitespace mismatches.
  1. Cascade for large files — For large documents, use a two-stage approach: (1) large model identifies what changes and where, using semantic anchors; (2) a smaller or deterministic system applies the change mechanically. (Cascaded Code Editing, 2026)
  1. Instrument for learning — The adaptive toolset is also a data collection opportunity. Logging which tool the model chooses, and whether the output is accepted, generates training signal for future specialisation — closing the gap the research currently identifies.

Open Research Gap

A systematic empirical comparison of these operations across document types (Markdown, JSON, XML, prose) with respect to quality, token cost, latency, and error rate does not yet exist. Conducting such a benchmark would be a direct contribution to the field.