Як двогодинний воркшоп з Pomodoro-проєктом вчить будувати Ralph Loops

У спільноті AI-інженерів дедалі частіше звучить ім’я Кріс Парсонс — розробник із майже 30-річним досвідом, колишній CTO венчурних стартапів і керівник агенції, який тепер спеціалізується на тому, як команди можуть реально впроваджувати штучний інтелект у щоденну роботу. На каналі AI Engineer він проводить практичний воркшоп із Ralph Loops — простих, але впертих AI-циклів, які замість складної оркестрації просто знову і знову пробують виконати завдання, поки результат не стане прийнятним. Центральний полігон для цього експерименту — невеликий Python‑проєкт Pomodoro‑таймера, який учасники розширюють власноруч, а потім навчаються автоматизувати за допомогою Ralph Loops.

Воркшоп без «магії»: дві години реального коду на власному ноутбуці

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

Парсонс одразу окреслює очікування: за ці дві години кожен має піти з чимось, що реально працює. Не з теоретичним розумінням Ralph Loops, а з робочим циклом, який можна застосувати до власних задач. Для цього він пропонує максимально простий, але показовий навчальний полігон — Pomodoro‑таймер у вигляді невеликої Python‑утиліти.

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

Хто такий Кріс Парсонс і чому він нав’язливо говорить про AI‑цикли

Біографія Парсонса пояснює, чому воркшоп побудований саме так. Він близько трьох десятиліть професійно пише софт, був CTO у кількох VC‑бекд стартапах і скейлапах, керував агенцією, займався agile‑консалтингом і тренінгами. Іншими словами, це людина, яка бачила, як змінюється розробка — від класичних процесів до сучасних AI‑інструментів.

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

Показово, що Ralph Loops для нього — не експериментальна іграшка, а робочий інструмент. Він використовує їх буквально «24/7» для всього: написання й відповіді на листи, перевірки календаря, створення контенту й розсилок, роботи з клієнтами, написання та рефакторингу коду. Воркшоп із Pomodoro‑проєктом — це спроба передати саме цей практичний досвід: як побудувати такі ж цикли у власній роботі, починаючи з дуже простого прикладу.

Pomodoro як полігон: мінімальний код, реалістичний беклог

Щоб навчити Ralph Loops, Парсонс обирає максимально простий, але знайомий багатьом формат — Pomodoro‑таймер. Це невеликий Python‑проєкт, який працює з командного рядка. На старті в ньому є мінімальний функціонал: базова команда, що запускає таймер, і невеликий набір тестів, які перевіряють, що все працює як слід.

Ключовий елемент — структура проєкту, яка імітує реальну розробку. Окрім коду й тестів, у репозиторії є директорія tickets. У ній лежать текстові «тікеті» — невеликі описані завдання на покращення Pomodoro‑таймера. Кожен тікет — це інкрементальна зміна: додати команду, змінити поведінку, покращити UX. Такий формат нагадує типовий беклог у продуктовій команді, де розробники беруть задачі по одній, реалізують, проганяють тести, роблять рев’ю.

Це важливий момент: воркшоп не зводиться до «зробімо щось абстрактне з AI». Учасники працюють із кодовою базою, яка виглядає й поводиться як маленький, але реальний продукт. Є CLI‑інтерфейс, є тестовий набір, є беклог у вигляді тікетів. Саме на цьому ґрунті потім будуються Ralph Loops, які вчаться «закривати» такі тікети автоматично.

Ticket 001: проста «status»‑команда як тест для AI‑асистентів

Перший крок воркшопу — взяти найпростішу задачу з беклогу й реалізувати її без жодних Ralph Loops, лише за допомогою сучасних AI‑асистентів коду. Учасникам пропонують відкрити репозиторій, знайти директорію tickets і прочитати опис Ticket 001.

Цей перший тікет формулює дуже конкретне покращення: додати команду status, яка дозволить користувачеві подивитися, скільки часу залишилося в поточній Pomodoro‑сесії. З погляду розробки це невелика, але показова зміна. Потрібно зрозуміти, як зараз працює таймер, де зберігається стан, як краще організувати вивід, і при цьому не зламати існуючу поведінку, яку вже покривають тести.

Учасників прямо просять спочатку реалізувати Ticket 001 за допомогою інструментів на кшталт Claude Code або Codeex. Тобто не писати все вручну, а поводитися так, як поводиться дедалі більша частина розробників: делегувати чорнову роботу моделі, а потім перевіряти й коригувати результат.

Критичний етап — запуск тестів. Після того як AI‑асистент згенерує зміни, потрібно переконатися, що всі тести проходять. Це дисциплінує і самих учасників, і моделі: завдання не в тому, щоб «щось зібрати, аби працювало», а в тому, щоб інтегрувати нову функцію в існуючу систему без регресій. Лише коли Ticket 001 реалізований і тестовий набір зелений, воркшоп переходить до власне Ralph Loops.

Такий порядок не випадковий. Він показує, що Ralph Loops — це не заміна базовим практикам розробки, а надбудова над ними. Спочатку потрібно мати зрозумілий код, тести й чітко сформульовані тікети. Лише тоді є сенс автоматизувати виконання цих тікетів за допомогою циклів.

Ralph Loops: чому «дурний» цикл виявляється розумнішим за складну оркестрацію

Назва Ralph Loops звучить іронічно, і це не випадково. Вона походить від персонажа Ральфа Віггама з «Сімпсонів», який відомий тим, що вперто повторює одну й ту саму дію, поки щось не вийде. Ця метафора лягла в основу підходу: замість того щоб будувати складні графи агентів і планувальників, AI просто знову й знову намагається виконати одне й те саме завдання з тим самим промптом.

Базовий патерн виглядає майже смішно просто. Спочатку формулюється інструкція: побудувати певну фічу, змінити код, реалізувати тікет. Модель виконує завдання, повертає результат і заявляє, що роботу завершено. На цьому етапі звичайний користувач зупинився б. Ralph Loop робить інше: одразу ж дає моделі той самий промпт ще раз.

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

Цикл можна повторювати кілька разів. Кожного разу модель «дивиться в дзеркало» — на свій попередній код — і знаходить дрібні недоліки, які не помітила раніше. У певний момент вона впевнено заявляє, що тепер усе точно завершено. Ralph Loop, у своїй найрадикальнішій формі, може навіть тоді ще раз повторити промпт, змушуючи модель ще раз перевірити себе.

На воркшопі Парсонс пропонує учасникам спочатку пройти цей шлях вручну: реалізувати Ticket 001 за допомогою Claude Code, переконатися, що тести проходять, а потім спробувати обгорнути цей процес у Ralph Loop. Ідея в тому, щоб AI‑асистент не просто один раз «написав фічу», а кілька разів пройшов повний цикл: прочитав тікет, змінив код, перевірив себе, покращив рішення.

Від Pomodoro до повсякденної роботи: як Ralph Loops масштабуються за межі коду

Хоча воркшоп формально присвячений коду й Pomodoro‑проєкту, контекст, який задає Парсонс, значно ширший. Він сам використовує Ralph Loops не лише для розробки, а практично для всіх аспектів роботи: від листування й планування календаря до створення контенту, розсилок і виконання клієнтських завдань.

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

Ключовий урок воркшопу полягає в тому, що справжня сила сучасних моделей розкривається не в разових запитах, а в циклах. Коли AI не просто генерує відповідь і зникає, а повертається до власного результату, аналізує його, порівнює з вимогами й намагається зробити краще. Ralph Loops формалізують цю поведінку в простий, але потужний патерн, який можна реалізувати навіть у невеликому проєкті на кшталт Pomodoro‑таймера.

Висновок: чому варто почати з маленького Pomodoro‑проєкту

Двогодинний воркшоп Кріса Парсонса демонструє, що навчитися працювати з Ralph Loops можна без складної інфраструктури й багаторівневих агентних систем. Достатньо невеликого Python‑проєкту, кількох текстових тікетів, сучасного AI‑асистента коду й готовності дозволити моделі кілька разів «переписати» власну роботу.

Pomodoro‑таймер із Ticket 001 на «status»‑команду — це не просто дрібна вправа. Це концентрований приклад того, як виглядає реалістичний беклог, як AI‑інструменти інтегруються в звичний процес розробки, як тести стають об’єктивним критерієм якості, а Ralph Loops — механізмом поступового покращення без ручного мікроменеджменту.

Для команд, які лише починають впроваджувати AI у свою роботу, такий підхід може стати безпечним стартом. Замість того щоб одразу будувати складні конвеєри, можна взяти маленький, добре окреслений проєкт, структурувати його у вигляді тікетів, підключити Claude Code чи Codeex і навчитися обгортати ці задачі в прості, повторювані цикли. Саме з таких «дурних» на вигляд кроків починається більш зріла, системна робота з AI, яку Парсонс уже сьогодні застосовує у власній щоденній практиці.

Джерело

YouTube: Ralph Loops: Build Dumb AI Loops That Ship — Chris Parsons, Cherrypick

Системний дизайн мобільних застосунків зазвичай асоціюється з екранами, архітектурними патернами та UX. Але на співбесідах усе частіше питають інше: як саме застосунок спілкується з бекендом, що відбувається з даними, коли немає мережі, як поводяться медіафайли, де зберігаються токени й як команда розуміє, що відбувається в продакшені. У своєму гайді з мобільного системного дизайну розробник і автор каналу Philipp Lackner розкладає ці рішення на конкретні технічні вибори, які очікують від інженера рівня middle–senior.

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

REST, WebSockets, SSE чи GraphQL: як вибір протоколу змінює застосунок

На рівні діаграми все виглядає просто: «клієнт говорить із сервером». Але системний дизайн починається там, де з’являється запитання «як саме?». Для мобільних застосунків це не абстрактна деталь, а фундаментальне рішення, яке впливає на батарею, затримки, стабільність і навіть UX.

Найочевидніший варіант — REST поверх HTTP. Класична модель: застосунок робить HTTP‑запит, сервер відповідає, з’єднання закривається. Для більшості CRUD‑операцій цього достатньо: отримати профіль, оновити налаштування, завантажити список постів. Простота, зрозумілі інструменти, величезна екосистема.

Проблеми починаються, коли продукт вимагає реального часу. Соціальна стрічка, чат, лайви, нотифікації — усе це спокушає до наївного рішення: «давайте просто опитувати сервер у циклі». Технічно це працює: клієнт кожні N секунд робить GET‑запит до REST‑ендпойнта, перевіряє, чи є нові події, оновлює UI. Але з погляду мобільного системного дизайну це майже завжди поганий компроміс.

Постійне опитування REST‑ендпойнтів створює зайве навантаження на мережу, витрачає батарею й усе одно не дає справжнього «реального часу». Якщо інтервал занадто великий, користувач бачить затримки; якщо занадто малий — пристрій гріється, а бекенд отримує лавину запитів, більшість з яких повертають «нічого нового».

Тут у гру вступають WebSockets і server‑sent events (SSE). Обидва підходи дозволяють тримати довготривале з’єднання між клієнтом і сервером, але з різною семантикою. WebSocket — двосторонній канал: клієнт і сервер можуть надсилати повідомлення один одному в будь‑який момент. Це природний вибір для чатів, ігор, спільного редагування. SSE — односторонній потік від сервера до клієнта, коли саме сервер пушить події, а клієнт лише слухає. Для стрічок, нотифікацій чи оновлень статусу цього часто достатньо, і реалізація простіша.

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

Окремою лінією йде GraphQL. Це не стільки про реальний час, скільки про гнучкість даних. Якщо REST‑ендпойнти повертають фіксовані структури, то GraphQL дозволяє клієнту описати, які саме поля потрібні. Для мобільних застосунків це критично, коли один і той самий бекенд обслуговує різні платформи й екрани: замість «товстих» відповідей, де половина полів не використовується, клієнт може запитати рівно те, що потрібно для конкретного екрану. Це зменшує трафік і прискорює рендеринг.

У системному дизайні мобільного застосунку вибір між REST, WebSockets, SSE та GraphQL — не питання «модності», а відповідь на конкретні вимоги: чи потрібен реальний час, наскільки важливі оптимізація трафіку, простота кешування, стабільність з’єднання в умовах мобільної мережі. На співбесіді від кандидата очікують не назви технологій, а аргументований вибір і розуміння компромісів.

API та схема даних: профіль, стрічка, пагінація й соціальний граф

Щойно визначено протокол, наступний шар системного дизайну — це власне API й схема даних. Для мобільного розробника це не лише «документація бекенда», а частина професійної відповідальності: як виглядають ендпойнти, які параметри вони приймають, як організовано пагінацію, які таблиці стоять за цими запитами.

Уявімо типовий соціальний застосунок. Мінімальний набір функцій — профіль користувача, стрічка постів, можливість підписуватися, коментувати. На рівні API це перетворюється на зрозумілі ендпойнти: наприклад, GET /profile для отримання профілю, GET /feed для завантаження стрічки. Але важливо не лише «що» повертає ендпойнт, а й «як».

Стрічка — класичний приклад, де без пагінації система не виживе. Сотні чи тисячі постів не можуть завантажуватися одним запитом. Тому в системному дизайні одразу закладається механізм посторінкового завантаження. Поширений підхід — курсорна пагінація: клієнт передає курсор (ідентифікатор останнього отриманого елемента або спеціальний токен) і ліміт — скільки елементів потрібно повернути. Бекенд відповідає наступним «шматком» стрічки й, за потреби, новим курсором.

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

Під API завжди стоїть схема даних. У тому ж соціальному прикладі мінімальний набір таблиць виглядає передбачувано, але саме його потрібно вміти проговорити. Таблиця users з базовими полями профілю. Таблиця posts, де кожен запис належить одному користувачу, але один користувач може мати довільну кількість постів. Таблиця comments, де кожен коментар прив’язаний до конкретного поста, а пост може мати багато коментарів. Таблиця follows, яка описує, хто на кого підписаний: один користувач може мати багато підписників, і водночас сам підписуватися на багатьох.

Ці зв’язки формують соціальний граф і безпосередньо впливають на те, як формується стрічка, як рахуються лічильники, як працюють рекомендації. Для мобільного розробника важливо розуміти, що дизайн API й схема даних — це не «чорний ящик бекенда», а частина загального системного дизайну, де клієнт і сервер мають бути узгоджені.

Offline‑first і локальний кеш: коли телефон — головне джерело правди

Мобільні застосунки живуть у світі нестабільної мережі. Потяги, тунелі, ліфти, роумінг, обмежений трафік — усе це робить підхід «онлайн‑або‑нічого» дедалі менш прийнятним. Звідси — популярність offline‑first‑підходу, який у системному дизайні змінює саму модель роботи з даними.

Ключовий принцип offline‑first — локальний кеш як єдине джерело правди. Застосунок у першу чергу читає дані з локального сховища, а не з мережі. Бекенд стає джерелом синхронізації, а не обов’язковою умовою для роботи. Користувач відкриває стрічку — застосунок показує те, що є в локальній базі, а в бекграунді оновлює дані з сервера. Користувач редагує профіль — зміни спершу потрапляють у локальне сховище, а потім синхронізуються.

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

Якщо один і той самий користувач редагує ті самі дані офлайн на різних пристроях, система неминуче стикається з конфліктами. Один телефон змінює ім’я профілю, інший — аватар, обидва роблять це без мережі, а потім виходять в онлайн у різний час. Або складніший сценарій: два пристрої змінюють одне й те саме поле по‑різному. Без явної стратегії розв’язання конфліктів дані будуть перезаписуватися в непередбачуваному порядку.

