Сім місяців вайб-кодингу: ілюзія контролю, п’ять стадій прийняття та чому Future Flow тепер Unthread

Про 7 місяців вайб-кодингу розширення для Safari: від наївної ідеї до працюючого продукту Unthread — через десятки помилок, неможливі фічі та повний редизайн.

Існує золоте правило будь-якого творчого процесу: найнебезпечніша його частина — це не старт, а середина. Це той момент, коли ти вже занадто далеко зайшов, щоби повернути назад, але фінішу ще і близько не видно. Момент, коли початковий ентузіазм вичерпався, а до фінального «вау-ефекту» — ще одна геологічна епоха.

Саме в цю пастку я і втрапив, завершуючи першу частину розповіді про своє браузерне розширення. Вона закінчилася на дуже оптимістичній ноті, на вершині цього солодкого самообману.

Якщо коротко — це базовий, класичний, типовий та показовий приклад того, як можна помилитись приблизно на 180 градусів.

Для тих, хто не в курсі — мова про мою спробу створити AI-розширення для Safari, яке автоматично групує вкладки за релевантністю під конкретно ваші завдання. Першу частину статті ви знайдете тут.

До речі, щоб ви розуміли, сам термін «вайб-кодинг» зʼявився, поки я писав цю статтю. Так, коли виходила перша частина його ще не існувало — ось настільки все затягнулося.

Нагадаю, що весь цей експеримент став можливим завдяки співпраці з українським стартапом Cabina.AI — вони надали доступ до своєї платформи, яка об'єднує десятки AI-моделей в одному місці. Без цього партнерства історія була б значно коротшою та менш цікавою.

Отже, під кінець першої частини в мене було: два пакетики базової архітектури, сімдесят п’ять ампул інтерфейсу в стилі macOS, сільничка, наполовину наповнена системою кешування та навіть власна реалізація віртуальних груп для Safari.

Ну і свята впевненість, що залишилося «всього лише» прикрутити штучний інтелект. Я тоді думав: ну скільки це може зайняти? Тиждень або два, ну три — максимум. Такий молодий, такий наївний.

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

Якщо після першої частини у вас могло скластись враження, що вайб-кодинг, коли ти нічорта не розумієш — це скоріше весело та здебільшого легко, то ця частина розставить трішки більше крапок над «і».

Буде цікаво.

15 спроб і одна кнопка

Знаєте, які найцікавіші моменти у вайб-кодингу? Не ті, коли ти не розумієш, як щось працює. Найцікавіші — це ті, коли ти не розумієш, чому щось НЕ працює, хоча має. І при цьому AI разом із тобою теж не розуміє ні чорта.

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

Спочатку я подумав: «Ну це дрібниця, за півгодини виправимо». Це було в понеділок вранці. У п’ятницю ввечері я все ще сидів над цією триклятою кнопкою.

Описував проблему Claude — він починав пропонувати рішення: перевір обробники подій, подивись на валідацію, може конфлікт стилів. Я раз за разом переписував код, тестував — не працює.

Claude продовжував пропонувати варіанти. Може треба по-іншому підключити JavaScript? Переписав. Може проблема в порядку завантаження файлів? Змінив. Може треба іншу структуру HTML? Але кнопка як була мертвою, так і лишалася.

Найстрашніше почалося, коли Claude почав пропонувати все більш екзотичні рішення. Заміни кнопку на div. Додай inline обробники подій прямо в HTML. Спробуй через форми. Може треба iframe?

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

До того ж на цьому етапі я вже навіть почав паралельно гуглити проблему самостійно. І тут, серед купи інформації та тредів, нарешті знайшов підказку: «Safari Web Extensions have specific CSP requirements».

Повернувся до Claude із цією інформацією. Й ось тут, коли я передав йому цей глибший контекст, він нарешті змінив підхід. І ні, я не забував щоразу тицяти Claude носом у той факт, що ми працюємо в Safari. Я нагадував йому про це, здається, частіше, ніж дихав — чи допомогло? Питання риторичне.

