Автодополнение и inline-правки
Что это
Заголовок раздела «Что это»Автодополнение — режим, в котором модель предлагает продолжение кода в момент ввода, не дожидаясь запроса. Пользователь видит серый «ghost text» и принимает его клавишей Tab либо игнорирует и продолжает печатать.
К этому же уровню относятся inline-правки: выделенный фрагмент переписывается по короткой инструкции («добавь обработку ошибки», «перепиши на async»), а результат показывается как diff прямо в редакторе — без перехода в чат.
Общее у них одно: человек остаётся автором, а система лишь ускоряет набор. Это принципиально отличает уровень от генерации кода, где модель выполняет задачу целиком.
Почему это отдельная инженерная задача
Заголовок раздела «Почему это отдельная инженерная задача»Автодополнение ограничено не качеством модели, а бюджетом задержки. Подсказка, пришедшая через две секунды, бесполезна: курсор уже ушёл дальше. Рабочий диапазон — сотни миллисекунд, и в него нужно уложить поиск контекста, вызов модели и фильтрацию результата.
Из этого следуют три отличия от чата:
- Маленький контекст. Обычно это префикс и суффикс текущего файла, импорты, сигнатуры соседних функций. Полный репозиторий в такой запрос не помещается.
- Специальная постановка задачи. Модель обучают и вызывают в режиме fill-in-the-middle (FIM): она видит текст до и после курсора и должна заполнить пропуск, а не продолжить текст в одну сторону.
- Фильтрация и ранжирование. Предложений может быть несколько; показывается одно, и выбор часто делает не модель, а эвристика по свежести контекста и частоте паттерна.
Что предлагают современные среды
Заголовок раздела «Что предлагают современные среды»| Вид | Когда срабатывает | Что даёт |
|---|---|---|
| Однострочное дополнение | Набор аргументов, конец условия, повторяющийся паттерн | Экономит секунды на рутине |
| Многострочное дополнение | Начало функции, тела метода, конфигурации | Собирает каркас, который остаётся проверить |
| Inline-правка выделенного | Явный запрос к фрагменту | Локальный рефакторинг без переключения контекста |
| Next-edit suggestions | После правки в одном месте | Подсказывает следующие места, которые обычно меняются вместе с этим |
| Автодополнение в терминале и конфигах | Команды, YAML, SQL | Снижает число обращений к документации |
Next-edit suggestions — содержательный сдвиг: среда перестаёт предсказывать текст и начинает предсказывать изменение. Это уже шаг в сторону агентного режима, где правки выполняются пакетом.
Где ломается
Заголовок раздела «Где ломается»- Устаревший API. Модель уверенно предлагает метод, удалённый два мажора назад: в её обучающих данных он был. Спасает только проверка типами и тестами.
- Правдоподобный, но неверный код. Синтаксис корректен, компилятор доволен, логика — нет. Особенно заметно в граничных условиях, обработке ошибок и работе с деньгами.
- Копирование шаблона. В проекте с «своим» способом работы с БД или HTTP модель тянет общепринятый, а не проектный. Лечится контекстом и правилами проекта — см. Контекст для агентов.
- Небезопасные паттерны. Склеивание SQL, доверие пользовательскому вводу, отключение проверки TLS — такие подсказки выглядят как обычный код и проходят ревью на бегу.
- Юридический след. Длинные фрагменты могут повторять лицензированный код; корпоративные среды фильтруют совпадения по публичному коду, но опираться на это в проекте без такой настройки нельзя.
Что измерять
Заголовок раздела «Что измерять»Автодополнение легко оценить количественно, и это один из немногих компонентов, где метрики действительно работают:
- Acceptance rate — доля принятых подсказок.
- Retention — остался ли принятый фрагмент в коде через день и через неделю. Высокий acceptance при низком retention означает, что инструмент создаёт работу: подсказку приняли, потом переписали.
- Время до мержа — итоговая метрика, которую легко испортить локальными улучшениями.
Ориентир из первого крупного исследования GitHub: в контролируемом эксперименте с задачей на написание HTTP-сервера группа с Copilot закончила примерно на 55% быстрее. Это результат конкретной задачи и конкретной выборки, а не универсальный множитель производительности.
Практики
Заголовок раздела «Практики»- Типы и линтер как первый фильтр. Подсказка, которая не проходит
tsc,phpstanили линтер, не должна доходить до ревью. - Короткие функции и явные имена. Чем однозначнее локальный контекст, тем точнее подсказка; длинные функции с десятью переменными дают худший результат.
- Тесты рядом с кодом. Автодополнение охотнее предлагает вызовы, которые уже есть в тестах, — и это правильное поведение, если тесты отражают требования.
- Отключение для чувствительных файлов. Секреты, платёжные сценарии, миграции и файлы с персональными данными — разумные кандидаты на исключение из индексации.
- Проверка diff, а не доверие курсору. Inline-правки принимают так же небрежно, как подсказки, хотя меняют уже написанный код.
Связанные материалы
Заголовок раздела «Связанные материалы»- Генерация кода и структурные правки — следующий уровень: изменения по запросу и на несколько файлов.
- Понимание кодовой базы — что видит инструмент, когда предлагает код.
- Ассистенты и среды — какие продукты реализуют это на практике.
- Оценка качества — как строить измерение на наборе задач, а не на впечатлении.
Материалы и источники
Заголовок раздела «Материалы и источники»- GitHub Copilot: документация — режимы подсказок, настройки и исключения
- Efficient Training of Language Models to Fill in the Middle (Bavarian et al., 2022) — постановка задачи FIM
- The Impact of AI on Developer Productivity: Evidence from GitHub Copilot (Peng et al., 2023) — контролируемый эксперимент с ускорением около 55%
- Measuring AI assistant impact — как GitHub считает acceptance и удержание принятых подсказок