У системному дизайні offline‑first‑застосунку конфлікт‑резолюшн — не деталь реалізації, а обов’язковий елемент. Потрібно визначити, що вважається «правильним» у разі розбіжностей: остання зміна за часом, пріоритет певного пристрою, мерж окремих полів, ручне вирішення користувачем. Кожен варіант має наслідки для UX і складності бекенда.

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

Медіа: великі файли, chunked‑завантаження й кешування зображень

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

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

Тому в системному дизайні мобільних застосунків для великих медіа зазвичай закладають chunked‑завантаження. Файл розбивається на менші частини, кожна з яких завантажується окремо. Це дозволяє контролювати споживання пам’яті, відновлювати завантаження після обриву мережі, розподіляти навантаження. Застосунок може трекати прогрес по чанках, повторно відправляти лише ті, що не дійшли, і не тримати весь файл у пам’яті.

Зворотний бік — завантаження медіа з сервера. Тут у гру вступає кешування зображень на клієнті. Без нього кожен скрол стрічки перетворюється на десятки однакових запитів до тих самих URL, зайвий трафік і помітні затримки. Кешування дає змогу зберігати зображення локально й повторно використовувати їх при повторному показі. Це не лише економія трафіку, а й відчутне покращення сприйняття швидкості.

Для системного дизайну важливо, що рішення щодо медіа приймаються не «в кінці», а на рівні загальної архітектури: як організовано API для завантаження, чи підтримує бекенд chunked‑upload, як клієнт керує чергою завантажень, що відбувається при втраті мережі, як довго й де зберігається кеш зображень. Усе це безпосередньо впливає на стабільність, батарею й досвід користувача.

Безпека: токени, шифрування, HTTPS і обмеження zero‑knowledge

Безпека в мобільному системному дизайні — це не лише «додати HTTPS». Йдеться про повний ланцюжок: як користувач автентифікується, де й як зберігаються токени, які дані шифруються, що може побачити сервер.

Починається все з токенів доступу. Мобільний застосунок неминуче зберігає деяку форму облікових даних — access‑токен, refresh‑токен чи інші секрети, які дозволяють відновити сесію без повторного логіну. Системний дизайн має передбачити безпечне сховище для цих токенів, а не простий SharedPreferences чи локальний файл у відкритому вигляді. На Android і iOS існують спеціальні механізми захищеного зберігання, і їх використання — не «бонус», а базова вимога.

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

Найрадикальніший варіант — zero‑knowledge‑підхід, коли сервер технічно не може прочитати вміст користувацьких даних. У такій моделі шифрування й дешифрування відбуваються виключно на клієнті, а бекенд бачить лише зашифровані блоки. Це значно підвищує приватність, але різко обмежує можливості бекенда: стає складно робити пошук по вмісту, рекомендації, серверні фільтри, аналіз даних.

У системному дизайні мобільного застосунку zero‑knowledge — це не просто «галочка про безпеку», а фундаментальне архітектурне рішення. Воно визначає, які операції можливі на сервері, як виглядає схема даних, як організовано синхронізацію між пристроями. Від розробника очікують розуміння, що кожен додатковий рівень безпеки має ціну — у складності, продуктивності, функціональності.

Спостережуваність після релізу: краші, аналітика, перформанс і A/B‑тести

Системний дизайн мобільного застосунку не закінчується в момент публікації в сторі. Після релізу починається етап, де без спостережуваності продукт фактично «сліпий». Для мобільних команд це особливо критично: оновлення проходять через модерацію, користувачі не оновлюються миттєво, а відкат версії — нетривіальна операція.

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

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

Третій компонент — моніторинг продуктивності. Час запуску, затримки мережевих запитів, споживання пам’яті, частота ANR — усе це впливає на рейтинги в сторах і утримання користувачів. Інструменти перформанс‑моніторингу дозволяють побачити, як зміни в коді чи конфігурації впливають на реальну роботу застосунку на різних пристроях і в різних мережах.

Над цим шаром будуються механізми віддаленої конфігурації й A/B‑тестування. Remote config дозволяє змінювати поведінку застосунку без оновлення через стор: вмикати чи вимикати фічі, змінювати пороги, перемикати експериментальні алгоритми. A/B‑тестування дає змогу порівнювати різні варіанти UX, алгоритмів або налаштувань на реальних користувачах, поступово розкочуючи вдалі зміни.

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

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

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

Вибір між REST, WebSockets, SSE та GraphQL визначає, як застосунок поводиться в реальному часі й як витрачає батарею. Дизайн API й схема даних задають межі масштабованості й можливості клієнта. Offline‑first із локальним кешем як єдиним джерелом правди дає швидкість і стійкість до поганої мережі, але вимагає продуманого конфлікт‑резолюшну. Стратегія роботи з медіа впирається в обмеження пам’яті й мережі. Рівень безпеки, включно з потенційним zero‑knowledge, визначає, що взагалі може робити бекенд. А спостережуваність після релізу перетворює застосунок із «запакованого продукту» на живу систему, яку можна вимірювати й покращувати.

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

Джерело

Beginner’s Guide to Mobile App System Design (+ Tips for Interviews!)

«Фундаментально божевільні»: як Тобі Лютке переосмислює роль CEO і довгострокове лідерство

Співзасновник і CEO Shopify Тобі Лютке керує однією з найпомітніших технологічних компаній світу: публічним гігантом e‑commerce із тисячами співробітників і мільярдними оборотами. В розмові на подкасті 20VC з Гаррі Стеббінгсом він майже демонстративно ламає звичні уявлення про «правильного» керівника: називає засновників «фундаментально божевільними», зізнається, що не хотів бути CEO, і пояснює, чому справжня продуктова компанія неминуче живе в режимі нескінчального «marshmallow test» — вибору між сьогоднішніми цифрами й завтрашньою цінністю.

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

«Будівельники компаній — фундаментально божевільні люди»

Лютке не романтизує підприємництво. Навпаки, він намагається зняти з нього глянець і повернути до базової, не надто привабливої істини: нормальна, «розумна» людина, за визначенням, не повинна так жити.

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

Лютке апелює до старого трюїзму про «нерозумну людину», від якої нібито залежить увесь прогрес: саме вона не погоджується на «як у всіх» і пробує робити інакше. У його інтерпретації це не красивий афоризм, а тверезий опис психотипу з високою варіативністю: ті самі риси, які дозволяють засновнику створити щось велике, роблять його складним, непередбачуваним і часто незручним для оточення.

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

Лютке не закликає копіювати жорсткі моделі минулого, але наполягає: якщо ми хочемо чесно говорити про те, як насправді створюються компанії, треба визнати, що за фасадом «правильного» лідерства стоять люди з дуже нетиповою психікою, високою емоційною амплітудою і готовністю йти проти колективної раціональності.

«Вісімки» проти системи: чому компанії змовляються проти тих, хто каже «це лайно»

Щоб пояснити, як саме ця «божевільність» проявляється в організаціях, Лютке звертається до популярної типології особистостей Enneagram. Він не перетворює її на культ, але використовує як корисну мову для опису різних мотиваційних профілів у керівництві.

За його спостереженнями, більшість топ-менеджерів у великих, «професійно керованих» компаніях — це так звані «трійки» (achievers): люди, які «ніколи не бачили драбини, на яку не хотіли б вилізти». Вони орієнтовані на досягнення, кар’єрне зростання, зовнішній успіх. У фінансових ролях часто зустрічаються «п’ятірки» — ті, хто любить занурюватися дуже глибоко в аналітику, структури, системи.

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

У типовій корпоративній структурі такі люди небезпечні для кар’єр інших. Вони руйнують комфортні ілюзії, не підтримують «фасад», не грають у політичні ігри. За словами Лютке, системи управління часто фактично «змовляються» проти них: «вісімки» рідко отримують підвищення, частіше йдуть з компаній. Але саме вони, побачивши, як усе влаштовано, найчастіше й засновують нові бізнеси.

Цікаво, що Лютке бачить у цьому не просто соціальну динаміку, а свого роду історичний експеримент, який триває з моменту повернення Стіва Джобса в Apple. Тоді ринок уперше побачив, що можна дати засновнику «довший розбіг» і не намагатися замінити його «професійним менеджером» після певного етапу зростання. Результати виявилися настільки переконливими, що дедалі більше рад директорів і інвесторів почали дозволяти фаундерам залишатися при владі значно довше.

У підсумку в керівництві з’явилася нова форма різноманіття: поруч із класичними «achievers» і «аналітиками» з’явилися люди, яких «ніхто не може звільнити» і які мають право вголос називати речі своїми іменами. Лютке вважає, що це виявилося надзвичайно корисним для компаній. У Shopify він свідомо шукає таких «вісімок» і будує культуру, де прямота й нетерпимість до самообману — не вада, а ресурс.

«Я не хотів бути CEO»: чому продуктова компанія потребує контролю засновника

Попри те, що сьогодні Лютке — публічний CEO глобальної компанії, він відверто визнає: спочатку він не хотів цієї ролі. Його природний інтерес — у створенні продукту, у технічній і продуктовій роботі, а не в управлінні великою організацією.

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

Лютке формулює це як постійний «marshmallow test» — відсилання до відомого психологічного експерименту, де дитині пропонують один зефір зараз або два пізніше. Для керівника продуктової компанії це щоденна дилема: «з’їсти зефір» у вигляді гарних короткострокових метрик чи відмовитися від них, щоб отримати «два зефіри» через кілька років.

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

Саме тому, за логікою Лютке, засновник, який справді хоче будувати продукт, змушений взяти на себе роль CEO. Інакше хтось інший — більш орієнтований на короткострокові результати — неминуче почне приймати рішення, які суперечать довгостроковим інтересам продукту. Це не питання его чи контролю заради контролю, а структурна необхідність: без поєднання продуктової й корпоративної влади компанія рано чи пізно обере «один зефір зараз».

CEO як сервісна роль: «Я маю цю роботу, щоб інші могли мати роботи, які я сам хотів би»

На цьому тлі особливо показовим є те, як Лютке описує власну мотивацію залишатися CEO. Він не говорить про владу, статус чи фінансову вигоду. Натомість формулює свою роль як сервісну: «У мене є ця робота, щоб інші люди могли мати роботи, які я сам хотів би мати».

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

Фактично він описує CEO як людину, яка бере на себе найбільш неприємну, політичну, публічну частину роботи — зустрічі з інвесторами, складні кадрові рішення, стратегічні компроміси — щоб інші могли зосередитися на тому, що створює реальну цінність. Це не альтруїзм у романтичному сенсі, а прагматичне розуміння: якщо засновник із продуктовим мисленням не встане між командою й зовнішнім тиском, продуктова культура не виживе.

У цій логіці легко побачити й відповідь на питання про самотність фаундера. Лютке не заперечує, що життя в голові CEO може бути самотнім і хаотичним, але не драматизує це. Він говорить про себе як про «славний безлад» — людину з масою внутрішніх суперечностей, яка водночас має «класну роботу» й багато привілеїв. Його позиція: так, це важко й не для всіх, але це частина пакету, який іде разом із можливістю будувати щось велике.

Marshmallow test у публічній компанії: як мислити довго під мікроскопом ринку

Один із найцікавіших моментів у філософії Лютке — його ставлення до публічних ринків. На тлі поширеного скепсису серед фаундерів щодо IPO і «тиранії квартальних результатів» він формулює майже єретичну для Кремнієвої долини думку: «Немає нічого кращого у світі, ніж бути довіреною публічною компанією. Друге найкраще — бути довіреною приватною компанією».

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

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

Показово, що Лютке почав мислити як публічний CEO ще до формального виходу Shopify на біржу. Він говорить про те, що ще до ключової зустрічі з банкірами щодо ціни IPO вже діяв із фідуціарним мисленням публічного керівника. Тобто внутрішній перехід до ролі людини, яка відповідає перед широким колом акціонерів і має приймати рішення в їхніх довгострокових інтересах, відбувся до того, як це було закріплено юридично.

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

У цій рамці «marshmallow test» набуває нового виміру. Лідер публічної компанії має не просто відмовлятися від короткострокових «зефірів» заради продукту, а й переконувати в правильності цього вибору ринок, який бачить лише цифри й заголовки. Саме тому, за логікою Лютке, так важливо стати «довіреною» компанією: тоді інвестори готові приймати тимчасові просідання, розуміючи, що за ними стоїть послідовна стратегія, а не хаотичні імпульси.

Лідерство без кіношного глянцю: тепло замість естетики

На тлі всього цього Лютке різко критикує те, як суспільство конструює образ «хорошого лідера». Він стверджує, що «вся естетика навколо того, яким має бути лідерство, приходить із фільмів» або з ретельно відредагованих публічних образів. У результаті ми оцінюємо керівників за тим, наскільки вони відповідають цим естетичним стандартам, а не за тим, наскільки ефективно вони будують компанії.

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

Ця метафора добре поєднується з усіма іншими елементами його філософії. «Божевільний» засновник, який бере на себе роль CEO не з честолюбства, а з необхідності захистити продукт; людина, яка щодня проходить «marshmallow test» між цифрами й цінністю; керівник, який мислить як публічний фідуціар ще до IPO, — усе це не виглядає як герой із фільму про стартапи. Це радше складний, суперечливий, але енергетично потужний центр системи, який дозволяє іншим займатися тим, що вони роблять найкраще.

Висновок: довгострокове божевілля як нова норма для технологічних лідерів

Філософія Тобі Лютке про лідерство й ризик звучить різко, але в ній є внутрішня послідовність. Він одночасно:

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

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

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

Джерело

Shopify CEO on How AI is a Scapegoat for Mass Layoffs & Trump Derangement Syndrome in Canada — 20VC

У Confluent давно звикли до масштабних експериментів із потоковими даними, але Warpstream — окрема історія. Це продуктова лінійка, якою нині керує Калеб Ґрілло, staff product manager в Confluent, і яка поєднує одразу кілька радикальних ідей: Kafka без дисків, модель BYOC (bring your own cloud), жорсткий акцент на вартості інфраструктури замість мікросекундної затримки та новий сервіс Tableflow на базі Apache Iceberg. Разом це виглядає як спроба переосмислити, якою має бути сучасна стрімінгова платформа в епоху дешевих об’єктних сховищ і дорогих керованих сервісів.

BYOC як вихід із глухого кута «керований сервіс vs контроль»

Warpstream у складі Confluent позиціонується як BYOC-продукт: клієнт «приносить» власну хмару або дата-центр, а Confluent постачає програмну логіку та контрольну площину. Це не просто ще один варіант розгортання, а відповідь на типову напругу між безпекою, контролем і зручністю.

Класичний керований Kafka-сервіс означає, що постачальник керує інфраструктурою у своєму акаунті, а клієнт довіряє йому не лише дані, а й IAM-права, мережеві налаштування, ключі доступу. Для великих організацій із жорсткими політиками безпеки це часто неприйнятно. Warpstream намагається зняти цю напругу за рахунок чітко розділених площин.

Уся дата-плейн-частина Warpstream — те, що безпосередньо приймає, зберігає й віддає повідомлення — працює всередині середовища клієнта: у його VPC або в його ж дата-центрі. Confluent не отримує крос-акаунтних IAM-привілеїв, не має технічної можливості «зайти» в обчислювальні ресурси клієнта й напряму торкнутися даних. Назовні виходить лише метадані, які потрапляють у контрольну площину Confluent.

