DEV Community

Devanshu Biswas
Devanshu Biswas

Posted on

Line-Range Edits Are Wrong on 93.14% of Three-Hunk Calls and Refuse 0.00% of Them

When you ask a model to change a document rather than write one, your prompt names a shape for the answer: the whole file back, a search block and its replacement, a unified diff, a line range, an anchor line.

That choice gets argued about as a token bill. It is not a token bill. It decides which of your failures you are told about.

Read it: https://dev48.infy.uk/prompt/day75-edit-formats.html

Nothing here simulates language

Nine documents are data. All 507 edit sites are enumerated. Every reply is serialized by a real emitter, put through a real string transformation, and applied by a real applier — so an outcome is decided by running the code, never by a formula. Exactly three numbers are declared, all three on sliders and all three labelled where they are used.

The parameter-free centrepiece

Put three hunks in one call. Enumerate every one of the 11,883 disjoint triples in the corpus.

format wrong refused
line ranges, applied top-down 93.14% 0.00%

Nine times in ten it produces a wrong document, and it never once declines. The mechanism is not subtle: the first hunk changes the line numbering, so hunks two and three land in the wrong place — and nothing in a line range can detect that, because a line number is always valid.

apply hunk at lines 10-12  ->  file is now 2 lines shorter
apply hunk at lines 40-45  ->  these are no longer the lines you meant
                               and there is nothing to notice
Enter fullscreen mode Exit fullscreen mode

Apply them bottom-up and the numbering problem disappears. Same format, same model, same call — one ordering decision between a correct edit and a silent corruption.

The general point

A format that can refuse tells you when it did not understand. A format that always applies converts every misunderstanding into a plausible-looking document. The ones that look most precise — line ranges, character offsets — are precisely the ones with no way to say that does not match.

Verifier 1,428,476 asserts, 516,883 in-page assertions, 0 failures.

Top comments (0)