ПостДень 2786. #AI

День 2786. #AI Пусть Copilot Поспорит с Вами Как разработчик или архитектор, вы ежедневно принимаете множество проектных решений. Вы выбираете Redis для кэширования, отдаете предпочтение REST вместо GraphQL и так далее. Приняв решение, вы движетесь дальше, но где-то на заднем плане звучит внутренний голос: «Стоит ли беспокоить коллегу и спрашивать его мнение?», «А вдруг я что-то упустил?», «Действительно ли это правильный выбор?» GitHub Copilot может помочь вам в этом с помощью новой команды: /spar. Что это? Команда /spar переключает Copilot из режима «помоги мне это создать» в режим «убеди меня, что это плохая идея». Вместо того чтобы просто принять ваш план и сгенерировать код, Copilot начинает ставить под сомнение ваши допущения, спрашивает о граничных случаях и указывает на компромиссы, которые вы могли не заметить. Примечание: это отличается от команды /plan, которая помогает разбить задачу на части. /spar исходит из того, что план уже есть, и стремится подвергнуть его стресс-тестированию, прежде чем вы приступите к реализации. Как пользоваться? Введите /spar в поле чата, а затем укажите, какое решение хотите подвергнуть критике. Вот несколько примеров из документации: Проверка архитектурного решения: /spar Я планирую использовать Redis в качестве уровня кэширования для API продукта. Проверь мой подход и укажи на возможные проблемы с масштабируемостью или согласованностью данных, которые я мог упустить. Сравнение вариантов реализации: /spar Помоги мне выбрать между REST и GraphQL для клиентского API. Задавай вопросы, ставь под сомнение мои допущения и порекомендуй подход, который лучше всего подойдет для приложения с мобильными клиентами. Анализ плана миграции: /spar Я переношу нашу базу данных на новый управляемый сервис с минимальным временем простоя. Найди слабые места в моём плане миграции и укажи на риски или граничные случаи, которые стоит учесть. Или проверка оптимизации производительности перед выпуском: /spar Я планирую использовать ленивую загрузку (lazy loading) для большинства компонентов сайта, чтобы сократить время начальной загрузки. Оцени мой подход и скажи, где он может ухудшить пользовательский опыт или создать излишнюю сложность. Совет: чем конкретнее ваш запрос, тем более глубокой и точной будет критика. Фраза «Подвергни критике мою стратегию кэширования» приведёт лишь к общим замечаниям. Если же вы назовете конкретный аспект, вызывающий сомнения (например, стратегия инвалидации кэша, согласованность данных или масштабируемость), то получите по-настоящему содержательный диалог. Место в рабочем процессе Команда /spar работает внутри приложения GitHub Copilot (а не в CLI или чате VS Code); это одна из специализированных команд, ориентированных на многосеансовый рабочий процесс, наряду с /plan, /autopilot, /rubber-duck и /orchestrate. Разумный сценарий использования выглядит так: /plan — для разбивки задачи, /spar — для проверки плана на прочность (до внесения изменений в код), а затем /autopilot — для его реализации. Чем отличается от /grill-me? Если вы следите за экосистемой навыков, то команда /grill-me от Мэтта Покока может показаться аналогичной. Но это не так, и важно понимать разницу: - /spar исходит из того, что у вас уже есть решение или подход, и пытается их опровергнуть. Вы предлагаете что-то конкретное — например, «я использую Redis для кэширования», — а команда выступает оппонентом, критикуя ваш план. - /grill-me предполагает, что решения у вас ещё нет. Команда берёт за основу общую идею и проводит серию опросов, пока вы не определитесь с конкретным вариантом. Здесь нет готового плана, который нужно критиковать; система пытается «вытянуть» его из вас, задавая вопросы последовательно — по одной теме за раз, — чтобы не спрашивать о том, что зависит от ещё не полученного ответа. Ещё несколько отличий: - Роль: /spar — критик. /grill-me — интервьюер. - Входные данные: /spar требует сформулированного подхода для критики. /grill-me достаточно лишь смутного направления. Точность и конкретика — это результат, а не исходные данные. - Состояние: /grill-me работает без сохранения состояния. Никаких файлов, рабочих областей или следов — только более чёткая идея у вас в голове. /spar выполняется в рамках сессии или рабочей области приложения Copilot, привязанных к контексту текущего проекта. - Риски: в случае со /spar есть риск проигнорировать критику и продолжить работу без изменений. Для /grill-me задокументированный риск — это пассивность: отвечать «согласен, согласен, согласен» на сорок вопросов и получить план, который составил агент, а вы лишь кивали в знак согласия. Примечание: возможно, более интересная параллель — это не /spar против /grill-me, а /spar против /rubber-duck. В режиме /rubber-duck тоже используется вторая модель для независимого анализа уже проделанной работы; по своей концепции это ближе к /grill-me, чем к /spar. /spar спорит с вами в режиме реального времени в ходе того же диалога, тогда как /rubber-duck и интервью в стиле /grill-me предполагают более независимый и структурированный этап дополнительной проверки. Если попытаться выстроить их на одной шкале: /grill-me работает на этапе до появления плана, /plan помогает этот план составить, /spar подвергает его критике, когда он уже готов, а /rubber-duck позволяет взглянуть на него со стороны перед финальным выпуском. Конечно, такой подход не выявит абсолютно все проблемы. В конце концов, это всё тот же Copilot, который спорит сам с собой через вашу клавиатуру. И всё же, когда система сама озвучивает вопрос «А подумали ли мы, что произойдет в случае сбоя?» — ещё до того, как об этом спросит коллега, — это простой и полезный прием. Источник: https://bartwullems.blogspot.com/2026/09/let-copilot-argue-with-you-spar-slash.html