Коротше, як виявилося, Safari блокує певні JavaScript події в popup вікнах через систему безпеки. Те, що прекрасно працює в Chrome, Safari може просто ігнорувати. Довелося додати спеціальні дозволи, змінити спосіб зберігання даних і переписати логіку обробки подій.

Але кнопка нарешті запрацювала. Проте це була тільки перша з багатьох подібних проблем — наступна виявилася ще цікавішою.

Safari проти світу цього

Отже, коли нарешті виправив кнопочку, почав розбиратися з tabGroups API — це той механізм, який дозволяє браузеру створювати групи вкладок. Саме заради цього я і почав створювати це розширення. Нагадую, ідея була доволі простою: AI аналізує вкладки, релевантні збирає в одну групу, нерелевантні — в іншу.

Запитав Claude, як це реалізувати в Safari. Він видав мені красивенький код з browser.tabGroups.create() та іншими методами. Вставляю код, тестую… нічого. Думаю, може щось не так написав? Переписую. Знову нічого. Може проблема з дозволами в маніфесті? Додаю всі можливі permissions. Результат той самий.

І тут я вирішив погуглити «Safari tabGroups API support».

Коли я побачив перший же результат пошуку: «Tab Groups API is not supported in Safari Web Extensions», — це був момент, коли світ трішечки зупинився.

Читаю ще раз. Потім іду на офіційний сайт Apple і читаю документацію. І там чорним по білому: Safari НЕ ПІДТРИМУЄ tabGroups API. Взагалі. Ніяк. Ніколи.

Ви 100 % чули про п’ять стадій прийняття неминучого: заперечення, гнів, торг… Я, здається, пройшов їх усі за хвилин п’ять, сидячи перед монітором. І застряг десь між «та ні, тут якась помилка» й бажанням запустити ноутбук у стіну.

Уявіть, я пʼятсот тисяч років розробляв розширення, основна фіча якого — групування вкладок. А виявляється, що в цьому найкращому у світі браузері це технічно неможливо.

Найцікавіше, що я разів 30 ще ДО початку розробки запитував у Claude, чи все тут ок, чи можемо ми це технічно реалізувати? Направду він не брехав: tabGroups API справді існує і прекрасно працює. Тільки не в Safari. Малеееесенька деталь, яку він, мабуть, вирішив не згадувати, щоб не псувати мені настрій на старті.

Отже окей, Safari не підтримує tabGroups API. Перший шок пройшов, треба було щось робити. Варіантів у мене було не багато — змінити браузер, кинути проєкт, або знайти обхідний шлях.

З перших двох варіантів не підходив жоден. Safari — мій основний браузер, і не збирався я через якесь там розширення чи ще мільярд обмежень і проблем змінювати звички. А кидати проєкт після стількох тижнів роботи — звучало солодко, але це не дуже про мене.

Залишався третій варіант — creative problem solving, як кажуть вестерни.

Найпростіший та найбільш схожий на первинну задумку варіант — це не групувати вкладки всередині одного вікна, а створювати окремі вікна. Релевантні вкладки переміщувати в нове вікно, нерелевантні залишати в поточному.

Технічно це інше рішення. Але з погляду користувача — результат схожий. Твої вкладки все одно розділені за релевантністю, просто не в групах, а в різних вікнах.

Запитав Claude: «А чи можна в Safari створювати нові вікна та переміщати туди вкладки?». І тут він радісно (або саме я це так інтерпретував) видав: «Так, можна». Потім він написав для мене купу коду з browser.windows.create() та browser.tabs.move().

Тестую — працює! Safari спокійно дозволяє створювати нові вікна та переміщувати вкладки між ними.

Й от штука в тому, що коли я протестував це рішення, воно виявилося навіть зручнішим за оригінальну ідею. Групи вкладок всередині одного вікна можна було не помітити. А коли релевантні вкладки опиняються в окремому вікні — це неможливо проігнорувати.

