RESEARCH NOTE
Localized code modification with generative models
How to prevent unnecessary whole-function rewriting while preserving enough freedom for a generative model to make the requested code change.
DIRECT ANSWER
How can a generative model modify code without rewriting the entire function?
Define protected and editable regions before generation, reuse or constrain the protected representation, generate only candidate changes, and reject outputs that alter protected code or fail task-specific checks. Locality and task success must be measured together.
Why the distinction matters
The method and the claimed guarantee need the same observable boundary.
Localized code modification is an editing problem, not merely a shorter code-generation prompt. The input already contains an artifact worth preserving, so the method needs an explicit boundary between the region allowed to change and the properties that must remain stable.
The boundary may be a source span, syntax node, API signature, test behavior, dependency contract, or learned latent position. These choices are not interchangeable: each protects a different observable property and requires a matching verification step.
A practical procedure
State the preservation contract
Identify the editable region and the exact text, structure, interface, or behavior that must remain unchanged.
Choose the narrowest useful control surface
Reuse unchanged source spans, use infilling or edit-oriented decoding, apply formal constraints, or lock selected latent positions according to the required property.
Generate only where change is allowed
Keep enough freedom inside the editable region to solve the task; copying the entire input is local but makes no progress.
Verify locality and success together
Reject candidates that alter protected regions, fail parsing or compilation, violate structural invariants, or do not satisfy the requested change.
Evidence to require
A claim is only as strong as the property measured after generation or decoding.
- Outside-region diff or another direct protected-region stability measure.
- Task success inside the editable region.
- Parsing, compilation, tests, static checks, or task-specific invariants as applicable.
- Editable-region change rate so copying is not mistaken for control.
- Candidate uniqueness and repeated-run variability so locality is not confused with mode collapse.
What the linked study reports
- The linked experiment compresses 64-token Python functions into hierarchical discrete positions and regenerates selected latent positions under partial constraints.
- Locking four top-level codes raised parse rate from 0.453 to 0.591 while unlocked positions changed at rate 0.936 and conditional samples remained 0.998 unique.
- Those measurements expose a stability-freedom trade-off above the token level; they do not prove exact source-span, AST, semantic, or behavioral preservation.
Scope boundary
- A locked latent code is not automatically an AST node, protected source span, or formal invariant.
- Parse rate establishes syntactic well-formedness, not functional correctness or successful repair.
- The reported evidence comes from short preprocessed Python functions and does not establish repository-scale behavior.
Primary and nearby sources
Use the linked papers for the original methods, measurements, and stated limitations.
- Inspectable Control for Structure-Preserving Software Regeneration
Primary paper and bounded hierarchical-latent experiment.
- EfficientEdit: Accelerating Code Editing via Edit-Oriented Speculative Decoding
Edit-oriented decoding that reuses unchanged source regions.
- PAFT: Preservation Aware Fine-Tuning for Minimal-Edit Program Repair
Makes preservation and minimal change explicit in program-repair training.