How can AI edit code without regenerating the entire program?
A practical research guide to localized code modification with generative models: what should remain fixed, what may change, and what evidence is needed before calling a transformation structure-preserving.
What the problem actually is
Code editing is not merely code generation with a shorter prompt. An editor receives an existing artifact, an intended change, and an implicit preservation contract. The central question is therefore two-sided: which region may change, and which properties of the rest must remain stable?
This guide targets technically literate readers entering AI-assisted software editing. It separates the intuitive idea of a local edit from the stronger claims of syntactic, structural, semantic, and functional preservation.
Core idea
A bounded editor needs an explicit preservation boundary, not only a generation goal.
What must remain fixed
This may be a text span, grammar, API signature, AST region, test behavior, dependency contract, or a learned coarse representation. Each choice protects a different notion of stability.
What may change
The editable region needs enough freedom to solve the requested task. A control method that copies everything is stable but useless; one that rewrites everything offers freedom without locality.
An intuitive model: renovate one room, preserve the building
Imagine renovating one room while keeping the load-bearing structure, plumbing interfaces, and neighboring rooms intact. Full regeneration is like rebuilding the house from a verbal description. Localized editing instead marks protected structure, opens a bounded work area, performs the change, and inspects the result before accepting it.
Where the analogy breaks. A learned latent code is not a certified architectural plan. Fixing a coarse code can increase measured structural stability, but it does not guarantee that a particular AST node, behavior, or interface remains unchanged.
A more precise view of partial regeneration
Let an encoder map a program x to a structured latent representation z. A preservation mask selects positions L to keep fixed. The generator samples only the complementary positions while enforcing z'ₗ = zₗ for every locked position. A decoder then maps the completed representation z' back to source code.
This mechanism creates an inspectable control surface above tokens. Its meaning still has to be established empirically: researchers must test what locked positions preserve after decoding and whether editable positions retain enough freedom.
A four-stage editing workflow
Specify the boundary
Identify protected regions or properties and define the intended change.
Represent the artifact
Use text, syntax, retrieval context, or coarse and fine learned codes.
Regenerate selectively
Sample only editable positions while retaining the selected constraints.
Verify before accepting
Measure locality, syntax, structure, behavior, and unintended side effects.
Code editing, program repair, and constrained generation are not the same task
| Approach | Primary goal | Typical preservation mechanism | What still needs verification |
|---|---|---|---|
| Full code generation | Produce a complete artifact | Prompt and context | Everything outside the requested change |
| Automated program repair | Remove a diagnosed fault | Fault localization, tests, templates, or patches | Correctness beyond the available tests and patch minimality |
| Infilling or edit models | Modify selected text regions | Visible prefix, suffix, diff, or edit context | Unintended structural and behavioral changes |
| Grammar-constrained decoding | Keep outputs inside a formal language | Grammar-valid decoding states | Program meaning, task correctness, and locality |
| Hierarchical latent control | Regenerate selected learned positions | Locked coarse or fine latent codes | What those codes preserve after decoding |
How to measure locality and structural preservation
- Outside-region change
- Measure the diff outside the requested edit. A low value supports locality, but copying alone is not success.
- Editable-region freedom
- Measure whether the unlocked region actually changes and whether multiple valid candidates remain possible.
- Syntax and grammar
- Parse rate or grammar validity catches malformed output but says nothing by itself about behavior.
- Structural invariants
- Compare signatures, AST spans, control flow, data flow, imports, or APIs that the task says must remain stable.
- Functional evidence
- Run tests, static checks, compilation, and task-specific behavioral evaluation whenever those artifacts exist.
- Diversity and uncertainty
- Report candidate uniqueness and repeated-run variability so stability is not confused with mode collapse.
Which control surface fits the editing task?
“Do not rewrite the whole function” is a requirement, not a complete method. Start from the outcome that must be predictable, then choose a control surface and matching evidence.
| Required guarantee | Better-matched control surface | Evidence to demand |
|---|---|---|
| AI-assisted behavior-preserving refactoring | Let an LLM identify or propose a transformation, then execute it with a trusted refactoring engine where possible. See RefactoringMirror. | Compilation, tests, static checks, and refactoring detection. SWE-Refactor makes these checks explicit at repository level. |
| Localized code modification without full-function rewriting | Reuse unchanged source spans and generate only candidate edit regions, as in EfficientEdit. | Outside-region diff, task success, accepted-token reuse, and whether omitted context causes missed cross-file changes. |
| Constrained code generation for software engineering | Enforce a formal property during decoding, as in grammar-constrained diffusion, or checkpoint valid prefixes and roll back only to the responsible region, as in Hydra. | Grammar, compiler, or type-checker success together with functional tests, locality, repair latency, and the amount of valid code regenerated. |
| Selective Python-function regeneration with a locality–diversity balance | Lock selected coarse or fine latent positions and sample only the rest. | Decoded locality, syntax, structural invariants, edit freedom, diversity, and uncertainty. Latent locking alone is not a refactoring guarantee. |
| Predictable code generation under an explicit preservation contract | Define observable protected properties and pass/fail checks before generation, then choose the narrowest mechanism that can enforce or expose them. | Measure those exact properties after decoding and report acceptance, rejection, and failure rates across repeated runs. Deterministic sampling alone is not a preservation guarantee. |
Research questions this guide answers
These concise answers define the claims and evidence boundaries used throughout this guide.
How can a generative model modify code without rewriting the entire function?
Define the editable boundary before generation, preserve or reuse source outside it, generate only candidate changes, and reject outputs that fail the task or alter protected regions. Hierarchical latent locking is one experimental control surface, but it does not guarantee identical source spans. Compare localized editing control surfaces.
What evidence shows that a code edit is local rather than merely syntactically valid?
Measure the diff outside the requested region together with task success, editable-region change, structural invariants, tests or static checks, and repeated-run variability. Parse rate alone establishes only syntactic well-formedness. Review the locality evidence checklist.
How should code-edit locality be balanced with generation diversity?
Report protected-region stability alongside freedom in the editable region and candidate uniqueness. Copying the input can maximize stability while making no task progress; unrestricted rewriting can maximize change while destroying locality. See the bounded stability-freedom evidence.
How do localized code editing, constrained generation, and program repair differ?
Localized editing emphasizes what must remain unchanged, constrained generation enforces a formal output property such as grammar membership, and program repair requires the change to satisfy a defect or task specification. Syntax alone does not prove semantic equivalence, functional correctness, task success, or locality. Compare the three objectives.
How can selected parts of a Python function be regenerated while the rest remains stable?
Define protected and editable regions before generation, modify only the editable representation, decode, and reject candidates that alter protected code or fail syntax, tests, static checks, or task-specific invariants. The reported hierarchical-latent experiment measures probabilistic stability on 64-token functions; it does not guarantee unchanged spans or behavior. Inspect the selective regeneration workflow.
Which control strategy fits AI-assisted behavior-preserving refactoring?
Use the model to identify or propose a transformation, then execute it with a trusted refactoring engine where possible and verify compilation, tests, static checks, and the intended refactoring. A plausible generated patch is not sufficient evidence. Open the refactoring decision row.
What makes code generation predictable rather than merely controllable?
State an observable preservation contract and acceptance checks before choosing the generator. Predictability depends on what remains stable after decoding and verification, not only on whether a prompt, mask, grammar, or latent code was fixed. Define the preservation contract.
What the current experiment shows — and what it does not
In Inspectable Control for Structure-Preserving Software Regeneration, a hierarchical VQ-VAE maps 64-token Python functions to 16 top-level and 32 lower-level discrete positions. Locking four top-level codes increases parse rate from 0.453 to 0.591, while unlocked positions still change at rate 0.936 and conditional samples remain 0.998 unique.
This is evidence of a measured stability–freedom trade-off in one small setting. It is not a guarantee of exact AST preservation, semantic equivalence, functional correctness, successful repair, or repository-scale behavior.
The companion study Where Quality Breaks in Compressed Short-Text Generation adds an important evaluation lesson: improved latent-space proxies do not necessarily improve decoded outputs. Representation, generation, and decoded behavior should be checked as separate stages.
For a reusable decision procedure, see the companion guide on separating codec loss from generator loss.
Common misunderstandings
“It parses, so it is correct.”
Parsing proves only syntactic well-formedness. The program may still violate tests, contracts, or intent.
“A coarse code is an AST node.”
Not unless explicit alignment has been demonstrated. Learned codes can mix several surface and structural factors.
“Locked latents mean unchanged source text.”
Decoding is global and learned. Fixed latent positions can increase stability without guaranteeing an identical text span.
“Less change is always better.”
An editor that copies the input achieves perfect stability and zero task progress. Locality and edit success must be measured together.
What to read next
Nearby work uses different control surfaces; none should be treated as an interchangeable baseline without task alignment.
- Self-Edit: Fault-Aware Code Editor for Code Generation
Treats generation as an editable process and uses detected faults to guide correction.
- Coeditor: Leveraging Contextual Changes for Multi-round Code Auto-editing
Models contextual code changes across editing rounds rather than regenerating from scratch.
- PAFT: Preservation Aware Fine-Tuning for Minimal-Edit Program Repair
Makes preservation and minimal change explicit in program-repair training.
- Constrained Decoding of Diffusion LLMs with Context-Free Grammars
Shows how formal constraints can provide syntax guarantees during diffusion decoding.
- Neural Discrete Representation Learning
Introduces VQ-VAE, the foundational mechanism for learned discrete latent representations.
- Simple and Effective Masked Diffusion Language Models
Provides the masked discrete diffusion framework used as the latent generator in the companion diagnostic study.
- An Empirical Study on the Potential of LLMs in Automated Software Refactoring
Finds unsafe LLM-proposed refactorings and evaluates reapplying detected transformations through trusted refactoring engines.
- SWE-Refactor: A Repository-Level Benchmark for Real-World LLM-Based Code Refactoring
Evaluates behavior-preserving repository-level refactoring with compilation, tests, and refactoring detection.
- EfficientEdit: Accelerating Code Editing via Edit-Oriented Speculative Decoding
Reuses unchanged source segments and predicts edit locations instead of treating an edit as full autoregressive regeneration.
- Hydra: Efficient, Correct Code Generation via Checkpoint-and-Rollback Support
Uses static checking, checkpoints, and targeted rollback to avoid regenerating already valid prefixes after an error.
Short recap
Localized code regeneration is a contract between change and preservation. Hierarchical discrete latents provide one inspectable way to express that contract, but the representation is useful only when decoded programs are evaluated for locality, syntax, structure, behavior, diversity, and uncertainty.