Плюс психологічно це працює краще: ти фокусуєшся на завданні в одному вікні, а все зайве — в іншому. Можеш перетягнути вікно з релевантними вкладками на інший монітор. Якщо вони взагалі не потрібні — закриваєш те тупе віконце й допобачення.

Коротше кажучи, іноді те, що здається проблемою, насправді може стати перевагою. Safari змусив мене переосмислити концепцію розширення. І в підсумку я отримав щось навіть у якомусь аспекті краще, ніж планував спочатку. 

Як би зараз це речення позитивно не звучало, тоді я ще не знав, що це ще далеко не кінець історії з Safari… Залишалося найскладніше — прикрутити AI, щоб він дійсно аналізував контент вкладок.

А прикол тут у тому, що от ви вже прочитали половину статті — а першу частину я закінчував якраз десь на цьому ж моменті: «У наступній частині розповім про найцікавіше — інтеграцію з AI для аналізу контенту». Виявлось, що все трішки складніше.

API-ключі, CSP та ще трішки радощів Safari

Safari вирішив, що одного сюрпризу з tabGroups було замало. Попереду чекали API ключі, Content Security Policy та ще ціла купа «особливостей». І кожна з них ставила одне просте питання: «А ти точно хочеш створювати розширення саме для Safari?».

Наступним викликом стало збереження API ключа користувача. Звучить як щось не надто складне, правда? Відкриваєш локальне сховище браузера, кидаєш туди рядок тексту, готово. Але ж Safari — це не просто браузер, це філософія. Філософія того, як ускладнити життя розробникам «заради безпеки користувачів».

Перша спроба була класичною: localStorage.setItem('apiKey', userKey). Тестую — не працює. Claude каже: «Спробуй browser.storage.local». Пробую — теж нічого. Може chrome.storage? Та ж фігня.

Я почав паралельно тестувати ту саму проблему через інші моделі — може хтось побачить те, що пропускає Claude? Тут дуже виручила можливість Cabina.AI швидко перемикатися між моделями, не створюючи купу чатів.

Зʼясувалось, що тут я зіткнувся із прекрасною штуковиною під назвою Content Security Policy, або CSP. Це система правил, яка контролює, які скрипти можуть виконуватися на веб-сторінці. Звучить розумно, але дияволь, як завжди, у деталях.

Safari блокує доступ до сховища, якщо в HTML є хоч якісь «підозрілі» елементи. Inline-скрипти? Заборонені. JavaScript в атрибутах HTML? Не під цим дахом! Навіть безневинний onclick може зламати всю систему.

Chrome (я гуглив!) ставиться до цього набагато толерантніше — дозволяє багато речей, які Safari категорично відкидає. І найгірше, що ці обмеження не завжди логічні. Твій код може бути ідеально безпечним, але якщо Safari вирішить, що щось виглядає підозріло — ти отримуєш мовчазну відмову. Без пояснень, без помилок у консолі, просто нічого не працює.

Довелося переписувати всю архітектуру збереження даних. Замість простого localStorage — складніша схема з дозволами в manifest.json, спеціальними метатегами CSP та chrome.storage.local. А потім з’ясувалося, що навіть messaging між частинами розширення Safari розуміє по-своєму.

У Chrome є зручний messaging API — одна частина розширення відправляє повідомлення іншій, отримує відповідь, усі щасливі. Safari цей API теоретично підтримує, але практично… ну, тенденцію ви вже зрозуміли.

Довелося будувати власну систему комунікації через localStorage. Одна частина розширення записує запит у сховище, інша його читає, обробляє і записує відповідь. Працює як пошта — не дуже швидко, але надійно.

Тут я остаточно зрозумів, що Safari — це не «Chrome, але від Apple». Це повністю інша екосистема з власними правилами, обмеженнями та особливостями. І коли створюєш щось для Safari, треба думати як Safari.