Це розділення виглядає принциповим. З одного боку, клієнт зберігає повний контроль над своїми даними, мережею та політиками доступу. З іншого — отримує керований сервіс: оновлення, операційні практики, аналітику використання, інтеграцію з іншими продуктами Confluent. Для Warpstream це ще й спосіб відрізнитися від класичних «Kafka-as-a-service», які часто вимагають значно більшої довіри до провайдера.

Ключовим елементом цієї архітектури стає агентний процес, який розгортається у середовищі клієнта й фактично замінює роль Kafka-брокера. Саме агент — ядро дата-плейну Warpstream: він приймає трафік від продюсерів і конс’юмерів, працює з об’єктним сховищем, взаємодіє з контрольної площиною через метадані, але не передає самі повідомлення назовні.

Kafka без дисків: ставка на об’єктне сховище замість низької затримки

Найрадикальніша ідея Warpstream — відмова від традиційної моделі Kafka, де брокери тримають дані на локальних або мережевих дисках. Замість цього платформа реалізує «diskless Kafka»: усі повідомлення зберігаються в хмарному об’єктному сховищі.

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

Цей підхід змінює базову економіку Kafka-кластерів. Традиційні розгортання орієнтовані на мінімальну затримку: локальні SSD, щільні кластери, високошвидкісні мережі, складні схеми реплікації. Усе це дорого, особливо в хмарі, де кожен гігабайт диска й кожен IOPS мають свою ціну. Об’єктне сховище, навпаки, оптимізоване під вартість і довгострокове зберігання, а не під мікросекундні затримки.

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

У 2023 році Warpstream опублікував блог «Kafka is Dead, Long Live Kafka», де ця ідея була сформульована як стратегічна ставка: Kafka як протокол і екосистема залишаються, але архітектура під них може бути зовсім іншою. Дисклес-підхід дозволяє використовувати Kafka там, де раніше її вважали надто дорогою для великих обсягів історичних даних або довгої ретенції.

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

Традиційно Kafka асоціюється з низькою затримкою — мілісекунди від продюсера до конс’юмера. Warpstream фактично ставить під сумнів, чи справді всім потрібна така швидкість, якщо її ціна — кратно вищі рахунки за інфраструктуру.

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

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

Warpstream фактично формалізує те, що багато команд робили неявно: будували складні пайплайни з Kafka, об’єктного сховища та окремих аналітичних систем, щоб зменшити навантаження на кластери. Тут же пропонується єдина платформа, де компроміс «затримка проти вартості» закладений в основу архітектури.

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

Агент замість брокера: як працює дата-плейн у VPC клієнта

Щоб поєднати BYOC-модель, дискless-архітектуру та вимоги безпеки, Warpstream використовує агентний підхід. Замість того, щоб розгортати повноцінні Kafka-брокери, клієнт запускає у своїй інфраструктурі кластери агентів.

Ці агенти виконують кілька ролей одночасно. Вони приймають підключення від продюсерів і конс’юмерів, реалізують протокольну поведінку Kafka, керують записом і читанням з об’єктного сховища, а також взаємодіють із контрольної площиною Confluent через метадані. При цьому жодні корисні дані не виходять за межі VPC або дата-центру клієнта.

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

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

Цей підхід також створює основу для подальших сервісів поверх Kafka-протоколу, зокрема для Tableflow, який використовує окремий тип агентного кластера для роботи з Apache Iceberg.

Ретенція без меж: новий сторедж-движок поверх об’єктного сховища

Перехід на об’єктне сховище як основний носій змусив Warpstream повністю перебудувати сторедж-движок. Класичні механізми Kafka — сегментовані логи на диску, політики видалення за часом або розміром, компактовані топіки — розраховані на файлові системи, а не на S3-подібні сервіси.

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

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

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

Для клієнтів це відкриває можливість тримати в Kafka не лише «гарячі» дані останніх годин або днів, а й роки історії — без необхідності постійно вивантажувати все в окремі data lake-системи. Або, принаймні, значно відтермінувати момент, коли така міграція стає неминучою.

Tableflow і Apache Iceberg: «нижня половина» бази даних у BYOC

Наступний логічний крок Warpstream — зробити ці довготривалі стріми придатними для аналітики та батчевих сценаріїв без складних ETL-пайплайнів. Для цього з’являється Warpstream Tableflow — сервіс, який нині перебуває в режимі раннього доступу.

Tableflow матеріалізує Kafka-топіки як таблиці Apache Iceberg в об’єктному сховищі. По суті, це автоматизований міст між світом стрімінгу та світом табличних даних: повідомлення з топіків перетворюються на Parquet-файли, а поверх них будується Iceberg-метадані — маніфести, снапшоти, схеми.

Технічно Tableflow використовує окремий тип агентного кластера. Якщо «звичайні» агенти відповідають за протокол Kafka й логіку стрімінгу, то Tableflow-агенти спеціалізуються на табличному шарі: вони пишуть Parquet, оновлюють Iceberg-маніфести, виконують фонові операції з обслуговування таблиць.

Ці фонові задачі — критичний, але часто недооцінений аспект data lake-архітектур. Tableflow автоматизує компакцію файлів, щоб уникнути тисяч дрібних Parquet-об’єктів, які вбивають продуктивність; прибирає сирітські файли, що більше не належать жодному актуальному снапшоту; обробляє видалення, щоб логічно видалені рядки не залишалися фізично вічно.

Калеб Ґрілло описує Apache Iceberg не як «готове озеро даних», а як табличний формат і будівельний блок. Сам по собі Iceberg визначає, як організовані файли, як виглядають снапшоти, як еволюціонує схема. Але він не вирішує питання, хто й як буде створювати ці файли, коли їх компактувати, як чистити «сміття» й гарантувати, що таблиці залишаються в здоровому стані.

Warpstream Tableflow позиціонується як «нижня половина» бекенду бази даних, побудованого на Iceberg. Він не намагається стати повноцінним SQL-двигуном або BI-платформою, але бере на себе все, що стосується фізичного шару: перетворення стрімів у таблиці, керування файлами, підтримку метаданих. Поверх цього клієнт може використовувати будь-який сумісний двигун — від Spark до Trino чи Flink.

Важливо, що Tableflow у BYOC-варіанті Warpstream задуманий як керований сервіс із тим самим ядром функціональності, що й Confluent Cloud Tableflow. Різниця — знову ж таки в моделі розгортання: дата-плейн у VPC клієнта, контрольна площина в Confluent, без крос-акаунтних IAM-привілеїв, із виходом назовні лише метаданих.

Аналітика використання як частина продуктового циклу

Уся ця архітектура — від агентів до Tableflow — живе не у вакуумі. Warpstream, як і інші продукти Confluent, активно аналізує власне використання. Увесь consumption- і usage-трафік потрапляє в корпоративне сховище даних Confluent, де над ним проводять трендовий аналіз: доходи, витрати, маржа, ефективність різних конфігурацій.

Для продуктового менеджера на кшталт Калеба це не просто звітність, а інструмент перевірки гіпотез. Модель «жертвуємо затримкою заради вартості» має сенс лише тоді, коли це підтверджується реальними патернами використання: які обсяги даних клієнти зберігають, як довго, які профілі навантаження мають, де саме економія інфраструктури перекриває потенційні втрати від вищої латентності.

Така аналітика також критична для BYOC-моделі. Оскільки дата-плейн працює в середовищі клієнта, а Confluent не має прямого доступу до ресурсів, правильне ціноутворення й розуміння собівартості вимагають точного збору й інтерпретації метрик. Це продовження тієї ж логіки, яку Калеб колись застосовував до побудови системи білінгу Confluent Cloud, але тепер — у контексті нової архітектури.

Висновок: Kafka як протокол, а не як догма

Warpstream демонструє, що Kafka — це не лише конкретна реалізація брокерів і дисків, а насамперед протокол і модель роботи з подіями. Дисклес-архітектура, BYOC-дата-плейн, ставка на об’єктне сховище, розширена ретенція й Tableflow на Iceberg — усе це разом пропонує альтернативний шлях еволюції стрімінгових систем.

Цей шлях не універсальний. Він навмисно відходить від фетишизації мінімальної затримки й натомість оптимізує вартість, масштаб і інтеграцію з аналітичними сценаріями. Для організацій, яким потрібен повний контроль над середовищем, але водночас хочеться мати керований сервіс, модель BYOC із агентами в VPC виглядає особливо привабливою.

Блог «Kafka is Dead, Long Live Kafka» у 2023 році зафіксував цю зміну оптики: Kafka не «вмирає», а перероджується в нових формах. Warpstream — один із найпослідовніших експериментів у цьому напрямку, який показує, що жертва затримкою може бути не поразкою, а свідомою інженерною стратегією, коли на кону — масштаб, вартість і довгострокова цінність даних.

Джерело

Being Wrong in the Right Direction with Caleb Grillo | Ep. 29 | Confluent Developer Podcast

Усередині крихітного трансформера: як влаштована модель, що поміщається в ноутбук

У спільноті AI-інженерів дедалі більше уваги отримують не лише гігантські хмарні моделі, а й маленькі, зрозумілі системи, які можна тренувати локально. На одному з таких практичних воркшопів дослідник ElevenLabs Ангелос Періволаропулос, який очолює команду speech‑to‑text і стоїть за транскрипційною моделлю Scribe v2, демонструє, як побудувати й навчити з нуля невеликий GPT‑2‑подібний LLM на звичайному ноутбуці.

Цей матеріал розбирає внутрішню будову цієї «іграшкової» моделі: від радикально простого токенайзера до архітектури трансформера та навчальної цілі next‑token prediction. Попри скромні розміри, це практично повноцінний GPT‑2 у мініатюрі — і дуже наочний приклад того, як реально працюють сучасні мовні моделі.

Чому тут символи, а не слова: радикально простий токенайзер

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

Модель працює на рівні окремих символів, а не слів чи морфем. У корпусі (тексти Шекспіра, що входять до репозиторію) виявляється лише 65 різних символів — літери, пробіли, пунктуація та службові знаки. Відповідно, словник токенайзера — це рівно 65 токенів.

Технічно токенайзер — це просте відображення «символ → ціле число». У Python це реалізується через побудову словника з допомогою enumerate: кожному унікальному символу присвоюється індекс. Далі рядок перетворюється на послідовність індексів, а вже ці індекси в моделі замінюються на вектори через embedding‑шар.

Такий мінімалістичний дизайн має дві ключові переваги для локального навчання:

По-перше, він різко скорочує комбінаторний вибух можливих пар токенів. Для 65 токенів кількість біграм (усіх можливих пар «поточний токен → наступний токен») дорівнює 65 × 65, тобто 4 225. Для невеликого датасету це критично: модель має шанс багаторазово побачити майже всі можливі біграми й навчитися їх статистиці.

По-друге, він радикально зменшує розмір embedding‑таблиці й загальну кількість параметрів, що безпосередньо впливає на те, чи можна взагалі тренувати модель на ноутбуці.

Чому не «нормальний» токенайзер: математика, яка вбиває локальне навчання

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

Ключова причина — кількість можливих пар токенів, які модель має побачити, щоб адекватно вивчити статистику мови. Якщо словник містить приблизно 200 000 токенів, то кількість можливих біграм — це 200 000 у квадраті. Це вже десятки мільярдів різних пар. Щоб модель «з нуля» навчилася розуміти такі переходи, їй потрібен корпус відповідного масштабу — порядку 200 000² токен‑пар. Для невеликого шекспірівського датасету це абсолютно нереалістично.

У символьному варіанті ситуація протилежна. 65 токенів дають 4 225 біграм — величину, яку невеликий корпус може покрити не лише один раз, а багаторазово. Це означає, що модель має шанс побачити практично всі можливі переходи «символ → наступний символ» у різних контекстах, а отже, навчитися їх передбачати.

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

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

Вартість словника: як 65 токенів перетворюються на 25 тисяч параметрів

Словник токенайзера безпосередньо впливає на розмір embedding‑шару — першого великого масиву параметрів у будь-якій трансформерній моделі. У воркшопі embedding‑вимірність обрана рівною 384. Це означає, що кожен із 65 токенів представляється вектором із 384 чисел.

Embedding‑таблиця в цьому випадку має розмір 65 × 384. Це приблизно 25 тисяч параметрів. Для сучасних LLM це мізер, але для маленької моделі, яку потрібно тренувати на ноутбуці, це вже відчутна, але цілком підйомна частина загального бюджету параметрів.

Для порівняння, якщо взяти типовий словник GPT‑2 на 50 000 токенів і залишити ту саму embedding‑вимірність 384, embedding‑таблиця матиме вже 50 000 × 384 ≈ 19 мільйонів параметрів. Це на кілька порядків більше, ніж 25 тисяч. І це лише один шар моделі.

Різниця тут не лише в пам’яті. Кожен крок навчання повинен оновлювати ці параметри через зворотне поширення помилки. 19 мільйонів параметрів у одному шарі означають суттєво більші витрати на обчислення, більший час епохи, більші вимоги до GPU/CPU та оперативної пам’яті. Для ноутбука з 16 ГБ ОЗП це вже зона ризику, а для безкоштовного GPU в Google Colab — дуже жорстке обмеження.

Символьний словник із 65 токенів, навпаки, дозволяє тримати embedding‑шар у межах десятків тисяч параметрів, що робить модель придатною для локального навчання. Це ще один приклад того, як архітектурні рішення на рівні токенайзера визначають не лише якість моделі, а й сам факт її технічної здійсненності.

GPT‑2 у мініатюрі: шість шарів, кілька голів і класичні блоки

Архітектурно модель у воркшопі базується на GPT‑2 — класичному decoder‑only трансформері з каузальною самоувагою. Хоча GPT‑2 вже вважається «старою» архітектурою, її фундаментальні елементи залишаються стандартом для багатьох сучасних LLM. У цьому прикладі вони просто масштабовані вниз.

У моделі використовується стек із шести трансформерних шарів. Кожен шар містить модуль самоуваги (self‑attention) і MLP‑блок, а також окремі шари нормалізації (layer normalization). Між компонентами проходять резидуальні з’єднання, які додають вихід підблоку до його вхідного сигналу, полегшуючи навчання глибокої мережі.

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

Це важливо навіть у символьному налаштуванні. Хоча модель бачить лише окремі символи, а не слова, голови самоуваги можуть навчитися відстежувати послідовності символів, які відповідають словам, фразам чи синтаксичним шаблонам. Саме багатоголова увага дає моделі можливість одночасно дивитися на різні «ракурси» контексту.

Повна архітектура включає:

• токен‑ембеддинги, які перетворюють індекси символів на вектори розмірності 384;
• позиційні ембеддинги, які додають інформацію про позицію токена в послідовності;
• стек із шести трансформерних блоків, кожен із власним self‑attention, MLP і layer norm;
• резидуальні з’єднання навколо основних підблоків;
• LM‑head — фінальний лінійний шар, який перетворює приховані стани назад у логіти над словником із 65 токенів.

Це класичний GPT‑2‑подібний дизайн, реалізований без високорівневих бібліотек трансформерів — безпосередньо в PyTorch. Такий підхід дозволяє побачити всі деталі: як дані проходять через шари, де застосовується нормалізація, як організовані резидуальні гілки.

Контекстне вікно 256 токенів: скільки пам’яті потрібно маленькій моделі

Ще один важливий гіперпараметр — розмір контекстного вікна, або block size. У цій моделі він дорівнює 256 токенів. Це означає, що під час навчання й інференсу модель одночасно бачить до 256 попередніх символів, коли прогнозує наступний.

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

