# Como a IA pode editar código sem regenerar o programa inteiro?

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

Document language: pt

Um guia prático de pesquisa sobre modificação localizada de código com modelos generativos: o que deve permanecer fixo, o que pode mudar e quais evidências são necessárias antes de classificar uma transformação como preservadora de estrutura.

Publicado 25 de julho de 2026 Atualizado 30 de julho de 2026 [Alexey Gavrilov](https://aogavrilov.com/about/)

## Qual é, de fato, o problema

A edição de código não é mera geração de código com um prompt mais curto. Um editor recebe um artefato existente, uma alteração pretendida e um contrato implícito de preservação. A questão central tem, portanto, duas vertentes: **qual região pode mudar e quais propriedades do restante devem permanecer estáveis?**

Este guia destina-se a leitores com formação técnica que estão ingressando na edição de software assistida por IA. Ele distingue a noção intuitiva de edição local das alegações mais fortes de preservação sintática, estrutural, semântica e funcional.

## Ideia central

Um editor de escopo delimitado requer uma fronteira de preservação explícita, e não apenas um objetivo de geração.

### O que deve permanecer fixo

Pode tratar-se de um trecho de texto, uma gramática, uma assinatura de API, uma região da AST, um comportamento de teste, um contrato de dependência ou uma representação aprendida de granularidade grossa. Cada escolha protege uma noção distinta de estabilidade.

### O que pode mudar

A região editável precisa de liberdade suficiente para resolver a tarefa solicitada. Um método de controle que copia tudo é estável, porém inútil; um método que reescreve tudo oferece liberdade sem localidade.

## Um modelo intuitivo: reformar um cômodo, preservar o edifício

Imagine reformar um cômodo mantendo intactas a estrutura de sustentação, as interfaces hidráulicas e as dependências vizinhas. A regeneração integral equivale a reconstruir a casa com base em uma descrição verbal. Já a edição localizada demarca a estrutura protegida, delimita uma área de trabalho, realiza a alteração e inspeciona o resultado antes de aceitá-lo.

**Onde a analogia deixa de ser válida.** Um código latente aprendido não constitui um plano arquitetural certificado. Fixar um código de granularidade grossa pode aumentar a estabilidade estrutural medida, mas não garante que determinado nó da AST, comportamento ou interface permaneça inalterado.

## Uma visão mais precisa da regeneração parcial

Considere um codificador que mapeia um programa `x` para uma representação latente estruturada `z` . Uma máscara de preservação seleciona as posições `L` a serem mantidas fixas. O gerador amostra apenas as posições complementares, ao mesmo tempo que impõe `z'l = zl` para cada posição bloqueada. Em seguida, um decodificador converte a representação completa `z'` de volta ao código-fonte.

Esse mecanismo cria uma superfície de controle inspecionável acima dos tokens. Seu significado ainda precisa ser estabelecido empiricamente: os pesquisadores devem testar o que as posições bloqueadas preservam após a decodificação e se as posições editáveis mantêm liberdade suficiente.

## Um fluxo de edição em quatro etapas

1. Especifique a fronteira Identifique as regiões ou propriedades protegidas e defina a alteração pretendida.
2. Representar o artefato Utilize texto, sintaxe, contexto recuperado ou códigos aprendidos de granularidade grossa e fina.
3. Regenerar seletivamente Amostre somente as posições editáveis, preservando as restrições selecionadas.
4. Verifique antes de aceitar Avalie a localidade, a sintaxe, a estrutura, o comportamento e os efeitos colaterais não intencionais.

## Edição de código, reparo de programas e geração com restrições não são a mesma tarefa

| Abordagem | Objetivo principal | Mecanismo típico de preservação | O que ainda precisa ser verificado |
| --- | --- | --- | --- |
| Geração integral de código | Produzir um artefato completo | Prompt e contexto | Tudo o que estiver fora da alteração solicitada |
| Reparo automatizado de programas | Remover uma falha diagnosticada | Localização de falhas, testes, modelos ou correções | Correção para além dos testes disponíveis e minimalidade do patch |
| Modelos de preenchimento ou edição | Modificar regiões selecionadas do texto | Prefixo, sufixo, diferença ou contexto de edição visível | Alterações estruturais e comportamentais não intencionais |
| Decodificação com restrições gramaticais | Mantenha as saídas dentro de uma linguagem formal | Estados de decodificação gramaticalmente válidos | Semântica do programa, correção da tarefa e localidade |
| Controle latente hierárquico | Regenerar posições aprendidas selecionadas | Códigos latentes granulares ou refinados bloqueados | O que esses códigos preservam após a decodificação |

## Como medir a localidade e a preservação da estrutura

## Qual superfície de controle é adequada à tarefa de edição?

“Não reescreva a função inteira” é um requisito, não um método completo. Comece pelo resultado que deve ser previsível; em seguida, escolha uma superfície de controle e evidências correspondentes.

| Garantia exigida | Superfície de controle mais bem alinhada | Evidências a exigir |
| --- | --- | --- |
| Refatoração assistida por IA com preservação de comportamento | Permita que um LLM identifique ou proponha uma transformação e, quando possível, execute-a com um mecanismo de refatoração confiável. Consulte [RefactoringMirror](https://arxiv.org/abs/2411.04444) . | Compilação, testes, verificações estáticas e detecção de refatoração. [SWE-Refactor](https://arxiv.org/abs/2602.03712) torna explícitas essas verificações no âmbito do repositório. |
| Modificação localizada de código sem reescrever a função inteira | Reutilize trechos inalterados do código-fonte e gere somente as regiões candidatas à edição, como em [EfficientEdit](https://arxiv.org/abs/2506.02780) . | Diferenças fora da região, êxito na tarefa, reutilização de tokens aceitos e ocorrência de alterações não detectadas entre arquivos em razão da omissão de contexto. |
| Geração de código com restrições para engenharia de software | Imponha uma propriedade formal durante a decodificação, como em [difusão com restrições gramaticais](https://arxiv.org/abs/2508.10111) , ou criar pontos de verificação de prefixos válidos e reverter apenas até a região responsável, como em [Hydra](https://arxiv.org/abs/2605.15238) . | Êxito na validação pela gramática, pelo compilador ou pelo verificador de tipos, em conjunto com testes funcionais, localidade, latência do reparo e quantidade de código válido regenerado. |
| Regeneração seletiva de funções Python com equilíbrio entre localidade e diversidade | Bloqueie posições latentes granulares ou refinadas selecionadas e realize a amostragem apenas das demais. | Localidade decodificada, sintaxe, invariantes estruturais, liberdade de edição, diversidade e incerteza. O bloqueio latente, por si só, não garante a refatoração. |
| Geração previsível de código sob um contrato de preservação explícito | Defina propriedades protegidas observáveis e verificações de aprovação ou reprovação antes da geração; em seguida, escolha o mecanismo mais restrito capaz de impô-las ou torná-las observáveis. | Avalie exatamente essas propriedades após a decodificação e informe as taxas de aceitação, rejeição e falha em execuções repetidas. A amostragem determinística, por si só, não garante a preservação. |

## Perguntas de pesquisa respondidas por este guia

Estas respostas concisas definem os limites das alegações e das evidências adotados ao longo deste guia.

1. Como um modelo generativo pode modificar código sem reescrever toda a função? Defina a fronteira editável antes da geração, preserve ou reutilize o código-fonte fora dela, gere apenas alterações candidatas e rejeite resultados que não cumpram a tarefa ou alterem regiões protegidas. O bloqueio latente hierárquico é uma interface de controle experimental, mas não garante intervalos idênticos no código-fonte. [Compare interfaces de controle para edição localizada](https://aogavrilov.com/pt/projects/discrete-latent-generation/#control-surface) .
2. Que evidências demonstram que uma edição de código é local, e não apenas sintaticamente válida? Avalie as diferenças fora da região solicitada em conjunto com o êxito na tarefa, as alterações na região editável, os invariantes estruturais, os testes ou as verificações estáticas e a variabilidade entre execuções repetidas. Isoladamente, a taxa de análise sintática estabelece apenas a boa formação sintática. [Consultar a lista de verificação das evidências de localidade](https://aogavrilov.com/pt/projects/discrete-latent-generation/#measurement) .
3. Como conciliar a localidade da edição de código com a diversidade da geração? Informe a estabilidade da região protegida em conjunto com a liberdade na região editável e a unicidade dos candidatos. Copiar a entrada pode maximizar a estabilidade sem produzir qualquer avanço na tarefa; a reescrita irrestrita pode maximizar a mudança e, ao mesmo tempo, destruir a localidade. [Consultar as evidências delimitadas sobre estabilidade e liberdade](https://aogavrilov.com/pt/projects/discrete-latent-generation/#evidence) .
4. Em que diferem a edição localizada de código, a geração com restrições e o reparo de programas? A edição localizada enfatiza aquilo que deve permanecer inalterado; a geração com restrições impõe uma propriedade formal da saída, como a pertinência a uma gramática; e o reparo de programas exige que a alteração satisfaça a especificação de um defeito ou de uma tarefa. A sintaxe, por si só, não comprova equivalência semântica, correção funcional, êxito na tarefa nem localidade. [Compare os três objetivos](https://aogavrilov.com/pt/projects/discrete-latent-generation/#comparison) .
5. Como regenerar partes selecionadas de uma função Python mantendo estável o restante? Defina as regiões protegidas e editáveis antes da geração, modifique apenas a representação editável, decodifique e rejeite candidatos que alterem o código protegido ou não satisfaçam a sintaxe, os testes, as verificações estáticas ou as invariantes específicas da tarefa. O experimento relatado com representações latentes hierárquicas mede a estabilidade probabilística em funções de 64 tokens; ele não garante intervalos nem comportamento inalterados. [Examine o fluxo de trabalho de regeneração seletiva](https://aogavrilov.com/pt/projects/discrete-latent-generation/#workflow) .
6. Qual estratégia de controle é adequada à refatoração assistida por IA com preservação de comportamento? Utilize o modelo para identificar ou propor uma transformação; em seguida, sempre que possível, execute-a com um mecanismo de refatoração confiável e verifique a compilação, os testes, as análises estáticas e a refatoração pretendida. Um patch gerado que pareça plausível não constitui evidência suficiente. [Abrir a linha de decisão sobre refatoração](https://aogavrilov.com/pt/projects/discrete-latent-generation/#control-surface) .
7. O que torna a geração de código previsível, e não apenas controlável? Defina um contrato de preservação observável e verificações de aceitação antes de escolher o gerador. A previsibilidade depende do que permanece estável após a decodificação e a verificação, e não apenas de um prompt, uma máscara, uma gramática ou um código latente ter sido fixado. [Defina o contrato de preservação](https://aogavrilov.com/pt/projects/discrete-latent-generation/#core-idea) .

## O que o experimento atual demonstra — e o que não demonstra

Em [*Controle inspecionável para regeneração de software com preservação da estrutura*](https://aogavrilov.com/pt/publications/inspectable-control/) , um VQ-VAE hierárquico mapeia funções Python de 64 tokens em 16 posições discretas de nível superior e 32 de nível inferior. O bloqueio de quatro códigos de nível superior eleva a taxa de análise sintática de **0,453 a 0,591** , enquanto as posições desbloqueadas ainda mudam à taxa de **0.936** e as amostras condicionais permanecem **0,998 de unicidade** .

Esta é uma evidência de um compromisso mensurado entre estabilidade e liberdade em um contexto restrito. Não representa garantia de preservação exata da AST, equivalência semântica, correção funcional, reparo bem-sucedido ou comportamento na escala de um repositório.

O estudo complementar [*Where Quality Breaks in Compressed Short-Text Generation*](https://aogavrilov.com/pt/publications/where-quality-breaks/) acrescenta uma importante lição de avaliação: melhorias nas métricas substitutas do espaço latente não melhoram necessariamente as saídas decodificadas. A representação, a geração e o comportamento decodificado devem ser verificados como etapas distintas.

Para um procedimento decisório reutilizável, consulte o guia complementar sobre [distinção entre a perda do codec e a perda do gerador](https://aogavrilov.com/pt/projects/codec-bottleneck-diagnosis/) .

## Equívocos comuns

### “A análise sintática foi bem-sucedida, portanto está correto.”

A análise sintática comprova apenas a boa formação sintática. O programa ainda pode violar testes, contratos ou a intenção especificada.

### “Um código de granularidade grossa é um nó da AST.”

Não, a menos que se demonstre um alinhamento explícito. Os códigos aprendidos podem combinar diversos fatores superficiais e estruturais.

### “Variáveis latentes bloqueadas significam código-fonte inalterado.”

A decodificação é global e aprendida. Posições latentes fixas podem aumentar a estabilidade sem garantir um intervalo de texto idêntico.

### “Mudar menos é sempre melhor.”

Um editor que apenas copia a entrada alcança estabilidade perfeita, mas não progride na tarefa. A localidade e o êxito da edição devem ser medidos em conjunto.

## O que ler a seguir

Trabalhos relacionados utilizam interfaces de controle distintas; nenhum deles deve ser tratado como uma linha de base intercambiável sem que haja alinhamento com a tarefa.

1. [Self-Edit: Fault-Aware Code Editor for Code Generation](https://arxiv.org/abs/2305.04087) Trata a geração como um processo editável e utiliza as falhas detectadas para orientar a correção.
2. [Coeditor: Leveraging Contextual Changes for Multi-round Code Auto-editing](https://arxiv.org/abs/2305.18584) Modela alterações contextuais no código ao longo de sucessivas rodadas de edição, em vez de regenerá-lo do zero.
3. [PAFT: Preservation Aware Fine-Tuning for Minimal-Edit Program Repair](https://arxiv.org/abs/2604.03113) Torna explícitas a preservação e a alteração mínima no treinamento para reparo de programas.
4. [Constrained Decoding of Diffusion LLMs with Context-Free Grammars](https://arxiv.org/abs/2508.10111) Mostra como restrições formais podem oferecer garantias sintáticas durante a decodificação por difusão.
5. [Neural Discrete Representation Learning](https://arxiv.org/abs/1711.00937) Apresenta o VQ-VAE, mecanismo fundamental para representações latentes discretas aprendidas.
6. [Simple and Effective Masked Diffusion Language Models](https://arxiv.org/abs/2406.07524) Apresenta o arcabouço de difusão discreta mascarada empregado como gerador latente no estudo diagnóstico complementar.
7. [An Empirical Study on the Potential of LLMs in Automated Software Refactoring](https://arxiv.org/abs/2411.04444) Identifica refatorações inseguras propostas por LLMs e avalia a reaplicação das transformações detectadas por meio de mecanismos de refatoração confiáveis.
8. [SWE-Refactor: A Repository-Level Benchmark for Real-World LLM-Based Code Refactoring](https://arxiv.org/abs/2602.03712) Avalia a refatoração em nível de repositório que preserva o comportamento, mediante compilação, testes e detecção de refatorações.
9. [EfficientEdit: aceleração da edição de código por meio de decodificação especulativa orientada à edição](https://arxiv.org/abs/2506.02780) Reutiliza segmentos inalterados do código-fonte e prevê os locais de edição, em vez de tratar uma edição como regeneração autorregressiva completa.
10. [Hydra: Efficient, Correct Code Generation via Checkpoint-and-Rollback Support](https://arxiv.org/abs/2605.15238) Utiliza verificação estática, pontos de verificação e reversão direcionada para evitar a regeneração de prefixos já válidos após um erro.

## Breve recapitulação

A regeneração localizada de código constitui um contrato entre **alteração** e **preservação** . Variáveis latentes discretas hierárquicas oferecem uma forma inspecionável de expressar esse contrato, mas a representação só é útil quando os programas decodificados são avaliados quanto a localidade, sintaxe, estrutura, comportamento, diversidade e incerteza.

## Publicações nesta linha de pesquisa

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

Onde a qualidade se degrada na geração comprimida de textos curtos: localização escalonada de gargalos

Metodologia de diagnóstico FRUCT 39 2026 Conferência principal

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

Controle inspecionável para regeneração de software com preservação de estrutura

Método de controle no espaço latente FSE Companion '26 2026 Pôster complementar