GitHub Copilot в VS Code: как подключить и использовать в реальном проекте

GitHub Copilot установлен, чат открыт, курсор мигает. Самый трудный вопрос на этом этапе не «что умеет ИИ», а что именно поручить ему сейчас. Просьба «доделай приложение» слишком широка: ассистенту придётся самому угадать цель, выбрать файлы и решить, как проверить результат. Чем больше таких догадок, тем труднее понять получившиеся изменения.

В VS Code Copilot работает на нескольких поверхностях. Он может дописывать код рядом с курсором, отвечать на вопросы о проекте, составлять план и выполнять изменения как агент. Это не четыре уровня качества, а четыре разных способа работы. Выбирать их стоит по размеру и риску задачи.

В актуальном VS Code начните со значка Copilot в строке состояния и действия для подключения AI-функций. Редактор предложит войти в GitHub. Если активной подписки нет, можно оформить Copilot Free с месячным лимитом запросов и подсказок. Условия и доступность функций меняются, поэтому перед работой лучше свериться с текущей страницей настройки, а не ориентироваться на старый скриншот.

После входа откройте папку проекта, а не отдельный случайный файл. Так Copilot сможет использовать структуру рабочей области как контекст. Если это существующий проект, сначала убедитесь, что он запускается без новых изменений и что текущая версия сохранена в Git. Иначе будет сложно отделить старую проблему от правки ассистента.

Команда /init в чате помогает создать инструкции для проекта. VS Code анализирует кодовую базу и формирует файл .github/copilot-instructions.md. Не принимайте его автоматически: откройте файл и оставьте только проверяемые правила, например команду запуска тестов, используемый менеджер пакетов, расположение исходников и запрет менять определённую папку. Ошибочная инструкция будет повторяться в каждой следующей задаче.

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

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

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

Agent выбирайте, когда задача уже ограничена и критерий готовности понятен. В этом режиме Copilot может находить контекст, редактировать файлы и предлагать команды терминала. Объём полномочий зависит от настроек и подтверждений. Само наличие Agent mode не означает, что ему нужно разрешать любую команду или принимать все правки пакетом.

Локальный агент в VS Code не следует смешивать с GitHub coding agent, которому назначают задачу на GitHub и который работает в отдельной среде над pull request. В этой статье речь только о цикле внутри редактора: вы ставите малую задачу, наблюдаете изменения в своей рабочей папке и сами решаете, что попадёт в коммит.

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

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

До чата проверьте git status. Если в рабочей папке уже есть нужные незакоммиченные изменения, сохраните их отдельным осмысленным коммитом или явно отделите от новой задачи. Затем запустите приложение и существующие проверки той командой, которая принята в проекте. Запишите уже известные ошибки. Цель этого шага: получить точку сравнения, а не доказать, что весь проект идеален.

Не просите агента самостоятельно «очистить репозиторий». Он может удалить файлы, которые кажутся ему лишними, но относятся к вашей незавершённой работе.

Хорошая постановка состоит из цели, места изменения, ограничений и проверки. Её можно написать так:

Фраза «сделай красивое пустое состояние» короче, но оставляет агенту продуктовые решения, которых в задаче нет. Конкретные состояния дают и вам, и Copilot общий способ проверить результат.

Если правило относится ко всему проекту, его можно вынести в .github/copilot-instructions.md. Например, там уместны команда проверки и правило не добавлять зависимости без запроса. Детали одной функции лучше оставить в сообщении: постоянный файл не должен разрастаться в историю разовых пожеланий.

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

• использует ли он существующий компонент и стиль интерфейса;

• отличает ли пустые данные от загрузки и ошибки;

• не предлагает ли новый пакет ради одной надписи;

• называет ли конкретную проверку после изменения.

Если план затрагивает несвязанные файлы, сузьте задачу. Если Copilot не нашёл тестов, это не доказательство, что их нет: попросите показать, где он искал, и проверьте структуру проекта самостоятельно.

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

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

Не ограничивайтесь зелёной отметкой в чате. Откройте diff и для каждого файла ответьте:

1. Зачем этот файл изменён?

2. Какое условие теперь выбирает пустое состояние?

3. Что произойдёт во время загрузки и при ошибке?

