Next Edit Prediction in Dynamic Editing

• Next Edit Prediction is a predictive paradigm that forecasts subsequent modifications by leveraging current state, edit history, and user interactions.
• It employs diverse representations—from diff-based encodings to AST operations—to predict edit locations, content changes, and outcomes across domains like code and spreadsheets.
• Modular architectures separate location and content prediction, enhancing workflow efficiency while addressing challenges such as security risks and evaluation complexities.

Searching arXiv for recent and foundational papers on next edit prediction and related edit-prediction formulations. Next edit prediction is a family of predictive tasks in which a system infers a subsequent edit from a partially observed editing process. Across the literature, the predicted object ranges from a binary decision about whether a suggested edit will be rejected, to the location and content of the next code change, to a local edit operator on a visual program, to a future sequence of spreadsheet actions, and even to the number of edits an editor will make in a later time window. What unifies these settings is the use of current state, edit history, interaction traces, or user identity to forecast the next modification rather than merely completing text at the cursor (Mondal et al., 2022, Wei et al., 2023, Jones et al., 2024, Lu et al., 13 Aug 2025, Agrawal et al., 11 Jun 2026, Zhang, 2011).

1. Conceptual scope and task formulations

In code editing, next edit prediction is commonly formulated as conditional prediction of the next change given the current codebase and prior edits. Coeditor formalizes repository-level code auto-editing as

$P(\Delta u \mid \Delta_k \ldots \Delta_1, U),$

where $U$ is the original codebase, $\Delta_1,\ldots,\Delta_k$ are already-applied code changes in the same commit, $u$ is the target region, and $\Delta u$ is the next edit to apply (Wei et al., 2023). More recent IDE-oriented work defines the task more explicitly as predicting both location and content from current code state and interaction history. One formulation separates a location prediction function maximizing $P(L_{t+1}\mid C_t,H_t)$ from an edit suggestion function maximizing $$P(E_{t+1}^{\text{suggestion}} \mid C_t,H_t,L_{t+1})$$, with $H_t$ including code states, edit operations, and user behavior signals such as cursor moves, selections, and time spent (Chen et al., 4 Aug 2025). A related benchmark frames training as autoregressive generation of a next code version conditioned on <|original_code|>, <|edits_diff|>, and <|current_version|> (Lu et al., 13 Aug 2025).

Other domains preserve the same predictive core while changing the artifact and target. In visual program induction, the task is to predict a local edit operation $e$ that transforms a current program $z$ into $U$0 so as to improve similarity between the executed output and a visual target, and the edit network learns a conditional distribution $U$1 (Jones et al., 2024). In Stack Overflow post editing, the task is split into a binary classifier that predicts whether a suggested edit will be rejected and a rejection reason classifier that identifies one or more reasons if rejection is predicted (Mondal et al., 2022). In spreadsheets, the problem is posed as predicting one or more future UI actions $U$2 from spreadsheet state $U$3 and action history $U$4 (Agrawal et al., 11 Jun 2026). In temporal participation forecasting, the “next edit” object is not an edit operation but the number of edits a Wikipedia editor will make in the next 5 months, learned as a regression target $U$5 from temporal dynamics alone (Zhang, 2011).

This diversity suggests that “next edit prediction” is best understood as a predictive paradigm rather than a single benchmark. The predicted variable may be an edit script, an edit location, a content diff, a rejection outcome, a future factual update, or an action count. A plausible implication is that the field is organized less by output datatype than by the common requirement to model change trajectories rather than static artifacts.

2. Representations of edits, history, and context

A central design choice is how edits are represented. Several code-editing systems adopt explicit diff-based encodings. Coeditor represents code changes in a line diff format and encodes the target unit by inserting status tokens and edit-region placeholders such as \<1>, \<2>, …, <n>, while prior contextual changes are encoded with the same representation but with an empty edit region (Wei et al., 2023). CoEdPilot also operates on explicit edit objects $U$6 and predicts line-level edit types from $U$7, then concrete code changes for those lines (Liu et al., 2024). Overwatch moves from concrete AST edits to parameterized edit templates with holes and hole predicates, so that temporal patterns can link corresponding structural elements across multiple edits (Zhang et al., 2022).

Structural representations can be even more explicit. In the EditCompletion task, edits are modeled directly as AST operations—Move, Insert, Update, and Delete—and each operation is represented by the path between its source and target nodes in the AST. This allows the model to estimate $U$8 by learning the likelihood of the edit itself rather than the likelihood of the edited code (Brody et al., 2020). In tutoring systems, the Continuous Hint Factory generalizes edit-based hinting by embedding states through edit distance and then inferring what capable students would do next from similar states rather than identical ones (Paaßen et al., 2017).