Саме контекстне вікно визначає розмір матриць уваги: self‑attention у кожному шарі має працювати з матрицями розміром 256 × 256 для кожної голови. Зі збільшенням block size ці матриці ростуть квадратично, що швидко робить модель важкою для локального навчання. Обмеження на 256 токенів дозволяє зберегти обчислення в межах можливостей ноутбука чи безкоштовного GPU.

У сучасних великих LLM контекстні вікна сягають десятків і навіть сотень тисяч токенів, але це досягається за рахунок складних оптимізацій і спеціалізованих архітектурних трюків. У цьому воркшопі мета інша: показати «чистий» GPT‑2‑подібний трансформер без додаткових ускладнень, тому 256 — природний вибір для наочності й керованої складності.

Як модель вчиться: next‑token prediction і крос‑ентропія

Навчальна ціль моделі — класична для мовних моделей: передбачення наступного токена (next‑token prediction). На вхід подається послідовність із до 256 токенів, а модель має для кожної позиції передбачити, який токен іде наступним.

Форвард‑прохід працює так: послідовність індексів символів перетворюється на ембеддинги, до них додаються позиційні ембеддинги, далі дані проходять через стек із шести трансформерних блоків. На виході LM‑head генерує логіти — необмежені значення, які відповідають «сирим» оцінкам ймовірностей для кожного з 65 токенів у словнику.

Ці логіти подаються в крос‑ентропійний лосс разом із правильними наступними токенами. Крос‑ентропія вимірює, наскільки розподіл ймовірностей моделі відрізняється від «ідеального» розподілу, де вся маса ймовірності зосереджена на правильному токені. Чим ближче модель до правильного передбачення, тим менший лосс.

Кожен трансформерний блок у цьому процесі має власний модуль self‑attention, власний MLP і окремі layer norm. Саме така модульність дозволяє кожному шару поступово уточнювати представлення послідовності: увага вчиться відстежувати залежності між токенами, MLP‑частина — нелінійно трансформувати ці представлення, а нормалізація стабілізує навчання.

Важливо, що модель тренується саме як каузальний мовний модель (causal LM): при передбаченні токена на позиції t вона бачить лише токени з позицій ≤ t, а не майбутні. Це реалізується через маскування в self‑attention, яке забороняє головам уваги дивитися «вперед». Такий підхід відповідає реальній задачі генерації тексту, де майбутні слова невідомі.

Обмеження символьного підходу: чому це не шлях до SOTA‑LLM

Символьний токенайзер і маленький GPT‑2‑подібний стек — чудовий навчальний інструмент, але він має очевидні обмеження, якщо говорити про реальні промислові LLM.

Головна проблема символьного рівня — погана масштабованість семантики. Модель має вчитися не лише тому, що «sky is blue» — послідовність слів, яка часто зустрічається разом, а й тому, що «s», «k», «y», пробіл, «i», «s», пробіл, «b», «l», «u», «e» утворюють цю фразу. З погляду самоуваги, це означає, що корисні залежності розмазуються по довгих ланцюжках символів, а не концентруються на кількох токенах, як у субсловних моделях.

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

Крім того, символьні моделі неефективні на інференсі: для генерації того самого тексту вони повинні робити більше кроків, оскільки кожен крок відповідає одному символу, а не слову чи його частині. Це збільшує час відповіді й вартість обчислень.

Саме тому в реальних продуктах, на кшталт Scribe v2 від ElevenLabs чи сучасних чат‑моделей, використовуються значно складніші токенайзери й масштабніші архітектури. Але для освітнього воркшопу, де головна мета — зрозуміти принципи, а не побити бенчмарки, символьний GPT‑2‑подібний трансформер виявляється ідеальним компромісом.

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

Крихітний GPT‑2‑подібний трансформер із символьним токенайзером, контекстним вікном у 256 токенів і шістьма шарами — це не спроба створити чергову «революційну» модель. Це радше прозоре вікно в те, як насправді влаштовані сучасні LLM.

Через радикально простий токенайзер із 65 символів стає видно, як словник визначає і кількість можливих біграм, і вимоги до даних. Через embedding‑таблицю на 25 тисяч параметрів — як словник масштабу GPT‑2 миттєво перетворює цей шар на 19‑мільйонного монстра. Через шість стекових трансформерних блоків — як багатоголова увага, MLP, layer norm і резидуальні з’єднання складаються в єдину архітектуру.

Нарешті, через просту навчальну ціль next‑token prediction із крос‑ентропійним лоссом стає зрозуміло, що в основі навіть найскладніших моделей лежить та сама базова задача: передбачити наступний токен у послідовності.

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

Джерело

Training an LLM from Scratch, Locally — Angelos Perivolaropoulos, ElevenLabs

Платформа автоматизації n8n отримала великий апдейт: у систему додали нативний MCP‑сервер (Model Context Protocol). Канал KODARIK розібрав, як це працює на практиці, чим новий підхід відрізняється від попередніх рішень і чи залишається n8n актуальним інструментом для розробників автоматизацій.

MCP у n8n: від JSON до TypeScript і нова роль платформи

MCP (Model Context Protocol) — це універсальний протокол, який дозволяє AI‑агентам напряму взаємодіяти з зовнішніми інструментами. У випадку з n8n це означає, що агент (Claude, Cursor, Code, Gemini тощо) може під’єднатися до вашого інстансу й:

• створювати нові workflow;
• змінювати існуючі;
• видаляти ноди;
• запускати тести та валідацію.

Фактично агент отримує ті ж можливості, що й користувач у веб‑інтерфейсі, але працює автоматично, на основі текстових інструкцій.

Раніше подібний сценарій уже був можливий завдяки неофіційному community‑MCP‑серверу з GitHub. Він дозволяв генерувати базові робочі процеси, але здебільшого це були «каркаси», які вимагали години ручного доопрацювання. Часто виявлялося швидше зібрати workflow з нуля.

Ключова технічна зміна нового нативного MCP — перехід від генерації JSON до генерації TypeScript‑коду, з якого вже формується workflow n8n. Це важливо з кількох причин:

• JSON крихкий для великих схем. У складних workflow багато вкладених полів, ID, зв’язків між нодами. Будь‑яка дрібна помилка в структурі — і весь процес ламається.
• TypeScript краще знайомий моделям. Сучасні LLM навчені на величезних обсягах коду з інтернету, де TypeScript представлений значно ширше, ніж специфічний JSON‑формат n8n.
• Легше дебажити й перевіряти. Код можна розбивати на частини, виправляти помилки, запускати валідацію до того, як результат потрапить у сам n8n.

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

• «сховище» та середовище виконання workflow;
• інтерфейс для перегляду, логування й ручних правок;
• інструмент, яким керує AI‑агент, а людина виступає архітектором системи.

Як працює новий MCP‑сервер: валідація, тести, ітерації

Офіційний MCP‑сервер у n8n вміє не лише створювати чи оновлювати workflow, а й:

• валідувати їх перед збереженням;
• запускати тести;
• генерувати тестові дані, якщо потрібно;
• читати помилки виконання й намагатися їх виправити.

Типовий цикл виглядає так:

1. Агент генерує TypeScript‑опис робочого процесу.
2. MCP‑сервер валідує результат.
3. Якщо валідація падає — агент вносить правки й повторює спробу.
4. Workflow запускається з тестовими даними.
5. У разі помилки виконання агент аналізує лог, виправляє код і знову запускає.

Це наближає роботу до сучасної парадигми AI‑агентів: багато ітерацій «створити → перевірити → виправити», поки результат не стане прийнятним. Важливо, що це не гарантує ідеальний workflow з першого разу, але суттєво зменшує кількість базових помилок і ручної рутини.

Налаштування MCP у n8n: безпека та інтеграція з агентами

Щоб скористатися новим MCP‑сервером, потрібна версія n8n 0.218.4 або вище. Перевірити це можна в меню:

Settings → Usage and plan — у лівій частині відображається версія інстансу.

Далі в меню з’являється пункт Instance level MCP:

1. Увімкнути MCP‑сервер перемикачем.
2. Обрати, до яких workflow агент матиме доступ.

За замовчуванням MCP не бачить усі процеси — це зроблено з міркувань безпеки. Продакшн‑workflow можна залишити недоступними для агента, щоб уникнути випадкових змін. У список доступних автоматично потраплятимуть усі нові процеси, створені через MCP.

Для підключення агента:

1. У вікні Connection Details згенерувати Access Token.
2. Скопіювати конфігурацію MCP‑сервера.
3. Вставити її в конфіг‑файл агента (наприклад, у mcp.json для Claude) або просто надіслати агенту команду на підключення з цією конфігурацією.

Перевірити підключення можна командою /mcp (у випадку Claude в терміналі) — у списку має з’явитися n8n MCP. Якщо потрібна автентифікація, агент відкриє посилання для авторизації, після чого підтвердить успішний логін.

Практичний тест: два складних workflow за 25 хвилин

Щоб перевірити, наскільки новий MCP‑сервер придатний для реальних задач, було поставлено нетривіальне завдання: побудувати систему для аналізу YouTube‑каналу та подальшого пошуку по вмісту відео через Telegram‑бота.

Завдання для агента

Потрібно було створити два пов’язані workflow, які:

1. Збирають нові відео з YouTube‑каналу за розкладом.
2. Відфільтровують шорти та вже оброблені ролики.
3. Завантажують транскрипти через Apify.
4. Повертаються не лише тексти, а й фрази з таймкодами.
5. Обробляють транскрипти:
6. розбивають на чанки;
7. векторизують через Google Gemini Embedding;
8. зберігають у Supabase Vector Store.
9. Відстежують статус обробки кожного відео,
   щоб уникнути дублювання роботи.
10. У підсумку стек мав виглядати так:
    n8n + YouTube API + Apify + Supabase + Google Gemini Embedding.

Для виконання використовувалася модель Claude Sonnet 4.6 як агент. Від Opus відмовилися через обмеження п’ятигодинного ліміту — очікувалося, що складне завдання може його «з’їсти».

Результат роботи агента

• На виконання пішло приблизно 21–22 хвилини (з них ~17 хвилин безпосередньо в активній сесії, решта — через зависання й перезапуск).
• Було витрачено 77% п’ятигодинного ліміту Claude Pro.
• Заповнено майже половину контекстного вікна на 200 000 токенів.

Агент створив два окремі workflow:

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

У схемах були відсутні креденшли (YouTube, Supabase, Apify) — їх довелося додати вручну, що логічно з точки зору безпеки. Агент залишив у workflow текстові інструкції, які саме таблиці створити в Supabase і які SQL‑запити виконати.

Після:

• додавання всіх креденшлів;
• створення таблиць у Supabase;
• підключення webhook між двома workflow —

процеси успішно відпрацювали: ноди позначилися зеленим, у базі з’явилися потрібні записи. Для завершення системи залишалося лише додати Telegram‑бота, який би звертався до векторної бази й повертав користувачам посилання на потрібні фрагменти відео з точністю до секунди.

Порівняння з ручною розробкою

Оцінка витрат часу:

• Ручна розробка двох таких workflow — орієнтовно 1–1,5 години.
• З MCP‑сервером:
• ~25 хвилин роботи агента;
• ~20 хвилин на додавання креденшлів і виконання SQL‑запитів.

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

Плюси, мінуси й актуальність n8n у 2026 році

Переваги нового MCP‑підходу

• Реально працюючий нативний MCP. На відміну від community‑рішень, новий сервер видає не просто «каркас», а близький до робочого результат, який потребує мінімальних правок.
• Прискорення розробки. Особливо помітно на складних workflow з великою кількістю інтеграцій.
• Краще використання можливостей LLM. Перехід на TypeScript робить процес генерації й виправлення схем більш стабільним.
• Безпечніший доступ. Можна чітко обмежити, до яких workflow агент має доступ, не ризикуючи продакшн‑процесами.

Недоліки й обмеження

• Високе споживання токенів. Навіть без флагманської моделі Opus на один складний проєкт може піти більша частина ліміту.
• Тривалий час виконання. 20+ хвилин на створення двох workflow — це відчутно, якщо потрібно часто ітеративно змінювати автоматизації.
• Необхідність ручної участі. Креденшли, структура бази, архітектура системи — усе це все одно залишається на розробнику.

Чи актуальний n8n зараз?

Попри думку, що n8n «втратив хайп» і став менш потрібним, практика показує інше:

• інструмент активно розвивається (нативний MCP — тому підтвердження);
• залишається зручним для швидкого прототипування й тестування ідей;
• підходить як для особистих задач, так і для клієнтських автоматизацій.

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

Джерело

https://www.youtube.com/watch?v=qqCeCQi3g4I

Коли творців багатства плутають із винними: чому суспільний наратив про успіх зламаний

У розмові на подкасті 20VC засновник і CEO Shopify Тобіас Лютке — людина, яка понад два десятиліття будує одну з найуспішніших технологічних компаній світу, — виходить далеко за межі теми бізнесу й AI. Він говорить про те, як суспільство сьогодні ставиться до багатства, успіху та людей, які створюють реальну економічну цінність. Його теза проста й незручна: ми критикуємо не тих, кого треба, і робимо це так, що відбиваємо охоту в наступного покоління щось будувати.

Коли більше ресурсів — це більше уваги, але приціл збитий

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

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

У публічному просторі в один кошик часто потрапляють:

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

Зовні всі вони — «дуже багаті люди». Але з точки зору впливу на реальну економіку, інновації та добробут суспільства це принципово різні ролі. Саме цю різницю, вважає Лютке, сучасні наративи системно розмивають.

Плутанина між творцями цінності та рентієрами

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

У цій логіці немає місця для базових запитань:

• Чи створює ця людина або компанія нові продукти, сервіси, інфраструктуру, які роблять життя інших кращим, дешевшим, ефективнішим?
• Чи їхній бізнес-моделью є доступ до регулятора, монополія, інформаційна асиметрія або складні фінансові інструменти, які мало хто розуміє?

Коли ці відмінності ігноруються, у публічній дискусії з’являється зручна, але хибна картина: «усі багаті однакові». У ній засновник, який 20 років живе в режимі постійного ризику, відповідальності та високої варіативності, виглядає так само підозріло, як і той, хто просто вміло монетизує регуляторні прогалини.

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

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

Культура, яка не любить масштаб: як успіх стає підозрілим

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

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

У результаті формується дивна моральна географія:

• маленький, але неефективний або навіть шкідливий проєкт може отримувати позитивне висвітлення, бо «звучить правильно»;
• велика, але продуктивна компанія, яка створює реальну цінність, автоматично потрапляє в категорію «підозрілих», незалежно від того, як саме вона працює.

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

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

Як зламані наративи відлякують майбутніх засновників

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

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

У традиційних корпораціях, каже Лютке, такі люди зазвичай «не проходять відбір». Вони незручні, конфліктні, прямо називають речі своїми іменами, руйнують комфортні ілюзії й загрожують кар’єрам тих, хто навчився жити в системі компромісів і політичної обережності. Їх рідко підвищують, вони часто йдуть — і нерідко засновують власні компанії.

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

Меседж, який вони чують, приблизно такий:

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

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

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

Лідер як «джерело тепла» проти холодної моралізаторської оптики

Окремий пласт критики Лютке спрямований на те, як культура уявляє собі «правильного лідера». Більшість естетики лідерства, каже він, приходить не з реального досвіду, а з кіно й ретельно відполірованих публічних образів. У цій естетиці лідер — завжди врівноважений, раціональний, передбачуваний, майже беземоційний.

