Koda Showed How It Trained Next Edit Suggestions Model for Code Edit Prediction

Koda shared how it trained a Next Edit Suggestions model for autocompletion that attempts to predict not the next token, but the next meaningful code edit by a developer. This approach moves the IDE from ordinary completion to an assistant that understands refactoring flow, renaming, and minor batch fixes. NES differs from classical autocomplete in that it accounts for recent change history and operates not just under the cursor, but anywhere in the file.

The model can not only add code, but also delete or replace fragments. Practical scenarios for this mode are clear: bulk renaming, updating calls after signature changes, continuing an ongoing refactoring, replicating similar fixes, style alignment, dead code removal, and even minor lint fixes. At Koda, they believe that against the backdrop of the AI-agent boom, such a tool remains useful: many minor fixes are faster to confirm with a single keystroke than to formulate a separate prompt.

During training, the team first selected a base model under strict latency constraints. On their target GPU servers, developers measured inference speed and narrowed the selection to Qwen2.5-Coder-1.

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

The data source was anonymized partial logs of their own code-completion model accumulated over a year. These FIM-logs were grouped by user, session, and file to reconstruct chains of local code changes. The problem was that one real programmer fix in the logs often broke down into dozens of micro-events.

So engineers glued such subsequences into single meaningful changes using the Incremental Difference Detecting algorithm described in the NES research paper. After this, they separately filtered examples where the target fix was actually causally linked to the edit history, rather than simply being another logical piece of code. In the end, from millions of candidate samples, only several tens of thousands remained.

Additionally, the team upsampled replace-edits to better balance insertion, replacement, and deletion types. Next, Koda compared its 1.5-billion-parameter model with open NES solutions from Continue, Zed, and Sweep, and mentioned Cursor Tab, GitHub Copilot NES, and JetBrains AI Assistant as closed benchmarks.

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

0% and 20.4% respectively. On several datasets, the company gives higher priority to the Judge evaluation, as it is better suited for comparing models with different response formats.

By simple average, their model ranked first, and by weighted average result remained among leaders even against larger 7B and 8B parameter models. Separately, Koda highlights the NEP dataset as a more independent benchmark, since it is not 'native' to any of the compared systems. The feature already appeared in beta mode in the KodaCode 0.

9.0 plugin for VS Code. The team plans to further enrich context with similar code fragments and linter hints, and test larger models if they can maintain the required latency.

Another development direction is the plugin interface: for NES it is important not only to predict the fix, but also to show it in a way that allows the developer to quickly accept or reject the suggestion without losing momentum. Koda's story shows that the market for AI tools for programmers is not limited to agents that try to do everything at once. Between manual editing and fully autonomous execution, there is a large layer of tasks where the greatest value comes from fast, local, and predictable advice right in the editor.

If such models continue to grow in quality without losing speed, this class of assistants could become the most widespread format of AI in everyday development.