# Modifica localizzata del codice mediante modelli generativi Canonical HTML: https://aogavrilov.com/it/research-notes/localized-code-modification-generative-models/ Document language: it NOTA DI RICERCA Come evitare di riscrivere inutilmente un’intera funzione, lasciando al contempo a un modello generativo libertà sufficiente per apportare la modifica richiesta al codice. Pubblicato 30 luglio 2026 [Alexey Gavrilov](https://aogavrilov.com/about/) RISPOSTA DIRETTA ## Come può un modello generativo modificare il codice senza riscrivere l'intera funzione? Definire le regioni protette e modificabili prima della generazione, riutilizzare o vincolare la rappresentazione protetta, generare soltanto modifiche candidate e rifiutare gli output che alterano il codice protetto o non superano i controlli specifici del compito. Località e successo nel compito devono essere misurati congiuntamente. ## Perché la distinzione è importante Il metodo e la garanzia dichiarata devono riferirsi allo stesso confine osservabile. La modifica localizzata del codice è un problema di editing, non semplicemente un prompt più breve per la generazione di codice. L’input contiene già un artefatto che merita di essere preservato; il metodo richiede pertanto un confine di preservazione esplicito tra la regione che può cambiare e le proprietà che devono rimanere stabili. Il confine può consistere in un intervallo del codice sorgente, un nodo sintattico, una firma API, il comportamento di un test, un contratto di dipendenza o una posizione latente appresa. Queste scelte non sono intercambiabili: ciascuna protegge una diversa proprietà osservabile e richiede una fase di verifica corrispondente. ## Una procedura operativa 1. Definire il contratto di preservazione Individuare la regione modificabile e il testo, la struttura, l’interfaccia o il comportamento esatti che devono rimanere invariati. 2. Scegliere l'interfaccia di controllo utile più circoscritta Riutilizzare i segmenti invariati del sorgente, impiegare l’infilling o una decodifica orientata alla modifica, applicare vincoli formali oppure bloccare le posizioni latenti selezionate in funzione della proprietà richiesta. 3. Generare soltanto dove la modifica è consentita Mantenere nella regione modificabile un grado di libertà sufficiente a risolvere il compito; copiare l’intero input è un’operazione locale, ma non produce alcun avanzamento. 4. Verificare congiuntamente località e successo Scartare i candidati che alterano regioni protette, non superano il parsing o la compilazione, violano invarianti strutturali oppure non soddisfano la modifica richiesta. ## Evidenze da richiedere La solidità di un'affermazione non può superare quella della proprietà misurata dopo la generazione o la decodifica. - Diff esterno alla regione o un'altra misura diretta della stabilità della regione protetta. - Successo del compito nella regione modificabile. - Parsing, compilazione, test, controlli statici o invarianti specifici del compito, secondo necessità. - Tasso di modifica della regione editabile, affinché la copia non venga scambiata per controllo. - Unicità dei candidati e variabilità tra esecuzioni ripetute, affinché la località non venga confusa con il collasso delle modalità. ### Che cosa riporta lo studio collegato - L’esperimento collegato comprime funzioni Python di 64 token in posizioni discrete gerarchiche e rigenera posizioni latenti selezionate in presenza di vincoli parziali. - Il blocco di quattro codici di livello superiore ha innalzato il tasso di parsing da 0.453 a 0.591; nel contempo, il tasso di modifica delle posizioni non bloccate è rimasto pari a 0.936 e l’unicità dei campioni condizionati a 0.998. - Tali misure evidenziano un compromesso tra stabilità e libertà al di sopra del livello dei token; non provano la preservazione esatta dell'intervallo sorgente, dell'AST, della semantica o del comportamento. [Leggi la panoramica della pubblicazione](https://aogavrilov.com/it/publications/inspectable-control/) [Cerca nel testo integrale dell’articolo](https://aogavrilov.com/publications/inspectable-control/full-text/) ## Confine dell’ambito - Un codice latente bloccato non equivale automaticamente a un nodo AST, a un intervallo protetto del sorgente o a un invariante formale. - Il tasso di parsing attesta la correttezza sintattica, non la correttezza funzionale né il buon esito della riparazione. - Le evidenze riportate provengono da brevi funzioni Python pretrattate e non dimostrano il comportamento su scala di repository. ## Fonti primarie e affini Consultare gli articoli collegati per i metodi originali, le misurazioni e le limitazioni dichiarate. 1. [Inspectable Control for Structure-Preserving Software Regeneration](https://aogavrilov.com/it/publications/inspectable-control/) Articolo principale ed esperimento con rappresentazioni latenti gerarchiche vincolate. 2. [EfficientEdit: Accelerating Code Editing via Edit-Oriented Speculative Decoding](https://arxiv.org/abs/2506.02780) Decodifica orientata alla modifica che riutilizza le regioni invariate del sorgente. 3. [PAFT: Preservation Aware Fine-Tuning for Minimal-Edit Program Repair](https://arxiv.org/abs/2604.03113) Rende espliciti la preservazione e il cambiamento minimo nell’addestramento per la riparazione dei programmi. Curato da Alexey Gavrilov . Questa pagina sintetizza le evidenze esistenti e non aggiunge risultati sperimentali ulteriori rispetto alle fonti citate.