---
title: Автодополнение и inline-правки
description: "Почему автодополнение кода — отдельный класс задач с бюджетом задержки: как работает fill-in-the-middle, что предлагают next-edit suggestions и где такие подсказки ломаются."
---

## Что это

Автодополнение — режим, в котором модель предлагает продолжение кода **в момент ввода**, не дожидаясь запроса. Пользователь видит серый «ghost text» и принимает его клавишей Tab либо игнорирует и продолжает печатать.

К этому же уровню относятся inline-правки: выделенный фрагмент переписывается по короткой инструкции («добавь обработку ошибки», «перепиши на async»), а результат показывается как diff прямо в редакторе — без перехода в чат.

Общее у них одно: **человек остаётся автором**, а система лишь ускоряет набор. Это принципиально отличает уровень от [генерации кода](https://wpcraft.ru/kb/ai/coding/code-generation.md), где модель выполняет задачу целиком.

## Почему это отдельная инженерная задача

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

Из этого следуют три отличия от чата:

- **Маленький контекст.** Обычно это префикс и суффикс текущего файла, импорты, сигнатуры соседних функций. Полный репозиторий в такой запрос не помещается.
- **Специальная постановка задачи.** Модель обучают и вызывают в режиме **fill-in-the-middle** (FIM): она видит текст до и после курсора и должна заполнить пропуск, а не продолжить текст в одну сторону.
- **Фильтрация и ранжирование.** Предложений может быть несколько; показывается одно, и выбор часто делает не модель, а эвристика по свежести контекста и частоте паттерна.

## Что предлагают современные среды

| Вид | Когда срабатывает | Что даёт |
|---|---|---|
| **Однострочное дополнение** | Набор аргументов, конец условия, повторяющийся паттерн | Экономит секунды на рутине |
| **Многострочное дополнение** | Начало функции, тела метода, конфигурации | Собирает каркас, который остаётся проверить |
| **Inline-правка выделенного** | Явный запрос к фрагменту | Локальный рефакторинг без переключения контекста |
| **Next-edit suggestions** | После правки в одном месте | Подсказывает следующие места, которые обычно меняются вместе с этим |
| **Автодополнение в терминале и конфигах** | Команды, YAML, SQL | Снижает число обращений к документации |

Next-edit suggestions — содержательный сдвиг: среда перестаёт предсказывать **текст** и начинает предсказывать **изменение**. Это уже шаг в сторону агентного режима, где правки выполняются пакетом.

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

- **Устаревший API.** Модель уверенно предлагает метод, удалённый два мажора назад: в её обучающих данных он был. Спасает только проверка типами и тестами.
- **Правдоподобный, но неверный код.** Синтаксис корректен, компилятор доволен, логика — нет. Особенно заметно в граничных условиях, обработке ошибок и работе с деньгами.
- **Копирование шаблона.** В проекте с «своим» способом работы с БД или HTTP модель тянет общепринятый, а не проектный. Лечится контекстом и правилами проекта — см. [Контекст для агентов](https://wpcraft.ru/kb/ai/context.md).
- **Небезопасные паттерны.** Склеивание SQL, доверие пользовательскому вводу, отключение проверки TLS — такие подсказки выглядят как обычный код и проходят ревью на бегу.
- **Юридический след.** Длинные фрагменты могут повторять лицензированный код; корпоративные среды фильтруют совпадения по публичному коду, но опираться на это в проекте без такой настройки нельзя.

## Что измерять

Автодополнение легко оценить количественно, и это один из немногих компонентов, где метрики действительно работают:

- **Acceptance rate** — доля принятых подсказок.
- **Retention** — остался ли принятый фрагмент в коде через день и через неделю. Высокий acceptance при низком retention означает, что инструмент создаёт работу: подсказку приняли, потом переписали.
- **Время до мержа** — итоговая метрика, которую легко испортить локальными улучшениями.

Ориентир из первого крупного исследования GitHub: в контролируемом эксперименте с задачей на написание HTTP-сервера группа с Copilot закончила примерно на 55% быстрее. Это результат конкретной задачи и конкретной выборки, а не универсальный множитель производительности.

## Практики

1. **Типы и линтер как первый фильтр.** Подсказка, которая не проходит `tsc`, `phpstan` или линтер, не должна доходить до ревью.
2. **Короткие функции и явные имена.** Чем однозначнее локальный контекст, тем точнее подсказка; длинные функции с десятью переменными дают худший результат.
3. **Тесты рядом с кодом.** Автодополнение охотнее предлагает вызовы, которые уже есть в тестах, — и это правильное поведение, если тесты отражают требования.
4. **Отключение для чувствительных файлов.** Секреты, платёжные сценарии, миграции и файлы с персональными данными — разумные кандидаты на исключение из индексации.
5. **Проверка diff, а не доверие курсору.** Inline-правки принимают так же небрежно, как подсказки, хотя меняют уже написанный код.

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

- [Генерация кода и структурные правки](https://wpcraft.ru/kb/ai/coding/code-generation.md) — следующий уровень: изменения по запросу и на несколько файлов.
- [Понимание кодовой базы](https://wpcraft.ru/kb/ai/coding/code-understanding.md) — что видит инструмент, когда предлагает код.
- [Ассистенты и среды](https://wpcraft.ru/kb/ai/coding/harnesses.md) — какие продукты реализуют это на практике.
- [Оценка качества](https://wpcraft.ru/kb/ai/agents/evaluation.md) — как строить измерение на наборе задач, а не на впечатлении.

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

- [GitHub Copilot: документация](https://docs.github.com/en/copilot) — режимы подсказок, настройки и исключения
- [Efficient Training of Language Models to Fill in the Middle (Bavarian et al., 2022)](https://arxiv.org/abs/2207.14255) — постановка задачи FIM
- [The Impact of AI on Developer Productivity: Evidence from GitHub Copilot (Peng et al., 2023)](https://arxiv.org/abs/2302.06590) — контролируемый эксперимент с ускорением около 55%
- [Measuring AI assistant impact](https://github.blog/news-insights/research/) — как GitHub считает acceptance и удержание принятых подсказок