Physics of Coding Agents: Part 1, Fit, Not Format at the Edit Interface

Source abstract

In a coding agent, the edit interface is where model and harness meet: to edit a file, the model must say where a change goes, by pointing at line numbers or by quoting existing code, as search/replace and patch formats require. Models become fluent in both forms from internet text in pretraining and from harness trajectories in post-training, and an interface fits a model when it asks for the forms the model writes reliably. In a controlled harness where only the edit interface varies, across six models, three benchmarks and more than 4,700 runs, we find that task success hides a poor fit. On large-file refactors, GPT-5.6-luna's line-range edit is accepted on the first attempt in 99% of runs, compared with 58% for search/replace, yet both solve the same share of tasks. Agents retry rejected edits, so the gap shows up as token cost. The interfaces also fail differently. A long quotation costs output and fails visibly, while a line range is cheap but a wrong one silently edits the wrong lines, most often off by a single line. Which form wins depends on the model, and given several formats, models reach for their habitual form rather than the one they write most fluently. Building on the two forms that natural text teaches every model, we introduce verified selection, in which the model gives a line range and quotes only its first and last lines, while the harness checks them and absorbs small offsets. On large-file refactors, compared with line ranges, it cuts silently broken first edits by 63% for GPT-5.6-luna and 92% for MiMo-v2.5-Pro; compared with search/replace, it solves 1.43-1.77x as many tasks per output token. On Microsoft's multi-file RefactorBench, it cuts broken first edits from 11 to 2. The lesson is fit, not format: models should express edit intent in a compact form they produce reliably, while harnesses handle verification and bookkeeping.