# Come può l’IA modificare il codice senza rigenerare l’intero programma?

Canonical HTML: https://aogavrilov.com/it/projects/discrete-latent-generation/

Document language: it

Una guida pratica di ricerca alla modifica localizzata del codice mediante modelli generativi: che cosa deve rimanere fisso, che cosa può cambiare e quali evidenze occorrono prima di definire una trasformazione capace di preservare la struttura.

Pubblicato 25 luglio 2026 Aggiornato 30 luglio 2026 [Alexey Gavrilov](https://aogavrilov.com/about/)

## Qual è il problema effettivo

La modifica del codice non è una mera generazione di codice con un prompt più breve. Un sistema di modifica riceve un artefatto esistente, una modifica desiderata e un contratto implicito di preservazione. La questione centrale presenta dunque due aspetti: **quale regione può cambiare e quali proprietà della parte restante devono rimanere stabili?**

Questa guida si rivolge a lettori con competenze tecniche che si avvicinano all'editing del software assistito dall'IA. Distingue l'idea intuitiva di modifica locale dalle affermazioni più forti di preservazione sintattica, strutturale, semantica e funzionale.

## Idea centrale

Un editor circoscritto richiede un confine di preservazione esplicito, non soltanto un obiettivo di generazione.

### Che cosa deve rimanere invariato

Può trattarsi di un intervallo testuale, una grammatica, una firma API, una regione dell'AST, un comportamento verificato dai test, un contratto di dipendenza o una rappresentazione appresa a grana grossa. Ogni scelta tutela una diversa nozione di stabilità.

### Che cosa può cambiare

La regione modificabile deve disporre di libertà sufficiente per risolvere il compito richiesto. Un metodo di controllo che copia tutto è stabile ma inutile; uno che riscrive tutto offre libertà senza località.

## Un modello intuitivo: ristrutturare una stanza, preservare l'edificio

Si immagini di ristrutturare una stanza mantenendo intatti la struttura portante, i raccordi idraulici e gli ambienti adiacenti. Una rigenerazione completa equivale a ricostruire la casa a partire da una descrizione verbale. La modifica localizzata, invece, contrassegna la struttura protetta, delimita l’area d’intervento, esegue la modifica e ispeziona il risultato prima di accettarlo.

**Dove l'analogia cessa di valere.** Un codice latente appreso non costituisce un progetto architetturale certificato. Fissare un codice a granularità grossolana può aumentare la stabilità strutturale misurata, ma non garantisce che uno specifico nodo AST, comportamento o interfaccia rimanga invariato.

## Una visione più precisa della rigenerazione parziale

Si consideri un encoder che mappa un programma `x` in una rappresentazione latente strutturata `z` . Una maschera di preservazione seleziona le posizioni `L` da mantenere fisse. Il generatore campiona soltanto le posizioni complementari, imponendo al contempo `z'l = zl` per ogni posizione bloccata. Un decodificatore trasforma quindi la rappresentazione completata `z'` nuovamente in codice sorgente.

Questo meccanismo crea, al di sopra dei token, un’interfaccia di controllo ispezionabile. Il suo significato deve ancora essere accertato empiricamente: occorre verificare che cosa preservino le posizioni bloccate dopo la decodifica e se quelle modificabili conservino sufficiente libertà.

## Un flusso di modifica in quattro fasi

1. Definire il confine Individuare le regioni o le proprietà protette e definire la modifica prevista.
2. Rappresentare l’artefatto Utilizzare testo, sintassi, contesto di recupero oppure codici appresi a grana grossa e fine.
3. Rigenerare in modo selettivo Campionare soltanto le posizioni modificabili, mantenendo i vincoli selezionati.
4. Verificare prima di accettare Misurare località, sintassi, struttura, comportamento ed effetti collaterali indesiderati.

## Modifica del codice, riparazione dei programmi e generazione vincolata non sono lo stesso compito

| Approccio | Obiettivo principale | Meccanismo di preservazione tipico | Che cosa resta da verificare |
| --- | --- | --- | --- |
| Generazione completa del codice | Produrre un artefatto completo | Prompt e contesto | Tutto ciò che esula dalla modifica richiesta |
| Riparazione automatizzata dei programmi | Eliminare un difetto diagnosticato | Localizzazione dei guasti, test, modelli o patch | Correttezza oltre i test disponibili e minimalità della patch |
| Modelli di completamento interno o di modifica | Modificare regioni di testo selezionate | Prefisso, suffisso, diff o contesto di modifica visibile | Modifiche strutturali e comportamentali non intenzionali |
| Decodifica vincolata dalla grammatica | Mantenere gli output all’interno di un linguaggio formale | Stati di decodifica grammaticalmente validi | Semantica del programma, correttezza rispetto al compito e località |
| Controllo latente gerarchico | Rigenerare le posizioni apprese selezionate | Codici latenti bloccati a grana grossa o fine | Che cosa preservano quei codici dopo la decodifica |

## Come misurare la località e la preservazione della struttura

## Quale interfaccia di controllo è adatta al compito di modifica?

«Non riscrivere l'intera funzione» è un requisito, non un metodo completo. Si parta dall'esito che deve essere prevedibile, quindi si scelgano una superficie di controllo e le evidenze corrispondenti.

| Garanzia richiesta | Interfaccia di controllo più adatta | Evidenze da esigere |
| --- | --- | --- |
| Refactoring assistito dall'IA con preservazione del comportamento | Affidare a un LLM l’individuazione o la proposta di una trasformazione, quindi eseguirla, ove possibile, mediante un motore di refactoring affidabile. Si veda [RefactoringMirror](https://arxiv.org/abs/2411.04444) . | Compilazione, test, controlli statici e rilevamento del refactoring. [SWE-Refactor](https://arxiv.org/abs/2602.03712) rende espliciti questi controlli a livello di repository. |
| Modifica localizzata del codice senza riscrittura integrale della funzione | Riutilizzare i segmenti invariati del sorgente e generare soltanto le regioni candidate alla modifica, come in [EfficientEdit](https://arxiv.org/abs/2506.02780) . | Diff esterno alla regione, successo del compito, riuso dei token accettati e verifica dell'eventuale perdita di modifiche tra file causata dall'omissione del contesto. |
| Generazione vincolata di codice per l'ingegneria del software | Imporre una proprietà formale durante la decodifica, come in [diffusione vincolata dalla grammatica](https://arxiv.org/abs/2508.10111) , oppure salvare checkpoint dei prefissi validi e ripristinare soltanto la regione responsabile, come in [Hydra](https://arxiv.org/abs/2605.15238) . | Esito positivo della grammatica, del compilatore o del controllo dei tipi, congiuntamente a test funzionali, località, latenza della riparazione e quantità di codice valido rigenerato. |
| Rigenerazione selettiva di funzioni Python con un equilibrio tra località e diversità | Bloccare posizioni latenti selezionate, a grana grossa o fine, e campionare soltanto le restanti. | Località decodificata, sintassi, invarianti strutturali, libertà di modifica, diversità e incertezza. Il solo blocco delle variabili latenti non garantisce il refactoring. |
| Generazione prevedibile di codice con un contratto di preservazione esplicito | Definire, prima della generazione, proprietà protette osservabili e verifiche con esito positivo o negativo; scegliere quindi il meccanismo più circoscritto in grado di imporle o renderle osservabili. | Misurare esattamente tali proprietà dopo la decodifica e riportare, su esecuzioni ripetute, i tassi di accettazione, rifiuto e fallimento. Il solo campionamento deterministico non garantisce la preservazione. |

## Domande di ricerca a cui risponde questa guida

Queste risposte concise definiscono i confini delle affermazioni e delle evidenze adottati nell'intera guida.

1. Come può un modello generativo modificare il codice senza riscrivere l'intera funzione? Definire il confine modificabile prima della generazione, preservare o riutilizzare il codice sorgente al suo esterno, generare soltanto modifiche candidate e rifiutare gli output che non soddisfano il compito o alterano le regioni protette. Il blocco gerarchico delle variabili latenti è un'interfaccia di controllo sperimentale, ma non garantisce intervalli identici nel codice sorgente. [Confrontare le interfacce di controllo per la modifica localizzata](https://aogavrilov.com/it/projects/discrete-latent-generation/#control-surface) .
2. Quali evidenze mostrano che una modifica del codice è locale, anziché meramente valida sul piano sintattico? Misurare il diff esterno alla regione richiesta insieme al successo del compito, alle modifiche nella regione editabile, agli invarianti strutturali, ai test o ai controlli statici e alla variabilità tra esecuzioni ripetute. Il solo tasso di parsing attesta unicamente la correttezza sintattica. [Esamina la lista di controllo delle evidenze di località](https://aogavrilov.com/it/projects/discrete-latent-generation/#measurement) .
3. Come si dovrebbe bilanciare la località delle modifiche al codice con la diversità della generazione? Riportare la stabilità della regione protetta insieme alla libertà nella regione modificabile e all’unicità dei candidati. Copiare l’input può massimizzare la stabilità senza produrre alcun avanzamento nel compito; una riscrittura priva di vincoli può massimizzare il cambiamento distruggendo però la località. [Consulta le evidenze circoscritte sul compromesso tra stabilità e libertà](https://aogavrilov.com/it/projects/discrete-latent-generation/#evidence) .
4. In che cosa differiscono la modifica localizzata del codice, la generazione vincolata e la riparazione dei programmi? La modifica localizzata pone l’accento su ciò che deve rimanere invariato; la generazione vincolata impone una proprietà formale dell’output, come l’appartenenza a una grammatica; la riparazione dei programmi richiede invece che la modifica soddisfi la specifica di un difetto o di un compito. La sola sintassi non dimostra l’equivalenza semantica, la correttezza funzionale, il successo nel compito o la località. [Confrontare i tre obiettivi](https://aogavrilov.com/it/projects/discrete-latent-generation/#comparison) .
5. Come si possono rigenerare parti selezionate di una funzione Python mantenendo stabile il resto? Definire le regioni protette e modificabili prima della generazione, intervenire soltanto sulla rappresentazione modificabile, decodificare e rifiutare i candidati che alterano il codice protetto o non superano la sintassi, i test, i controlli statici o gli invarianti specifici del compito. L'esperimento riportato con variabili latenti gerarchiche misura la stabilità probabilistica su funzioni di 64 token; non garantisce che gli intervalli o il comportamento rimangano invariati. [Esaminare il flusso di lavoro di rigenerazione selettiva](https://aogavrilov.com/it/projects/discrete-latent-generation/#workflow) .
6. Quale strategia di controllo è adatta al refactoring assistito dall'IA con preservazione del comportamento? Usare il modello per individuare o proporre una trasformazione; ove possibile, eseguirla poi con un motore di refactoring affidabile e verificare la compilazione, i test, i controlli statici e il refactoring previsto. Una patch generata plausibile non costituisce evidenza sufficiente. [Apri la riga decisionale relativa al refactoring](https://aogavrilov.com/it/projects/discrete-latent-generation/#control-surface) .
7. Che cosa rende la generazione di codice prevedibile, anziché soltanto controllabile? Definire un contratto di preservazione osservabile e i controlli di accettazione prima di scegliere il generatore. La prevedibilità dipende da ciò che resta stabile dopo la decodifica e la verifica, non soltanto dall’aver fissato un prompt, una maschera, una grammatica o un codice latente. [Definire il contratto di preservazione](https://aogavrilov.com/it/projects/discrete-latent-generation/#core-idea) .

## Che cosa dimostra l'esperimento attuale — e che cosa non dimostra

In [*Controllo ispezionabile per la rigenerazione del software con preservazione della struttura*](https://aogavrilov.com/it/publications/inspectable-control/) , un VQ-VAE gerarchico mappa funzioni Python di 64 token in 16 posizioni discrete di livello superiore e 32 di livello inferiore. Il blocco di quattro codici di livello superiore aumenta il tasso di analisi sintattica da **da 0.453 a 0.591** , mentre le posizioni non bloccate continuano a cambiare con un tasso pari a **0.936** e i campioni condizionati rimangono **0.998 univoci** .

Si tratta dell'evidenza di un compromesso misurato tra stabilità e libertà in un contesto circoscritto. Non garantisce la preservazione esatta dell'AST, l'equivalenza semantica, la correttezza funzionale, il buon esito della riparazione o il comportamento alla scala di un repository.

Lo studio complementare [*Dove si deteriora la qualità nella generazione compressa di testi brevi*](https://aogavrilov.com/it/publications/where-quality-breaks/) aggiunge un'importante indicazione per la valutazione: il miglioramento delle misure surrogate nello spazio latente non migliora necessariamente gli output decodificati. Rappresentazione, generazione e comportamento decodificato dovrebbero essere verificati come stadi distinti.

Per una procedura decisionale riutilizzabile, consulta la guida complementare dedicata a [distinzione tra la perdita del codec e la perdita del generatore](https://aogavrilov.com/it/projects/codec-bottleneck-diagnosis/) .

## Fraintendimenti comuni

### «Supera l'analisi sintattica, dunque è corretto».

Il parsing dimostra soltanto la correttezza sintattica. Il programma può comunque violare test, contratti o finalità previste.

### «Un codice a granularità grossolana è un nodo AST».

Non senza aver dimostrato un allineamento esplicito. I codici appresi possono combinare diversi fattori superficiali e strutturali.

### «Variabili latenti bloccate implicano testo sorgente invariato».

La decodifica è globale e appresa. Posizioni latenti fisse possono aumentare la stabilità senza garantire un intervallo testuale identico.

### «Una modifica minore è sempre preferibile».

Un editor che copia l'input ottiene stabilità perfetta ma nessun avanzamento nel compito. La località e il successo della modifica devono essere misurati congiuntamente.

## Letture successive

I lavori affini adottano interfacce di controllo differenti; nessuno di essi dovrebbe essere considerato una baseline intercambiabile senza un allineamento rispetto al compito.

1. [Self-Edit: Fault-Aware Code Editor for Code Generation](https://arxiv.org/abs/2305.04087) Considera la generazione un processo modificabile e usa gli errori rilevati per guidare la correzione.
2. [Coeditor: Leveraging Contextual Changes for Multi-round Code Auto-editing](https://arxiv.org/abs/2305.18584) Modella le modifiche contestuali al codice nei diversi cicli di editing, anziché rigenerarlo da zero.
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.
4. [Constrained Decoding of Diffusion LLMs with Context-Free Grammars](https://arxiv.org/abs/2508.10111) Mostra come i vincoli formali possano offrire garanzie sintattiche durante la decodifica per diffusione.
5. [Apprendimento neurale di rappresentazioni discrete](https://arxiv.org/abs/1711.00937) Introduce VQ-VAE, il meccanismo fondamentale per l’apprendimento di rappresentazioni latenti discrete.
6. [Simple and Effective Masked Diffusion Language Models](https://arxiv.org/abs/2406.07524) Fornisce il quadro di diffusione discreta mascherata impiegato come generatore latente nello studio diagnostico complementare.
7. [An Empirical Study on the Potential of LLMs in Automated Software Refactoring](https://arxiv.org/abs/2411.04444) Individua i refactoring non sicuri proposti dagli LLM e valuta la riapplicazione delle trasformazioni rilevate mediante motori di refactoring affidabili.
8. [SWE-Refactor: A Repository-Level Benchmark for Real-World LLM-Based Code Refactoring](https://arxiv.org/abs/2602.03712) Valuta il refactoring a livello di repository che preserva il comportamento, mediante compilazione, test e rilevamento delle trasformazioni di refactoring.
9. [EfficientEdit: Accelerating Code Editing via Edit-Oriented Speculative Decoding](https://arxiv.org/abs/2506.02780) Riutilizza i segmenti invariati del sorgente e predice le posizioni delle modifiche, anziché trattare una modifica come una rigenerazione autoregressiva completa.
10. [Hydra: Efficient, Correct Code Generation via Checkpoint-and-Rollback Support](https://arxiv.org/abs/2605.15238) Impiega controlli statici, checkpoint e rollback mirati per evitare di rigenerare prefissi già validi dopo un errore.

## Breve riepilogo

La rigenerazione localizzata del codice costituisce un contratto tra **modifica** e **preservazione** . Le variabili latenti discrete gerarchiche offrono un modo ispezionabile di esprimere tale contratto, ma la rappresentazione è utile soltanto se i programmi decodificati vengono valutati rispetto a località, sintassi, struttura, comportamento, diversità e incertezza.

## Pubblicazioni in questa linea di ricerca

### [Where Quality Breaks in Compressed Short-Text Generation: Staged Bottleneck Localization](https://aogavrilov.com/it/publications/where-quality-breaks/)

Dove si deteriora la qualità nella generazione compressa di testi brevi: localizzazione per stadi del collo di bottiglia

Metodologia diagnostica FRUCT 39 2026 Conferenza principale

### [Inspectable Control for Structure-Preserving Software Regeneration](https://aogavrilov.com/it/publications/inspectable-control/)

Controllo ispezionabile per la rigenerazione del software con preservazione della struttura

Metodo di controllo nello spazio latente FSE Companion '26 2026 Poster di accompagnamento