Реальність, якщо судити з біографій засновників великих компаній, зовсім інша. Лютке згадує історію засновника IBM Томаса Вотсона, де кожна зустріч описується як «феєрверк». Справжні будівничі часто емоційні, різкі, непередбачувані. Вони створюють напругу, а не згладжують її.

У своїй власній моделі лідерства Лютке використовує метафору «екзотермічності»: великий лідер має бути джерелом тепла для компанії. Це означає не лише енергію й драйв, а й готовність брати на себе удар, «прикривати» команду від зовнішнього тиску, приймати непопулярні рішення, які в короткостроковій перспективі виглядають погано, але в довгостроковій — створюють цінність.

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

У поєднанні з уже згаданою плутаниною між продуктивним і непродуктивним багатством це створює ще одну пастку: замість того, щоб вимагати від лідерів результатів і чесності щодо реального стану справ, суспільство починає вимагати від них насамперед відповідності естетичним стандартам «правильного» лідерства. А це, на думку Лютке, поганий критерій відбору.

Довгострокове мислення проти короткострокового обурення

Ще один вимір зламаних наративів — часовий горизонт. Лютке багато говорить про те, що справжнє будівництво компанії — це постійний «маршмелоу-тест»: щоденний вибір між тим, щоб «з’їсти зефірку зараз» (показати гарні короткострокові цифри, уникнути конфлікту, зробити популярний жест) і тим, щоб чекати на дві зефірки потім (інвестувати в продукт, прийняти непопулярне рішення, витримати період поганих показників заради довгострокового результату).

Для засновника публічної компанії цей вибір особливо болючий: ринок, аналітики, медіа, політики — усі дивляться на короткі інтервали. Кожен квартальний звіт, кожна новина, кожен твіт може стати приводом для хвилі обурення або захоплення.

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

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

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

Чому важливо відремонтувати наративи, а не лише інституції

Критика Лютке не зводиться до скарг на «несправедливі медіа» чи «заздрісне суспільство». Він фактично говорить про те, що культурні наративи — це така сама частина інфраструктури, як закони, ринки чи технології. Вони визначають, які ролі в суспільстві вважаються почесними, які — підозрілими, а які — взагалі невидимими.

Сьогоднішня конфігурація, на його думку, має кілька небезпечних ефектів:

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

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

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

Лютке не пропонує простих рецептів. Але з його аргументації випливає кілька очевидних напрямів «ремонту» наративів:

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

важливо змістити фокус критики з естетики (як людина говорить, виглядає, які символічні жести робить) на практику (які рішення приймає, які інституції будує або руйнує, які наслідки це має в довгостроковій перспективі);

суспільству варто прийняти, що люди, які будують великі речі, часто будуть «дивними», «складними» й «високоваріативними» — і навчитися відрізняти небезпечну токсичність від просто незручної, але продуктивної відмінності.

Висновок: повернути повагу до тих, хто справді будує

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

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

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

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

Джерело

YouTube — Shopify CEO on How AI is a Scapegoat for Mass Layoffs & Trump Derangement Syndrome in Canada

У новому випуску каналу Tech With Tim розробник і контентмейкер Тім показує практичний шлях, як перетворити потужні, але незручні у використанні моделі зображень Nano Banana Pro та Nano Banana 2 на керований інструмент у щоденному робочому середовищі. Він поєднує їх із Claude Code, Google Gemini API, голосовим диктуванням та хмарним робочим простором Skywork, будуючи повноцінний конвеєр автоматизованої генерації зображень.

Цей матеріал зосереджується на трьох ключових речах: як правильно підняти Nano Banana через Gemini API, як не «спалити» бюджет на токени, і як організувати робочий процес за допомогою Claude Code, Whisper Flow та Skywork.

Від сайту Nano Banana до API: чому потрібен Google AI Studio

Базовий сценарій роботи з Nano Banana знайомий більшості користувачів генеративної графіки: відкрити сайт, ввести текстовий промпт, отримати картинку, повторити. Це повільно, незручно для складних проєктів і майже не масштабується.

Щоб перетворити Nano Banana 2 на частину автоматизованого пайплайна, Тім обходить вебінтерфейс і звертається до моделі через Gemini API. Для цього потрібен Google AI Studio — саме він виступає точкою входу до API Google Gemini, через який і доступні моделі зображень, включно з Nano Banana.

Перший крок — створити обліковий запис у Google AI Studio, якщо його ще немає. Після входу користувач потрапляє в playground, де можна тестувати моделі вручну. Але для програмного доступу потрібен API‑ключ. У інтерфейсі AI Studio є окремий розділ «Get API key» (у нижній частині навігації), де створюється новий ключ для проєкту.

Тім радить одразу дати ключу осмислену назву — наприклад, «Gemini API key» або «Claude API key», якщо він буде використовуватися саме з Claude Code. Після створення ключа його можна скопіювати, але важливо не ділитися ним з іншими та не публікувати в коді чи скріншотах.

На цьому етапі багато хто очікує, що можна одразу почати генерувати зображення. Але для Nano Banana через API цього недостатньо: потрібна активна платна підписка.

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

Генерація зображень через Gemini API — це не безкоштовна функція. Для виклику Nano Banana з коду потрібно налаштувати білінг у Google AI Studio.

Після створення API‑ключа інтерфейс пропонує перейти до налаштування оплати. Користувач має підключити банківську картку та вказати платіжну адресу. Після цього активується «paid tier» — платний рівень, який дозволяє виконувати запити до моделей зображень. Google зазвичай надає стартові безкоштовні кредити, але Тім прямо підкреслює: розраховувати на повністю безкоштовну роботу з просунутою генерацією зображень не варто. Це платна послуга, і до неї потрібно ставитися як до будь-якого іншого хмарного ресурсу.

Щоб уникнути неприємних сюрпризів, Тім одразу переходить до розділу контролю витрат. У Google AI Studio є можливість встановити spending cap — верхню межу витрат для конкретного проєкту. Він задає ліміт у 10 доларів і рекомендує робити так само всім, хто експериментує з Nano Banana через агентів на кшталт Claude Code або термінальні скрипти.

Логіка проста: коли ви віддаєте API‑ключ у руки автоматизованих інструментів, ви втрачаєте повний ручний контроль над кількістю запитів. Агент може запускати десятки генерацій паралельно, а помилка в налаштуваннях або невдалий цикл легко перетворюється на сотні запитів за короткий час. Spending cap у 10 доларів — це своєрідний запобіжник: навіть якщо щось піде не так, витрати не вийдуть за межі комфортної суми.

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

Безпечний доступ до Gemini: змінна середовища замість «ключа в чаті»

Коли API‑ключ створено і білінг налаштовано, наступне завдання — передати цей ключ у робоче середовище, де запускається код, що викликає Nano Banana через Gemini API. У демонстрації Тіма таким середовищем виступає Claude Code — десктопний застосунок, який він використовує як основний інтерфейс для запуску навичок (skills) і побудови автоматизованих пайплайнів.

Щоб Nano Banana‑skill у Claude Code міг звертатися до Gemini, ключ потрібно зробити доступним для Python‑скрипта, який викликає API. Тім використовує стандартний підхід: експортує ключ як змінну середовища з назвою GEMINI_API_KEY.

Це означає, що в операційній системі задається змінна, яку потім читає скрипт. Такий спосіб має дві важливі переваги. По‑перше, ключ не зберігається в коді або конфігураційних файлах, які можуть потрапити в репозиторій чи лог. По‑друге, один і той самий код можна запускати в різних середовищах (локально, у хмарі, на CI) просто змінюючи значення змінної середовища, не переписуючи сам скрипт.

Тім окремо застерігає від спокуси зробити «по‑швидкому» і просто вставити ключ прямо в чат Claude Code. У такому разі ключ опиняється у середовищі Anthropic, а не лише на вашій машині. Якщо користувач усе ж таки йде цим шляхом, він наполягає: робити це варто тільки з тимчасовим ключем, який буде видалено одразу після експериментів.

Це зауваження добре ілюструє нову реальність роботи з AI‑інструментами: розробники взаємодіють не лише з одним постачальником, а з цілою екосистемою сервісів — Google, Anthropic, сторонні навички, хмарні платформи. Кожен з них має власні політики зберігання даних, і API‑ключі в такій системі стають критичним активом, який потрібно захищати не менше, ніж паролі до продакшн‑баз.

Claude Code як центр керування Nano Banana

Хоча Nano Banana доступний через вебінтерфейс, Тім показує інший підхід: зробити Claude Code центральним «пультом керування» для всієї роботи із зображеннями. Він використовує десктопну версію Claude Code як основний інструмент, де запускає навички, пише запити, переглядає результати й оркеструє весь пайплайн.

У цьому робочому просторі встановлюються спеціальні skills — розширення, які додають Claude Code нові можливості. Для Nano Banana Тім використовує два типи навичок.

Перший — JSON‑промптер для Nano Banana, знайдений на MCP Market. Він орієнтований на створення маркетингових зображень, UI‑макетів, інфографіки та подібних візуалів. Навичка описує, коли її варто застосовувати, а коли ні, і містить схему JSON із полями на кшталт кадрування, освітлення, поверхня, матеріали та інші параметри сцени. Це дозволяє перетворювати прості текстові запити на структуровані, дуже детальні промпти для моделі зображень.

Другий — власний Nano Banana‑skill, який обгортає Python‑скрипт для виклику Gemini 3.1 image generation API. Саме цей скрипт фактично звертається до Nano Banana, використовуючи GEMINI_API_KEY. Навичка підтримує параметри на кшталт референс‑зображень, роздільної здатності та співвідношення сторін, що робить її придатною не лише для генерації «з нуля», а й для редагування існуючих картинок.

Тім встановлює JSON‑промптер глобально в Claude Code, щоб він був доступний усім «агентам», які виявляє система. Для цього він використовує команду npx skillfish add <username>/claude-code-nano-banana-skills у терміналі. Після інсталяції навичка з’являється в інтерфейсі Claude Code, і її можна викликати через слеш‑команди.

Саме десктопна версія Claude Code стає для нього головним робочим середовищем: тут він одночасно керує навичками, пише запити, переглядає JSON‑схеми й запускає генерацію зображень. У результаті користувач працює з Nano Banana не через кілька вкладок браузера, а через один інтерфейс, який уже використовується для коду, тексту й аналітики.

Голос замість клавіатури: Whisper Flow для швидких промптів

Окремий елемент цього робочого процесу — інструмент AI‑диктування Whisper Flow (у відео згадується як Wispr Flow). Тім використовує його для прискорення створення промптів усередині Claude Code.

Замість того щоб вручну набирати довгі, деталізовані описи сцен, він просто проговорює вимоги вголос. Whisper Flow перетворює мовлення на текст, який потім можна передати JSON‑промптеру або безпосередньо Nano Banana‑skill. Це особливо корисно, коли йдеться про складні композиції, де потрібно описати кілька об’єктів, фон, стиль, освітлення, матеріали й інші нюанси.

У поєднанні з JSON‑схемою це створює цікаву зв’язку: людина формулює задум у природній мові, Whisper Flow перетворює його на текст, Claude Code за допомогою JSON‑промптера структурує цей текст у формальний опис, а Nano Banana через Gemini API генерує зображення.

Такий підхід зменшує бар’єр входу для складних промптів. Багатьом користувачам легше проговорити ідею, ніж одразу сформулювати її у вигляді детального текстового опису з десятками параметрів. AI‑диктування перетворює цей «потік свідомості» на матеріал, з яким уже може працювати промптер‑навичка.

Skywork як хмарний аналог локального пайплайна

Частина відео присвячена Skywork — сервісу, який виступає спонсором випуску. Але в контексті Nano Banana він цікавий не лише як рекламна вставка, а як приклад того, як подібні пайплайни можуть працювати в хмарі без локальної конфігурації.

Тім описує Skywork як «zero‑configuration» хмарний AI‑workspace. Користувач отримує виділену хмарну віртуальну машину, готову до роботи «з коробки». Керувати нею можна з браузера або навіть через WhatsApp чи Telegram.

Усередині Skywork є власна система Skills — не прості плагіни, а вбудовані продуктивні інструменти для роботи з документами, слайдами, зображеннями, таблицями, сайтами й навіть багатодоріжковим відео. Ключова ідея — їх можна комбінувати в одному сценарії. У прикладі Тіма один запит запускає одразу кілька навичок: збір даних про інфлюенсерів, побудову бюджетної таблиці та створення презентації.

Ще одна важлива деталь — підтримка різних моделей. У Skywork можна призначати конкретні моделі для різних завдань: GPT 5.4 або 5.5 Pro для складного коду, Claude Opus 4.6 для глибокого аналізу тексту, Gemini 3.1 Pro для генерації зображень і відео. Або ж дозволити системі автоматично маршрутизувати запити до найвідповіднішої моделі.

У контексті Nano Banana це означає, що той самий тип робочого процесу, який Тім демонструє локально через Claude Code, можна відтворити в хмарі без налаштування серверів, Docker‑контейнерів чи VPN. Для команд, які вже витрачають суттєві суми на окремі підписки для дизайну, аналізу даних і створення сайтів, Skywork позиціонується як спосіб об’єднати ці витрати в один сервіс і водночас отримати гнучкіший AI‑стек.

Демо‑сайт і відкриті ресурси: як відтворити пайплайн

Щоб зробити процес налаштування Nano Banana більш прозорим, Тім створює демонстраційний сайт, поки записує вступ до відео. Claude Code у цей час генерує зображення через Nano Banana і збирає з них повноцінний лендінг.

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

• JSON‑skill для Nano Banana з MCP Market,
• документацію Gemini API для генерації зображень,
• сторінку Google AI Studio для створення API‑ключів,
• посилання на завантаження Nano Banana‑skill.

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

Висновок: Nano Banana як сервіс, а не сайт

У підсумку показаний Тімом підхід змінює спосіб взаємодії з моделями на кшталт Nano Banana 2. Замість того щоб сприймати їх як окремий сайт для «погратися з картинками», він перетворює Nano Banana на сервіс у складі більшого робочого процесу.

Google AI Studio та Gemini API забезпечують технічний доступ і білінг, spending cap захищає від неконтрольованих витрат, змінна середовища GEMINI_API_KEY — від витоку ключів. Claude Code стає центральним інтерфейсом, де навички керують як створенням структурованих JSON‑промптів, так і викликом самої моделі. Whisper Flow прискорює формування складних запитів, а Skywork демонструє, як подібні сценарії можуть масштабуватися в хмарі без локальної інфраструктури.

Усе це разом показує, що сучасна генерація зображень — це вже не про «ввести промпт у віконце», а про побудову керованих, безпечних і економічно прогнозованих AI‑пайплайнів, де Nano Banana — лише один із потужних, але добре інтегрованих компонентів.

Джерело

Claude Code + Nano Banana 2 = This Changes Everything

Штучний інтелект стрімко входить у всі сфери економіки США, але система працевлаштування та перекваліфікації виявляється до цього неготовою. У виступі на TED міністерка торгівлі США та колишня губернаторка Род-Айленду Джина Раймондо окреслила ризики масового витіснення працівників і запропонувала базові принципи політики, які мають пом’якшити удар.

Масштаб загрози: «AI-вразливі» робочі місця

За оцінками, які наводить Раймондо, десятки мільйонів американців працюють на посадах, вразливих до автоматизації за допомогою ШІ. Йдеться не про окремі галузі чи вузькі професійні групи:

• усі вікові категорії
• різні регіони країни
• працівники з різним рівнем доходу
• люди з різною освітою

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

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

Чому «загальмувати ШІ» та UBI не працюють як стратегія

У політичних і технологічних дебатах сьогодні домінують дві крайні позиції.