Але найцікавіше почалося, коли треба було навчити розширення збирати контент із веб-сторінок. Як витягти суть із хаосу HTML-тегів, JavaScript та реклами?

Перше питання — як взагалі отримати текст із веб-сторінки? Браузерне розширення бачить тільки назву вкладки та її адресу. А щоб зрозуміти, про що сторінка, потрібен її вміст.

Claude запропонував content scripts — спеціальні скрипти, які виконуються на кожній веб-сторінці. Але швидко з’ясувалося, що просто забрати весь текст — кепська ідея. Типова веб-сторінка містить купу сміття: меню, реклама, коментарі, футер. Якщо все це відправити на аналіз, AI з якоюсь  ймовірністю видасть не релевантну відповідь, а я хотів, щоб все працювало максимально надійно.

Треба було навчитися відрізняти корисний контент від шуму. Створили систему пріоритетів: спочатку заголовок сторінки та опис із meta-тегів, потім основні заголовки (H1, H2, H3), нарешті перші кілька абзаців основного тексту — але не більше 1000 символів, щоб не перевантажувати AI.

І знову Safari підкинув сюрпризів. Content scripts іноді запускалися із затримкою, іноді взагалі не запускалися, а іноді запускалися двічі. Довелося додавати перевірки, захист від дублювання, затримки на всякий випадок.

Коли система збору контенту нарешті запрацювала, я подумав: «Ну все, тепер треба тільки підключити штучний інтелект». Звучало просто — є контент, треба його проаналізувати.

Але виявилося, що між «контент зібрано» та «AI розуміє, що з ним робити» лежить ще одна прірва технічних та концептуальних проблем. І саме тут почалася найцікавіша частина всієї розробки.

Вау, воно що працює?

І нарешті настав момент, заради якого все й починалось — інтеграція зі штучним інтелектом.

Перше питання — який AI використовувати для аналізу — вирішилось швидко: рішення прикручувати саме Gemini API було найкращим із кількох прагматичних причин.

По-перше, безкоштовний API ключ. Google дає досить щедрі можливості, яких вистачає практично для всього. По-друге, швидкість. Для аналізу вкладок я обрав Gemini 1.5 Flash — найшвидшу модель із лінійки. Не найрозумніша, але для конкретно цього кейсу цілком підходить. Коли в користувача відкрито 15+ вкладок, кожна секунда має значення. Ніхто не хоче чекати хвилину, поки AI обдумує, чи релевантна стаття про приготування гречки для завдання з програмування.

Завдання наступне — зробити так, щоб AI стабільно розумів, що означає «релевантна вкладка». Для людини очевидно, що стаття про React пов’язана із завданням «підготуватися до співбесіди з фронтенд розробки». Але для AI це треба пояснити трішки детальніше, щоб все було надійно.

Після кількох експериментів я зупинився на простій структурі запиту:

«Завдання користувача: [опис того, над чим працює людина]
Заголовок сторінки: [title]
URL: [адреса сторінки]
Опис: [meta description]
Основний контент: [перші 1000 символів тексту]

Чи допоможе інформація із цієї сторінки виконати завдання? Відповідай JSON: {«isRelevant»: true/false, «confidence»: 0–1, «reason»: «пояснення»}"

Виявилося, що коли даєш AI конкретну структуру відповіді та просиш пояснити рішення, він працює набагато точніше.

Сама інтеграція з Gemini API виявилася приємно простою — зрозуміла документація, стабільні ендпоінти, без дивних сюрпризів. Після всіх пригод з Safari це було як ковток свіжого повітря.

Найголовніше — правильно обробити помилки та додати кешування. Якщо користувач двічі аналізує ті самі вкладки з тим самим завданням, навіщо повторно витрачати час та API квоту? Зберігаємо результати в локальному сховищі браузера на 30 хвилин.

