10 сентября 2026 года GitHub в официальном блоге разобрала, как в Copilot app смотреть diff агента, гонять команды в терминале и открывать превью сайта рядом, не прыгая по вкладкам. Пост Kayla Cinnamon из серии Copilot app for Beginners: Using the diff, terminal, and browser.
Это не новый id модели и не смена тарифа API. Три встроенные панели в десктоп-приложении, чтобы перед merge увидеть, что агент поменял, что проект запускается и что интерфейс живой.
Три панели вместо трёх вкладок
Формулировка GitHub короткая: когда агент меняет код, его нужно просмотреть, запустить и увидеть результат. Раньше это означало редактор, отдельный терминал и браузер. Теперь те же три шага стоят панелями внутри сессии Copilot app.
На продуктовой странице приложения это названо built-in validation loop: inspect diffs, preview через in-app browser, проверки в терминале и merge pull request прямо из сессии. Приложение заявлено для macOS, Windows и Linux, на любом плане Copilot или со своим ключом. Весов модели нет. Self-host LLM в этих текстах нет.
3 сентября в той же серии уже был пост про несколько агентов сразу и отдельные Git worktree на сессию. Сегодняшний текст про другое: не про параллельный запуск, а про то, как не принимать чужой diff вслепую.
Diff: что агент поменял
Панель diff показывает, какие строки добавлены, удалены или изменены. Добавления подсвечены зелёным, удаления красным. Это обычный before/after, не «агент всё сделал, жмите Accept».
Дальше выбор за человеком: принять правки, оставить комментарии или попросить Copilot переделать. GitHub отдельно пишет, что финальное решение остаётся за вами. Для сайта и бота это важнее маркетинга: агент может переписать nginx-конфиг, шаблон темы или обработчик формы, и без diff вы это увидите уже на проде.
Терминал и кнопка Run
Читать diff мало. Команды запускаются из терминальной панели той же сессии. GitHub специально оговаривает: в основном вы гоняете штатные команды самого проекта и смотрите вывод, а не выдумываете новый стек.
Код можно запустить руками или оформить как скрипт через кнопку Run. Вендорский пример как раз про сайт:
- добавить скрипт
dev server: открыть папку клиента, затем запуститьnpm run dev; - нажать Run, чтобы поднять сервер.
npm run dev
Терминальных окон может быть несколько. Можно переключаться между ними и не гасить одно, чтобы запустить другое. Это удобно, если один процесс держит dev-сервер, а второй гоняет тесты или линтер. Каких именно команд «для всех» GitHub не публикует: берите те, что уже есть в репозитории.
Браузер и Pick & Polish
Если у задачи есть интерфейс, цикл закрывает браузерная панель. В том же примере с сайтом вы открываете превью и проверяете фичу так, как ею будут пользоваться, а не только по зелёному diff.
Для следующей итерации есть инструмент Pick & Polish: выделяете элемент и просите агента его поправить. После правок вендор предлагает снова прогнать скрипт dev server и посмотреть, что изменилось. Это не отдельный Images API и не генерация обложки. Это правка UI в том же приложении, где лежит код.
Когда результат устраивает, изменение можно принять прямо из Copilot app и создать pull request. GitHub сводит это к трём вопросам до Accept:
- Что изменилось?
- Оно запускается?
- Оно реально работает?
Если у вас сайт, бот или просто репозиторий
Практический смысл не в слове Beginners, а в контуре проверки. Агент пишет. Вы смотрите diff. Поднимаете то, что и так принято в проекте. Если есть экран, открываете его в панели браузера. Только потом Accept и PR.
Пример GitHub про npm run dev ближе к фронтенду и статике, чем к PHP-админке WordPress. На VPS с nginx это не пакет в apt и не плагин. Это десктоп-клиент, который ходит в ваш репозиторий и в облако Copilot. Если отдать агенту боевой wp-admin, SSH и root, в этом посте такого рецепта нет.
Linux-клиент на продуктовой странице назван явно, вместе с macOS и Windows. В тексте от 10 сентября нет deb/rpm, версии сборки и команды установки. Качать «что-то с GitHub» в обход официальной страницы приложения я бы не стал. Про доступ из России в первоисточнике ничего нет, гадать не буду.
Проверить руками, если приложение у вас уже стоит, можно на копии репозитория, не на проде. Маленькая задача, один diff, штатная команда проекта, при наличии UI – одно превью и один элемент через Pick & Polish. Если зелёный diff не совпадает с тем, что видно в браузере, Accept рано.
GitHub формулирует итог спокойно: когда review, run и preview стоят рядом, правки агента перестают казаться страшными, потому что вы можете доказать, что в merge уходит работающий код. Это продуктовый тезис, не обещание, что агент не сломает шаблон. Контроль по-прежнему на вашей стороне.