1. «Зупинити або жорстко загальмувати ШІ»

Прихильники цієї лінії закликають до надмірного регулювання або фактичної паузи у розвитку технологій. Раймондо вважає цей підхід хибним з двох причин:

• він позбавляє американців потенційних переваг ШІ — від зростання продуктивності до нових робочих місць, які можуть з’явитися внаслідок технологічного прориву;
• він відкриває шлях конкурентам: надто жорстке регулювання в США створює ризик, що Китай та інші країни вирвуться вперед у «гонці ШІ».

2. Універсальний базовий дохід як відповідь на автоматизацію

Інша популярна ідея — універсальний базовий дохід (UBI), який мав би компенсувати втрату роботи. Але Раймондо наголошує: робота — це не лише зарплата. Це:

• гідність
• відчуття мети
• професійна й особиста гордість

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

Як змінити правила гри для освіти і бізнесу

Замість крайнощів пропонується системна перебудова стимулів — як для держави, так і для приватного сектору.

Освіта і перекваліфікація за результатами, а не за фактом існування

Ключова теза: уряд має фінансувати школи та програми навчання, орієнтуючись на їхні результати. Йдеться про зміну логіки:

• не просто підтримувати інституції, бо вони історично існують;
• а вкладати гроші туди, де навчання реально допомагає людям отримати роботу або перейти в нову сферу.

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

Нові стимули для компаній: не звільняти, а переорієнтовувати

Сьогодні фінансові ринки винагороджують компанії за масові скорочення:

• компанія оголошує про звільнення великої кількості працівників;
• уже наступного дня її акції зростають у ціні.

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

Пропонований напрямок змін — пілотні програми податкових кредитів та інших економічних стимулів, які б:

• заохочували компанії до перепрофілювання працівників, а не їх звільнення;
• підтримували найм на початкові позиції, відкриваючи двері для нових кадрів;
• мотивували реінвестувати вигоди від зростання продуктивності завдяки ШІ у створення нових робочих місць.

Ідея в тому, щоб зробити для бізнесу економічно вигідним не скорочення, а інвестування в людей.

Чому це спільний інтерес усіх гравців

Раймондо попереджає: якщо не змінити підхід, країна ризикує зіткнутися з комбінацією негативних сценаріїв:

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

Водночас досягнення «захопливого потенціалу інновацій ШІ» вигідне всім — і державі, і бізнесу, і працівникам. Технологічний прогрес сам по собі не купує товари й послуги: «агенти не заходять у магазин і не купують речі», нагадує Раймондо. Потрібні люди з доходом, упевненістю в майбутньому й доступом до нових можливостей.

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

Джерело

The U.S. workforce was not built for the AI disruption, but there’s still time to prepare #TEDTalks

У спільноті AI‑інженерів усе частіше звучить одна й та сама думка: замість хитромудрих графів агентів і десятків вузлів автоматизації краще працюють максимально прості цикли. На воркшопі каналу AI Engineer цю ідею розкриває Кріс Парсонс — розробник із майже 30‑річним досвідом, колишній CTO венчурних стартапів і керівник агенції, який зараз допомагає командам впроваджувати штучний інтелект у щоденну роботу. Центральне місце в його підході займають так звані Ralph Loops — навмисно «дурні» цикли для AI‑агентів, що виконують одну задачу за раз, оцінюють результат і пробують ще раз, поки не стане краще.

Від крихких графів до одного циклу

Кілька років поспіль автоматизація з AI виглядала як складні сценарії в інструментах на кшталт n8n: десятки вузлів, гілки, умови, інтеграції з API, окремі гілки для різних типів контенту. Сам Парсонс показує свій колишній робочий процес: великий граф у n8n, який збирав його щотижневу розсилку.

Схема виглядала вражаюче: одна гілка читала статті з блогу, перевіряла, чи не публікувалися вони раніше, узагальнювала їх за допомогою AI й формувала «featured»‑матеріал. Інша гілка тягнула посилання зі списку, додавала коментарі, ще одна — керувала форматуванням. Усе це трималося на десятках вузлів і тонкій логіці переходів.

На практиці система виявилася крихкою. Майже щопонеділка о 14:00 приходило повідомлення: workflow упав. Далі — ручний дебаг, пошук, де саме в ланцюжку щось зламалося, перезапуск, виправлення. Попри те, що n8n залишався зручним інструментом для керування ключами, API й загальною оркестрацією, вартість підтримки такого графа виявилася надто високою. У якийсь момент Парсонс визнає: простіше було б просто написати розсилку вручну — і, ймовірно, вона вийшла б кращою.

Цей досвід добре ілюструє проблему складних AI‑оркестрацій. Вони виглядають як «майбутнє автоматизації», але в реальності часто перетворюються на систему, яку важко тестувати, важко змінювати й ще важче відлагоджувати. Кожна нова гілка додає не лише функціональність, а й потенційні точки відмови.

Перелом стався, коли Парсонс замінив увесь цей граф… одним скілом у Claude Code. Він просто скопіював JSON‑опис workflow з n8n, вставив у Claude і попросив: «Створи скіл на основі цього флоу». Модель згенерувала код, який тепер працює як єдиний цикл: читає інструкції, викликає потрібні інструменти, повертається на початок, знову читає інструкції, знову викликає інструменти — і так доти, доки не вирішить, що розсилку завершено.

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

Цей приклад підводить до ключової тези: будь‑яка система з AI‑агентами по суті вже є циклом. Агент читає інструкції, робить крок, оцінює стан, робить наступний крок. Якщо це й так цикл, навіщо ховати його всередині заплутаного графа? Набагато надійніше зробити цей цикл явним, простим і прозорим.

Ralph Loops: простий патерн із «Сімпсонів»

На цьому тлі з’являється концепція Ralph Loops — навмисно простого патерну для побудови AI‑агентів. Назва походить від персонажа мультсеріалу «Сімпсони» — Ральфа Віггама, який наївно повторює одну й ту саму дію, поки вона зрештою не спрацює. У цьому й суть: не хитрувати з плануванням, а дозволити моделі кілька разів поспіль спробувати виконати одну й ту саму задачу, щоразу трохи покращуючи результат.

Ідея, яку Парсонс приписує Джеффрі Гантлі, з’явилася приблизно в червні минулого року — за мірками AI це вже «давнина». Пропозиція була майже образливо простою: щоразу, коли ви закінчуєте роботу з AI над будь‑яким завданням, просто запустіть те саме ще раз із тим самим промптом. Ніяких додаткових інструкцій, ніяких складних ланцюжків — просто повтор.

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

Ralph Loop використовує цю слабкість як ресурс. Базовий патерн виглядає так: спочатку в промпті формулюється завдання — наприклад, «збудуй цю фічу в коді». Модель генерує рішення й повідомляє, що все готово. Замість того, щоб одразу приймати результат, система повторює той самий запит: «добре, тепер знову побудуй цю фічу, виконавши всі інструкції». Модель змушена ще раз «подивитися» на власний код і вимоги. У цьому другому проході вона часто помічає пропуски: не оновлений тест, не врахований параметр, відсутню гілку логіки.

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

Цей підхід навмисно не використовує складні механізми планування чи багатокрокові графи. Він спирається на просту ідею: моделі вже вміють аналізувати й покращувати власний код, якщо дати їм ще одну спробу. Ralph Loop лише формалізує цю другу, третю, четверту спробу як частину стандартного робочого процесу.

Чому простий цикл виявляється надійнішим

Аргумент Парсонса на користь Ralph Loops виходить за межі окремих прикладів. Він стосується самої архітектури систем із AI‑агентами. Якщо будь‑який агент по суті працює в циклі — читає інструкції, виконує дію, оцінює стан, повторює — то головне питання полягає в тому, наскільки цей цикл прозорий і керований.

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

Ralph Loop, навпаки, робить цикл явним і мінімалістичним. Є одна задача, один агент, один промпт (або один скіл), і є повторення. Система не намагається заздалегідь спланувати всі можливі гілки виконання. Вона покладається на те, що сучасні моделі достатньо потужні, щоб самостійно обирати наступний крок усередині цього циклу.

Перехід від графів до циклів став можливим завдяки новому поколінню моделей. Парсонс згадує, що подібні підходи «не працювали довгий час», але почали давати результат із появою моделей на кшталт GPT 5.8.x, GPT 5.12 і Claude Opus / Sonnet 4.6. Ці системи краще тримають контекст, точніше виконують інструкції й здатні протягом кількох хвилин послідовно будувати складні артефакти — від коду до повноцінних текстів.

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

Ще один аргумент — дебаг і підтримка. Коли вся поведінка агента зосереджена в одному циклі, легше зрозуміти, що пішло не так. Можна подивитися на промпт, на історію викликів інструментів, на проміжні результати. Якщо потрібно щось змінити, достатньо відредагувати інструкції або додати невелику логіку всередині циклу, а не перебудовувати цілий граф.

У цьому сенсі Ralph Loops продовжують давні принципи розробки, які Парсонс згадує зі свого досвіду agile‑консалтингу: віддавати перевагу простим, прозорим конструкціям, які легко змінювати й тестувати, замість складних архітектур, що вражають на діаграмі, але погано живуть у продакшені.

Витоки патерну та його еволюція

Парсонс чітко віддає належне авторству: перша формулювання Ralph Loop належить Джеффрі Гантлі й з’явилася приблизно в червні минулого року. Тоді це було радше спостереження, ніж повноцінний патерн: якщо після завершення роботи моделі просто повторити той самий запит, результат часто стає кращим.

На ранніх етапах Ralph Loops використовували специфічну поведінку старіших кодових моделей. Вони мали схильність «обрізати» задачу: виконувати основну частину, але пропускати деталі. Наприклад, модель могла реалізувати нову команду в CLI‑інструменті, але забути оновити help‑повідомлення або додати тест на нову опцію. Людина, перевіряючи код, легко помічала ці прогалини. Але якщо просто дати моделі ще один шанс із тим самим промптом, вона нерідко сама знаходила й виправляла пропуски.

Це зробило Ralph Loops своєрідним «автоматичним рев’юером» власного коду. Замість того, щоб одразу приймати перший результат, розробник вбудовував у процес ще одну (або кілька) ітерацій, у яких модель переглядала свою роботу. У багатьох випадках цього було достатньо, щоб довести рішення до прийнятного стану без додаткових складних механізмів контролю якості.

З часом, із появою потужніших моделей, патерн еволюціонував. Якщо спочатку Ralph Loop був радше «хаком» поверх звичайного використання AI‑асистентів, то тепер він перетворюється на базову архітектурну одиницю для побудови агентів. Замість того, щоб думати в термінах «ланцюжків» і «графів», інженери починають мислити циклами: одна задача, один агент, багато ітерацій.

Парсонс поширює цей підхід далеко за межі коду. Він говорить, що фактично «крутить» Ralph Loops 24/7 для всіх аспектів своєї роботи: листування, календар, контент, розсилки, клієнтські проєкти, програмування. У кожному випадку суть одна: сформулювати задачу, дозволити агенту пройти кілька ітерацій, оцінити результат, за потреби повторити.

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

Чому майбутнє агентів — у «дурних» циклах

Ключова теза Парсонса полягає в тому, що сучасна AI‑автоматизація має віддавати пріоритет простим циклам і навичкам, а не складним графам оркестрації. Причина не лише в надійності, а й у тому, як розвиваються самі моделі.

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

У цьому світлі Ralph Loops виглядають не як тимчасовий хак, а як фундаментальний патерн для епохи потужних LLM. Вони поєднують кілька важливих якостей.

По‑перше, прозорість. Уся логіка зосереджена в одному місці — у промпті або скілі, який виконується в циклі. Це полегшує аудит, тестування й поступове вдосконалення.

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

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

По‑четверте, відповідність реальному використанню. Більшість людей, які сьогодні активно користуються Claude Code, Codeex, Cursor та іншими інструментами, уже мислять у термінах «одна задача — один сеанс». Ralph Loop лише формалізує природну поведінку: дати моделі ще один шанс, якщо результат не ідеальний.

Це не означає, що складні оркестрації зникнуть повністю. Є класи задач, де потрібні чіткі бізнес‑процеси, суворі SLA, інтеграція з багатьма системами. Але навіть там базовою будівельною цеглиною дедалі частіше ставатиме не граф із десятків вузлів, а простий агентний цикл, який можна комбінувати з іншими такими ж циклами.

У цьому сенсі Ralph Loops — це не лише технічний патерн, а й певна філософія: замість того, щоб намагатися одразу побудувати «розумну» складну систему, краще створити «дурний» цикл, який стабільно працює, і дозволити моделям поступово робити його розумнішим.

Висновок: сила в простоті

Історія Ralph Loops — це історія про те, як реальні розробники, втомлені від крихких графів автоматизації, повертаються до базових принципів інженерії: простота, прозорість, поетапне вдосконалення. Коли Кріс Парсонс замінив свій складний workflow у n8n одним скілом у Claude Code, він не просто оптимізував власну розсилку. Він продемонстрував, що в епоху потужних LLM складність інфраструктури часто є зайвою.

Ralph Loops, названі на честь наївного персонажа з «Сімпсонів», виявляються напрочуд дорослим підходом до побудови AI‑систем. Вони приймають обмеження моделей, перетворюють їх на ресурс і будують навколо цього дисципліну роботи: одна задача, один цикл, багато ітерацій.

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

Джерело

Відео на YouTube: Ralph Loops: Build Dumb AI Loops That Ship — Chris Parsons, Cherrypick

У сучасних технологічних компаніях кордони між ролями стрімко розмиваються. У розмові на каналі The Pragmatic Engineer творці Pi та Flask — Маріо Цехнер і Армін Ронахер — обговорюють тенденцію, коли продакт-менеджери, маркетинг і навіть сейлз-команди безпосередньо втручаються в інженерні процеси: від правок на сайті до фактичних pull request’ів у репозиторій продукту.

Коли «не-інженери» заходять у код

Те, що ще кілька років тому виглядало б екзотикою, стає нормою:
– продакт-менеджери надсилають pull request’и;
– маркетингова команда самостійно змінює сайт;
– команда продажів збирає демо-функціонал, якого формально не існує в продукті.

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

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

Чому «усі можуть усе» без процесів — погана ідея

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

• Прозорих правилах внесення змін. Хто має право змінювати продакшн, а хто — лише демо чи тестові середовища.
• Рев’ю та валідації. Навіть якщо pull request створює продакт-менеджер, остаточне слово має залишатися за технічною командою.
• Синхронізації очікувань. Якщо сейлз показує клієнтам демо-функцію, має бути зрозуміло, чи й коли вона з’явиться в реальному продукті.

Без цього «участь усіх у всьому» перетворюється на хаос. Формально кожен може внести свій вклад, але немає механізму, який би гарантував цілісність продукту й передбачуваність його поведінки.

Нові ролі, старі принципи

Участь неінженерів в інженерних процесах — не тимчасовий тренд, а новий робочий стандарт. Проте базові принципи розробки залишаються незмінними:

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

Фактична участь продакт-менеджерів у коді — це логічний крок у бік більш інтегрованих команд. Але без чітких «рейок» процесу така інтеграція швидко виходить за межі керованості.

Джерело

YouTube: Mario & Armin: Product managers are now sending pull requests

Коли користувачі вже не можуть увійти, знайти товар чи завершити оплату, команда фактично опиняється в режимі інцидент‑респонсу. Канал IBM Technology пропонує інший підхід: синтетичний моніторинг як спосіб виявляти проблеми ще до того, як справжній трафік натрапить на зламані сценарії.

