GitHub предложил использовать в приложении Copilot специализированные интерактивные интерфейсы вместо длинных диалогов с AI-агентом. Такие интерфейсы компания называет canvases: агент может создать небольшое приложение под конкретную задачу, а пользователь — работать с кнопками, таблицами, редакторами и визуальными состояниями, не формулируя каждое действие в чате.
Подход описан в публикации GitHub от 24 сентября 2026 года. Это демонстрация возможностей приложения, а не результаты независимого тестирования. В материале не приводятся данные о расходе токенов, скорости выполнения задач или надежности созданных интерфейсов по сравнению с обычным чатом.
Canvas как приложение внутри Copilot
В терминологии GitHub canvas — это небольшое full-stack-приложение, запущенное непосредственно внутри GitHub Copilot без обычных элементов браузера. У него могут быть клиентский интерфейс и серверная часть. Агент обменивается данными с сервером приложения, а тот возвращает агенту действия или информацию от пользователя.
За счет такой двусторонней связи canvas может выполнять функции привычной программы: отображать таблицы, принимать команды через элементы интерфейса, обращаться к сторонним API и запускать код на компьютере пользователя. Чат при этом сохраняется как способ объяснить намерение или заказать новый инструмент, однако повторяющаяся работа переносится в специализированный интерфейс.
Один из простых примеров GitHub — игра Connect 4. Пользователь просит Copilot создать canvas, в котором человек сможет играть против агента. После генерации приложения ходы выполняются на игровом поле, а не через последовательность текстовых инструкций. Этот пример показывает сам механизм взаимодействия, хотя ничего не говорит о применимости canvases в производственной разработке.
Общий контекст продукта и его функций компания публикует на странице GitHub Copilot. Описанные canvases относятся именно к отдельному приложению Copilot; из исходной публикации не следует, что такой же интерфейс уже доступен во всех IDE-расширениях или веб-режимах сервиса.
Зачем выносить повторяющиеся команды из чата
Чат удобен, когда заранее неизвестно, какую задачу поставит пользователь. Разработчик может свободно сформулировать запрос, добавить контекст и уточнить результат. Проблема возникает после того, как процесс уже определен: команды «покажи статус», «выполни запрос», «подготовь изменения» и «перейди к следующему шагу» приходится отправлять снова.
Автор публикации GitHub считает такое использование агента неоправданным расходом токенов. Если действие можно представить кнопкой, формой или таблицей, агенту достаточно один раз построить инструмент. Последующие операции выполняются средствами созданного приложения и не требуют отдельного обращения к языковой модели на каждом шаге.
Это различие особенно заметно в задачах с четкой структурой:
- просмотр и фильтрация данных;
- установка или удаление пакетов;
- запуск заранее определенных команд;
- работа с базой данных;
- проверка промежуточных результатов;
- согласование отдельных этапов автоматизированного процесса.
Canvas в этой модели не заменяет агента полностью. Агент нужен для создания интерфейса, адаптации логики и обработки ситуаций, которые нельзя заранее описать. Детерминированные операции после этого берет на себя обычный программный код.
Примеры с Winget и SQLite
В публикации показан canvas для Winget — менеджера пакетов Windows. Интерфейс позволяет искать пакеты в реестре, просматривать установленные программы, устанавливать их и удалять. Сами операции Winget не требуют участия AI: Copilot используется для построения оболочки, после чего пользователь работает с обычным инструментом управления пакетами.
Возможности и команды Winget отдельно описаны в официальной документации Microsoft. Демонстрация GitHub не означает, что созданный агентом интерфейс получает особые полномочия: фактические действия по-прежнему зависят от локальной среды, прав пользователя и возможностей пакетного менеджера.
Второй пример касается SQLite. Вместо диалога, в котором агент пишет SQL, выполняет запрос и пересказывает результат, canvas может предоставить редактор с автодополнением и область для просмотра данных. Разработчик продолжает писать и проверять SQL самостоятельно, обращаясь к агенту только тогда, когда требуется помощь. Техническую информацию о самой базе данных следует сверять с документацией SQLite, поскольку публикация GitHub демонстрирует интерфейс, а не меняет поведение СУБД.
Такой подход снижает зависимость от текстовой интерпретации. Пользователь видит запрос и результат напрямую, может изменить отдельное условие и повторить операцию без нового диалога. При этом canvas не устраняет риски ошибочного SQL или небезопасных операций с данными.
Многоэтапные процессы и участие разработчика
Более сложный сценарий — автоматизация рабочего процесса, в котором агент исследует задачу, создает прототип, готовит материалы для проверки и сообщает, когда требуется решение человека. В обычном чате промежуточные результаты смешиваются с пояснениями и командами, а состояние процесса постепенно теряется в истории сообщений.
Canvas может представить такой процесс как набор этапов с отдельными статусами и результатами. Разработчик подключается к точкам контроля, где нужно принять или отклонить вариант, дать обратную связь либо разрешить переход дальше. Остальные этапы агент выполняет без постоянного присутствия пользователя у клавиатуры.
GitHub не утверждает, что такие процессы создаются мгновенно. По словам автора публикации, простой интерфейс для SQLite можно получить одним запросом, тогда как настройка демонстрационного workflow заняла большую часть рабочего дня. Это существенное ограничение: создание одноразового canvas может оказаться дороже нескольких команд в чате. Выигрыш появляется у повторяющихся процессов, где затраты на проектирование распределяются между многими запусками.
Что проверить перед использованием canvas
Поскольку canvas способен обращаться к сторонним сервисам и выполнять локальный код, разработчику следует оценивать его как обычное приложение, а не как безопасную визуальную надстройку над чатом. Исходная публикация не раскрывает модель разрешений, изоляцию процессов и правила доступа к учетным данным, поэтому их нельзя считать автоматически решенными.
Перед запуском созданного агентом интерфейса имеет смысл проверить:
- какие команды и исполняемые файлы он вызывает;
- к каким локальным каталогам и базам данных получает доступ;
- какие данные отправляются во внешние API;
- где хранятся токены и другие учетные данные;
- можно ли предварительно просмотреть изменения;
- предусмотрены ли подтверждение опасных операций и откат;
- остается ли журнал действий для последующей проверки.
Практический критерий выбора прост: если действие выполняется редко и требует обсуждения, чат, вероятно, останется удобнее. Если одни и те же команды повторяются, а результат лучше воспринимается в таблице, редакторе или панели состояния, canvas может сократить число обращений к модели. Перед переносом реального рабочего процесса разумно протестировать интерфейс на копии репозитория или базы данных и отдельно сравнить затраты на его настройку с экономией времени и токенов.