Але навіть з ідеальним промптом AI іноді видавав дивацькі результати. Довелося додати страхувальну сітку: якщо AI не може пояснити свій вибір або дає впевненість нижче 30 %, використовуємо простий аналіз за ключовими словами із заголовка та URL.

І нарешті настав ТОЙ момент. Вводжу в розширення «підготовка до співбесіди з фронтенд розробки», натискаю «Аналізувати», і через кілька секунд бачу нове вікно з релевантними вкладками.

По-перше, AI правильно визначав, що статті про React та JavaScript — релевантні, а вкладка з вакансією продавця в Beerland — ні. І, по друге, розширення вперше за всі місяці розробки робило саме те, для чого розроблялось — відкривало нове вікно з потрібними вкладками.

Це був справжній вау-момент. Той самий, коли розумієш — воно працює! Не «майже працює» чи «працює, але з нюансами». А просто працює — і цього вже достатньо.

Місяцями борешся з кнопками, Safari обмеженнями, API ключами — і раптом усе складається в єдине ціле. Штучний інтелект аналізує контент, розуміє контекст, приймає рішення, усі модулі працюють без помилок, а ти просто дивишся на екран, не віриш власним очам і тішишся.

Але на той момент лишався ще один, останній, барʼєр.

Народження Unthread: все працює, але очі болять — коротко про редизайн

Червень 2024 року. Розширення нарешті працювало: AI аналізував контент, групував вкладки, переміщував їх у нові вікна. Технічно все було ідеально. Але коли я подивився на інтерфейс…

Пам’ятаєте, як у першій частині я розповідав про роботу над дизайном у стилі macOS? Ну так от, місяцями борючись з Safari обмеженнями, API ключами та технічними проблемами, я потроху зламав увесь той гарненький інтерфейс. Одна правка тут, аварійний фікс там — й от уже моє «творіння» виглядало як калюжка з-під смітника.

Сірі кнопки, стрьомні шрифти, кривенькі відступи… Коротше кажучи, візуально — катастрофа.

Я розумів, що простіше переробити дизайн із нуля, ніж лагодити те, що розвалилося під час розробки. І це був ідеальний момент для кардинальних змін, особливо враховуючи, що під час тестування в мене з’явилося купка нових ідей про те, як це має виглядати та працювати.

До речі, приблизно десь тут я вирішив змінити ще й назву. FutureFlow звучало, з першого погляду, непогано, але із часом стало якось прісно. Хотілося щось більш catchy, що відображає саму суть — розплутування хаосу вкладок.

Так з’явилася назва Unthread. З крапкою в кінці — Unthread. Логіка проста: ти маєш купу заплутаних «ниток» (вкладок), а розширення допомагає їх «розплутати» (unthread). Крапка в кінці — як у реченні, символ завершеності та порядку. Плюс це, як на мене, виглядає незвично та запам’ятовується.

Але змінити назву — це було найлегше. Головний виклик чекав попереду: переробити дизайн у просторі 300x170 пікселів. Уявіть, що вам треба вмістити зручний інтерфейс у прямокутник розміром із візитку. Кожен піксель має значення. Кожен відступ — це компроміс між красою та функціональністю.

При цьому, через цей сраний розмір варіативність дизайну тут не те, щоб велика — з фантазією не розбіжишся.

Я почав з основ: системний шрифт (-apple-system), щоб розширення виглядало як частина macOS. Правильні відступи — не забагато, не замало, саме стільки, щоб око відпочивало. Основний синій — як у системних елементах Apple. Для темної теми — адаптивні відтінки, які автоматично змінюються залежно від налаштувань системи.

Але найскладніше — анімації. У такому маленькому просторі кожна анімація має бути ідеально відкалібрована. Занадто швидко — користувач не помітить. Занадто повільно — буде дратувати. Занадто різко — вибивається з macOS стилістики.

Тут дуже допоміг Gemini 2.5 Pro — я не памʼятаю скільки запитів зробив, що отримати нарешті коректний результат, але якби я це робив через Claude, то цю статтю ви б побачили, мабуть, у наступному році.