Що таке синтетичний моніторинг

Синтетичний моніторинг — це проактивний спосіб контролю цифрових сервісів через імітацію дій користувача та вимірювання результатів.

Йдеться не про аналіз реальних логів, а про запуск заздалегідь прописаних сценаріїв:

• завантаження сторінки;
• виклик API;
• проходження ключового бізнес‑шляху (логін → пошук → кошик → оплата).

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

Навіщо це DevOps-командам

Від «побачимо по трафіку» до проактивного контролю

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

• отримувати алерти, коли сайт, сервіс або регіон стають недоступними;
• ловити збої в критичних потоках (логін, пошук, checkout) до появи записів у логах чи звернень у підтримку;
• бачити деградацію продуктивності та часткову недоступність, коли сервіс «ніби працює, але користуватися неможливо».

«Shift left» для тестування і CI/CD

Один із ключових плюсів — можливість використовувати ті самі синтетичні тести і в продакшні, і в CI/CD‑конвеєрі. Це дає кілька ефектів:

• узгодженість умов тестування до й після релізу;
• менше «фальшивої впевненості», коли переддеплойні тести не відповідають реальним сценаріям;
• виявлення регресій, поламаних залежностей і падіння продуктивності до потрапляння змін у продакшн.

CI/CD‑інструмент просто викликає запуск визначених синтетичних тестів і продовжує деплой лише в разі їх успішного проходження.

Підготовка до запуску в нових регіонах

Коли в новому ринку ще немає реального трафіку, оцінити якість досвіду складно. Синтетичні тести дозволяють:

• виміряти доступність і затримки з потрібних геолокацій;
• задати базові показники доступності та латентності;
• переконатися, що сервіс укладається в прийнятні параметри до старту кампаній і залучення користувачів.

Контроль SLO та продуктивності

Синтетичні сценарії можна напряму прив’язати до сервісних цілей (SLO) і порогів продуктивності. Це перетворює абстрактні «має бути швидко» на вимірювані метрики, які постійно перевіряються автоматично.

Три ключові сценарії використання

Синтетичний моніторинг умовно ділиться на три великі категорії.

1. Uptime та базова доступність

Ці перевірки відповідають на запитання «чи взагалі сервіс досяжний?» і включають:

• базовий тест досяжності (is it reachable?);
• вимірювання затримки відповіді;
• час і коректність DNS‑резолюції;
• валідність SSL‑сертифіката.

Це фундамент, без якого інші метрики втрачають сенс.

2. Перевірка API

Для сервісів, де основна логіка винесена в API, синтетичні тести можуть:

• викликати ключові ендпоїнти;
• перевіряти статус‑коди та час відповіді;
• робити асерти важливих полів у payload (чи повертаються потрібні дані, чи немає критичних помилок у структурі).

Такі перевірки дозволяють виявляти як повні відмови, так і часткові збої в бізнес‑логіці.

3. Транзакційні та «journey»‑тести

Найближчий до реального досвіду рівень — це повні користувацькі сценарії:

• вхід у систему;
• виконання пошуку;
• додавання в кошик;
• оформлення замовлення тощо.

Вони виявляють ситуації «формально все працює, але користуватися неможливо»: наприклад, логін проходить, але дашборд не завантажується, або checkout зависає на останньому кроці.

На що варто налаштовувати алерти

Алерти мають бути сигналом, а не шумом. Базовий набір, з якого варто почати:

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

2. Перевищення порогів латентності
   Алерти при перетині заздалегідь визначеного ліміту часу відповіді — коли «занадто повільно, щоб це було прийнятно для користувача».

3. Функціональні асерти
   Наприклад: логін успішний, але далі дашборд не вантажиться. Формально endpoint відповів, але функціонально сценарій зламаний.

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

5. Сигнали безпеки та довіри
   Закінчення строку дії сертифіката, проблеми з DNS, аномально повільна резолюція — усе це варто виносити в окремі алерти, бо такі збої напряму б’ють по довірі до сервісу.

Як розгорнути синтетичний моніторинг без зайвої складності

Початковий запуск не обов’язково має бути масштабним. Базовий план впровадження виглядає так:

1. Визначити 3–5 найкритичніших робочих потоків
   Це можуть бути логін, пошук, оформлення замовлення, ключові дії в особистому кабінеті.

2. Додати перевірки доступності для доменів і API
   Uptime‑тести, DNS, SSL — мінімальний набір для розуміння, чи сервіс «живий».

3. Наростити повні journey‑тести з важливих регіонів
   Обрати географії, які найбільше впливають на бізнес, і запускати з них повні сценарії.

4. Інтегрувати тести в CI/CD
   З часом — зробити синтетичні перевірки обов’язковим етапом перед деплоєм, щоб ловити проблеми до потрапляння змін у продакшн.

Висновок

Синтетичний моніторинг перетворює моніторинг із реактивного на проактивний. Він допомагає:

• вчасно виявляти відмови та деградацію продуктивності;
• вимірювати якість роботи сервісу в різних регіонах;
• зменшувати ризик релізу «зламаного» або повільного оновлення;
• контролювати критичні сигнали безпеки — від DNS до сертифікатів.

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

Source

YouTube: Synthetic Monitoring Explained: A Guide to Reliable DevOps Workflows

У розмові на подкасті 20VC з Гаррі Стеббінгсом засновник і CEO Shopify Тобі Лютке окреслює доволі радикальний погляд на те, хто такі засновники компаній, що таке хороша робота, яким має бути лідер — і чому грудень та поява нових інструментів ШІ «змінили все» для інженерів.

Засновники як «фундаментально божевільні» та страх перемоги

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

Він протиставляє дві групи:

• тих, хто боїться програти;
• і тих, хто боїться… виграти.

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

Міфологія лідерства проти реальності

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

Він пропонує іншу оптику:

• Лідер — це не герой із фільму, а функція в системі, яка має забезпечити роботу всієї організації.
• Чим більше ресурсів і влади у компанії чи людини, тим більше вона заслуговує на пильну перевірку й критику. Багатство й масштаб — це не привід для захоплення, а причина для посиленої суспільної уваги.

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

«У мене ця робота, щоб інші мали роботи, які я сам хотів би мати»

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

Це підводить до критики «робіт-суцільних завдань». На його думку:

• Люди, чия робота зводиться лише до виконання нескінченного набору дрібних тасків, не мають по-справжньому хороших робіт.
• Хороша робота — це не просто набір задач, а діяльність із сенсом, автономією та простором для мислення.

Фактично йдеться про те, що компанії мають відповідальність не тільки створювати робочі місця, а й робити ці місця змістовними. Інакше — це просто конвеєр завдань, де люди легко замінні.

Філантропія, що «звучить добре», проти того, що працює

Лютке різко висловлюється про те, як суспільство оцінює «добрі вчинки» бізнесу та багатих людей. Він вважає, що:

• Світ надто часто віддає перевагу ініціативам, які добре звучать, замість тих, які реально працюють.
• Сам факт «віддати гроші» не є чеснотою, якщо це не призводить до правильних наслідків.

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

ШІ, який «змінив усе»: інженери без коду

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

• «Грудень змінив усе» — саме тоді, за його словами, стався перелом у тому, як працюють команди розробки.
• «Opus змінив усе» — йдеться про інструмент або технологію, яка радикально вплинула на процес створення продукту.

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

• від ручного написання коду — до проєктування систем, постановки задач, роботи з інструментами ШІ;
• від «виробництва» коду — до управління складними технічними й продуктовими рішеннями.

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

Джерело

Подкаст 20VC з Тобі Лютке, CEO Shopify: https://www.youtube.com/watch?v=xByFHB-e6pE

Системний дизайн мобільних застосунків давно вийшов за межі вибору «MVVM чи MVI» та улюбленої бібліотеки для мережі. Для розробників, які готуються до співбесід або проєктують складні продукти, ключовим стає інше запитання: що саме має робити застосунок і за яких умов він повинен це робити.

У розмові про системний дизайн мобільних застосунків Android‑розробник та автор освітнього контенту Філіп Лакнер розкладає цей процес на зрозумілі кроки: від формулювання вимог до вибору архітектури й технічних рішень. Центральна ідея — чітко розділяти функціональні та нефункціональні вимоги й усвідомлено будувати навколо них дизайн системи.

З чого починається системний дизайн: не з коду, а з вимог

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

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

Для старших або менш технічно підкованих користувачів доводиться закладати інші UX‑принципи: більші шрифти, простіші сценарії, мінімум прихованих жестів, очевидні кнопки й підказки. До цього додається ще один важливий наслідок: підтримка старіших Android‑пристроїв і версій ОС. Це автоматично обмежує доступні технології, впливає на вибір бібліотек, підхід до оптимізації пам’яті й продуктивності.

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

Саме тут починається формалізація функціональних вимог — опису того, що застосунок повинен уміти робити. Наприклад, якщо є профіль, то користувач має мати змогу завантажити аватар, змінити ім’я користувача, мати приховану e‑mail‑адресу, яка не відображається публічно. Це конкретні, перевірювані можливості, які можна протестувати: «може / не може», «працює / не працює».

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

Функціональні проти нефункціональних: що робить застосунок і як саме він це робить

У системному дизайні важливо чітко розділяти два типи вимог. Функціональні відповідають на запитання «що застосунок робить». Нефункціональні — «як саме він це робить за різних умов».

Функціональні вимоги описують поведінку системи. Умовна соцмережа повинна дозволяти реєстрацію, авторизацію, створення постів, підписку на інших користувачів, перегляд стрічки, коментування. Для кожної функції можна розписати деталі: які поля є в профілі, які типи медіа підтримуються, які обмеження на довжину тексту, чи можна редагувати пости після публікації.

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

Це не «додаткові побажання», а повноцінні драйвери архітектурних рішень. Наприклад, вимога «застосунок повинен запускатися менш ніж за X мілісекунд» вплине на те, що саме ініціалізується під час старту, а що відкладається. Обмеження на розмір APK змусить переглянути набір бібліотек, підхід до ресурсів, використання нативного коду. Вимога до мережевої затримки визначить, чи можна дозволити собі важкі запити, чи потрібно агресивно кешувати дані й мінімізувати кількість звернень до сервера.

У добре спроєктованому мобільному застосунку нефункціональні вимоги формулюються так само явно, як і функціональні. Наприклад, можна задати цільове споживання батареї на 10 хвилин активного використання, максимальний обсяг оперативної пам’яті для певного екрану, допустимий час відгуку на дії користувача. Це перетворює абстрактне «має працювати швидко» на конкретні критерії, під які вже можна підбирати технічні рішення.

Нефункціональні вимоги мобільних застосунків: батарея, мережа, пам’ять, локалізація

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

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

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

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

Третій аспект — використання пам’яті. На мобільних пристроях RAM обмежена, особливо якщо йдеться про старі Android‑моделі, які все ще масово в обігу. Робота з великими файлами, наприклад відео чи високоякісними зображеннями, вимагає обережності. Замість того, щоб завантажувати весь файл у пам’ять, доводиться розбивати його на частини, використовувати потокову обробку, chunked‑завантаження. Це не просто оптимізація, а відповідь на нефункціональну вимогу «не виходити за межі доступної пам’яті й не падати з OutOfMemory».

До нефункціональних вимог також належать продуктивність і час запуску. Якщо встановлено цільовий час старту, архітектура має мінімізувати важкі операції в onCreate, відкладати ініціалізацію другорядних сервісів, використовувати lazy‑завантаження. Обмеження на розмір APK змушує відмовлятися від надлишкових бібліотек, оптимізувати ресурси, обережно ставитися до вбудованих шрифтів і зображень.

Локалізація виходить за межі перекладу текстів. Потрібно враховувати підтримку різних мов і регіонів, формати дат і чисел, а також специфічні вимоги на кшталт підтримки right‑to‑left‑інтерфейсів для арабських мов. Це впливає на верстку, компонування елементів, вибір UI‑компонентів, які коректно працюють у двох напрямках.

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

Коли користувачі старші: старі Android‑пристрої й інший UX за замовчуванням

Вікова й технічна характеристика аудиторії — один із найсильніших факторів, що впливають на системний дизайн. Якщо цільова група — люди старшого віку, це автоматично створює низку нефункціональних вимог.

По‑перше, підтримка старіших пристроїв. Багато користувачів похилого віку не оновлюють смартфони щороку й часто користуються моделями кількарічної давності. Це означає старіші версії Android, менший обсяг оперативної пам’яті, повільніші процесори, гірші модулі зв’язку. Вимога «застосунок повинен коректно працювати на таких пристроях» впливає на вибір мінімальної версії SDK, використання важких анімацій, обсяг кешу, підхід до фонових задач.

По‑друге, UX‑принципи. Інтерфейс для старшої аудиторії має бути максимально «дуростійким» — із великими клікабельними зонами, очевидними кнопками, мінімумом прихованих функцій, зрозумілими повідомленнями про помилки. Складні жести, багаторівневі меню, агресивні анімації, дрібний текст — усе це стає ризиком, а не перевагою.

По‑третє, очікування від стабільності. Менш технічно обізнані користувачі гірше переносять збої, незрозумілі стани, «зависання» інтерфейсу. Для них нефункціональні вимоги до надійності й передбачуваності поведінки застосунку стають критичними. Це означає більш консервативний підхід до експериментів, ретельніше тестування на реальних пристроях, продуману обробку помилок мережі й бекенду.

Ці фактори не просто впливають на дизайн екранів. Вони змінюють пріоритети в архітектурі: відмова від надмірно складних патернів, які важко підтримувати на старих пристроях, спрощення навігації, обмеження кількості одночасно активних фонових процесів. Усе це — прямий наслідок нефункціональних вимог, що випливають із портрета користувача.

WhatsApp як приклад: коли нефункціональні вимоги керують усім дизайном

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

Для такого застосунку критично важливі швидкість обміну повідомленнями й надійність роботи за нестабільної мережі. Користувач очікує, що повідомлення буде відправлено й доставлено максимально швидко, навіть якщо він у поїзді, у тунелі чи в зоні з поганим покриттям. Це означає, що дизайн має враховувати часті обриви з’єднання, повторні спроби відправлення, локальне кешування повідомлень, чіткі стани «відправлено / доставлено / прочитано».

Ще одна ключова вимога — мінімальне споживання батареї. Месенджер — це застосунок, який працює постійно: у фоні, з push‑сповіщеннями, із періодичними синхронізаціями. Якщо він надто агресивно використовує мережу чи тримає забагато активних з’єднань, батарея тане на очах. Тому нефункціональна вимога «мінімізувати споживання енергії» стає одним із головних драйверів рішень: скільки одночасних real‑time‑з’єднань допустимо, як організувати фонову синхронізацію, як часто оновлювати статуси.

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

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

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

Висновок: системний дизайн починається з правильних запитань

У мобільній розробці системний дизайн — це не спроба вгадати, як влаштований продакшн‑WhatsApp чи Instagram. Це вміння послідовно пройти шлях від ідеї продукту до чітко сформульованих функціональних і нефункціональних вимог, а вже потім — до архітектури й технічних рішень.

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

Саме ці нефункціональні обмеження часто визначають, як виглядатиме архітектура, які протоколи зв’язку буде обрано, як організують кешування й роботу зі списками, як поводитиметься застосунок за нестабільного інтернету. Приклади на кшталт WhatsApp лише підкреслюють: у реальних продуктах саме «як» часто важливіше за «що».