4. Не удалена ли существующая логика или проверка?

5. Не появились ли новая зависимость, небезопасная вставка данных или случайный секрет?

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

После чтения примите решение по каждой предложенной правке: оставьте понятные и относящиеся к задаче через Keep, лишние верните через Undo. Команды Keep All и Undo All действуют сразу на весь набор, поэтому не используйте пакетное принятие, пока не проверили каждое изменение. Затем ещё раз откройте список файлов и diff: только принятые правки должны перейти к финальным проверкам.

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

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

Когда результат понятен, выполните git status, убедитесь, что в коммит попадают только относящиеся к задаче файлы, и создайте коммит с описанием изменения. Checkpoint Copilot помогает откатить агентские правки внутри редактора, но Git остаётся общей историей проекта и точкой передачи работы другому человеку.

Такой короткий цикл повторяется почти для любой функции: контекст, критерии, план, небольшое изменение, diff, проверки, коммит. В программе курса «Вайбкодинг на максималках» он собран в последовательную практику: после устройства Git, GitHub, Codex и VS Code идут цикл разработки функции, работа с логами и ошибками, база данных, деплой, нейросетевые функции и защита проекта. Последовательность связывает запрос к ассистенту с наблюдаемым изменением, проверкой и сохранённой версией проекта.

Agent ускоряет работу именно потому, что получает больше контекста и может совершать больше действий. Поэтому разрешения следует выдавать под конкретную задачу, а не «на всякий случай». Перед подтверждением команды прочитайте её целиком, проверьте рабочую папку и поймите, какие файлы или внешние ресурсы она затронет.

Особенно внимательно относитесь к четырём зонам.

Секреты. Не добавляйте API-ключи, пароли, приватные сертификаты и production-данные в чат или инструкции проекта. Проверьте, какие файлы исключены из Git и какие из них доступны рабочей области. Если секрет уже попал в публичный код или историю репозитория, простого удаления строки недостаточно: ключ нужно отозвать и заменить у его поставщика.

Зависимости. Новый пакет меняет не только одну строку импорта. У него есть версия, лицензия, цепочка зависимостей и будущие обновления. Если задача решается средствами проекта, попросите не устанавливать библиотеку. Если пакет действительно нужен, проверьте официальный источник, назначение и изменения lock-файла.

Команды терминала. Фраза «запусти проект» может привести к установке пакетов, миграции базы или скрипту с побочным действием. Разрешайте сначала безопасную диагностическую команду, затем конкретную проверку. Не подтверждайте удаление, публикацию, деплой или изменение удалённых данных, если это не было явной целью задачи.

Большие правки. Checkpoint в VS Code помогает сравнить состояние и вернуть агентские изменения. Но он не заменяет понимание diff и обычную историю Git. Чем шире задача, тем полезнее разделить её на несколько коммитов с отдельным критерием готовности.

После возврата к checkpoint снова проверьте diff и запустите нужные команды: откат интерфейса редактора сам по себе не подтверждает рабочее состояние приложения.

Не каждый запрос должен заканчиваться автоматическим редактированием. Используйте Ask, если вы разбираетесь в незнакомом коде или ещё не уверены в причине ошибки. Выбирайте inline suggestion, если продолжение локально и очевидно. Начинайте с Plan, если затрагиваются несколько файлов, данные или публичное поведение. Agent уместен после того, как вы способны назвать результат и способ его проверки.

Красные флаги во время работы:

• агент меняет файлы вне обозначенной области;

• предлагает отключить тест, линтер или проверку типов;

• добавляет зависимость без объяснения;

• повторяет одну и ту же правку после ошибки;

• просит широкое разрешение, не связанное с задачей;

• результат нельзя описать как наблюдаемое поведение.

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

Для первой недели с Copilot достаточно одного правила: одна задача, один проверяемый результат и один понятный коммит. Перед Agent зафиксируйте исходную версию, сформулируйте критерии и посмотрите план. После правок примите или отклоните их по diff, запустите проверки и только затем сохраните коммит.

Copilot не обязан написать идеальный код с первой попытки. Его практическая роль в VS Code состоит в том, чтобы сократить путь от вопроса к варианту изменения. Ответственность за цель, разрешения и принятую версию остаётся у человека, который ведёт проект.