Summary / 10. Editing mechanism / Document
Paper 2026-09-06
Shared copy: the operator's name and machine names are replaced by roles. Nothing else is changed.
Rendering…
# The Write Path: Deterministic Transformation, a Scope-Ordered Representation Ladder, and Apply–Verify–Revert Gating for the Editing Mechanism of a Weak-Model Coding Harness *Component 10 of 27 — Coding-Harness Program. This document specifies the editing mechanism: the write-path stage in which an intended change, already chosen by component 09's candidate generation, is reliably transformed into repository bytes. It sits immediately after component 09 (patch/code generation), which decided WHAT should change, and before the components that execute and validate the landed result (11 and 17–18); editing decides WHETHER that change lands. The two must stay distinct because they fail differently: generation mispicks semantics, editing mis-applies them — a correct decision lost to a malformed diff, an ambiguous match, or a stale anchor is an editing failure no generator can fix. Component 10 is the last place before the verifier where a correct decision can still be silently lost, and it is the harness's one opportunity to make the landing deterministic. It is written to drive a reversible build; the executable specification follows in a companion document.* --- ## Abstract Editing is the stage where the coding-harness program's decisions become disk state: component 09 generated the candidate change that should land, and this component decides whether, and exactly how, it lands. This paper argues that editing should be a deterministic transformation service behind the model, not free-form repository manipulation: the harness classifies the intended modification by scope and structure, selects the lowest-complexity edit representation capable of expressing it, prefers entity-aware or exact replacement operations over positional formats for weak models, applies the transformation outside the LLM, and gates the resulting repository state through uniqueness, parsing, linting, and collateral-change checks. Edit representations themselves must be benchmarked per model and change type rather than standardized by convention. The model-facing representation and the developer-facing representation need not be the same thing — the harness generates the diff afterward. The paper reviews six lines of evidence — the anchor result that editing is an interface-design problem whose lint-and-revert gate is a large single ablation gain [1], the direct ablation showing string replacement beats diff for weaker models with a shrinking gap as the model strengthens [2], the structured-action-space result that AST/entity editing buys most precisely where models are weakest [3], the structure-aware-diff result that no edit format is universally optimal [4], the representation-isolation outlier showing format interacts with model size and operation [5], and the collateral-change outlier showing that editing benchmarks mostly cannot see out-of-scope modifications [6] — together with honourable mentions, the corrected attributions that keep a benchmark from being credited with a format-reliability claim it never made [7], and the classical roots beneath them. It derives seven design principles and specifies an architecture in which every stage except a single, exceptional, schema-constrained adjudication call is deterministic software on CPU, so the L column holds exactly one entry and the weak model is kept out of the repository's bytes. It closes with the recursive self-improvement protocol and a measurement plan whose honest instruments separate apply success from collateral change, so that a harness cannot hide a leaking edit behind a green end-to-end solve. ## 1. Introduction The coding-harness program decomposes software engineering into a sequence of questions, and components 01 through 09 answered the opening nine. Components 05–08 decided where the fault is, what an edit will break, in what order the work proceeds, and what the model should see. Component 09, patch/code generation, made the first genuinely generative decision: it produced the candidate change — the concrete code edit that should satisfy the change obligation. This paper answers the question component 09 leaves open: *given that a change should be made, how does it reliably land on the disk?* Component 10, the editing mechanism, is the write path. It is the stage that turns a generated intent — the semantic content of a desired modification, whether expressed as a search/replace block, an entity operation, or a rewrite — into a validated, parseable repository state that the downstream validation and repair components (11, 17–18) can then judge. Where generation decides *what* changes, editing decides *whether it lands*: whether the right bytes are replaced, at the right place, once, with nothing collateral touched, and with a repository that still parses and still lints afterward. The central fact of the problem is that an edit is a fragile act at the boundary between the model's distribution and the disk, and that the naive picture — let the LLM rewrite the file, or hand it a diff it must format perfectly — conflates the *decision* to change something with the *reliability* of landing that change. The evidence shows these come apart. SWE-agent built its whole thesis on editing as an interface-design problem rather than plumbing, and its single most consequential design choice was a guardrail: the edit command applies a change, runs a linter over the result, and rolls back on a parse failure so the agent never reasons over a corrupted file — a lint-and-revert gate that was one of the largest single ablation gains in the paper [1]. That gate is not about what the model knows; it is about the channel between the model's decision and the repository bytes, and a whole class of agent failures lives in that channel. Lita made the channel itself the experimental variable, ablating string replacement against diff editing while holding the agent fixed, and found the representation gap is real and largest where models are weakest: GPT-4o's Aider Polyglot pass rate more than doubled from 19.8% with diff to 45.8% with string replacement, while by GPT-5 the gap nearly vanished (94.9% to 96.0%) [2]. The edit representation is not a fixed convention; it is a measured variable that interacts with model capability. A second, reinforcing fact is that the format the model emits is only half the story — the *structure* the harness exposes is the other half, and it is the half most under the harness's control. CODESTRUCT attacks the assumption beneath both diff and search/replace, that code is edited as text at all: reframing the repository as a structured action space of named AST entities, with readCode and editCode operating on semantic program elements rather than text spans, improved Pass@1 by 1.2–5.0 percentage points across six models on SWE-bench Verified while cutting token consumption 12–38% — and the weakest tested model, GPT-5-nano, improved by a disproportionate 20.8 points as its empty-patch failures fell from 46.6% to 7.2% [3]. The lesson compounds the Lita one: the weaker the model, the more value structure-aware editing creates, because a weak model is least reliable at the positional and textual bookkeeping that diff and even search/replace demand. The structure-aware-diff line refines the picture further: To Diff or Not to Diff represents changes as block-level rewrites of syntactically coherent units aligned to tree-sitter AST nodes, wraps unstructured or malformed regions in special fine-grained nodes so a local edit is not promoted to a parent, and trains an adapter to switch per-sample between diff and full rewrite — concluding, explicitly, that "any edit format is not universally optimal" and matching full-code accuracy while cutting latency and cost by over 30% [4]. A third fact is that editing tools misbehave in ways the benchmarks used to compare them mostly cannot see. Edit, But Verify audits instructed-editing benchmarks and finds they answer "was the edit made?" more reliably than "was ONLY the requested edit made?": 59% of EDIT-Bench's low-coverage test suites would not detect modifications outside the edit region, and 56% of tests scope exclusively to the edited code — which matters because editing tools in practice routinely introduce out-of-scope modifications [6]. This is the reason the word "reliably" in this component's mandate needs a metric of its own: a whole-file rewrite that silently reformats two hundred unrelated lines, or a fuzzy search/replace that matches the wrong occurrence, is a successful apply by the naive count and a catastrophe by the collateral-change count. And the same representation-isolation that Lita performs on an interactive agent, Diff-XYZ performs on the raw operation, isolating apply, anti-apply, and generation over real-commit triples to show that search/replace works best for larger models on most tasks while structured diff variants are close but weaker, and that smaller open models benefit little from any format choice — so no format deserves universal status merely because one benchmark favored it [5]. The thesis follows from these observations. **Editing should be a deterministic transformation service behind the model, not free-form repository manipulation: classify the intended modification by scope and structure, select the lowest-complexity edit representation capable of expressing it, prefer entity-aware or exact replacement operations over positional formats for weak models, apply the transformation outside the LLM, and gate the resulting repository state through uniqueness, parsing, linting, and collateral-change checks. Edit representations themselves must be benchmarked per model and change type rather than standardized by convention. The model-facing representation and the developer-facing representation need not be the same thing — the harness generates the diff afterward.** The paper proceeds as follows. Section 2 reviews six modern lines of prior work plus honourable mentions and classical roots, each with its claims, numbers, venue caveats, and weak-model implication. Section 3 derives seven design principles. Section 4 specifies the architecture, labeling every node deterministic (D) or learned (L) and holding the invariant that the L column contains exactly one entry. Section 5 states the recursive self-improvement protocol. Section 6 gives the measurement plan. Section 7 concludes. ## 2. Related Work The literature divides into six modern lines — an interface-design anchor, a representation ablation, a structured-action-space result, a structure-aware-diff result, and two outliers, one isolating representation and one measuring the tool rather than the model — plus a set of honourable mentions and the classical roots beneath all of them. Each modern line answers one question the editing stage must resolve: is an edit primitive plumbing or interface, does representation move agent performance, does structure beat text for the models that need it most, is any format optimal, does representation generalize across operation and size, and can the evaluation even see when an edit misbehaves. Six lines are presented below, followed by the mentions and the roots. ### 2.1 The anchor: SWE-agent, editing as interface design **SWE-agent** [1] is the anchor for this component, and the point here is narrower than its general Agent-Computer-Interface thesis, which appears elsewhere in the program. SWE-agent treats editing as an interface-design problem: it builds LM-oriented commands for viewing and editing files rather than exposing an unrestricted shell, and it couples every edit with immediate feedback instead of leaving the model to reason over whatever it wrote. The edit-specific result that matters for component 10 is the guardrail. SWE-agent's edit command applies a change, runs a linter over the edited region, and — on a syntax or lint failure — rejects the edit and rolls it back, showing the error, so the agent never reasons over a corrupted file. That lint-and-revert gate was one of the largest single ablation gains in the paper: removing or weakening the validation-around-the-edit materially degrades performance because it lets the model accumulate malformed state, and post-hoc error analyses repeatedly attribute a large share of agent failures to edit friction — indentation slips, format errors, half-applied hunks — rather than to missing reasoning ability. Two caveats are carried from the primary source. First, "NeurIPS 2024" is not stated in the arXiv record, so the venue should be treated as unconfirmed. Second, the field's own convergence is not to SWE-agent's original interface but away from it: SWE-agent 2.0 (2025) later adopted the simpler `str_replace_editor` primitive, an exact-match search/replace operation whose origin is Anthropic's `text_editor` tool — evidence that the community's default settled on search/replace-style application, a point the honourable mentions confirm from the scaffold side [10]. The weak-model implication is the component's opening premise: an edit primitive is not plumbing, and the harness's choice of interface, plus the validation it does before accepting a write, is a first-class design axis with its own measurable success. ### 2.2 The representation ablation: Lita **Lita** [2] is the cleanest direct ablation of edit representation, holding the broader agent design fixed and swapping only the editing format. It implements two versions of the same lite agent — Lita (string replacement) and Lita-diff (git-diff-based editing) — and finds the choice matters substantially, especially as model capability decreases. The numbers, all located in Table 3 and §3.3 of the full text rather than the abstract, are precise: on the Aider Polyglot 50-turn pass rate, GPT-4o moves from 19.8% with diff to 45.8% with string replacement; GPT-4.1-mini from 62.9% to 67.8%; and GPT-5 from 94.9% to 96.0% — the representation gap shrinks almost to nothing as the core model strengthens. Lita's own conclusion is that replacing diff-based editing with string replacement significantly improves edit success, especially for smaller models with weaker instruction-following ability, and it generalizes this into the *Agent Complexity Law*: the performance gap between agents of differing complexity shrinks as the core model improves, converging toward negligible difference. The venue is not stated on the arXiv record. The weak-model lesson is decisive for this component: string replacement works by lifting the formatting burden — file location, matching, uniqueness, write, encoding, rollback, syntax check — off the model and onto the harness, which is exactly the division of labour a weak model needs. But Lita does not prove string replacement is universally best; it proves representation interacts strongly with model capability, which is the caution the outliers below sharpen. ### 2.3 The structured-action-space result: CODESTRUCT **CODESTRUCT** [3] attacks the assumption beneath both diff and search/replace, that code should be edited as text at all. It reframes the codebase as a structured action space: the model operates on named AST entities rather than text spans, retrieving complete syntactic units with readCode and applying syntax-validated transformations to semantic program elements with editCode, so brittle string matching against unstructured text — which frequently fails on formatting drift or ambiguous patterns — is replaced by operations the harness locates and validates against the repository's own parser. The reported results are in the abstract and confirmed against the primary source: across six models on SWE-bench Verified, CODESTRUCT improves Pass@1 by 1.2–5.0 percentage points while cutting token consumption by 12–38% for most models, and on CodeAssistBench it holds consistent accuracy gains of +0.8–4.4% with cost reductions up to 33%. The result that matters most for a weak-model harness is the distribution of the gain: models that frequently fail to produce valid patches under text-based interfaces benefit most, with GPT-5-nano improving by 20.8 points as empty-patch failures fell from 46.6% to 7.2%. The venue is confirmed — accepted at the ACL 2026 main conference, aclanthology.org/2026.acl-long.607 — with a minor author-name alias (the arXiv and anthology list the second author under different names, "Joe Hsu" versus "Chao-Chun Hsu"). The weak-model implication is the strongest single warrant in this component's review: the weaker the model, the more value structure-aware editing creates, because the harness already knows the file, the byte range, the AST node, the current syntax, and how to reparse after the edit, and does not ask the model to re-derive any of it. ### 2.4 The structure-aware-diff result: To Diff or Not to Diff? **To Diff or Not to Diff?** [4] occupies the middle ground between full-text editing and pure AST operations, and it contributes two things: a structure-aware representation and an explicit demonstration that no single format is optimal. It first observes that conventional diff formats are generationally unnatural — fragile offsets and fragmented hunks make edits hard for an LLM to emit — and introduces BlockDiff and FuncDiff, structure-aware diff formats that represent changes as block-level rewrites of syntactically coherent units such as control structures and functions, aligned to tree-sitter AST nodes; contiguous unstructured or malformed line regions, such as import statements or syntax-error zones, are encapsulated into special fine-grained nodes so that a local modification is not improperly promoted to a coarse-grained parent. It then introduces AdaEdit, which trains the model to switch per-sample between a diff format and full-code generation, choosing whichever is most token-efficient for that instance. The results match full-code accuracy while reducing both latency and cost by over 30% on long-code editing tasks, and the paper states the lesson verbatim: "any edit format is not universally optimal," since the overhead of a diff format can exceed full-code generation when changes are pervasive. The venue is confirmed (Findings of ACL 2026), and the tree-sitter alignment and the non-universality claim are in the full text rather than the abstract. The weak-model implication is that the representation should be *adaptive to the change's structure*, not merely chosen once: a one-line change is cheaply expressed as a search/replace or block rewrite, while a pervasive rewrite may be cheaper and more reliable as a full replacement of the entity — and the choice is a deterministic classification, not a per-candidate model gamble. ### 2.5 The representation-isolation outlier: Diff-XYZ **Diff-XYZ** [5] is the outlier that prevents over-learning from Lita, because it isolates edit representation itself as the experimental variable rather than measuring it through an interactive agent. Its benchmark is built on real-commit triples of old code, new code, and diff, and it evaluates three distinct abilities — applying a diff, reverse/anti-applying it, and generating one — while comparing alternative representations such as traditional unified diffs and search/replace forms. The finding is not "diff bad, search/replace good"; it is that the best representation changes with the task and the model size. The authors report that search/replace works best for larger models across most tasks, that structured unified-diff variants are close but slightly weaker, and that smaller open models benefit little from any format choice — so representation interacts with model size and with the operation, and no format deserves universal status merely because one benchmark favored it. Diff-XYZ and Lita study different things and both belong in this review: Lita asks whether an interactive agent can reliably modify a repository under a given format, Diff-XYZ asks whether a model can understand or generate particular representations at all. The weak-model implication is the empirical basis for the honourable mentions' observation that the ecosystem converged on exact-match search/replace: a 7B local model and a frontier model do not have the same reliable format, and the format that suits one cannot be assumed for the other. This is what makes P7 (benchmark the representation, never standardize by convention) a first-class requirement rather than a nicety. ### 2.6 The collateral-change outlier: Edit, But Verify **Edit, But Verify** [6] is the unusual paper in this row because it measures the *tool* rather than the model: it audits instructed-editing benchmarks — of which a survey of over 150 code benchmarks finds only two, CanItEdit [7] and EDIT-Bench, actually target instructed code editing with human-authored instructions and test-based evaluation — to ask whether they can even see an edit misbehave. The answer is that they mostly cannot. 59% of EDIT-Bench's low-coverage test suites would not detect modifications outside the requested edit region, and 56% of all tests scope exclusively to the edited code; the authors conclude that both benchmarks answer "was the edit made?" more reliably than "was only the requested edit made?", motivated by the practical finding that LLM editing tools routinely introduce modifications beyond the requested scope. The 59% figure is in the abstract; the 56% figure is in the full text. The collateral-change failure mode this exposes is precisely the one a whole-file rewrite that silently reformats unrelated code, or a fuzzy search/replace that matches the wrong occurrence, exploits — and it is the reason the word "reliably" in this component's thesis needs its own metric (the collateral-change rate of Section 6) rather than being subsumed into a solve rate that cannot distinguish a clean edit from a leaky one. For completeness, the benchmark that Edit, But Verify audits alongside EDIT-Bench — **CanItEdit** [7], Cassano et al., arXiv:2312.12450 — is a benchmark of 105 code-editing problems across corrective, perfective, and adaptive edits whose contribution is to show that even GPT-3.5-Turbo beats the best open model at editing and that fine-tuning open models on a permissively-licensed training dataset closes much of that gap. It does NOT analyze edit formats: any claim that format reliability varies by model, or that models anchor context text with varying tightness for a substitution, should not be attributed to it — those findings belong to the format strand of this review (Lita [2], To Diff or Not to Diff [4], Diff-XYZ [5]), not to the CanItEdit benchmark. ### 2.7 Honourable mentions Six recent works sharpen specific decisions without anchoring the component. **SWE-Edit** [8] — cross-referenced from component 09 — splits a coding agent into a reasoning agent, a Viewer that extracts relevant code, and an Editor that executes modifications, training the Editor to adaptively select between exact find/replace and whole-file rewrite rather than committing to one fixed representation; on SWE-bench Verified it raises resolve by 2.1 points and cuts inference cost by 17.9%. **Cascaded Code Editing** [9] — also cross-referenced from 09 — is the semantic/mechanical cascade in which a large model produces a concise edit sketch and a specialized small model applies it, the same sketch/apply split this component realizes with deterministic software as the applier rather than a second model. **Inside the Scaffold** (Rombaut) [10] is the source-code taxonomy of thirteen agent scaffolds that independently found edit formats converge: the `str_replace_editor` primitive appears in 5 of 13 scaffolds (OpenHands, SWE-agent, Codex CLI's apply_patch in freeform mode, Agentless as one of three repair output formats, and one more), a count that carries a real tension — it lists OpenHands among the five, which conflicts with OpenHands' own paper and its line-range editor [12], so the two primary sources disagree and the count should be cited with that caveat. **CodeEditorBench** [11] is the editing-only benchmark of 7,961 code-editing tasks across four scenarios — Code Debug, Code Translate, Code Polish, and Code Requirement Switch (the often-repeated "optimize" scenario is wrong; the correct arXiv ID is 2404.03543, not the 2404.16772 sometimes attributed) — on which closed-source models, particularly Gemini-Ultra and GPT-4, outperform open models. **OpenHands** [12] (Wang et al., ICLR 2025) is the open platform whose primary editing primitive is `edit_file(start, end, content)`, a line-range replacement, NOT the `str_replace_editor`; the frequently repeated claim that its CodeAct agent reached ">50% on SWE-bench Lite with GPT-4o" is false — the paper's own Table 4 reports 22.0% for gpt-4o on SWE-bench Lite (the 53.1 figure is GPQA, 79.3 is BIRD), and the >50 SWE-bench Lite number does not exist in the paper. **Coeditor** [13] (Wei et al., ICLR 2024) is the pre-agent model that predicts line-diff edits from recent contextual changes within a codebase, the line-diff-prediction ancestor of the sketch/apply split. Together these are the reminder that the ecosystem has been converging, messily, on search/replace-style application, and that a harness's edit primitive is both a measured design axis and an interoperability asset. ### 2.8 The classical roots The modern lines rest on classical results, cited here for lineage rather than numbers. **GumTree** (Falleri et al., ASE 2014) is the AST-differencing substrate for tree-level edits, the lineage of computing change at the syntax level rather than the text level. The **deterministic transform tier** — OpenRewrite, jscodeshift, Semgrep autofix, codemods — is where the model emits a rule or a trigger and the tool performs the mechanical application, the strictest ancestor of this component's apply-outside-the-LLM principle and the one deterministic AST-transform layer that is strictly more reliable than token-level edits for migrations. The **SWE-bench harness** grounds the evaluation contract: gold patches are unified diffs, applied mechanically by a test-patch application that the harness's edits must satisfy, so the developer-facing representation is a diff by construction. **Anthropic's `text_editor` tool** is the origin of the `str_replace_editor` primitive that the scaffold taxonomy observes in the wild [10], the exact-match search/replace now the ecosystem default. And **CoEdIT** (Raheja et al., EMNLP 2023) is the instruction-tuned editing model, the model-side complement to the harness-side mechanisms this component specifies. These six appear throughout the program's later components; here they are the substrate on which the deterministic write path stands. ## 3. Design Principles Seven principles follow from the review, each tied to the evidence above. **P1 — Editing is an interface-design problem, not plumbing.** The edit primitive — its shape, its feedback, the validation around it — is a first-class design axis that materially moves agent performance, not a mechanical detail. SWE-agent is the warrant: it treats editing as an interface-design problem and builds LM-oriented commands with immediate feedback, and its lint-and-revert guard was one of the largest single ablation gains in the paper [1]. The harness should therefore treat the edit primitive as an ablatable object with its own success metric, exactly as it treats retrieval or planning, never as a fixed convenience it inherits from Git. **P2 — Minimize representational work: the model-facing and developer-facing representations need not be the same.** The model should not bear extra difficulty merely because the unified diff happens to be convenient for Git. The model emits an LM-friendly operation — an old-semantic-content and new-semantic-content pair, an entity operation — the harness applies it deterministically, and the harness generates the git diff afterward, so the developer and the version-control system still see the representation they expect. SWE-agent's demonstration that an LM-specific edit command outperforms a generic shell [1] and Lita's demonstration that string replacement beats diff for weaker models [2] are the warrant. The model-facing representation is chosen for the model; the developer-facing diff is generated by the harness. **P3 — Representation is model-dependent, and the default for weak models is exact replacement over positional formats.** The edit format is a measured variable with a model-size interaction, not a fixed convention. Lita's ablation shows string replacement beats diff most for the weakest models, with the gap shrinking as the model strengthens [2]; Diff-XYZ confirms the interaction, with search/replace best for larger models and small models benefiting little from any format [5]. The default for a weak-model harness is therefore exact search/replace over localized spans — the cheapest representation that applies and reparses reliably — with positional formats (line numbers, unified diffs) treated as last resorts rather than defaults. **P4 — Prefer entity/AST structure over positional text; the weaker the model, the more structure-aware editing buys.** Wherever the language parser supports it, editing should operate on named AST entities and syntactic units rather than raw text spans, and the harness should locate and validate the target itself rather than asking the model to re-derive byte ranges. CODESTRUCT is the warrant: structure-aware readCode/editCode improved Pass@1 by 1.2–5.0 points while cutting tokens 12–38%, with the weakest model improving by 20.8 points and empty-patch failures falling from 46.6% to 7.2% [3]. To Diff or Not to Diff shows the structure-aware diff format — block-level rewrites aligned to tree-sitter AST nodes, malformed regions wrapped so local edits are not promoted — matches full-code accuracy at over 30% lower latency and cost [4]. The principle is that the harness already knows the file, the node, the byte range, and how to reparse; it should not ask a weak model to prove it can locate the same thing. **P5 — Apply–verify–revert: deterministic application outside the LLM, with a parse/lint gate that rolls back on failure.** The transformation is applied by deterministic software, not by the model rewriting the file, and every apply is followed by a verification that the result parses and lints; a failure rolls the repository back atomically to its pre-application state so a malformed edit never persists and the agent never reasons over a corrupted file. SWE-agent's edit-lint-and-revert guard is the direct ancestor [1]. The point is that a failed apply is a harness failure, not a reasoning failure: the gate must reject a malformed or ambiguous edit at the cheapest possible stage so that the expensive downstream validation only ever sees a syntactically valid, uniquely-targeted repository change. **P6 — Gate collateral change: the resulting diff must stay inside the localized scope.** An edit is not reliable merely because the intended change landed; it is reliable only if nothing else moved. Edit, But Verify shows the benchmarks used to compare edit tools mostly cannot see out-of-scope modifications — 59% of low-coverage suites would not detect them, 56% of tests scope exclusively to the edited code — precisely because editing tools in practice introduce them, and whole-file rewrites and fuzzy search/replace are the mechanisms that leak [6]. The harness must therefore diff the repository after an apply and verify that the change falls inside the localized scope, flagging any bleed as a failure rather than accepting a green "the edit was made." **P7 — Benchmark the representation per model and change type; never standardize by convention.** Because representation interacts with model size and with the operation, the right representation is an empirical question for the specific model and change shape in use, not a convention to be settled once. Diff-XYZ isolates representation across apply/anti-apply/generate and shows no format is universally optimal [5]; Lita shows the representation gap is a function of model strength [2]; To Diff or Not to Diff states that "any edit format is not universally optimal" [4]; and the Aider leaderboard is the longest-running public exercise of exactly this per-model measurement. The harness should run its own isolated edit benchmark over its own model — whole-file rewrite, search/replace, AST/entity operation, diff — and choose per model and change type from the evidence, not from research averages computed on other models. ## 4. The Architecture The pipeline is a sequence of stages; every node is labeled D (deterministic software) or L (a learned model). The invariant that governs the whole is: *the L column contains exactly one entry — a single, exceptional, schema-constrained adjudication call that fires only when the deterministic machinery leaves a genuine ambiguity — and every other step is deterministic software on CPU.* The deterministic path is the default; the single learned call is the exception that fires only when scope classification genuinely cannot decide the representation, and it emits a single constrained choice rather than free-form output. The concrete input is the edit intent inherited from component 09: the candidate change that should land, already expressed as a semantic modification over a known location. The flow, from intent to committed repository state: 1. **Edit-scope classification [D].** The intended modification is classified deterministically by its scope and structure into one of a fixed ladder of edit classes — token/expression, statement, function/entity, file, multi-file. Scope is inferred from the change's own shape: how much of a single syntactic unit it touches, whether it crosses a unit boundary, whether it spans a whole entity or file. This is a deterministic classification over the intent and the repository's structure, mirroring the readCode/editCode entity boundary of CODESTRUCT [3]; nothing here invokes a model. 2. **Edit-representation selection [D].** A deterministic ladder selects the lowest-complexity representation capable of expressing the classified scope: search/replace over an exact-match span by default; an AST/entity transform when the language parser supports it for the target entity (per P4, preferred wherever the parser allows) [3]; a bounded rewrite of the whole entity when the change is genuinely structural and too pervasive for localized hunks (per To Diff or Not to Diff, pervasive changes may be cheaper and more reliable as a rewrite) [4]. This is a deterministic decision, not a model choice — the representation is chosen by the scope and by what the parser supports, mirroring the adaptive per-change selection these papers train but realizing it deterministically. 3. **Representation adjudication [L].** *The single learned node, and the sole entry in the L column.* A single weak-LLM call selects the representation ONLY when the deterministic ladder of step 2 leaves the choice genuinely ambiguous — for example, a change expressible either as a localized search/replace or as an entity transform, where scope classification is uncertain about whether it crosses a unit boundary. The call emits a single choice from a fixed, schema-constrained set, at temperature zero, in one call, and it fires only on genuine ambiguity: the default is deterministic, and this step is the exception that the deterministic ladder cannot resolve. It is deliberately narrow — choose among a small enumerated set of representations — because that is the one case where the two viable representations differ in reliability enough that adjudicating is worth a model call, and even then the model is not touching repository bytes. 4. **Edit application [D].** A deterministic transformer applies the chosen representation outside the LLM: an exact-match search/replace with a uniqueness check (rejecting zero or multiple matches before writing), an AST/entity transform performed against the repository's parser, or a bounded rewrite of the whole entity. The result is then reparsed. This is P5 made concrete: the harness, not the model, performs the byte-level transformation, so a correct semantic decision is not lost to a formatting slip [1], and the developer-facing unified diff is generated by the harness afterward rather than demanded of the model (P2). 5. **Uniqueness / parse / lint gate [D].** The applied result is checked by deterministic gates: reject an ambiguous target (zero or multiple matches), reject a result that does not parse, reject a result that does not lint; on any rejection the repository is rolled back atomically to its pre-application state. This is P5's apply–verify–revert discipline [1]: a malformed or ambiguous edit never persists and never reaches downstream validation, so the landed state handed onward is syntactically valid and uniquely targeted by construction. 6. **Collateral-change check [D].** The post-apply diff is compared against the localized scope declared in step 1: it must fall inside that scope. Any bleed — lines outside the target region changed, an unrelated symbol touched, a whole-file rewrite that reformatted surrounding code — flags the edit as a failure and rolls it back. This is P6, the Edit-But-Verify gate [6]: the edit is accepted only if ONLY the requested edit was made. 7. **Commit + anchor refresh [D].** The transaction is snapshotted and committed, and anchors are refreshed so no subsequent edit reuses stale line numbers or byte offsets from before this mutation. Line numbers are the weakest anchor: the file changes under the agent's own edits, and indices from an earlier round are lies by a later one, so every landed edit refreshes the coordinate space the next edit will address. The target is explicit and checkable: the L column holds exactly one entry — the representation-adjudication call, firing only on genuine ambiguity — and every other stage (scope classification, representation selection, application, uniqueness/parse/lint gating, collateral-change checking, commit and anchor refresh) is deterministic software on CPU. Any proposed addition that would put a language model elsewhere in this stage — a learned representation chooser that runs by default, a model-in-the-loop rewriter of a failed apply, a model that emits unified diffs directly — is a regression against P1–P7 and the L-column invariant, and must clear the same bar as in earlier components: beat the deterministic stage on the honest metrics of Section 6, on held-out repositories, at a defensible cost, or be rejected. The edit mechanism's whole point is to keep the model out of the repository's bytes; the single learned adjudication is the narrow exception where a model's judgment genuinely beats the deterministic tie-break, and even it never touches a byte. ## 5. Recursive Self-Improvement Protocol Component 10 of 27 follows the program's uniform protocol: the executable specification is written to 100%, round 1 lands at approximately 80% of the specified behavior, and later rounds close the gap. Each round is A/B-gated against the honest metrics of Section 6 — never the bare end-to-end solve rate alone, which would let downstream validation quality mask editing quality. The deterministic stages (1, 2, 4–7) improve by direct engineering, measured by ablation against a naive baseline that lets the model emit and apply raw edits with no surrounding gates. The single learned stage (3) improves only by direct improvement to the adjudication — a better schema-constrained prompt, a better criterion for when the deterministic ladder is genuinely ambiguous, a better threshold for firing the call at all — measured by whether firing it on ambiguous cases lands more cleanly than letting the deterministic tie-break decide. And because P5 and P6 hold that apply–verify–revert and the collateral gate are correct defaults, a *removal* is as much an improvement as an addition: any gate, any uniqueness check, any collateral check, any anchor-refresh step whose removal does not degrade the honest metrics is deleted, and the "never add an editing mechanism because it sounds sensible" discipline of Section 6 is thereby made mechanical. The edit log is diffable as it changes, so an editing regression — a rising apply-failure rate, a collateral-change leak, a drift toward whole-file rewrites — is visible in the produced diffs long before it surfaces as a failed downstream solve. ## 6. Measurement & Evaluation The editing mechanism is measured *separately* and *honestly*, in five instruments plus a set of explicit caveats, because a stage that cannot be scored apart from its downstream validators cannot be diagnosed apart from them — and because the collateral-change outlier shows that a solve rate alone cannot even see a leaky edit [6]. **Apply-success rate.** The fraction of intended edits that apply cleanly — a unique target matched, the transformation applied, the result parsing and linting — the direct score of the application and gate stages (steps 4 and 5). A failed apply is a HARNESS failure, not a reasoning failure: it means the channel between a correct decision and the repository bytes is failing, which is exactly the failure Lita and SWE-agent attribute to edit friction rather than missing reasoning [1][2]. SWE-Edit's edit-success rate (93.4% rising to 96.9% with its decomposition) is the external reference for what a mature harness should show [8]. **Collateral-change rate.** The fraction of applies whose resulting diff bleeds outside the localized scope declared before the edit — the Edit-But-Verify metric [6]. This is the instrument that makes P6 falsifiable: it catches the whole-file rewrite that silently reformats unrelated code, the fuzzy search/replace that matches the wrong occurrence, the entity transform that touches a sibling symbol. A harness with a low apply-failure rate but a high collateral-change rate is landing edits "successfully" while corrupting the repository, and only this instrument sees it. **Representation robustness.** The per-model, per-change-type apply success across search/replace versus AST/entity transform versus bounded rewrite — the Diff-XYZ / Lita instrument [2][5], and the empirical heart of P7. It reports, for this harness's model and for each change scope in step 1, which representation applies most reliably, so that the deterministic ladder and the adjudication trigger are tuned to evidence rather than to convention or to research averages computed on other models. **Solve rate / cost / tokens.** The end-to-end guard: does the whole pipeline — including this stage — resolve tasks at an acceptable cost? This is deliberately not the primary instrument, because it cannot distinguish an editing failure from a validation or generation failure; it is the guard that ensures the editing mechanisms are not bought at the price of the pipeline's overall competence. **Ablation.** The instrument that enforces the discipline of Section 5 mechanically: remove each mechanism — the lint gate (apply without reparse/rollback), the collateral-change check (accept any diff that applies), the deterministic representation ladder (force whole-file rewrites, or force search/replace everywhere), the ambiguity L step (never adjudicate, always take the deterministic tie-break) — in turn, and measure the honest metrics with it absent. A mechanism is *deleted* if its removal does not degrade the honest metrics, and is kept only if it demonstrably earns its place. This is the "never add an editing mechanism because it sounds sensible" rule turned into a standing gate. Two honest caveats close the section. First, the strong-model-transfer caveat: the headline numbers of Section 2 — Lita's 19.8%→45.8% for GPT-4o and its near-vanishing gap by GPT-5 [2], CODESTRUCT's +1.2–5.0pp with its 20.8-point GPT-5-nano outlier [3] — were obtained with models far stronger than this harness's target, and a weak model should not be expected to reproduce them; indeed the entire architecture (P3, P4, P5) exists precisely because a weak model underperforms on raw editing, and the apply-success and representation-robustness instruments are the ones that will show whether the deterministic stages are carrying that load. Second, the held-out and memorization caution inherited from the earlier components: a model that has memorized a repository's shape — or a benchmark's reference patches — will score well in-benchmark without the editing mechanism having done constructive work, so all editing metrics must be reported on held-out and out-of-benchmark repositories, exactly as the generation and localization metrics were. ## 7. Conclusion Editing is the write path of the coding-harness program: component 09 decided what should change, and component 10 decides whether, and exactly how, it lands. This paper has argued that editing should be a deterministic transformation service behind the model, not free-form repository manipulation — that the harness should classify the intended modification by scope and structure, select the lowest-complexity edit representation capable of expressing it, prefer entity-aware or exact replacement operations over positional formats for weak models, apply the transformation outside the LLM, and gate the resulting repository state through uniqueness, parsing, linting, and collateral-change checks; and that edit representations themselves must be benchmarked per model and change type rather than standardized by convention, because the model-facing representation and the developer-facing representation need not be the same thing — the harness generates the diff afterward. It has argued, on the strongest results in its review, for the thesis in full: the edit primitive is an interface-design problem, not plumbing, whose lint-and-revert guard is a large single ablation gain [1]; representation moves agent performance most where models are weakest, with the gap shrinking as the model strengthens [2]; structure-aware editing over named AST entities buys most precisely where models are weakest [3]; no edit format is universally optimal, and the adaptive choice of representation is a deterministic classification of the change's structure [4]; representation interacts with model size and operation, so it must be measured, not assumed [5]; and the benchmarks used to compare editing tools mostly cannot see out-of-scope modification, so "reliably" needs a collateral-change metric of its own [6]. The single learned decision is the representation-adjudication call that fires only on genuine ambiguity; everything around it — scope classification, representation selection, deterministic application, uniqueness/parse/lint gating, the collateral-change check, and commit-and-anchor-refresh — is deterministic software on CPU, so the L column holds exactly one entry and editing is audited deterministically. For a weak model, the consequence is the design's dividing line made concrete: *the LLM decides what the change ought to mean; the harness turns that decision into safe, validated, in-scope repository bytes, and emits the diff.* The honest metrics of Section 6 — above all the apply-success rate that separates apply failure from reasoning failure, and the collateral-change rate that no solve rate can see — decide whether the editing mechanism is earning its gates or quietly letting a correct decision die at the boundary of the disk. --- ## References 1. John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. *SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering.* 2024. arXiv:2405.15793. *(Anchor — the edit-specific result is the lint-and-revert guard, one of the largest single ablation gains; "NeurIPS 2024" is not stated in the arXiv record — unconfirmed. Cross-referenced from context construction. SWE-agent 2.0 (2025) later adopted the simpler str_replace_editor primitive.)* 2. Hankun Dai, Maoquan Wang, Mengnan Qi, Yikai Zhang, Zijian Jin, Yongqiang Yao, Yufan Huang, Shengyu Fu, and Elsie Nallipogu. *Lita: Light Agent Uncovers the Agentic Coding Capabilities of LLMs.* 2025. arXiv:2509.25873. *(Venue caveat: no venue stated on the arXiv record. Numbers are in Table 3 / §3.3, NOT the abstract. Verified: Aider Polyglot 50-turn pass rate — GPT-4o diff 19.8% → string replacement 45.8%; GPT-4.1-mini 62.9% → 67.8%; GPT-5 94.9% → 96.0%. Source for the Agent Complexity Law.)* 3. Myeongsoo Kim, Joe Hsu (alias Chao-Chun Hsu), Dingmin Wang, Shweta Garg, Varun Kumar, and Murali Krishna Ramanathan. *CODESTRUCT: Code Agents over Structured Action Spaces.* ACL 2026 (main). arXiv:2604.05407. *(Venue confirmed: accepted at ACL 2026 main, aclanthology.org/2026.acl-long.607. Author-name alias note: arXiv "Joe Hsu" = anthology "Chao-Chun Hsu". Verified, all in abstract: readCode/editCode on named AST entities; +1.2–5.0 pp Pass@1 across six models on SWE-bench Verified; −12–38% tokens; GPT-5-nano +20.8 pp with empty-patch failures 46.6% → 7.2%; CodeAssistBench +0.8–4.4%.)* 4. Wei Cheng, Yongchang Cao, Chen Shen, Binhua Li, Jue Chen, Yongbin Li, and Wei Hu. *To Diff or Not to Diff? Structure-Aware and Adaptive Output Formats for Efficient LLM-based Code Editing.* Findings of ACL 2026. arXiv:2604.27296. *(Venue confirmed in the arXiv comment field. BlockDiff/FuncDiff block-level rewrites aligned to tree-sitter AST nodes; unstructured/malformed regions "encapsulated into special fine-grained nodes" — "pseudo-node" is a faithful paraphrase, not the paper's word; AdaEdit switches per-sample; matches full-code accuracy with latency and cost cut >30%. Verbatim: "any edit format is not universally optimal.")* 5. Evgeniy Glukhov, Michele Conti, Egor Bogomolov, Yaroslav Golubev, and Alexander Bezzubov. *Diff-XYZ: A Benchmark for Evaluating Diff Understanding.* 2025. arXiv:2510.12487. *(Outlier — isolates edit representation over apply/anti-apply/generate on real-commit triples. Finding: search/replace best for larger models on most tasks; structured udiff variants close but weaker; smaller open models benefit little from any format. Cross-referenced from component 09.)* 6. Amir M. Ebrahimi and Gopi Krishnan Rajbahadur. *Edit, But Verify: An Empirical Audit of Instructed Code-Editing Benchmarks.* 2026. arXiv:2604.05100. *(Collateral-change outlier. Verified: 59% of EDIT-Bench's low-coverage suites would not detect modifications outside the edit region (in abstract); 56% of tests scope exclusively to the edited code (full text). Editing tools routinely introduce out-of-scope modifications in practice.)* 7. Federico Cassano, Luisa Li, Akul Sethi, Noah Shinn, Abby Brennan-Jones, Jacob Ginesin, Edward Berman, George Chakhnashvili, Anton Lozhkov, Carolyn Jane Anderson, and Arjun Guha. *"Can It Edit? Evaluating the Ability of Large Language Models to Follow Code Editing Instructions."* 2024. arXiv:2312.12450. *(ID correction: NOT 2403.04002 (astronomy) or 2406.08446 (OLMES) — both wrong; correct ID 2312.12450. Benchmark of 105 editing problems; open models lag closed (even GPT-3.5-Turbo beats the best open model); training dataset closes much of the gap. It does NOT analyze edit formats — do not attribute format-reliability claims, or any concept of varying context-anchoring tightness for substitution, to it.)* 8. Yikai Zhang, et al. *SWE-Edit: Rethinking Code Editing for Efficient SWE-Agent.* 2026. arXiv:2604.26102. *(Cross-referenced from component 09. Adaptive find-replace / whole-file-rewrite selection; resolve 69.9% → 72.0%; edit-success 93.4% → 96.9%; cost −17.9%. No venue in the arXiv record.)* 9. Chaozheng Wang, et al. *Cascaded Code Editing: Large-Small Model Collaboration for Effective and Efficient Code Editing.* FSE 2026. arXiv:2604.19201. *(Cross-referenced from component 09. Sketch/apply split; Aider Pass@2 +11.1% relative / +7.5 pp absolute with DeepSeek R1 sketch + fine-tuned applier; cost −18.7%.)* 10. Benjamin Rombaut. *Inside the Scaffold: A Source-Code Taxonomy of Coding Agent Architectures.* 2026. arXiv:2604.03515. *(Single-author source-code taxonomy of 13 agent scaffolds; the str_replace_editor primitive appears in 5 of 13. Caveat: the count lists OpenHands among the five, which conflicts with OpenHands' own paper [12] and its line-range editor — independent primary sources disagree; cite with care.)* 11. Jiawei Guo, et al. *CodeEditorBench: Evaluating Code Editing Capability of Large Language Models.* 2024. arXiv:2404.03543. *(ID correction: the 2404.16772 sometimes given is WRONG (a hep-ph paper); correct ID 2404.03543. Benchmark of 7,961 editing tasks. Four scenarios are Code Debug, Code Translate, Code Polish, Code Requirement Switch — "optimize" is NOT a scenario.)* 12. Xingyao Wang, et al. *OpenHands: An Open Platform for AI Software Developers as Generalist Agents.* ICLR 2025. arXiv:2407.16741. *(Venue ICLR 2025 confirmed in the arXiv comment field. Its primary editing primitive is edit_file(start, end, content), a line-range replacement — NOT str_replace_editor (the string does not appear in the paper). The ">50% on SWE-bench Lite with GPT-4o" claim is FALSE: the paper's Table 4 reports 22.0% for gpt-4o on SWE-bench Lite; the 53.1 figure is GPQA and 79.3 is BIRD.)* 13. Jiayi Wei, Greg Durrett, and Isil Dillig. *Coeditor: Leveraging Contextual Changes for Multi-round Code Auto-editing.* ICLR 2024. arXiv:2305.18584. *(Pre-agent line-diff prediction from contextual changes; ICLR 2024 confirmed in the arXiv comment field. The "sketch/apply" framing is an editorial inference, not the paper's own term.)* 14. Jean-Rémy Falleri, Floréal Morandat, Xavier Blanc, Matias Martinez, and Martin Monperrus. *Fine-grained and accurate source code differencing.* ASE 2014. *(Classical substrate — AST differencing for tree-level edits.)* 15. OpenRewrite / jscodeshift / Semgrep autofix (deterministic transform tier). *(Classical — the model emits a rule or trigger and the tool performs deterministic application; the ancestor of apply-outside-the-LLM.)* 16. SWE-bench harness (gold patches as unified diffs, mechanical test-patch application). *(Classical evaluation-side contract edits must satisfy.)* 17. Anthropic. *text_editor* tool. *(Classical — the origin of the str_replace_editor primitive now the ecosystem default.)* 18. Vipul Raheja, Dhruv Kumar, Ryan Koo, and Dongyeop Kang. *CoEdIT: Text Editing by Task-Specific Instruction Tuning.* Findings of EMNLP 2023. arXiv:2305.09857. *(Classical — instruction-tuned code editing as an NLP task, the model-side complement to harness-side mechanisms.)*