Koda details how it trained a Next Edit Suggestions model to predict code edits

Koda has explained how it trained a Next Edit Suggestions model for autocompletion that tries to guess not the next token but the developer's next meaningful edit. The approach moves the IDE from plain completion toward an assistant that understands the course of a refactoring, a rename, or a run of small repetitive fixes. NES differs from classic autocomplete in that it takes the history of recent changes into account and works anywhere in a file, not just under the cursor.

The model can do more than add code: it can also delete or replace fragments. The practical scenarios for this mode are clear: bulk renaming, updating calls after a signature change, continuing a refactoring already under way, replicating a repeated fix, aligning style, removing dead code, and even small lint fixes. Koda argues that, despite the boom around AI agents, such a tool remains useful: many small fixes are faster to accept with a single keystroke than to describe in a separate prompt.

For training, the team first picked a base model under a strict latency constraint. The developers measured inference speed on their target GPU servers and narrowed the choice to Qwen2.5-Coder-1.

5B and DeepSeek-Coder-1.3B. Based on the combined metrics, they chose Qwen as the base for supervised fine-tuning.

The data came from a year of accumulated, anonymized partial logs of Koda's own code-completion model. These FIM logs were grouped by user, session, and file to reconstruct chains of local code changes. The problem was that a single real edit by a programmer often broke up into dozens of micro-events in the logs.

So the engineers merged such subsequences into single meaningful changes using the Incremental Difference Detecting algorithm described in the NES research. They then separately filtered out examples where the target edit is genuinely causally linked to the editing history, rather than just being the next logical piece of code. In the end, only a few tens of thousands remained out of millions of candidate samples.

The team also upsampled replace edits to better balance insertions, replacements, and deletions. Koda then compared its 1.5-billion-parameter model with open NES solutions from Continue, Zed, and Sweep, and cited Cursor Tab, GitHub Copilot NES, and JetBrains AI Assistant as closed reference points.

On its own test set of 500 examples, Koda-next-edit scored 27.2% on Exact Match and 28.2% on Judge, while Zeta 2 got 17.

0% and 20.4% respectively. Across several datasets, the company gives higher priority to the Judge score, since it is better suited to comparing models with different response formats.

By simple average, its model came first, and by weighted average it stayed among the leaders even against larger 7B and 8B models. Koda also singles out the NEP dataset as a more independent benchmark, because it is not "native" to any of the compared systems. The feature has already appeared in beta in KodaCode 0.

9.0 for VS Code. Next, the team plans to enrich the context with similar code snippets and linter hints, and to test larger models if it can keep latency at the required level.

Another area of work is the plugin interface: for NES, it is not enough to predict an edit; it must also be shown so that the developer can quickly accept or reject the suggestion without losing pace. Koda's story shows that the market for AI tools for programmers is not limited to agents that try to do everything end to end. Between manual editing and fully autonomous execution lies a large layer of tasks where the most value comes from fast, local, predictable advice right in the editor.

If such models improve in quality without losing speed, this class of assistants may become the most widespread form of AI in everyday development.