Коли все нарешті заграло… Ну, скажімо так — воно нарешті почало виглядати як продукт, а не як бета-результат хакатону п’ятирічної давності. Анімації працювали плавно, кольори не різали очі, а відступи не викликали бажання вдарити когось лінійкою.

Уперше за всі місяці розробки я міг показати Unthread іншим людям і не соромитися. Але найголовніше — воно нарешті виглядало так само, як і працювало — гарно. І це був той момент, коли проєкт із суто технічного експерименту перетворився на справжній продукт.

Claude 3.5 → 4.0 та трішки Gemini

А тепер хочу розповісти про один важливий момент — чому розробка розтягнулася на стільки місяців. Справа не тільки в складності Safari. Головна проблема — моделі, доступні в жовтні-грудні 2024 року, просто не тягнули ті специфічні завдання, з якими я зіткнувся.

На початку я працював з Claude 3.5 Sonnet — найкращою моделлю для кодингу того часу. Вона чудово писала загальний JavaScript, але, здається, не розуміла відмінностей Safari Web Extensions від Chrome Extensions.

У грудні з’явився Claude 3.7 Sonnet — відчутно краще програмування, швидша генерація коду, менше синтаксичних помилок. Але Safari-специфічні проблеми залишалися. Більше того — коли модель «вирішувала» одну проблему, часто створювалися дві нові.

Класичний приклад: налаштували збереження API ключа — зламався CSP. Виправили CSP — зламалася комунікація між компонентами. Виправили комунікацію — знову проблеми з дозволами.

Так я застряг на два місяці. Кожен фікс породжував нові проблеми (помітьте, проблеми — слово в множині!).

А потім у травні з’явився Claude 4 Opus. І тут сталося диво.

Я описав йому всі проблеми, з якими бився два місяці: CSP конфлікти, комунікація між компонентами, Safari обмеження. І Claude 4 Opus просто все пофіксив. З трьох спроб.

Теоретично можливо, що хтось із досвідом розробки міг би вирішити ті проблеми, які мені заважали продовжувати роботу, навіть з Claude 3.5 Sonnet або якоюсь іншою моделлю, але тут є велике «але» у вигляді трішки тупенької в цьому форматі змінної — у вигляді мене перед монітором.

Claude 4 Opus доволі швидко зрозумів джерело проблеми та пояснив, чому попередні рішення створювали каскадні залежності. Запропонував системний підхід, який враховував усі Safari обмеження одночасно — а це в моїй ситуації було дууууже приємно.

Наприклад, замість боротьби з messaging API одразу запропонував chrome.storage.local для комунікації — не ідеально архітектурно, але стабільно працює.

Коли вже мав повністю робочу основу, для фінальної роботи з інтерфейсом, як уже писав раніше, використав Gemini 2.5 Pro. Основна перевага тут — ціна/якість відповідей.

І тут я вкотре подумки подякував розробникам Cabina.AI за їхню фічу зі збереженням контексту. Не довелося пояснювати Gemini все з нуля — він просто підхопив історію чату і ми продовжили далі.

Загалом, на жаль (чи на щастя), не встиг глибинно протестувати Gemini 2.5 Pro для основної розробки — до моменту залучення цієї моделі Claude 4 Opus уже вирішив усі критичні проблеми.

Інсайт-моменти, або Як не повторити моїх помилок

Семи місяців розробки вистачило, щоб наробити помилок, яких вистачило б на написання окремої книги «Антипатерни Safari Web Extensions». Але найцікавіше — ці помилки навчили мене речам, про які жоден туторіал не розповідає. Ось ті моменти прозріння, про які я хотів би знати на початку шляху.

