Что это решает
Большая часть рабочего дня разработчика уходит не на трудные решения, а на набор предсказуемого текста: обвязка вокруг вызова API, разбор ответа, обработка ошибок, таблица тестовых случаев, очередной DTO. Copilot дописывает этот текст прямо в редакторе, пока курсор стоит в файле.
Вторая закрытая боль — вопросы к чужому коду. Вместо поиска по репозиторию и чтения трёх слоёв вызовов задаётся вопрос в чат с указанием на файл или на весь проект, и ответ приходит со ссылками на конкретные места.
Третья — рутина вокруг pull request. Черновое описание изменений, первый проход ревью по diff, ответ на замечание «а что здесь вообще происходит» делаются без переключения на другой инструмент, потому что всё живёт внутри платформы, где и так лежит код.
Четвёртая — мелкие задачи, до которых не доходят руки: обновить зависимость, поправить текст ошибки, дописать пропущенный тест. Их можно назначить агенту и получить черновой pull request на ревью.
Как устроено
Продукт распадается на несколько разных механизмов с общим именем. Смешивать их вредно: у них разный контекст, разное качество и разные риски.
Дополнения в редакторе
Серый текст в позиции курсора, принимается клавишей Tab. Контекст собирается локально: текущий файл до и после курсора, соседние открытые вкладки, путь и язык файла. Отсюда практическое следствие — держать открытыми файлы, на которые опирается текущий код: интерфейс, модель, соседний похожий обработчик. Закрытая вкладка означает, что модель этого не увидит и придумает своё.
Модель для дополнений выбрана из соображений скорости: ответ должен успевать за набором текста. Глубоких выводов от неё ждать не нужно.
Чат
Чат работает в двух видах: панель сбоку и инлайн-режим прямо в редакторе, где ответ применяется как правка. Есть слэш-команды под частые задачи — объяснить выделенное, починить, сгенерировать тесты, написать документирующий комментарий. Есть участники-контексты: обращение к рабочему пространству разворачивает поиск на весь проект, обращение к терминалу подтягивает последний вывод команды. Отдельные файлы добавляются в контекст явной ссылкой.
Для репозиториев на платформе строится удалённый индекс кода, за счёт которого поиск по проекту работает быстрее и находит больше, чем локальный обход. Свежесть индекса влияет на ответы: только что созданная ветка с новыми файлами может отвечать хуже, чем основная.
Агентный режим в редакторе
Режим, где модель сама выбирает файлы, вносит правки в нескольких местах, запускает сборку и тесты, читает вывод и продолжает до результата. Команды выполняются с подтверждением. Работа заканчивается набором правок в рабочей копии, которые остаётся отревьюить и закоммитить.
Агент, который открывает pull request
Задача назначается агенту прямо на платформе. Он поднимает изолированное окружение, забирает репозиторий, вносит правки, гоняет проверки и открывает черновой pull request с описанием сделанного. Дальше — обычный процесс: ревью, замечания, доработка. Правила защиты веток и обязательные проверки продолжают действовать, слить без человека такой pull request не получится.
Ревью
Copilot назначается ревьюером на pull request и оставляет комментарии по строкам diff: пропущенная проверка на пустое значение, несогласованное именование, забытая обработка ошибки. Полезен как первый проход, отсекающий очевидное до того, как diff увидит человек.
Инструкции репозитория
Постоянный контекст задаётся файлом .github/copilot-instructions.md в репозитории: стек, соглашения, запреты, команда запуска тестов. Дополнительно инструкции привязываются к маскам путей — свои правила для тестов, свои для миграций. Файлы лежат в git, поэтому команда получает одинаковое поведение.
Управление на уровне организации
Администратор включает и выключает функции политикой, ведёт список исключённого контента — путей и репозиториев, содержимое которых не отправляется и по которым не работают дополнения, и управляет фильтром совпадений с публичным кодом. Действия пользователей видны в журнале аудита. Всё это настраивается до раскатки на команду, а не по факту инцидента.
Полезные сценарии
- Обвязка вокруг внешнего API: клиент, модели ответа, обработка кодов ошибок — там, где формат известен и однообразен.
- Таблица тестовых случаев к чистой функции: граничные значения, пустые входы, некорректные типы.
- Быстрый ответ на вопрос «где это используется» и «почему здесь такой порядок вызовов» на незнакомом репозитории.
- Первый проход ревью на pull request: очевидные пропуски отсекаются до того, как diff открывает человек.
- Мелкие изолированные задачи из очереди, отданные агенту: правка текста, обновление зависимости, недостающий тест.
- Разбор упавшей команды в терминале без копирования вывода в браузер.
Ограничения
Дополнение не знает архитектуры. Оно опирается на текущий файл и открытые вкладки, поэтому уверенно повторяет локальный стиль и мимо проходит по замыслу: пишет свой запрос к базе там, где в проекте есть репозиторий, или дублирует хелпер, лежащий в соседнем модуле.
Нетипичный стек проседает. Качество прямо связано с объёмом публичного кода на этом языке и фреймворке. На внутренней библиотеке компании и на редком диалекте предложения превращаются в правдоподобную выдумку.
Совпадения с публичным кодом. Длинный фрагмент может совпасть с чужим кодом под неудобной лицензией. Фильтр совпадений включают на уровне организации, а не полагаются на внимательность разработчика.
Контекст ограничен. Ответы чата зависят от свежести индекса, а дополнения — от того, что открыто прямо сейчас. «Модель не видит» — самая частая причина плохой подсказки, и лечится она добавлением файла в контекст, а не переформулировкой вопроса.
Облачный агент отрезан от внутреннего контура. Он не достучится до закрытого сервиса, приватного пакетного реестра или тестовой базы без явной настройки окружения. Задачи с интеграциями он не закроет.
Ревью остаётся на человеке. Черновой pull request от агента проходит те же проверки, что и любой другой. Автоматическое одобрение таких изменений превращает CI в единственный барьер перед продом.
Метрика принятых подсказок обманывает. Доля принятых дополнений растёт от привычки жать Tab. Она ничего не говорит ни о числе дефектов, ни о времени доставки.
Данные и комплаенс. Что уходит в сервис и как хранится, определяется планом и настройками организации. Для регулируемой отрасли это отдельный документ и отдельное согласование.
Как проверить результат
Смотреть, на какие файлы сослался чат. Ответ без ссылок на код проекта построен на общих знаниях о языке и к этому репозиторию отношения не имеет.
Проверить исключения делом: открыть файл, который по политике исключён, и убедиться, что дополнения по нему не приходят и чат его не цитирует. Запись в настройках без такой проверки — предположение.
Проверить, что фильтр совпадений с публичным кодом включён на уровне организации, а не оставлен на усмотрение каждого разработчика.
На pull request от агента — полное ревью и обязательный человек-апрувер в правилах ветки. Тесты в CI прогоняются те же, что для людей, без послаблений.
Проверять инструкции репозитория экспериментом: дать задачу, нарушающую записанное соглашение, и посмотреть, следует ли модель правилу. Инструкция, не влияющая на вывод, написана как пожелание.
Замерять пользу по потоку: время от начала задачи до слитого pull request, число возвратов из ревью, количество дефектов, дошедших до прода. Эти цифры сравнивают до и после раскатки, за одинаковые по составу периоды.
При плохих дополнениях сначала проверять состав открытых вкладок, потом всё остальное. Нужный интерфейс и соседний похожий модуль в соседних вкладках меняют качество подсказок сильнее любых настроек.
Правило: подсказку принимают только после проверки, что модель видела те файлы, от которых зависит правка.