Context construction is equally consequential. Modern next edit suggestion systems in AI-integrated IDEs assemble context from recently viewed code, edit history, structural context around the cursor, cross-file dependencies, file outline, diagnostics, and user action triggers such as text insertion, deletion, cursor movement, selection changes, undo/redo, auto-indentation, and empty-line insertion (Lyu et al., 6 Feb 2026). In Stack Overflow edit rejection prediction, context is instead derived from the original and edited post body plus user information, summarized into 15 texts and user-based features (Mondal et al., 2022). In spreadsheets, history is serialized as operation sequences such as INPUT, FILL_COLOR, BORDER_*, FONT_*, ALIGN_*, MERGE, AUTOFILL, and PASTE_FROM, with explicit ranges and values (Agrawal et al., 11 Jun 2026).

The literature therefore spans token, diff, tree-path, graph, and action-sequence representations. This suggests that representational adequacy depends on what aspect of “editness” must be preserved: local textual change, structural transformation, temporal workflow, or user–artifact interaction.

3. Predictive architectures and system pipelines

Most systems decompose next edit prediction into stages. Stack Overflow rejection prediction uses a three-component pipeline: a Feature Extractor computes 15 features; a Rejected Edit Predictor classifies the edit as rejected or accepted; and a Rejection Reason Classifier identifies one or more reasons using rules and small random-forest models (Mondal et al., 2022). NES for IDEs adopts a dual-model architecture consisting of an NES-Location Model for next edit location and an NES-Edit Model for next edit content, yielding a continuous Tab key interaction workflow (Chen et al., 4 Aug 2025). CoEdPilot similarly separates Subsequent Edit Analysis, Prior Edit Analysis, and Edit Generation, with an Edit-propagating File Locator, an Edit-propagating Line Locator, an Edit-dependency Analyzer, and an Edit-content Generator (Liu et al., 2024).

Architecturally, code-edit predictors range from fine-tuned LLMs to specialized long-context sequence models. Coeditor fine-tunes CodeT5-base with encoder block-sparse attention so that a query block for the target region can attend to multiple reference blocks representing prior edits and static-analysis signatures, while reference blocks do not attend to each other (Wei et al., 2023). Overwatch mines Edit Sequence Patterns from IDE traces and uses them to proactively offer automated edits when temporal context disambiguates intent (Zhang et al., 2022). In interactive next-token and next-line prediction after code edits, Positional Integrity Encoding modifies the key cache in RoPE-based transformers by removing the stale rotary matrices and reapplying the correct rotary matrices, so that only the edited subsequence must be re-encoded rather than the entire suffix (He et al., 2024).

Other domains use different learning machinery for analogous purposes. Visual program editing combines a one-shot model with an edit network in a bootstrapped finetuning loop; inference initializes a population from the one-shot model and evolves members of this population with the edit network (Jones et al., 2024). Photo-edit recommendation models edits as multimodal continuous outputs with hierarchical latent structure, using CGM-VAE for non-personalized multimodal edits and CGM-SVAE for user-specific style clusters and latent edit codes (Saeedi et al., 2017). A “who-edits-what” survival model for peer production estimates

$U$9

so that the probability an edit survives depends on user skill, item difficulty, and a user–item interaction term (Yardım et al., 2018).

A recurring pattern is modularity: location and content are often separated, local edits are often predicted relative to prior edits, and user or item factors frequently appear as independent signals. This suggests that next edit prediction is rarely treated as a monolithic generation problem.

4. Evaluation regimes and empirical measurements

Evaluation methods differ sharply across settings. In Stack Overflow edit rejection prediction, the best-performing model reports 69.1% precision, 71.2% recall, 70.1% F1-score, and 69.8% overall accuracy, and EditEx is reported to prevent 49% of rejected edits in the user experiment, prevent 12% rejections even in free-form regular edits, and reduce the median workload to half compared to the Stack Overflow edit system (Mondal et al., 2022). In code auto-editing, Coeditor reports exact-match accuracy rising from 34.7 up to 60.4 on a simplified single-round, single-edit task, and also reports substantial gains in a multi-round, multi-edit setting when conditioning iteratively on additional user edits (Wei et al., 2023). CoEdPilot reports edit-location accuracy of 70.8%-85.3%, edit content exact match rate of 41.8%, and BLEU4 score of 60.7 (Liu et al., 2024). NES reports 75.6% and 81.6% accuracy in two tasks of predicting next edit locations, alongside 91.36% ES and 27.7% EMR for intent-aligned edits (Chen et al., 4 Aug 2025).

Benchmarks also differ in whether they evaluate single predictions or interactive loops. The spreadsheet benchmark introduces an online evaluation in which the system predicts after each user action, the prediction is accepted or rejected, the future action sequence is updated upon acceptance, and the process repeats until the target spreadsheet is obtained. Its principal measures include User Actions Saved, Acceptance Rate, Precision, and Predictability Coverage (Agrawal et al., 11 Jun 2026). This is notably different from teacher-forced offline evaluation of one-step prediction. The same paper reports, under a single-action repredict setting with GREEDY acceptance, UAS 32.7%, AR 29.4%, PREC 41.6%, and PCOV 24.8% for GPT-5-R, while ALWAYS-accept yields negative savings (Agrawal et al., 11 Jun 2026).

