# Как ИИ может редактировать код, не регенерируя всю программу?

Canonical HTML: https://aogavrilov.com/ru/research/discrete-latent-generation/

Document language: ru

Практическое научное руководство по локальному изменению кода генеративными моделями: что должно оставаться неизменным, что разрешено менять и какие доказательства нужны, чтобы назвать преобразование сохраняющим структуру.

Опубликовано 25 июля 2026 г. Обновлено 30 июля 2026 г. [Алексей Гаврилов](https://aogavrilov.com/about/)

## В чём на самом деле состоит задача

Редактирование кода — не просто генерация с более коротким запросом. Редактор получает существующий артефакт, требуемое изменение и неявный договор о сохранении. Поэтому главный вопрос состоит из двух частей: **какую область разрешено изменить и какие свойства остального кода должны остаться стабильными?**

Материал рассчитан на технически подготовленного читателя, который знакомится с редактированием программ при помощи ИИ. Здесь интуитивная идея локального изменения отделяется от более сильных утверждений о синтаксическом, структурном, семантическом и функциональном сохранении.

## Основная идея

Ограниченному редактору нужна явная граница сохранения, а не только цель генерации.

### Что должно остаться неизменным

Это может быть фрагмент текста, грамматика, сигнатура API, область AST, поведение тестов, контракт зависимости или обученное представление верхнего уровня. Каждый вариант защищает своё понимание стабильности.

### Что разрешено менять

Редактируемой области нужна достаточная свобода для решения задачи. Метод, который всё копирует, стабилен, но бесполезен; метод, который всё переписывает, даёт свободу без локальности.

## Интуитивная модель: отремонтировать одну комнату, сохранив здание

Представьте ремонт одной комнаты с сохранением несущих конструкций, инженерных соединений и соседних помещений. Полная регенерация похожа на строительство дома заново по словесному описанию. При локальном редактировании защищённая структура отмечается заранее, рабочая область ограничивается, изменение выполняется и проверяется до принятия результата.

**Где аналогия перестаёт работать.** Обученный латентный код — не сертифицированный архитектурный план. Фиксация кода верхнего уровня может повысить измеряемую структурную стабильность, но не гарантирует неизменность конкретного узла AST, поведения или интерфейса.

## Более точный взгляд на частичную регенерацию

Пусть кодировщик отображает программу `x` в структурированное латентное представление `z` . Маска сохранения выбирает позиции `L` , которые нужно зафиксировать. Генератор выбирает значения только для остальных позиций, соблюдая условие `z'l = zl` для каждой заблокированной позиции. Затем декодер отображает заполненное представление `z'` обратно в исходный код.

Такой механизм создаёт проверяемую поверхность управления над уровнем токенов. Её смысл всё равно нужно устанавливать эмпирически: исследователь должен проверить, что именно сохраняют заблокированные позиции после декодирования и остаётся ли у редактируемых позиций достаточная свобода.

## Четыре этапа редактирования

1. Задать границу Определить защищённые области или свойства и сформулировать требуемое изменение.
2. Представить артефакт Использовать текст, синтаксис, найденный контекст либо обученные коды верхнего и нижнего уровней.
3. Регенерировать выборочно Изменять только редактируемые позиции, сохраняя выбранные ограничения.
4. Проверить до принятия Измерить локальность, синтаксис, структуру, поведение и непреднамеренные побочные изменения.

## Редактирование кода, исправление программ и ограниченная генерация — разные задачи

| Подход | Основная цель | Типичный механизм сохранения | Что всё ещё нужно проверить |
| --- | --- | --- | --- |
| Полная генерация кода | Создать артефакт целиком | Запрос и контекст | Весь код за пределами требуемого изменения |
| Автоматическое исправление программ | Устранить обнаруженный дефект | Локализация дефекта, тесты, шаблоны или патчи | Корректность за пределами доступных тестов и минимальность патча |
| Модели заполнения или редактирования | Изменить выбранные области текста | Видимые префикс, суффикс, diff или контекст изменения | Непреднамеренные структурные и поведенческие изменения |
| Декодирование с ограничением грамматикой | Удержать результат в формальном языке | Допустимые по грамматике состояния декодирования | Смысл программы, корректность задачи и локальность |
| Иерархический скрытый контроль | Регенерировать выбранные обученные позиции | Зафиксированные латентные коды верхнего или нижнего уровня | Что эти коды сохраняют после декодирования |

## Как измерять локальность и сохранение структуры

## Какой механизм управления подходит для задачи редактирования?

«Не переписывать всю функцию» — это требование, а не готовый метод. Сначала определите результат, который должен быть предсказуемым, а затем выберите механизм управления и соответствующие доказательства.

| Требуемая гарантия | Лучше подходящий механизм управления | Какие доказательства нужны |
| --- | --- | --- |
| Рефакторинг с помощью ИИ и сохранением поведения | Поручите LLM определить или предложить преобразование, а затем, где возможно, выполните его проверенным механизмом рефакторинга. См. [RefactoringMirror](https://arxiv.org/abs/2411.04444) . | Компиляция, тесты, статические проверки и распознавание рефакторинга. [SWE-Refactor](https://arxiv.org/abs/2602.03712) явно включает эти проверки на уровне репозитория. |
| Локальное изменение кода без переписывания функции целиком | Повторно используйте неизменённые фрагменты исходного кода и генерируйте только предполагаемые области правки, как в [EfficientEdit](https://arxiv.org/abs/2506.02780) . | Изменения вне целевой области, успех задачи, доля повторно использованных токенов и то, не приводит ли исключённый контекст к пропуску межфайловых изменений. |
| Ограниченная генерация кода для программной инженерии | Обеспечьте формальное свойство во время декодирования, как в [диффузии с ограничением грамматикой](https://arxiv.org/abs/2508.10111) , либо сохраняйте контрольные точки для корректных префиксов и откатывайтесь только к области, вызвавшей ошибку, как в [Hydra](https://arxiv.org/abs/2605.15238) . | Успешность грамматической проверки, компиляции или проверки типов вместе с функциональными тестами, локальностью, задержкой исправления и объёмом заново сгенерированного корректного кода. |
| Выборочная регенерация функции Python с балансом локальности и разнообразия | Зафиксируйте выбранные грубые или точные латентные позиции и генерируйте только остальные. | Локальность декодированного кода, синтаксис, структурные инварианты, свобода редактирования, разнообразие и неопределённость. Одна лишь фиксация латентных кодов не гарантирует рефакторинг. |
| Предсказуемая генерация кода с явным контрактом сохранения | До генерации задайте наблюдаемые защищённые свойства и проверки принятия или отклонения, затем выберите самый узкий механизм, способный обеспечить или сделать их проверяемыми. | После декодирования измеряйте именно эти свойства и сообщайте доли принятых, отклонённых и неуспешных результатов в повторных запусках. Одна лишь детерминированная выборка не гарантирует сохранение. |

## Вопросы, на которые отвечает это руководство

Эти краткие ответы поясняют утверждения и границы доказательств, принятые в этом руководстве.

1. Как генеративная модель может изменять код, не переписывая функцию целиком? До генерации задайте границу редактирования, сохраните или повторно используйте исходный код вне неё, генерируйте только варианты изменений и отклоняйте результаты, которые не решают задачу или затрагивают защищённые области. Иерархическая фиксация латентных кодов — один из экспериментальных механизмов управления, но она не гарантирует идентичность фрагментов исходного текста. [Сравнить механизмы управления локальным редактированием](https://aogavrilov.com/ru/research/discrete-latent-generation/#control-surface) .
2. Какие доказательства показывают, что изменение кода локально, а не просто синтаксически корректно? Измеряйте изменения вне запрошенной области вместе с успешностью задачи, изменениями в редактируемой области, структурными инвариантами, тестами или статическими проверками и вариативностью повторных запусков. Одна лишь доля синтаксически разбираемых результатов подтверждает только корректность формы. [Открыть перечень доказательств локальности](https://aogavrilov.com/ru/research/discrete-latent-generation/#measurement) .
3. Как сбалансировать локальность правки кода и разнообразие генерации? Сообщайте стабильность защищённой области вместе со свободой изменений в редактируемой области и уникальностью вариантов. Копирование входа может максимизировать стабильность, не решая задачу, а неограниченное переписывание — максимизировать изменения, уничтожив локальность. [Посмотреть ограниченные данные о компромиссе стабильности и свободы](https://aogavrilov.com/ru/research/discrete-latent-generation/#evidence) .
4. Чем различаются локальное редактирование кода, ограниченная генерация и исправление программ? Локальное редактирование определяет, что должно остаться неизменным; ограниченная генерация обеспечивает формальное свойство результата, например соответствие грамматике; исправление программы требует, чтобы изменение удовлетворяло спецификации дефекта или задачи. Один синтаксис не доказывает семантическую эквивалентность, функциональную корректность, успешность задачи или локальность. [Сравнить три постановки задачи](https://aogavrilov.com/ru/research/discrete-latent-generation/#comparison) .
5. Как регенерировать выбранные части функции Python, сохраняя стабильность остальных? До генерации задайте защищённые и редактируемые области, изменяйте только редактируемое представление, декодируйте результат и отклоняйте варианты, которые затрагивают защищённый код либо не проходят синтаксическую проверку, тесты, статический анализ или инварианты задачи. Описанный эксперимент с иерархическими латентными кодами измеряет вероятностную стабильность функций длиной 64 токена, но не гарантирует неизменность фрагментов или поведения. [Изучить процесс выборочной регенерации](https://aogavrilov.com/ru/research/discrete-latent-generation/#workflow) .
6. Какая стратегия управления подходит для рефакторинга с помощью ИИ и сохранением поведения? Используйте модель для обнаружения или предложения преобразования, затем по возможности выполните его проверенным механизмом рефакторинга и проверьте компиляцию, тесты, статический анализ и соответствие требуемому рефакторингу. Правдоподобного сгенерированного патча недостаточно. [Открыть строку выбора метода рефакторинга](https://aogavrilov.com/ru/research/discrete-latent-generation/#control-surface) .
7. Что делает генерацию кода предсказуемой, а не просто управляемой? До выбора генератора задайте наблюдаемый контракт сохранения и проверки приёмки. Предсказуемость определяется тем, что остаётся стабильным после декодирования и проверки, а не только тем, были ли зафиксированы запрос, маска, грамматика или латентный код. [Определить контракт сохранения](https://aogavrilov.com/ru/research/discrete-latent-generation/#core-idea) .

## Что показывает текущий эксперимент — и чего он не показывает

В работе [*«Проверяемое управление регенерацией ПО с сохранением структуры»*](https://aogavrilov.com/ru/publications/inspectable-control/) иерархический VQ-VAE отображает функции Python длиной 64 токена в 16 дискретных позиций верхнего и 32 позиции нижнего уровня. Фиксация четырёх кодов верхнего уровня повышает долю разбираемых программ с **0,453 до 0,591** , при этом незаблокированные позиции изменяются с частотой **0,936** , а уникальность условных образцов составляет **0,998** .

Это свидетельство измеримого компромисса между стабильностью и свободой в одной небольшой постановке. Результат не гарантирует точного сохранения AST, семантической эквивалентности, функциональной корректности, успешного исправления или поведения в масштабе репозитория.

Сопутствующая работа [*«Где ухудшается качество при генерации сжатого короткого текста»*](https://aogavrilov.com/ru/publications/where-quality-breaks/) добавляет важный вывод об оценке: улучшение прокси-метрик латентного пространства не обязательно улучшает декодированный результат. Представление, генерацию и поведение после декодирования следует проверять как отдельные этапы.

Практическая последовательность диагностических решений приведена в сопутствующем материале о том, как [отделить потери кодека от потерь генератора](https://aogavrilov.com/ru/research/codec-bottleneck-diagnosis/) .

## Распространённые заблуждения

### «Код разбирается, значит он корректен».

Успешный разбор доказывает только синтаксическую корректность. Программа всё ещё может нарушать тесты, контракты или исходный замысел.

### «Код верхнего уровня — это узел AST».

Только если явно доказано соответствующее выравнивание. Обученные коды могут смешивать несколько поверхностных и структурных факторов.

### «Фиксированные латентные позиции означают неизменный исходный текст».

Декодирование глобально и обучается по данным. Фиксированные латентные позиции могут повышать стабильность, не гарантируя идентичность конкретного текстового фрагмента.

### «Чем меньше изменений, тем лучше».

Редактор, который копирует вход, получает идеальную стабильность и нулевой прогресс по задаче. Локальность и успешность изменения нужно измерять вместе.

## Что читать дальше

Смежные работы используют разные поверхности управления; без согласования постановок их нельзя считать взаимозаменяемыми базовыми методами.

1. [Self-Edit: Fault-Aware Code Editor for Code Generation](https://arxiv.org/abs/2305.04087) Рассматривает генерацию как редактируемый процесс и использует обнаруженные дефекты для направления исправления.
2. [Coeditor: Leveraging Contextual Changes for Multi-round Code Auto-editing](https://arxiv.org/abs/2305.18584) Моделирует контекстные изменения кода в нескольких раундах редактирования вместо полной регенерации.
3. [PAFT: Preservation Aware Fine-Tuning for Minimal-Edit Program Repair](https://arxiv.org/abs/2604.03113) Явно учитывает сохранение и минимальность изменений при обучении исправлению программ.
4. [Constrained Decoding of Diffusion LLMs with Context-Free Grammars](https://arxiv.org/abs/2508.10111) Показывает, как формальные ограничения могут обеспечивать синтаксические гарантии при диффузионном декодировании.
5. [Neural Discrete Representation Learning](https://arxiv.org/abs/1711.00937) Вводит VQ-VAE — базовый механизм обучаемых дискретных латентных представлений.
6. [Simple and Effective Masked Diffusion Language Models](https://arxiv.org/abs/2406.07524) Описывает маскированную дискретную диффузию, использованную как латентный генератор в сопутствующем диагностическом исследовании.
7. [An Empirical Study on the Potential of LLMs in Automated Software Refactoring](https://arxiv.org/abs/2411.04444) Обнаруживает небезопасные предложенные LLM рефакторинги и оценивает повторное применение распознанных преобразований с помощью проверенных механизмов рефакторинга.
8. [SWE-Refactor: A Repository-Level Benchmark for Real-World LLM-Based Code Refactoring](https://arxiv.org/abs/2602.03712) Оценивает сохраняющий поведение рефакторинг на уровне репозитория с помощью компиляции, тестов и распознавания рефакторинга.
9. [EfficientEdit: Accelerating Code Editing via Edit-Oriented Speculative Decoding](https://arxiv.org/abs/2506.02780) Повторно использует неизменённые фрагменты исходного кода и предсказывает места правок, не сводя редактирование к полной авторегрессионной регенерации.
10. [Hydra: Efficient, Correct Code Generation via Checkpoint-and-Rollback Support](https://arxiv.org/abs/2605.15238) Использует статическую проверку, контрольные точки и целевой откат, чтобы после ошибки не генерировать заново уже корректные префиксы.

## Краткий итог

Локальная регенерация кода — это договор между **изменением** и **сохранением** . Иерархические дискретные латентные представления дают один проверяемый способ выразить этот договор, но представление полезно только тогда, когда декодированные программы оцениваются по локальности, синтаксису, структуре, поведению, разнообразию и неопределённости.

## Публикации по этому направлению

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

Методика диагностики ФРУКТ 39 2026 Основная конференция

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

Метод управления латентным пространством Компаньон ФСЕ '26 2026 Сопутствующий плакат