---
title: Генерация кода и структурные правки
description: "Как модель переходит от промпта к diff: правки на несколько файлов, изменения по AST и LSP, проверка перед применением и типичные способы испортить кодовую базу."
---

## Что это

Генерация кода — режим, в котором модель по запросу создаёт или изменяет код: пишет функцию, рефакторит модуль, добавляет эндпоинт, обновляет тесты. В отличие от [автодополнения](https://wpcraft.ru/kb/ai/coding/autocomplete.md), здесь человек формулирует задачу, а не просто продолжает печатать.

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

## Три формата изменений

| Формат | Что делает | Когда уместен |
|---|---|---|
| **Однофайловая правка** | Меняет функцию, блок или файл целиком | Локальная задача с ясными границами |
| **Многофайловый diff** | Собирает согласованное изменение по нескольким файлам | Новая функциональность, рефакторинг, миграция API |
| **Структурная трансформация** | Переписывает код по правилу, а не по смыслу: переименование, замена вызова, codemod | Массовые механические изменения в большом репозитории |

Структурные правки — недооценённый сценарий. Когда нужно заменить устаревший вызов в двухстах местах, правило на основе AST или LSP-переименование надёжнее генерации: результат детерминирован, его можно проверить диффом и повторить.

## Как правка попадает в код

Модель не «редактирует файл» — она возвращает текст или инструкцию, а применяет её среда. От этого зависит очень многое:

- **Search-and-replace блоки.** Модель отдаёт фрагмент «найти → заменить». Среда ищет фрагмент в файле дословно и падает, если он не совпал. Дешёво, но чувствительно к пробелам и переименованиям.
- **Полная перезапись файла.** Просто, но опасно на больших файлах: модель может потерять код, который не попал в контекст.
- **Правки через инструменты.** Среда даёт модели операции `read`, `grep`, `edit`, `write` с проверкой и подсчётом строк; агент вызывает их по шагам. Это уже [агентный режим](https://wpcraft.ru/kb/ai/agents.md).
- **Структурные операции.** Переименование, извлечение метода, применение codemod — выполняются языковым сервером или AST-инструментом, а не моделью.

Правило: чем более «текстовый» способ применения, тем важнее, чтобы после него запускались компилятор, типы и тесты. Дословное совпадение блока не гарантирует, что изменение осмысленно.

## Как повысить шанс успеха

1. **Дайте план до кода.** Список затрагиваемых файлов и порядок шагов уменьшает хаотичные правки и облегчает проверку. См. [SDD](https://wpcraft.ru/kb/ai/coding/sdd.md).
2. **Дробите задачу.** Три маленьких изменения с проверкой между ними почти всегда лучше одного большого diff.
3. **Покажите проектные паттерны.** Один существующий контроллер или тест в контексте работает лучше, чем абзац описания «как у нас принято».
4. **Зафиксируйте границы.** «Меняй только файлы в этом модуле» — не формальность: без границы агент тянет правки в соседние слои.
5. **Требуйте проверок.** Задача считается выполненной, когда тесты и линтер прошли, а не когда код выглядит правильным.

## Где ломается

- **Фантомные API.** Метод выглядит знакомо, но не существует в вашей версии библиотеки. Ловится типами и запуском.
- **Дрейф стиля.** Каждая правка сама по себе корректна, вместе они дают три способа делать одно и то же.
- **Дублирование абстракций.** Модель не видит существующий хелпер и пишет четвёртый по счёту.
- **Потеря кода при перезаписи.** Классика больших файлов: часть содержимого не попала в контекст и исчезла из результата.
- **Зелёные тесты при неверном поведении.** Если тест писал тот же агент, он мог закрепить ошибку, а не требование.
- **Разрастание diff.** Изменение на 40 файлов невозможно осмысленно отревьюить; это не признак эффективности, а риск.

## Что проверять

- **Проходит ли сборка** и типы — до чтения diff.
- **Покрыто ли новое поведение тестом**, который падал до изменения.
- **Нет ли правок за пределами заявленной области.**
- **Совпадает ли решение с проектными соглашениями** — или это общепринятый паттерн из обучающих данных.
- **Откатывается ли изменение** одной командой.

## Связанные материалы

- [Автодополнение и inline-правки](https://wpcraft.ru/kb/ai/coding/autocomplete.md) — уровень, где человек остаётся автором каждой строки.
- [Понимание кодовой базы](https://wpcraft.ru/kb/ai/coding/code-understanding.md) — откуда берётся контекст для правок.
- [TDD](https://wpcraft.ru/kb/ai/coding/tdd.md) — как превратить тест в спецификацию изменения.
- [Guardrails](https://wpcraft.ru/kb/ai/agents/guardrails.md) — права, лимиты и подтверждения при работе агента с репозиторием.

## Материалы и источники

- [GitHub Copilot: редактирование кода и агентный режим](https://docs.github.com/en/copilot) — как среда применяет предложенные правки
- [SWE-bench](https://www.swebench.com/) — бенчмарк на реальных issue: измеряет именно способность выдать работающий патч
- [Anthropic: Claude Code best practices](https://www.anthropic.com/engineering/claude-code-best-practices) — планирование, границы задачи и проверки в агентном режиме
- [Sourcegraph: AI developer tools 2026](https://sourcegraph.com/blog/ai-developer-tools) — почему многофайловые правки упираются в слой retrieval по коду