GitHub Copilot в VS Code: параллельные сессии, история и стоимость агентской работы
Новые режимы Copilot в VS Code удобны, когда задач несколько: один агент разбирает ошибку, второй пишет тест, третий проверяет интерфейс. Но параллельность не отменяет управление контекстом. Каждый агент должен знать границы своей задачи и критерий готовности.
Когда параллельные сессии действительно полезны
Разделяйте независимые работы: анализ лога, подготовку документации и тестирование. Если два агента меняют один компонент, выгода быстро исчезает из-за конфликтов и повторной проверки.
Разные независимые задачи
Для каждой сессии задайте папку, файлы и ожидаемый результат. Например, один агент читает код и не изменяет его, второй пишет тест в отдельной ветке. Такое разделение проще проверять через diff.
Почему нельзя делить один файл без координации
Агенты могут опираться на разные версии кода. Один перезапишет изменение другого, а итоговый diff будет выглядеть правдоподобно. Один ответственный должен собрать результаты и запустить общий тест.
Как дать агенту ограниченный контекст
Длинное описание не равно хорошему заданию. В начале укажите проблему, окружение, запрещённые действия и критерии готовности. Ссылки на конкретные файлы лучше общего требования «разберись во всём проекте».
Задание, критерий готовности и тест
Напишите: «Найди причину ошибки в форме, не меняй API, добавь тест на пустое поле и покажи diff». Агент понимает результат и не расширяет задачу без спроса.
Файлы, которые нельзя отправлять
Секреты, `.env`, реальные заявки и персональные данные уберите из контекста. Если нужен пример, замените значения фиктивными. Убедитесь, что исключения действуют не только в Git, но и в рабочей папке агента.
Как контролировать модели и расходы
Стоимость зависит от модели, объёма контекста и числа повторов. Для чтения небольшого файла не нужна самая дорогая модель. Сложную задачу лучше сначала разделить и проверить, чем несколько раз отправлять огромный проект.
Цена запроса и длина контекста
Фиксируйте, какие файлы агент получил. Если ответ требует повторной передачи всего проекта, улучшите структуру задания. Лишний контекст увеличивает стоимость и число нерелевантных гипотез.
Логирование результата
Сохраняйте краткий журнал: задача, модель, изменённые файлы, тест и итог. Это помогает понять, когда агентная работа ускоряет процесс, а когда создаёт дополнительное ревью.
Как использовать синхронизацию истории
История сессий полезна для поиска решения и восстановления контекста, но не заменяет Git. В репозитории источником истины остаются коммиты, ветки и pull request.
Что хранить в сессии
Оставляйте объяснение проблемы, команду проверки и ссылки на файлы. Не храните там настоящие токены и выгрузки CRM. Архив должен быть пригоден для повторения, а не содержать весь рабочий шум.
Чем история не заменяет Git
В чате нет полноценной проверки конфликтов и истории сборок. Любое принятое изменение должно попасть в ветку, пройти тесты и получить комментарий ревьюера.
Финальная проверка работы агента
Попросите агента перечислить изменения, но не принимайте список как доказательство. Откройте diff, запустите тесты и проверьте сценарий в браузере.
Тесты и diff
Если тестов нет, добавьте хотя бы воспроизводимую команду проверки. Убедитесь, что агент не изменил конфигурацию, зависимости и форматирование за пределами задачи.
Ручное принятие изменений
Ответственный разработчик должен понимать каждую правку. Для кода, который работает с доступами, платежами, DNS или персональными данными, обязательны дополнительная проверка и безопасный откат.