Temporal forecasting uses yet another metric family. Wikipedia participation prediction is evaluated with RMSLE, and the “zeditor” submission achieves 41.7% improvement over the WMF baseline model (Zhang, 2011). Edit survival prediction reports average log-likelihood and AUPRC; on French Wikipedia, Interank full reaches average log-likelihood $\Delta_1,\ldots,\Delta_k$0 and AUPRC 0.413, while on the Linux kernel it reaches $\Delta_1,\ldots,\Delta_k$1 and 0.527 (Yardım et al., 2018).

The breadth of metrics indicates that next edit prediction cannot be reduced to exact-match generation. Systems are also evaluated by workflow savings, abstention quality, calibration, survivability, and forecast error.

5. Major application domains

Domain	Input signal	Predicted object
Code editing and IDEs	Code state, prior edits, interaction history	Next edit location and content
Knowledge and peer-production systems	Post text, user features, user–item histories	Rejection, survival, or future edit count
Visual, educational, and productivity systems	Current artifact state and target or trace	Local edit, hint, or next action

Code editing is the most extensively developed domain. Repository-level models learn from commit histories, edit chunks, static-analysis signatures, and cross-file dependencies to predict subsequent edits that follow an initial change (Wei et al., 2023, Liu et al., 2024, Lu et al., 13 Aug 2025). AI-integrated IDE work explicitly contrasts next edit suggestion with cursor-based completion and chat-based editing, arguing for proactive, intent-driven, instruction-free systems that can operate across lines and files (Chen et al., 4 Aug 2025, Lyu et al., 6 Feb 2026).

Knowledge platforms and collaborative systems broaden the notion of edit prediction beyond content generation. On Stack Overflow, prediction targets whether a suggested edit will be rejected and why (Mondal et al., 2022). In Wikipedia and the Linux kernel, the target is whether an edit survives, modeled only from who edits what and whether the edit is accepted (Yardım et al., 2018). A separate Wikipedia forecasting line predicts how many edits an editor will make in the next 5 months from temporal dynamics only (Zhang, 2011). News revision modeling asks whether a sentence in an older draft will undergo a future factual update, formalized as $\Delta_1,\ldots,\Delta_k$2 (Spangher et al., 2024).

Visual, educational, and productivity systems show that the same paradigm applies outside text and code. Visual program induction predicts a DSL-aware local edit that improves a rendered output relative to a target image or voxel grid (Jones et al., 2024). The Continuous Hint Factory predicts what capable students would do next in open-ended tasks by averaging over similar states in a continuous embedding induced by edit distance (Paaßen et al., 2017). Spreadsheet systems predict future actions over a 2D grid, including content entry, formatting, merge, paste, and autofill (Agrawal et al., 11 Jun 2026). Photo-edit recommendation predicts multimodal continuous slider adjustments and personalizes them through user-level latent clusters (Saeedi et al., 2017).

Taken together, these domains show that the essential object is not “code completion” but the evolution of an artifact under repeated, structured modification.

6. Security, limitations, and unsettled questions

Next edit prediction raises risks that do not arise in ordinary local completion. A systematic security study of Next Edit Suggestions in AI-integrated IDEs finds that NES retrieves a significantly expanded context, including imperceptible user actions and global codebase retrieval, and that NES is susceptible to context poisoning and is sensitive to transactional edits and human-IDE interactions (Lyu et al., 6 Feb 2026). This establishes that richer context retrieval enlarges attack surface as well as predictive power.

Several lines of work expose other limitations. Edit-survival models that use only who-edits-what are broadly applicable and computationally inexpensive, but they do not use content-based features and therefore leave performance gaps relative to specialized content-based predictors in some settings (Yardım et al., 2018). Temporal dynamics models are intentionally domain-independent but use only recent counts, distinct articles, and lifetime, leaving content, social structure, and platform changes outside the model (Zhang, 2011). Spreadsheet evaluation shows that always accepting predictions can increase user work rather than reduce it, which makes abstention and trigger policy central rather than peripheral (Agrawal et al., 11 Jun 2026).

There are also optimization-level failures. In self-editing LLM adaptation, archive-conditioned search over self-edit templates can outperform a weaker baseline and approach a stronger human-designed baseline, but the archive can also accelerate homogenization, and the study argues that explicit novelty pressure may be required for robust progress (Cheong et al., 20 Jan 2026). This suggests that predicting the next edit is not only a perception problem but also a search problem over possible edit strategies.

A broader misconception is that next edit prediction is just a larger autocomplete. The literature does not support that reduction. Traditional autocompletion is mostly keystroke-based, local, and inline, whereas NES systems are rich interaction-driven, multi-line and multi-file, and operate over edit operations rather than short text continuations (Lyu et al., 6 Feb 2026). Another misconception is that exact next-step accuracy is sufficient. Interactive evaluations in spreadsheets, tutoring, and multi-round code editing all indicate that usefulness depends on how predictions alter future trajectories, how users accept or reject them, and how much work they save (Paaßen et al., 2017, Wei et al., 2023, Agrawal et al., 11 Jun 2026).

Next edit prediction therefore occupies a distinct position between completion, generation, forecasting, and interactive assistance. Its central technical problem is to model not merely the artifact being edited, but the dynamics of editing itself.