# Modificação localizada de código com modelos generativos

Canonical HTML: https://aogavrilov.com/pt/research-notes/localized-code-modification-generative-models/

Document language: pt

NOTA DE PESQUISA

Como evitar a reescrita desnecessária de toda a função e, ao mesmo tempo, preservar liberdade suficiente para que um modelo generativo realize a alteração de código solicitada.

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

RESPOSTA DIRETA

## Como um modelo generativo pode modificar código sem reescrever toda a função?

Defina as regiões protegidas e editáveis antes da geração, reutilize ou restrinja a representação protegida, gere apenas alterações candidatas e rejeite resultados que modifiquem o código protegido ou não passem nas verificações específicas da tarefa. A localidade e o êxito na tarefa devem ser medidos em conjunto.

## Por que a distinção é importante

O método e a garantia alegada precisam compartilhar o mesmo limite observável.

A modificação localizada de código é um problema de edição, e não apenas um prompt mais curto para geração de código. A entrada já contém um artefato que merece ser preservado; por isso, o método requer uma fronteira de preservação explícita entre a região que pode ser alterada e as propriedades que devem permanecer estáveis.

O limite pode ser um trecho do código-fonte, um nó sintático, uma assinatura de API, o comportamento de um teste, um contrato de dependência ou uma posição latente aprendida. Essas escolhas não são intercambiáveis: cada uma protege uma propriedade observável distinta e requer uma etapa de verificação correspondente.

## Um procedimento prático

1. Definir o contrato de preservação Identifique a região editável e o texto, a estrutura, a interface ou o comportamento exatos que devem permanecer inalterados.
2. Escolha a interface de controle útil mais restrita Reutilize trechos inalterados do código-fonte, empregue preenchimento ou decodificação orientada à edição, aplique restrições formais ou bloqueie posições latentes selecionadas de acordo com a propriedade exigida.
3. Gere apenas onde a alteração é permitida Mantenha liberdade suficiente na região editável para resolver a tarefa; copiar toda a entrada é uma operação local, mas não produz avanço algum.
4. Verifique conjuntamente a localidade e o êxito Rejeitar candidatos que alterem regiões protegidas, falhem na análise sintática ou na compilação, violem invariantes estruturais ou não atendam à alteração solicitada.

## Evidências necessárias

Uma afirmação é tão sólida quanto a propriedade medida após a geração ou a decodificação.

- Diferenças fora da região ou outra medida direta da estabilidade da região protegida.
- Êxito da tarefa na região editável.
- Análise sintática, compilação, testes, verificações estáticas ou invariantes específicas da tarefa, conforme aplicável.
- Taxa de alteração da região editável, para que a cópia não seja confundida com controle.
- Unicidade dos candidatos e variabilidade entre execuções repetidas, para que a localidade não seja confundida com colapso de modos.

### O que o estudo vinculado relata

- O experimento associado comprime funções Python de 64 tokens em posições discretas hierárquicas e regenera posições latentes selecionadas sob restrições parciais.
- O bloqueio de quatro códigos de nível superior elevou a taxa de análise sintática de 0.453 para 0.591, enquanto as posições desbloqueadas foram alteradas à taxa de 0.936 e 0.998 das amostras condicionais permaneceram únicas.
- Essas medições revelam um compromisso entre estabilidade e liberdade acima do nível dos tokens; não comprovam a preservação exata de trechos do código-fonte, da AST, da semântica ou do comportamento.

[Ler a visão geral da publicação](https://aogavrilov.com/pt/publications/inspectable-control/) [Pesquisar no texto integral do artigo](https://aogavrilov.com/publications/inspectable-control/full-text/)

## Limite do escopo

- Um código latente bloqueado não é automaticamente um nó da AST, um trecho protegido do código-fonte ou um invariante formal.
- A taxa de análise sintática estabelece a boa formação sintática, não a correção funcional nem o êxito do reparo.
- As evidências apresentadas provêm de funções Python curtas e pré-processadas e não estabelecem o comportamento na escala de repositórios.

## Fontes primárias e trabalhos relacionados

Consulte os artigos vinculados para conhecer os métodos originais, as medições e as limitações declaradas.

1. [Inspectable Control for Structure-Preserving Software Regeneration](https://aogavrilov.com/pt/publications/inspectable-control/) Artigo principal e experimento delimitado com variáveis latentes hierárquicas.
2. [EfficientEdit: Accelerating Code Editing via Edit-Oriented Speculative Decoding](https://arxiv.org/abs/2506.02780) Decodificação orientada à edição que reutiliza regiões inalteradas do código-fonte.
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.

Mantido por Alexey Gavrilov . Esta página sintetiza as evidências existentes e não acrescenta resultados experimentais além dos apresentados nas fontes citadas.