Перше, що зрозумів — AI може «клинити» на неправильному підході. 15 спроб виправити одну кнопку навчили мене важливого: якщо AI не може вирішити проблему за 4–5 ітерацій, проблема, скоріш за все, не в коді, а в підході. Треба зупинитися, погуглити самому й дати AI новий контекст. Інакше ви разом будете просто в тупу замінювати один шматок коду на інший, але результату буде мінус пʼять поінтів.

Друге відкриття — верифікуйте по максимуму все, що каже AI. Якщо це проігнорувати, то можете втрапити в дебільну ситуацію, коли ви місяцями розробляєте розширення для групування вкладок, а потім виявляєте, що Safari взагалі не підтримує tabGroups API. Повторю ще раз — перевіряйте документацію перед тим, як планувати функціонал. Перечитай ще раз. Точно поняв? Добре, читай далі.

Третє — найцікавіше та найскладніше у вайб-кодингу це не код, а продуктові рішення. AI може написати вам красивий JavaScript, але він не може вирішити, які фічі насправді потрібні користувачеві, як має виглядати інтерфейс, і чи взагалі хтось захоче ваш продукт. Я витратив 50 % часу не на програмування, а на дизайн, тестування та з’ясування того, що саме я роблю і навіщо. Вайб-кодинг — це скоріше про product management. А це вже зовсім інші скіли.

Що далі з Unthread?

Станом на червень 2025 року Unthread — це повноцінне працююче розширення. Воно робить саме те, для чого створювалося: аналізує контент вкладок через AI та організовує їх за релевантністю до поточного завдання.

Аналіз 15+ вкладок займає менше 30 секунд, інтерфейс виглядає як нативна частина macOS — зі всіма анімаціями, темною темою та піксель-perfect деталями.

Але найголовніше — воно реально корисне. Щодня використовую Unthread для організації робочих вкладок, підготовки до зустрічей, дослідження нових тем. Те відчуття, коли твій власний продукт стає частиною щоденної рутини — безцінне.

Найочевидніший наступний крок — версія для Chrome. Там є нативний tabGroups API, тому теоретично можна буде спробувати реалізувати оригінальну ідею з групуванням вкладок всередині одного вікна. Плюс Chrome має набагато більшу аудиторію.

А ще розглядаю можливість релізу в App Store. Хоча тут свої пригоди: спочатку треба платити $99 на рік за Developer Program (і це ще до того, як дізнаєшся, чи взагалі хтось купить твій продукт), Apple має параноїдальні вимоги до privacy policy (особливо коли твій додаток аналізує контент сторінок), та модератори, яким доведеться на пальцях пояснювати, чому це не spyware.

А ще, обʼєктивно, аудиторія Safari в рази менша за Chrome, тому монетизувати це — окремий квест із непередбачуваним фіналом.

Але хоч і робив я розширення, перш за все, для себе, усе ж планую спробувати зробити із цього щось більше, ніж просто експеримент. Можливо, марно, але цікаво.

Найбільший комплімент цій статті — якщо хтось після її прочитання спробує себе у вайб-кодингу.

До речі, якщо хочете спробувати — Cabina.AI виділили нам промокодик з додатковими токенами: FxS-2025, ще лінк про всяк випадок лишу.

Фінальна думка

Коли я починав цей проєкт, хотів вирішити особисту проблему з організацією вкладок. Не планував писати про це статті, не планував робити продукт для широкої аудиторії.

Але процес виявився настільки цікавим та новим, що захотілося поділитися. Можливо, через п’ять років AI зможе створювати такі продукти за кілька хвилин взагалі без людського втручання — поживемо, побачимо, відчуємо. Але зараз це все ще потребує творчості, наполегливості та розуміння того, що ти хочеш створити.

Якщо ця історія надихнула вас спробувати щось своє — моя місія виконана. Вайб-кодинг не замінить традиційне програмування, але він демократизує створення технологій. Він дає можливість людям з ідеями, але без технічних навичок, нарешті перестати казати «от якби хтось зробив…» і почати робити самим. І це прекрасно.

⛩ FUTURE : SIMPLE