Патерн, який я виробив для себе - як міг би виглядати інтерфейс ШІ, коли чату вже замало.
Якщо хочете погратися - commando-beryl.vercel.app.
Де це почалося
Після кількох місяців щоденного використання ШІ-інструментів я помітив, що чат перестав мені підходити. Не тому, що чат поганий - для одного питання він нормальний. Але що більше я працював з агентами, яким на будь-що треба було більше за кілька секунд, то сильніше я відчував, що форма інтерфейсу опирається мені.
Якщо я хотів запустити дві речі одночасно, доводилося відкривати дві вкладки. Якщо я хотів повернутися до гілки через три дні, доводилося прокручувати все вгору. Якщо в мене йшло чотири завдання в різних інструментах - одне в Cursor, одне в чатботі, одне в плагіні Figma, одне в Slack - не було місця, де я міг би бачити їх усі в одному поданні. Робота була паралельною. Інтерфейс і досі вдавав, що це розмова.
Тож я почав питати: якщо чат - неправильна форма, то яка правильна? Ось що це таке. Я намагаюся зрозуміти, чого я насправді хотів від того, чим користувався щодня.
У пошуках форми
Перш ніж щось закріпилося, минуло кілька напрямків.
Перше, що я спробував, - це просто кращий чат: гілки, розгалуження, кілька панелей. Це трохи допомогло, але все одно відчувалося як спроба змусити месенджер робити те, для чого його не будували. Основна метафора лишалася хибною.
До чого я постійно повертався - це стратегії в реальному часі. У чомусь на кшталт Starcraft гравець керує десятками юнітів на мапі водночас. Є щільний словник - виділення, гарячі клавіші, здібності юнітів - і добрі гравці рухаються крізь нього неймовірно швидко. Екран щільний, але лишається читабельним. Мова достатньо мала, щоб запам’ятати, і за якийсь час ти перестаєш дивитися на UI.
Такий стиснений словник відчувався саме тим, чого бракувало чату. Щойно я почав дивитися на інтерфейси ШІ крізь цю призму, від аналогії було важко відмовитися.
Форма, на якій я зупинився
Після кількох ітерацій прототип осів на трьох частинах.
Є артефакти - одиниці роботи, що живуть на полотні. Файл, посилання, PR, файл Figma, щось, що агент створив раніше. Кожен має позицію, тип, стан і невеликий прев’ю.
Є агенти - ті, хто власне виконує роботу. Кожен має колір, ідентичність, налаштовний набір дій і пам’ять. Кілька можуть працювати паралельно.
І є дії - те, що агент робить з вашим виділенням. Refactor, Slides, Convert, Test. Набір не фіксований - ви можете додавати свої.
Цикл короткий. Вибери кілька артефактів. Клікни агента. Клікни дію. Агент береться до роботи, картка показує, що він зайнятий, а коли закінчує, результат з’являється поруч на полотні. Без поля для промпту. Без чату. Ви вказуєте на речі й кажете агентам, що робити.
Записане словами, це звучить просто, але я переходив туди-сюди по кожній частині, перш ніж усе осіло. Решта - це питання, які мені довелося пропрацювати.
Чи треба було класифікувати дії?
Рано я помітив, що не всі дії роблять одне й те саме. Одні беруть вхідні дані й створюють щось нове. Одні беруть одну річ і переформовують її. Одні змінюють речі на місці. Спершу я ставився до всіх однаково й просто дозволяв агентам робити що завгодно - але потім мене почало турбувати, що з дока не видно, що зараз станеться з вашим полотном.
З цього й вийшла таксономія. Я розділив дії на три класи й дав кожному колір.
Продюсери беруть те, що ви виділили, і створюють щось нове. Більшість дій опинилися тут - Slides, Document, Deploy, Test.
Трансформери беруть один артефакт і конвертують його в інший формат. Той самий вміст, інша форма. Convert - найясніший приклад.
Мутатори змінюють артефакт на місці й зберігають історію версій на картці. Refactor на коді - це те, що я тут мав на увазі.
Deploy
Що для мене «клацнуло» - наскільки багато передбачення колір робив сам по собі. Щойно ти знаєш, що означає кожен колір, ти знаєш, що станеться, ще до кліку. Це зекономило багато когнітивного навантаження, якого я не помічав, доки не прибрав.
Що змінилося дорогою
Жменя рішень зрештою розвернулася назад.
Вибір кількох агентів. Я почав з ідеї, що одна команда може бути націлена на кількох агентів водночас. Звучало потужно. На практиці кожне цікаве питання - який агент відповідає за збій, чия палітра має пріоритет, як приписати результат - не мало чистої відповіді. Я закріпив кожну команду за одним виконавцем, і проблеми зникли. Паралелізм усе одно працює. Він просто походить із запуску кількох команд одночасно, а не з однієї команди на багатьох агентів. Я вагався, чи відкидати цю ідею, але відтоді за нею не сумував.
Універсальна палітра дій. Спершу кожен агент мав доступ до кожної дії. Це робило агентів взаємозамінними, що дещо знецінювало сенс мати більше за одного. Я розділив це - кожен агент отримує стандартне ядро для впізнаваності, спеціалізовані дії - за вибором.
Мутатори, що замінюють джерело. Перша версія Refactor просто перезаписувала джерело. Концептуально чистіше. Але це ламало правило «джерела лишаються недоторканими», на яке покладалася решта системи. Натомість мутатори отримали версіонування - v1, v2, v3 складаються на тій самій картці, оригінал збережено. Трохи більше стану на полотні. Набагато більше довіри.
Універсальне полотно. Єдине нескінченне полотно перетворилося б на спагеті після двадцяти завдань. Я додав робочі простори. Кожне полотно - це проєкт: назване, постійне, окреме. Зміна контексту означає зміну полотна. Просторова пам’ять працює лише тоді, коли контексти справді різні.
Як з’явилися ланцюги
Патерн виринув із власне використання прототипу. Я запускав дію, а тоді одразу хотів запустити ще одну на її результаті. Пауза, видих, знайти нову картку, виділити її, клікнути знову. Це траплялося достатньо часто, щоб тертя почало дратувати.
Тож я додав ланцюги. Після запуску дії відкривається коротке часове вікно. Поки воно відкрите, будь-яка дія, яку ви клікаєте, приєднується до черги й показується як пронумеровані «пігулки» над доком. Коли поточна дія завершується, запускається наступна - на її результаті, якщо попередня була продюсером чи трансформером, або на тому самому виділенні, якщо вона була мутатором. Постановка нового в чергу скидає часове вікно, тож ви керуєте тим, наскільки довгим стане ланцюг.
Це невелика функція, але вона змінила те, як прототип відчувався. Те, що було послідовністю окремих команд, почало відчуватися як одна плавна інструкція.
Швидкість виявилася несучою
Я не починав із думкою, що сенс у швидкості. Але десь під час прототипування я помітив, що момент, коли Commando почав відчуватися правильним, був моментом, коли я перестав тягтися до миші.
Тож я додав гарячі клавіші. Кожен агент має номер на доку, кожна дія - літеру. Виділення відбувається на полотні - той єдиний рух мишею, який вам справді потрібен - а все інше живе на клавіатурі. Натисни 2 для другого агента, S, щоб запустити Slides на виділенні, потім C, щоб поставити Convert у чергу за ним. Три клавіші - і багатокроковий конвеєр відправлено.
Порівняйте з написанням того самого наміру в чаті - «гей, візьми ці файли й перетвори їх на презентацію, а тоді конвертуй у PDF.» Абзац набирання, щоразу, без перенесення м’язової пам’яті з минулого разу. У Commando той самий намір - це виділення й три клавіші, і третього разу твої пальці вже знають послідовність.
Візуальний бік дока - для навчання. Клавіатурний бік - для роботи. Щойно ти знаєш, що робить кожен агент і що означає кожен колір, ти взагалі перестаєш дивитися на док. Ти просто граєш у нього.
Де його місце
Складнішою проблемою було з’ясувати, чим Commando насправді є, у ландшафті, де ШІ-агенти вже живуть у безлічі місць.
Проблема була не в жодному з них окремо. Це була та сама, що й раніше - кілька агентів, що працюють на різних поверхнях, без місця, де їх бачити разом чи простежити, що звідки взялося. Агенти були паралельні. Моє бачення їх - ні.
Commando, як я почав його бачити, - не ще одна поверхня, яку додають до купи. Це місце для тих частин роботи, що не мають природного дому - оркестрації, погляду між інструментами, відчуття того, що зараз насправді в роботі. Інші інструменти продовжують робити те, що роблять. Commando - це шар над ними, що дає змогу бачити всю картину одразу.
Я ще не впевнений, наскільки чистою лишається ця межа на практиці. Але це те, на чому я зупинився поки що.
Що я з цього беру
Це був перший раз, коли я проєктував UX-патерн як кінцевий результат, а не як засіб для чогось іншого. Я почав з малювання екранів, а в якийсь момент зрозумів, що екрани - це не дизайн. Дизайном були правила під ними - які частини існують, як вони поєднуються, що каже тобі кожен візуальний вибір. Екрани були лише там, де ти бачив результат. Цей зсув мене здивував, і я очікую, що він змінить те, як я підходитиму до складніших проблем взаємодії далі.
Сама метафора була ще одним сюрпризом. Наполовину запозичена RTS-візуалка була б костюмом. Що змусило це справді працювати - це відданість механіці: гарячі клавіші, що роблять реальне виділення, статус, що живе на об’єкті, результати, що з’являються фізично поруч зі своїми джерелами. Заходячи в це, я б не передбачив, наскільки багато від цього залежало.
Найбільше мене зрештою здивувало те, наскільки багато дизайнерської роботи виявилося позиціюванням. Версія Commando, що йде куди завгодно, - це не «новий спосіб взаємодіяти з ШІ». Це надто широко й конфліктує з надто багатьом. Це шар над іншими інструментами для людей, які вже користуються кількома ШІ-агентами й не мають способу керувати тим, що повертається. Виробити це формулювання зайняло стільки ж часу, як і дизайн самого патерну.
Що я ще з’ясовую - чи Commando справжній інструмент, чи лише прототип, що добре відчувається в контрольованих умовах. Зараз він працює для мене - жести відчуваються правильними, ритм клацає, полотно виправдовує свій простір. Але це докази рівня прототипу - мій робочий процес, мої дані, поки що без реальних вимог до нього.
Справжні інструменти мусять пережити те, чого прототипи не мусять - тертя, що з’являється за тижні використання, граничні випадки, яких я не можу передбачити, тривалу роботу, а не демосесії. Чи Commando витримає - я щиро поки не знаю.
Може, одного дня він таки виросте в щось справжнє, і тоді ми дізнаємося. А поки що - дякую, що дочитали аж сюди.