«Чат — не тот интерфейс»: GitHub показала canvases — приложения, которые агент собирает внутри Copilot

Что именно называется canvas

В приложении GitHub Copilot canvas — это небольшое full-stack-приложение: оно запускается внутри самого приложения, без браузерной обвязки, агент умеет обращаться к его серверной части, а серверная часть — отвечать агенту. Документация формулирует то же самое спокойнее: canvas extension — это общее интерактивное поле для рабочего артефакта вроде плана, доски разбора задач, сессии браузера, чек-листа релиза, дашборда, инцидента или таблицы.

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

Холланд отдельно подчёркивает разницу с веб-страницей: canvas — именно приложение, поэтому он может не только ходить в сторонние API, но и выполнять код локально на машине.

Как его собрать

Собрать canvas можно обычной просьбой: приложение Copilot знает, что такое canvas, и объяснять ему ничего не нужно. В документации тот же путь описан как навык /create-canvas — в строке ввода нужно набрать команду и описать, что должен уметь интерфейс, включая то, что доступно человеку и что агенту.

Дальше выбирается область видимости: проектные canvas'ы живут в каталоге.github/extensions и коммитятся в репозиторий вместе с командой, персональные — в ~/.copilot/extensions на вашей машине.

Агент собирает canvas и открывает его в правой панели, после чего поверхность можно дорабатывать: просить изменить интерфейс, общее состояние и набор возможностей.

Возможности — это то, что делает canvas управляемым из диалога. В документации приведён пример агентной канбан-доски с вызываемыми агентом действиями get_board, add_card и move_card: люди двигают задачи кнопками, агент — вызовами, и обе стороны работают с одной доской.

Готовые canvas'ы можно и не писать: часть поставляется плагинами — например, плагин Azure DevOps добавляет canvas для планирования и управления его работой, а список рекомендованных canvas'ов живёт в отдельном представлении Canvas.

Connect 4: агент на другой стороне доски

Первый пример в разборе — игра. Холланд просит собрать canvas с Connect 4 так, чтобы человек играл через интерфейс, canvas говорил с агентом, а агент управлял полем.

Дальше видно, зачем нужна двусторонность: человек бросает фишку в столбец, агент получает состояние доски, вызывает у canvas'а действие make_move и блокирует столбец — на скриншоте в разборе это отдельная запись о вызове действия canvas'а.

Соперником автор выбрал GPT-5.6 Sol на высоком уровне рассуждений и GPT-5.6 Luna без рассуждений, причём результат оговаривает сам: на высоком reasoning похвастаться нечем, зато Luna без рассуждений была обыграна, и Connect 4 — вообще трудная игра.

Дело не в красивой картинке

Второй пример — менеджер пакетов WinGet, который умеет искать пакеты в реестре, устанавливать и удалять их на локальной машине. Ни одной модели внутри нет, и в этом весь смысл: «Здесь нет ИИ, но в этом и суть».

Аргумент автора — экономический. Когда чат становится основным интерфейсом, он подталкивает поручать агенту всё подряд, а это часто просто чистый перерасход токенов. Почти всегда выгоднее один раз построить инструмент, после чего все дальнейшие взаимодействия бесплатны, чем каждый раз использовать самого агента как инструмент.

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

Локальный код и обычные приложения

Дальше примеры уходят от ИИ ещё дальше. Вместо того чтобы просить агента что-то сделать с базой SQLite, можно поднять canvas и поработать с ней самому — причём с подсказками кода, потому что это настоящий интерфейс, а не картинка.

Ещё один сценарий — редактор постов: зачем писать материалы для Jekyll в простом Markdown, если можно буквально воскресить Windows Live Writer.

Общее у всех примеров одно: canvas — это приложение, поэтому он умеет всё, что умеет обычная программа, и вдобавок разговаривает с агентом.

Формы, которые уже собирают

Часть форм описана в отдельных материалах блога. В июльском разборе приводятся примеры: интерфейс для разбора задач в стиле свайпов — вправо «в работу», влево «отклонить»; интерактивная схема кодовой базы, по которой можно ходить и фильтровать; вид рабочих деревьев с пометкой активных и осиротевших и уборкой в пару кликов; тренажёр промптов, разбирающий прошлые запросы и подсказывающий, чего в них не хватало; наконец, поиск по Slack, Teams, почте и документам, который показывает, кто в компании связан с конкретным файлом.

Документация добавляет свои сценарии: markdown-canvas как постоянный файл для планирования дня и запуска агентных сессий, документальные canvas'ы для таблиц и презентаций, а также канбан, где люди и агенты координируют работу с одной доски.

Общий принцип этих примеров один: вместо длинной цепочки запросов и ответов человек работает с информацией напрямую, а canvas'ы эволюционируют вместе с рабочим процессом.

Сколько это стоит

В августовском материале блога автор называет цифры: Site Studio обошёлся примерно в 2 000 AI-кредитов, а canvas для модернизации — примерно в 3 000. Вывод оттуда же: canvas — это инвестиция, а не «потратить больше токенов ради более удобного интерфейса»; цель — такая архитектура рабочего процесса, при которой повторяющаяся работа становится эффективнее, предсказуемее и управляемее.

Холланд подтверждает асимметрию на своём опыте: SQLite-canvas собирается с одного запроса, а canvas под автоматизацию рабочего процесса занял почти день на доводку дизайна и автоматизации.

Чего в этом тексте нет

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

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

Документация при этом описывает canvas'ы как обычную доступную возможность приложения Copilot: ни статуса preview, ни ограничений по доступу в разделе нет.