Microsoft Canvas Studio (preview): agentic coauthors у канві. Це сесія студії, а не редактор Bubble і не Agent 2

27 жовтня 2026 року Microsoft оголосила preview вбудованого асистента для створення застосунків. Він називається authoring agent і працює прямо в Power Apps canvas studio. Заголовки одразу підхопили фразу «agentic coauthoring у канві». Я розумію, як це сприймає нетехнічний фаундер, який збирає MVP на nocode чи вайбкодингом. Здається, що ще трохи, і ШІ сам складе готовий продукт в один клік у будь-якому візуальному середовищі. Про це окремо: Adalo Ada (11.10): prompt →.

Насправді ні. Це не редактор Bubble, не Cursor Canvases і не якийсь автономний «Agent 2». Це закритий компонент корпоративного конструктора Microsoft, і він створює тільки canvas-застосунки Power Apps. Про це окремо: Cloudflare Void (open-source): контроль вайб-застосунків.

Платформа специфічна, але я все одно розібрав, як влаштована ця сесія співавторства. У ній є кілька принципів роботи людини з ШІ, які я раджу забрати кожному соло-мейкеру. Вони допомагають запустити робочий прототип, перевірити гіпотезу на перших клієнтах і не потонути в технічному хаосі.

---

Що насправді показала Microsoft: анатомія студійного агента

Спершу контекст. На початку вересня 2026 року Microsoft уже вивела в загальну доступність (GA) окремий canvas authoring agent plugin. Він розрахований на зовнішні термінальні агенти, як-от GitHub Copilot CLI чи Claude Code, і працює через протокол MCP та синхронізацію коду .pa.yaml. Жовтневий анонс про інший сценарій: панель асистента ліворуч від візуального полотна, прямо в студії розробника. Поруч із цим: MCP як стандарт: Oracle AI.

Ось як ця сесія працює в preview:

1. Підключення інфраструктури. Адміністратор орендаря (tenant) вмикає опцію в Power Platform Admin Center. Творець відкриває студію і підключає акаунт GitHub.com. Через GitHub запускаються інструменти створення, і через нього ж тарифікується використання.
2. План перед дією (Plan-then-build). Автор пише запит звичайною мовою, але агент не починає хаотично малювати елементи. Спочатку він складає структурований документ Canvas App Plan. У ньому розписано, які екрани плануються, звідки беруться дані і як вони використовуються, а також які припущення та обмеження (assumptions and limitations) закладено.
3. Обов'язковий шлюз схвалення. Агент не торкається полотна, доки творець явно не натисне «Yes, continue» або не внесе правки через «Suggest changes».
4. Генерація з автоперевіркою. Після схвалення агент розгортає екрани, елементи керування та формули Power Fx. Паралельно він запускає внутрішню діагностику і виправляє помилки побудови.
5. Результат: стандартний застосунок. На виході звичайний canvas-проєкт. Його можна доробляти вручну або точковими запитами до агента.

Жорсткі обмеження preview: чому це не готова магія для бізнесу

У документації Microsoft Learn межі інструмента прописані чітко:

• Працює тільки для регіону США (United States) і тільки англійською.
• Офіційно не призначений для production.
• Модель у студії жорстко зафіксована інтеграцією, обрати іншу користувач не може.
• Запити та контекст структури застосунку передаються в GitHub, тож політики конфіденційності треба враховувати.
• Ключових прав агент не має. Він не може додавати чи змінювати реальні бізнес-дані всередині застосунку і не може додавати зображення. А головне, він не має права сам зберегти (save), опублікувати (publish) чи поділитися (share) створеним продуктом.

Тобто єдиний повноправний автор і випусковий редактор тут людина.

---

Практичні звички рев'ю для соло-фаундерів та вайбкодерів

Коли ви збираєте MVP на Bubble або швидко ліпите перший реліз вайбкодингом, дуже хочеться натиснути одну кнопку й отримати готовий сервіс. Досвід корпоративних платформ каже інше: надійний продукт виходить там, де межі контрольовані. Ось що я б переніс у свою практику вже зараз.

1. Впроваджуйте обов'язковий «шлюз плану» (Plan Gate)

Найбільша помилка нетехнічного фаундера під час генерації застосунку: не розібрати припущення, які закладає ШІ. Скажімо, ШІ вирішив, що користувач реєструється без підтвердження пошти. Або спростив платіжну логіку до звичайної галочки. Ви дізнаєтеся про це тільки тоді, коли застосунок тестуватимуть реальні користувачі. Тому правило просте. Перед генерацією будь-якої структури чи сторінки вимагайте від ШІ список обмежень і гіпотез, які він закладає в логіку. Якщо план не сходиться з моделлю вашого MVP, не генеруйте ні код, ні базу даних.

2. Перевірка за трьома точками перед релізом

Агент у студії Microsoft не може і не повинен сам публікувати проєкт. Я б забрав цю логіку як є і перевіряв кожен реліз так, як це роблять на корпоративних платформах:

• Дерево компонентів (Tree view). Перевірте, що на сторінці немає зайвих прихованих груп чи дубльованих контейнерів. Вони гальмують завантаження інтерфейсу.
• Властивості й вирази. Подивіться на формули та умови видимості. Якщо логіка незрозуміла, розберіться в ній до запуску, а не після того, як клієнт натисне зламану кнопку.
• Інтерактивний перегляд (Play preview). Самі пройдіть шлях клієнта від початку до кінця. Жоден агент не відчує інтерфейс так, як фаундер, що б'ється за першу конверсію.

3. Чіткий розподіл ролей: агент для рутини, руки для фінішу

Генеративні інструменти добре роблять однотипні екрани, картки списків і початкову розмітку форми. А от підганяти промптами відступ у три пікселі чи колір однієї кнопки не варто. Так ви перевитратите контекст, вичерпаєте ліміти й отримаєте несподівані побічні помилки. Чернетку нехай будує генератор, а фінальні штрихи й дизайн-акценти доводьте руками у візуальному редакторі.

---

Що взяти в роботу, а що залишити в preview

Налаштування орендарів і білінг через корпоративні акаунти GitHub залиште корпоративним адміністраторам. Чекати, поки студійний помічник вийде з тестового режиму, теж їм.

Для вашого MVP висновок інший. Автономні агенти не знімають відповідальності з творця. Швидкість запуску ідеї на nocode-інструментах зараз визначає не те, чи вміє платформа сама розгорнути застосунок. Її визначає те, наскільки прискіпливим редактором ви є. Ви затверджуєте план, перевіряєте логіку зв'язків і самі натискаєте кнопку публікації першого робочого прототипу.