Для розробників, які готуються до співбесід із системного дизайну або планують складні мобільні продукти, це означає одне: перш ніж говорити про MVVM, GraphQL чи WebSockets, варто навчитися ставити правильні запитання про користувачів, сценарії й обмеження. Відповіді на них і є справжнім фундаментом системного дизайну.

Джерело

Beginner’s Guide to Mobile App System Design (+ Tips for Interviews!)

Формула‑1 стрімко перетворюється з нішового чемпіонату на глобальний бізнес‑магніт для інвесторів, медіакомпаній і автогігантів. На спеціальному заході Axios у Маямі, присвяченому Гран‑прі, учасники обговорили, чому саме зараз у перегони вливаються мільярди й що стоїть за цим стрибком вартості.

Вибух оцінок і «вільний ринок» для інвесторів

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

Ключові фактори, які приваблюють капітал:

• Фіксовані й довгі медіаконтракти. Телеправа та стримінг забезпечують стабільні грошові потоки на роки вперед — те, що люблять інституційні інвестори.
• Зростання цін на спортивні активи. Вартість клубів і ліг у різних видах спорту злетіла настільки, що на ринку залишилися переважно суверенні фонди, надзаможні приватні особи та великі PE‑фонди, здатні оперувати мільярдами.
• Унікальна структура власності. На відміну від НБА чи інших американських ліг, де нових власників мають затверджувати інші клуби, у Формулі‑1 команди продаються «вільніше». Чемпіонат належить корпорації, а окремі стайні мають значно більше свободи в угодах купівлі‑продажу. Це робить F1 одним із найвідкритіших ринків у сегменті топ‑ліг, що зростають.

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

«Drive to Survive», пандемія й сила живого спорту

Глобальний вибух інтересу до Формули‑1 часто пов’язують із серіалом Netflix «Drive to Survive». Знімання стартували приблизно за рік до пандемії, а реліз відбувся буквально за два місяці до того, як мільйони людей опинилися вдома через локдауни.

Поєднання факторів виявилося ідеальним:

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

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

У ширшому контексті Формула‑1 стала символом того, як живий спорт зберігає унікальну цінність у медіа‑екосистемі:

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

У світі, де більшість контенту стала «on‑demand», прямі трансляції спорту й надалі залишаються одним із небагатьох гарантованих магнітів для масової аудиторії — і саме це підживлює інвестиційний бум.

Маямі, Вегас, Остін: три «Супербоули» на рік

Нові етапи чемпіонату в США перетворили Формулу‑1 на серію масштабних міських фестивалів. Маямі, Лас‑Вегас і Остін фактично виконують роль трьох американських «Супербоулів» на сезон:

• Місто стає сценою. У Маямі, наприклад, дизайн‑дистрикт заповнений гігантськими банерами, брендовими інсталяціями та паралельними подіями.
• Гонки — це лише ядро події. Навколо них розгортаються концерти, фан‑зони, корпоративні заходи, закриті вечірки.
• Масштабний туризм і спонсорство. Міста отримують потоки відвідувачів, бренди — майданчик для активацій, а чемпіонат — додаткові джерела доходу.

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

Ford, 125 років перегонів і 5000 деталей за п’ять тижнів

Інтерес до Формули‑1 з боку автогігантів теж виходить на новий рівень. Показовою є історія Ford:

• Ще в 1901 році Генрі Форд побудував гоночний автомобіль Sweepstakes, виграв перегони й використав призові гроші, щоб заснувати Ford Motor Company.
• У 2024‑му компанія відзначає 125 років у автоспорті, хоча сам автоконцерн молодший — 123 роки.
• Участь у перегонах для Ford історично була циклічною — компанія то заходила, то виходила з різних серій залежно від стратегії керівництва. Тепер у Формулі‑1 бачать довгострокову ставку: нішовий спорт перетворився на глобальну платформу з величезною аудиторією й медійною віддачею.

Ще один штрих до портрета сучасної F1 — швидкість інженерних інновацій. Керівник Williams Racing Джеймс Вовлз описав, як команда використала п’ятитижневу паузу між гонками, зокрема перед етапом у Маямі:

• за цей час було розроблено, виготовлено й встановлено близько 5000 нових деталей;
• усі ці компоненти мають інтегруватися в єдину систему боліда й працювати без збоїв;
• процес не зупиняється: оновлення плануються на наступні етапи — Канаду, Монако, інші гонки аж до Сінгапуру.

Такий темп розвитку — рідкість навіть для високотехнологічних галузей. Для інвесторів це ще один аргумент: Формула‑1 — не лише видовищний спорт, а й унікальний полігон для інженерних рішень, матеріалознавства, аеродинаміки та управління складними проєктами в стислі терміни.

Джерело

Why big money is racing into F1 | Axios Event Recap

Коли у 2019 році Кейлеб Ґрілло прийшов у Confluent як продакт-менеджер, Confluent Cloud уже мав помітну базу користувачів — але комерційно це був радше «хостинг брокерів Kafka», ніж сучасний хмарний сервіс. Сьогодні Ґрілло очолює продуктовий напрям Warpstream у Confluent, але саме його рання робота над білінгом стала одним із ключових кроків у перетворенні Confluent Cloud на повноцінну платформу зі споживчою (usage-based) моделлю оплати.

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

Дві хмари в одній: як виглядала комерційна «шизофренія» Confluent Cloud

На момент приходу Ґрілло в травні 2019 року Confluent Cloud фактично складався з двох різних світів.

Перший світ — це «серйозний» хмарний бізнес із виділеними кластерами. Це були не self‑serve інстанси, а радше керовані, але по суті індивідуальні розгортання Kafka для великих клієнтів. Інфраструктура була виділеною, угоди — індивідуальними, а білінг — далеким від класичної моделі AWS, де ви натискаєте кнопку, запускаєте EC2‑інстанс, оплачуєте його погодинно й зупиняєте, коли він більше не потрібен.

Другий світ — окремий self‑serve продукт на мультиорендних (multi‑tenant) кластерах. Тут уже була споживча модель: користувач міг самостійно зареєструватися, додати картку, почати використовувати сервіс і платити за фактичне використання. Це було ближче до очікувань від сучасної хмари, але масштаб цього продукту та його архітектура не відповідали потребам великих enterprise‑клієнтів, які звикли до виділених ресурсів, контрактів і знижок.

Обидва світи жили паралельно, з різними очікуваннями щодо білінгу, різними внутрішніми системами й різною логікою комерційних відносин. Технічні передумови для об’єднання вже існували: Confluent мав досвід керування кластерами, мультиорендною інфраструктурою та базовим usage‑білінгом. Але об’єднати ці моделі без єдиної комерційної логіки було неможливо.

Саме це й стало завданням Ґрілло: побудувати єдину, consumption‑based білінгову систему, яка б охоплювала обидва світи й дозволила Confluent Cloud стати тим, чим його уявляють сьогодні — повноцінним хмарним сервісом із гнучкою моделлю оплати.

Від «хостингу брокерів» до платформи: навіщо потрібен єдиний usage‑білінг

Початковий «хостинговий» підхід до Confluent Cloud був логічним для раннього етапу: потрібно було перевірити, чи готові компанії довірити Kafka зовнішньому провайдеру. Цей proof‑of‑concept спрацював настільки добре, що бізнес виріс швидше, ніж встигла еволюціонувати модель монетизації.

Наступний крок був очевидним: перейти від «ми просто запускаємо вам брокери» до «ми надаємо повноцінну стримінгову платформу як сервіс». Але для цього недостатньо було лише технічно розвинути продукт. Потрібно було, щоб комерційна модель відповідала очікуванням клієнтів і дозволяла масштабувати бізнес.

Єдина, споживча модель оплати мала вирішити кілька задач одночасно.

По‑перше, зробити можливим справжній self‑serve для широкого кола користувачів — від стартапів до великих компаній, які хочуть почати з невеликих обсягів і масштабуватися без перемовин на кожен крок.

По‑друге, дати змогу enterprise‑клієнтам працювати з виділеними кластерами, складними контрактами, мінімальними зобов’язаннями й індивідуальними знижками, але при цьому залишатися в тій самій логіці usage‑білінгу, що й self‑serve користувачі.

По‑третє, створити основу для подальшого розвитку платформи: додавання нових сервісів поверх Kafka, нових типів кластерів, нових метрик використання. Без гнучкого білінгу кожен новий продукт перетворювався б на окрему комерційну «острівну» систему.

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

Білінг як платформа: кластери, продукти, трафік і сховище в одній моделі

Нова білінгова система Confluent Cloud мала бути не просто «лічильником байтів». Вона мала стати платформою, яка вміє описувати різні типи інфраструктури, різні продукти й різні способи використання.

По‑перше, потрібно було підтримати кілька рівнів кластерів. У Confluent Cloud співіснували виділені кластери для великих клієнтів і мультиорендні кластери для self‑serve користувачів. Кожен тип мав свої характеристики продуктивності, надійності, ізоляції та, відповідно, свою цінову модель. Білінгова система мала вміти однаково коректно рахувати використання для обох типів, не перетворюючи їх на два різні світи.

По‑друге, йшлося не лише про Kafka як таку. Уже тоді Confluent Cloud включав додаткові сервіси: Kafka Connect для інтеграцій і ksql (сьогодні ksqlDB) для потокової обробки даних. Кожен із цих продуктів споживає ресурси по‑своєму: Connect — через конектори, які можуть активно читати й писати дані, ksql — через безперервні запити, що постійно обробляють потоки. Єдина білінгова модель мала вміти відобразити всі ці патерни використання, не розвалюючись на окремі «субсистеми» для кожного продукту.

По‑третє, потрібно було одночасно враховувати два ключові виміри використання: пропускну здатність (throughput) і сховище (storage). Стримінгова платформа — це не лише скільки даних проходить через кластери, а й скільки з них зберігається, як довго й у якому вигляді. Клієнти можуть мати різні патерни: хтось тримає коротку ретенцію, але з високим трафіком, хтось — навпаки, менший потік, але довге зберігання. Білінг мав коректно відображати обидва сценарії.

Усе це вимагало не просто додати нові поля в таблицю тарифів, а спроєктувати модель, яка дозволяє:

• описувати різні типи кластерів як різні «рівні» сервісу з власними характеристиками;
• прив’язувати до них кілька продуктів (Kafka, Connect, ksql) з різними патернами використання;
• рахувати використання за кількома осями (трафік, сховище) й робити це узгоджено для всіх клієнтів.

Це й стало суттю першої версії нового білінгу, яку Ґрілло мав вивести в продакшн: не просто «рахувати байти», а створити гнучку платформу, на якій можна будувати комерційну еволюцію Confluent Cloud.

Enterprise‑реальність: мінімальні зобов’язання, знижки й контракти

Usage‑білінг у стилі «ось прайс, ось ваші метрики, платіть по факту» добре працює для self‑serve сегмента, але погано відображає реальність великих enterprise‑угод. Для Confluent, який працює з великими компаніями, цього було явно недостатньо.

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

По‑перше, підтримку мінімальних зобов’язань (commitments). Enterprise‑клієнти часто підписують контракти, де зобов’язуються витратити певний мінімальний обсяг коштів або використання за період — наприклад, за рік. Це дає їм кращі умови, а провайдеру — прогнозованість доходів. Білінгова система має вміти відобразити, як фактичне використання співвідноситься з цими зобов’язаннями, чи виконується commit, чи є недовикористання.

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

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

Усе це означало, що Confluent мав побудувати не просто «рахівницю» для usage‑даних, а повноцінну модель комерційних відносин, де usage‑метрики, ціни, знижки й commitments зводяться в єдину картину. Саме така модель дозволяє одночасно підтримувати self‑serve користувачів із прозорим прайсингом і великі enterprise‑угоди з індивідуальними умовами — без розриву між технічною та фінансовою реальністю.

Коли метрики запізнюються: чому білінг має збиратися по‑частинах

Ще одна малопомітна, але критично важлива частина нової білінгової системи Confluent — це те, як вона працює з usage‑метриками в часі. У реальних розподілених системах дані про використання рідко приходять миттєво й ідеально синхронно. Метрики можуть запізнюватися, приходити пачками, частково дублюватися або потребувати агрегації.

Замість того, щоб робити білінг на основі «моментального знімка» використання, Confluent побудував модель, де usage‑дані агрегуються з часом, а суми до сплати поступово збігаються до коректного значення. Це означає кілька важливих речей для клієнтів і для самої платформи.

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

По‑друге, кращу стійкість до технічних збоїв. У розподіленій інфраструктурі завжди є ризик, що частина usage‑даних тимчасово недоступна або приходить із затримкою. Агрегаційна модель дозволяє системі «дотягувати» ці дані пізніше й коректно враховувати їх у підсумкових розрахунках, замість того щоб покладатися на один‑єдиний знімок.

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

Цей підхід до usage‑метрик добре узгоджується з тим, як Ґрілло сьогодні працює над Warpstream: усі дані про споживання й використання цього продукту також потрапляють у внутрішнє data warehouse Confluent, де їх можна аналізувати з тих самих позицій — як для білінгу, так і для продуктового розвитку.

Від білінгу до аналітики: як Warpstream наслідує data‑driven підхід

Сьогодні Кейлеб Ґрілло очолює продуктовий напрям Warpstream у Confluent — це BYOC‑продукт (bring your own cloud), де дата‑плейн працює у VPC або дата‑центрі клієнта, а Confluent керує контрольним рівнем. Технічно Warpstream радикально відрізняється від класичного Kafka‑розгортання, але в одному підході є пряма спадковість від роботи Ґрілло над білінгом Confluent Cloud: у ставленні до usage‑даних.

Усі дані про споживання та використання Warpstream потрапляють у внутрішнє data warehouse Confluent. Це означає, що до Warpstream застосовується той самий принцип, який колись ліг в основу нового білінгу Confluent Cloud: usage‑метрики — це не лише основа для виставлення рахунків, а й ключовий інструмент для розуміння продукту.

Такий підхід дозволяє:

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

Фактично, те, що починалося як «великий білінговий проєкт» у 2019 році, сьогодні перетворилося на ширший data‑driven підхід до управління стримінговими продуктами в Confluent. Білінгова система стала не лише механізмом монетизації, а й фундаментом для аналітики, планування й розвитку нових сервісів — включно з Warpstream.

Висновок: білінг як стратегічна інфраструктура, а не післямова

Історія еволюції білінгу Confluent Cloud показує, наскільки глибоко комерційна модель вплітається в технічну архітектуру хмарного сервісу. Неможливо побудувати справжню платформу зі self‑serve досвідом, enterprise‑контрактами й кількома продуктами поверх одного ядра, якщо білінгова система залишиться набором «латок» навколо окремих компонентів.

Єдина consumption‑based модель, яку допоміг створити Кейлеб Ґрілло, вирішила одразу кілька задач: об’єднала виділені й мультиорендні кластери в одну комерційну реальність, дозволила підтримувати кілька продуктів і вимірів використання, навчилася працювати з enterprise‑зобов’язаннями та знижками й запровадила підхід до usage‑метрик як до даних, що агрегуються й аналізуються з часом.

Сьогодні цей підхід продовжує жити в нових продуктах Confluent, зокрема у Warpstream, де всі дані споживання також потрапляють у внутрішнє сховище для аналізу. У світі, де стримінг стає базовою інфраструктурою для бізнесу, білінг перестає бути «фінансовим додатком» і стає такою ж критичною частиною платформи, як брокери, конектори чи стримінгові рушії.

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

Джерело

Being Wrong in the Right Direction with Caleb Grillo | Ep. 29 | Confluent Developer Podcast