Інструменти на кшталт Claude Code дедалі активніше використовують для розробки, експериментів з кодом і швидкого прототипування. Але разом із цим зростає й потреба безболісно “відмотати” невдалий крок назад. У свіжому огляді на каналі KODARIK показано, як саме це робити за допомогою вбудованого механізму відновлення стану проєкту.

Відкат до будь-якого кроку: що вміє команда rint

Claude Code зберігає історію запитів (prompts) і змін у проєкті, а команда rint дозволяє повернутися до одного з попередніх станів. Ключова ідея: можна не лише переглянути історію, а й фактично “перестрибнути” назад до конкретного запиту.

Користувач обирає потрібний крок зі списку — наприклад, найперший запит, коли ще не існувало певного файлу (у прикладі це тестовий README). Після вибору система пропонує, що саме відновити:

• і код, і розмову (conversation);
• лише розмову;
• лише код.

Якщо обрати повне відновлення, файли, створені пізніше (той самий README), зникають із проєкту, а стан повертається до моменту першого повідомлення. Це не просто візуальний “undo”, а реальне повернення до попередньої версії робочого середовища.

Коли варто відкотитися, а не виправляти

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

1. Небажаний результат генерації

Якщо Claude Code згенерував код, який:

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

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

2. Помилки, що “ламають” проєкт

Бувають ситуації, коли:

• у коді з’являються критичні помилки;
• ламається збірка чи тести;
• зміни важко локалізувати й виправити вручну.

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

3. Зміна планів під час розробки

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

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

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

Гнучке відновлення: код окремо, розмова окремо

Важлива деталь — можливість роздільного відновлення:

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

Такий підхід дає змогу гнучко керувати історією роботи, не перетворюючи відкат на грубий “reset” усього середовища.

Джерело

Повний огляд Claude Code – Частина 17 #аі #python #вайбкодинг — KODARIK

Швидкі відповіді від чатботів уже нікого не дивують. Новий етап — системи, які не лише «знають», а й реально щось роблять замість користувача. Канал IBM Technology на прикладі проєкту OpenClaw пояснює, як влаштовані AI-агенти, чим вони відрізняються від звичних LLM-чатів і які ризики з’являються разом із новими можливостями.

Від відповіді до дії: чим агент відрізняється від чатбота

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

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

AI-агент — це система, яка:

• поєднує LLM із набором інструментів (tools);
• може самостійно викликати ці інструменти;
• працює автономно в циклі «спланувати → виконати → перевірити результат».

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

Як працює agentic loop: React-патерн у дії

Основний принцип роботи сучасних агентів описують як React-патерн (Reason + Act):

1. Надходить завдання
   Запит може прийти з різних каналів — Slack, iMessage, WhatsApp, інших месенджерів чи внутрішніх систем.

2. Формується контекст
   Перед зверненням до LLM агент збирає все, що може бути корисним:

3. історію розмови;
4. довгострокову пам’ять (попередні сесії, виконані завдання);
5. системні інструкції (як поводитися, що дозволено, що заборонено);

6. список доступних інструментів.

7. Міркування (Reasoning)
   LLM отримує цей контекст і вирішує, чи потрібно:

8. просто сформувати відповідь;

9. чи викликати один або кілька інструментів для отримання додаткових даних або виконання дій.

10. Дія (Act)
    Якщо інструмент потрібен, агент може, наприклад:

11. виконати команду в терміналі;
12. прочитати файл на диску;
13. викликати зовнішній API;
14. виконати веб-пошук.

Результат повертається в агент і додається до контексту.

1. Спостереження й повторення
   Агент знову звертається до LLM уже з оновленим контекстом. Цикл «міркування → дія → спостереження» повторюється, доки:
2. завдання не буде виконано;

3. або модель не вирішить, що інструменти більше не потрібні.

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

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

Архітектура OpenClaw: локальний хаб для особистого AI-асистента

OpenClaw позиціонують як один із найяскравіших прикладів «агентного» асистента. Це безплатний open source-проєкт, створений наприкінці 2025 року, який швидко набрав популярність на GitHub.

Локальний сервіс і модель «hub and spoke»

OpenClaw запускається як локальний сервіс на Node.js:

• на ноутбуці;
• у віртуальній машині;
• на Raspberry Pi чи іншому пристрої.

Система побудована за моделлю «hub and spoke» з центральним елементом — gateway:

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

Інтеграції через адаптери

Спілкуватися з агентом можна через різні канали:

• Slack, Microsoft Teams, Discord;
• iMessage та інші платформи.

Щоб уніфікувати дані з різних джерел, OpenClaw використовує адаптери. Вони перетворюють вхідні повідомлення в єдиний внутрішній формат, який gateway уже може обробляти незалежно від джерела.

LLM, пам’ять і «душа» агента

LLM у OpenClaw може:

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

Для повноцінної роботи агенту потрібні не лише поточні запити, а й додаткові дані:

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

Усе це проходить через gateway і потім передається в LLM як частина контексту.

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

Найбільша сила OpenClaw — у шарі інструментів і навичок (skills), які визначають, що саме агент уміє робити.

Інструменти: браузер, термінал та інші можливості

OpenClaw має вбудовані інструменти, зокрема:

• браузер — для автоматизації дій у вебі;
• термінал — для виконання команд, запуску CLI-утиліт тощо.

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

Skills: розширювані сценарії для будь-яких задач

Skills — це те, що робить OpenClaw гнучким персональним асистентом. По суті, це:

• папки з markdown-файлами;
• у яких описано, як виконувати конкретне завдання чи робочий процес.

Приклади можливостей, які можна реалізувати через skills:

• керування Trello-дошками;
• доступ і редагування Google Calendar;
• для інженерів — робота з Docker (збірка, запуск, тестування контейнерів);
• інтеграції з CRM, GitHub та іншими джерелами даних.

Важливий момент: OpenClaw не завантажує всі скіли в контекст LLM за замовчуванням — це швидко «заб’є» контекстне вікно. Натомість:

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

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

Безпека AI-агентів: де проходить межа між асистентом і бекдором

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

• файлової системи;
• терміналу;
• інтегрованих сервісів.

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

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

Prompt injection: приховані інструкції в даних

Окрема категорія ризиків — prompt injection. Це типова вразливість для LLM-агентів:

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

Без додаткових захисних механізмів агент здатен:

• передати конфіденційні дані;
• виконати небажані дії в терміналі чи через API.

Рекомендовані практики

Для безпечної роботи AI-агентів варто:

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

Від розмови до оркестрації: що змінюють агенти в роботі з AI

Довгий час взаємодія з AI зводилася до діалогу: модель могла пояснити, що робити, але не робила це сама. З появою агентів роль LLM змінилася:

• модель стає оркестратором, який:
• планує послідовність дій;
• викликає інструменти;
• аналізує результати;
• повторює цикл, доки завдання не виконано.

OpenClaw — лише один із підходів до побудови таких систем. Паралельно розвиваються й інші фреймворки, зокрема LangGraph та подібні рішення. Але базові патерни — agentic loop, React-підхід, розділення на gateway, інструменти й skills — уже стали спільним фундаментом для нового покоління AI-систем.

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

Джерело

What is OpenClaw? Inside AI Agents, LLMs and the Agentic Loop — IBM Technology

Інструменти на кшталт Claude Code поступово рухаються в бік більш «автономного» режиму роботи з кодом. У свіжому огляді на каналі KODARIK розбирають, як поводиться режим accept edits on і чому він змінює взаємодію розробника з AI-асистентом.

Що таке режим Accept Edits

Режим accept edits on — це налаштування, за якого система автоматично застосовує зміни у файлах, які вона сама пропонує. Тобто:

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

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

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

Попри підвищену автономність, режим не перетворює Claude Code на повністю неконтрольованого агента. Важливе розділення виглядає так:

• Автоматично:
• редагування вмісту файлів (дописати функцію, виправити помилку, змінити логіку);
• внесення дрібних правок у вже наявний код;

• оновлення фрагментів, які безпосередньо пов’язані з поточним завданням.

• З підтвердженням користувача:

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

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

Навіщо це розробнику

Такий підхід змінює баланс між швидкістю та контролем:

• Менше тертя в роботі: не потрібно щоразу підтверджувати очевидні правки в коді.
• Збереження безпеки: будь-яка дія, яка може призвести до втрати даних (видалення файлів) або небажаних ефектів (виконання команд), все одно проходить через користувача.
• Зручність у довгих сесіях: коли асистент поступово рефакторить або дописує проєкт, автоматичні правки зменшують кількість дрібних взаємодій.

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

Коли варто вмикати Accept Edits

Режим accept edits on особливо доречний, коли:

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

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

Джерело

Повний огляд Claude Code – Частина 19 #аі #python #вайбкодинг

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

Чому Claude Code постійно питає дозволу

Claude Code має можливість:

• змінювати файли у вашому проєкті;
• виконувати команди в середовищі розробки.

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

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

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

Режими дозволів: як змінити поведінку Claude Code

Щоб збалансувати безпеку й зручність, у Claude Code передбачено кілька режимів роботи з дозволами. Перемикання між ними здійснюється комбінацією клавіш Shift + Tab.

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

• з’являється фіолетовий індикатор — один із спеціальних режимів;
• при наступному натисканні може з’явитися зелений напис з текстом plan mode;
• коли напис зникає, інструмент повертається до звичайного режиму.

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

Звичайний режим: максимальний контроль

У звичайному режимі Claude Code завжди запитує дозвіл на будь-яку дію, що змінює файли або виконує команди. Це означає:

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

Такий режим підходить, коли:

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

Плановий режим: спочатку план, потім дії

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

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

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

Коли варто змінювати режим

Постійні запити на підтвердження «інколи надокучливі» — особливо в сценаріях, коли розробник:

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

У таких випадках перемикання режимів через Shift + Tab дозволяє підібрати баланс між автономністю інструмента та рівнем контролю, який вам комфортний.

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

Джерело

Повний огляд Claude Code – Частина 18 #аі #python #вайбкодинг

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

Підприємиця та контент‑креаторка Марина Могилко (канал Silicon Valley Girl), яка перебудувала свій бізнес навколо AI‑інструментів, показує, що ключ до цього — не ще одна “чарівна модель”, а правильна інфраструктура: власні стилеві файли, продуманий бренд‑сетап і розуміння того, що нинішнє “вікно можливостей” для заробітку на AI не буде відкритим вічно.

Три файли, які “вибивають” AI зі стандартного тону

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

Щоб цього уникнути, команда Марини підтримує три базові документи, які підвантажуються в AI щоразу, коли він щось створює для її проєктів. Це не просто “підказки”, а постійні орієнтири, які змушують модель працювати в межах конкретного бренду.

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

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

Третій документ — факт‑досьє. Це база перевірених фактів про автора, компанію, продукти, аудиторію, ключові цифри, досягнення, позиціонування. Моделі схильні “домислювати” деталі, якщо їм бракує контексту. Факт‑досьє знімає цю проблему: AI не вигадує, а спирається на чітко прописану інформацію. Для бізнесу це не тільки про точність, а й про послідовність: усі тексти, від лендингу до поста в соцмережах, оперують одними й тими ж формулюваннями та цифрами.

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

Як масштабувати цей підхід: шаблони й повторюваність

Проблема більшості порад про “налаштування AI” у тому, що вони залишаються на рівні абстракцій. Марина пішла іншим шляхом: вона не лише описує концепцію трьох файлів, а й ділиться конкретними шаблонами та інструкціями в своїй розсилці Futureproof.

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

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

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

Design.com: один бренд‑сетап замість десятків брифів

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

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

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

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

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

“Вікно багатства”: чому зараз важливіше бренд і дистрибуція, а не унікальність продукту

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

Інвестор та підприємець Гаррі Вайнерчук (Gary Vaynerchuk), відомий увагою до трендів монетизації, дивиться на це як на тимчасове “вікно багатства”. На його думку, зараз, поки не всі навчилися “кодувати вайб” — тобто системно передавати відчуття бренду, стилю й емоцій у продукти й контент — є можливість побудувати значний капітал. Але з часом, коли AI ще більше спростить створення функціонально подібних сервісів, перевага від простої наявності продукту зникне.

Якби йому довелося починати з нуля, він робив би не складну B2B‑платформу, а відносно простий застосунок із підпискою в діапазоні 5–50 доларів на місяць. Ставка — не на унікальність технології, а на бренд і відкриття: органічний контент у LinkedIn, Twitter та TikTok як основні канали зростання.

Логіка проста: якщо AI стискає цикли розробки, то бар’єр входу в більшість ніш падає. У такому світі головною валютою стають увага й довіра. Той, хто вміє послідовно транслювати свій голос (через ті самі стилеві файли), підтримувати впізнаваний візуальний ряд (через платформи на кшталт Design.com) і системно з’являтися в стрічках соцмереж, отримує фору. Продукт можна буде відносно швидко перебудувати під нові потреби, але аудиторію “перекупити” значно важче.

Це й є суть “вікна”: зараз ще не всі гравці оптимізувалися під нову реальність, і тому є шанс зайняти позиції, які пізніше буде важко відібрати. Але це не триватиме вічно. Коли AI‑інструменти стануть настільки ж стандартними, як сьогодні CRM чи email‑маркетинг, ринок вирівняється, і маржа від простої швидкості зникне.

Duolingo, шахи й двоє некодерів: як AI знімає бар’єри до масштабів у мільйони користувачів

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

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

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

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

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

Від “AI як інструменту” до “AI як частини бізнес‑архітектури”

Якщо скласти всі ці елементи разом, вимальовується нова модель роботи з AI у бізнесі.

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

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

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

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

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

Висновок: AI як прискорювач, а не вирівнювач

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

Три документи, які підтримує команда Марини, — анти‑AI гайд, профіль голосу й факт‑досьє — показують, як можна “примусити” моделі працювати на унікальність, а не на усереднення. Design.com демонструє, як той самий підхід застосувати до дизайну, отримавши цілісний бренд‑набір із мінімальними зусиллями й зрозумілими юридичними рамками. Погляд Гаррі Вайнерчука нагадує, що це вікно можливостей тимчасове: коли AI ще не повністю комодитизував продукти, але вже достатньо сильний, щоб радикально прискорювати тих, хто вміє ним користуватися.

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

Джерело

YouTube: The 8 AI Tools That Will Change How You Make Money

У розмові на каналі The Pragmatic Engineer з автором книжки Designing Data-Intensive Applications Мартіном Клеппманном піднімається тема, яка стає дедалі гострішою для університетів і компаній: що відбувається з навчанням, коли студенти та молодші інженери масово користуються ШІ-інструментами?

Навчальні завдання — це не про результат, а про процес

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

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

Дослідження: ШІ допомагає зробити, але не допомагає навчитися

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

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

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

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

Чому «трохи поборотися» із задачею — необхідно

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

Ця «боротьба» включає:

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

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

• завдання формально виконане;
• але ментальна модель предмету не формується;
• наступного разу без підказки ШІ людина знову опиняється «з нуля».

Виклик для освіти: як зберегти мислення в епоху ШІ

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

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

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

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

Джерело

Martin Kleppmann: Students using AI did not learn much — The Pragmatic Engineer

У 2026 році створити застосунок з допомогою штучного інтелекту можна або за кілька вечорів, або перетворити процес на виснажливий хаос. Різниця — у наявності чіткої методики. Автор каналу Tech With Tim у своєму дев’ятиетапному роадмапі зосереджується на тому, як не «вайб‑кодити о другій ночі», а системно будувати продукт. Окремий, критично важливий блок цієї методики — вибір інструментів: no‑code чи AI‑асистований код, а також базова підготовка бекенд‑навичок і робочого середовища.

Ця стаття розбирає саме цей фрагмент: як зрозуміти, чи вистачить вам хостингового AI‑конструктора, коли варто переходити до AI‑редакторів коду, і чому навіть в епоху «кодить за тебе ШІ» все ще потрібні Git і фундаментальні знання бекенду.

No‑code проти AI‑редакторів коду: ключове рішення четвертого етапу

У запропонованому дев’ятиетапному плані четвертий етап — це розвилка, від якої залежить усе подальше: будувати застосунок на no‑code / hosted AI‑платформі чи писати код самостійно, використовуючи AI‑асистентів.

Логіка проста: спочатку потрібно чесно відповісти собі, який саме продукт ви створюєте. Якщо це щось на кшталт простої вебсторінки без складної логіки, користувачів, авторизації чи глибоких інтеграцій з бекендом, то немає сенсу одразу стрибати в повноцінний стек, локальне середовище й складні пайплайни. У таких випадках доцільно скористатися хостинговими AI‑платформами, які поєднують no‑code‑підхід із генеративним ШІ.

Серед прикладів таких сервісів згадуються Lovable, Bolt, Replit, Mocha та VZero. Вони дозволяють «накрутити» застосунок поверх готової інфраструктури: платформа сама хостить проєкт, керує розгортанням, часто бере на себе й базову конфігурацію. Користувачеві залишається сформулювати вимоги, налаштувати інтерфейс і дати моделі достатньо контексту, щоб вона зібрала робочий прототип.

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

Однак у того самого четвертого етапу є й інший шлях — повноцінна розробка з AI‑асистентами в редакторі коду. Тут у гру вступають інструменти на кшталт Cursor, Claude Code, Codeex, Anti‑Gravity та Trey. Вони працюють як «агентні» середовища або розширені IDE: аналізують репозиторій, пропонують зміни, генерують цілі файли, можуть рефакторити, писати тести й навіть планувати кроки розробки.

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

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

Коли вистачить no‑code, а коли без кодування не обійтися

Розмежування між цими двома підходами проходить не стільки по лінії «технічний / нетехнічний», скільки по складності задачі та горизонту планування.

No‑code та hosted AI‑платформи на кшталт Lovable, Bolt, Replit, Mocha чи VZero добре підходять для сценаріїв, де:

застосунок нагадує лендінг або простий сайт‑візитку;

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

бекендова логіка мінімальна або взагалі відсутня;

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

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

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

Саме тут стає актуальним другий шлях четвертого етапу — AI‑редактори коду й агентні інструменти. Cursor, Claude Code, Codeex, Anti‑Gravity, Trey та подібні рішення орієнтовані на розробників, які хочуть зберегти повний контроль над кодовою базою, але при цьому максимально використовувати можливості ШІ. Вони дозволяють:

працювати з реальним кодом у файлах, а не з абстрактними блоками в конструкторі;

запускати застосунок локально, налагоджувати, тестувати, вимірювати продуктивність;

інтегрувати будь‑які зовнішні сервіси, бази даних, черги, кеші, системи логування;

будувати архітектуру, яка не прив’язана до обмежень конкретної платформи.

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

Таким чином, вибір між no‑code і AI‑редактором коду — це вибір між швидким стартом із мінімальними технічними бар’єрами та інвестицією в керовану, гнучку кодову базу. Для простих лендінгів і одноразових MVP перший варіант цілком виправданий. Для всього, що претендує на життя довше кількох спринтів, другий шлях виглядає значно надійнішим.

П’ятий етап: навіщо навіть з AI потрібен Git і локальне середовище

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

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

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

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

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

Чому в епоху AI все ще важливо вчити бекенд

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

У цьому контексті в ролику окремо згадується Boot.dev — платформа, яка позиціонується як практичний навчальний сервіс для бекенд‑розробників. Вона робить акцент не на пасивному перегляді туторіалів, а на розв’язанні реальних задач. Користувачі проходять інтерактивні челенджі з Python, SQL та Go, отримують досвід, близький до того, що чекає на них у реальних проєктах.

Цікаво, що навіть у навчанні бекенду тут використовується ШІ: у Boot.dev є AI‑тьютор Boots, який не просто видає готові відповіді, а ставить уточнювальні запитання й допомагає дійти до рішення самостійно. Такий підхід ближчий до роботи з ментором, ніж до класичного «підкажи мені код» у чат‑бота. Це важливо, тому що без розуміння того, що відбувається «під капотом», розробник ризикує стати залежним від підказок моделі й не зможе самостійно розв’язувати нетипові задачі.

Модель монетизації платформи побудована так, щоб зняти бар’єр входу: весь контент можна безкоштовно читати й дивитися, а інтерактивне кодування, трекінг прогресу та AI‑допомога входять до платного плану. Для глядачів Tech With Tim передбачено знижку: код TECHWITHTIM дає 25% знижки на перший рік.

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

Висновок: AI прискорює розробку, але не скасовує дисципліну

Четвертий і п’ятий етапи дев’ятиетапного роадмапу показують, що головна цінність AI у розробці — не в магії, а в поєднанні швидкості з дисципліною. No‑code та hosted AI‑платформи на кшталт Lovable, Bolt, Replit, Mocha й VZero дозволяють блискавично запускати прості продукти, особливо коли йдеться про лендінги чи MVP без складної логіки. AI‑редактори коду й агентні інструменти — Cursor, Claude Code, Codeex, Anti‑Gravity, Trey — відкривають шлях до серйозних, довготривалих проєктів, де важливі контроль, прозорість і можливість розвивати кодову базу роками.

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

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

Джерело

YouTube: How to Make an App With AI – 9 Steps

Команда Google DeepMind представила нове покоління відкритих моделей Gemma 4, зосередившись на поєднанні високої якості, компактних розмірів і можливості запуску як у хмарі, так і безпосередньо на пристроях. У доповіді для каналу AI Engineer дослідниця Кессіді Гарден детально розібрала архітектурні рішення, що стоять за Gemma 4, та їхні наслідки для розробників.

Лінійка Gemma 4: від «кишенькових» моделей до потужних мультимодальних систем

Gemma 4 — це сімейство з чотирьох відкритих моделей, орієнтованих на різні сценарії використання:

• Дві «effective» моделі для on-device:
• ефективна 2B (E2B)

• ефективна 4B (E4B)
  Вони спроєктовані так, щоб працювати локально на телефонах, планшетах і ноутбуках, підтримуючи текст, зображення та аудіо на вході (вихід — текст).

• Дві старші моделі для складних задач:

• 26B Mixture-of-Experts (MoE) — перша MoE-модель у сімействі Gemma, яка під час інференсу активує лише 3,8–3,9 млрд параметрів із загального пулу експертів.
• 31B Dense — щільна (dense) мультимодальна модель, орієнтована на просунуте міркування, кодування та агентні (agentic) робочі процеси.

Обидві старші моделі увійшли до топ-6 відкритих моделей на платформі LLM Arena, а 31B посіла третє місце у глобальному рейтингу, перевершуючи системи, що більш ніж у 20 разів більші за розміром.

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

Архітектура: локально-глобальна увага, MoE та «ефективні» параметри

Оптимізована увага: локальні й глобальні шари

В основі dense-моделей (31B, E2B, E4B) — стандартний декодерний блок трансформера, але з низкою оптимізацій у механізмі attention:

• Інтерливінг локальних і глобальних шарів:
• у більшості моделей використовується співвідношення 5:1 (п’ять локальних шарів на один глобальний),
• у найменшій E2B — 4:1.
• Локальні шари працюють зі «слiding window»:
• 512 токенів у менших моделях,
• 1024 токени — у більших.
• Глобальні шари завжди бачать усю попередню послідовність, а останній шар моделі завжди глобальний, щоб підсумувати повний контекст.

Такий підхід знижує обчислювальну вартість локальних шарів, але глобальні шари залишаються дорогими. Щоб це компенсувати, застосовано Grouped Query Attention (GQA):

• у локальних шарах дві query-групи ділять одні й ті самі key/value-голови;
• у глобальних — вісім query на одну пару key/value;
• щоб не втратити якість, у глобальних шарах подвоєно розмір key/value-векторів (512 проти 256 у локальних).

Це дозволяє суттєво зменшити пам’яткові витрати та вартість інференсу без помітної втрати якості.

Mixture-of-Experts: 128 експертів, один спільний «якір»

26B — перша MoE-модель у Gemma 4. Вона використовує:

• 128 експертів — невеликі feed-forward-мережі;
• 8 активних експертів на кожен forward-pass;
• один спільний (shared) експерт, який:
• активується завжди,
• утричі більший за звичайних експертів,
• слугує стабільною «базою» для представлень.

Фактично, стандартний feed-forward-блок у трансформері замінено на MoE-блок із роутером, який обирає 8 експертів із 128 для кожного кроку. Це дає змогу поєднати високу виразність моделі з помірною кількістю активних параметрів під час інференсу.

«Effective» моделі: більше представлень, менше активних параметрів

Позначення E2B та E4B означають не лише розмір, а й особливий баланс між:

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

Наприклад:

• E2B:
• ~2,3 млрд ефективних параметрів,
• але 5,1 млрд параметрів, що формують представлення (representational depth).

Ці моделі спеціально оптимізовані для запуску на пристроях із жорсткими обмеженнями VRAM, без необхідності звертатися до віддалених API. Ключова технологія, що це забезпечує, — Per-Layer Embeddings (PLE).

Per-Layer Embeddings: як втиснути «велику» модель у пам’ять смартфона

У стандартних моделях токен-ембеддинги зберігаються в одній великій таблиці в GPU-пам’яті (VRAM). У Gemma 4 для E2B/E4B цей підхід доповнено перешаровими ембеддингами:

• Залишається звичайна основна embedding-таблиця:
• для E2B — розмір вектора 1536,
• для E4B — 2560.
• Додається per-layer embedding table:
• окрема таблиця для кожного шару моделі (35 шарів у E2B, 42 — у E4B),
• для кожного токена є окремий вектор на кожному шарі,
• розмір вектора — лише 256.

Ключовий момент:
per-layer embedding-таблиці зберігаються не у VRAM, а у flash-пам’яті пристрою. Це критично для телефонів і ноутбуків, де відеопам’ять — головне «вузьке місце».

Як це працює в обчисленні:

1. Токен проходить через стандартний декодерний блок.
2. Наприкінці шару для кожного токена виконується lookup у відповідній per-layer embedding-таблиці.
3. Вектор розмірності 256 лінійно проєктується до повного розміру ембеддингу моделі.
4. Таким чином модель отримує «багатші» представлення, не тримаючи всі великі таблиці у VRAM.

У результаті E2B та E4B суттєво перевершують попереднє покоління малих Gemma-моделей, залишаючись придатними для запуску на споживчих пристроях.

Мультимодальність: гнучкі зображення, аудіо та контроль токен-бюджету

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

У Gemma 3 вперше з’явилася підтримка зору, але з обмеженнями: для зображень зі змінними аспектами й роздільними здатностями доводилося застосовувати pan-and-scan — розбивати картинку на кілька квадратів, доповнювати паддінгом і обробляти як кілька окремих зображень.

Gemma 4 переходить до більш гнучкої схеми:

• 31B і 26B використовують візуальний енкодер на 550 млн параметрів.
• E2B та E4B — компактний енкодер на 150 млн параметрів.
• Підтримуються:
• змінні співвідношення сторін (variable aspect ratios),
• змінні роздільні здатності (variable resolutions),
• п’ять варіантів «soft token budget» для зображень.

Механіка роботи:

1. Зображення розбивається на патчі 16×16 пікселів.
2. Кожен патч:
3. «сплющується»,
4. лінійно проєктується в patch-ембеддинг,
5. доповнюється позиційним кодуванням.
6. Патчі групуються у 3×3 блоки:
7. кожен блок → один «soft token» (одна ембеддинг-«пулінг» одиниця).
8. Якщо модель налаштована, наприклад, на 280 токенів для зображення, це відповідає 2520 патчам (280 × 9).

Завдяки змінному токен-бюджету розробник може сам вирішувати:

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

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

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

Аудіопідтримка додана в E2B та E4B з орієнтацією на:

• розпізнавання мовлення,
• переклад.

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

1. Аудіо-токенайзер:
2. на вхід подається сирий аудіосигнал;
3. він перетворюється на MEL-спектрограму для виділення ознак;
4. спектрограма розбивається на фрагменти (n MEL-chunks);
5. далі йдуть дві згорткові (convolutional) шари для даунсемплінгу;

6. на виході — n/4 soft tokens (аудіо-ембеддинги).

7. Conformer-енкодер:

8. модель на 35 млн параметрів;
9. архітектурно подібна до dense/MoE-блоків Gemma, але з додатковим згортковим шаром;
10. працює з ембеддингами, а не з «жорсткими» токенами.

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

Як розробникам почати працювати з Gemma 4

Gemma 4 орієнтована на широкий спектр сценаріїв — від локальних застосунків до складних агентних систем у хмарі. Доступні два основні шляхи інтеграції:

1. Самостійний хостинг (self-hosted):
2. усі чотири моделі можна завантажити з:
   • Hugging Face,
   • Kaggle,
   • Ollama.

3. це підходить для локальних інсталяцій, edge-пристроїв, кастомного донавчання.

4. Хмарні сервіси:

5. для 31B та 26B доступні керовані варіанти через:
   • AI Studio,
   • Vertex AI.
6. це дає змогу швидко прототипувати:
   • агентні (agentic) робочі процеси,
   • функціональні виклики (function calling),
   • складні сценарії міркування та кодування без налаштування власної інфраструктури.

Завдяки поєднанню Apache 2.0, компактних on-device моделей і потужних мультимодальних систем у хмарі, Gemma 4 формує новий орієнтир для відкритих моделей, які одночасно придатні і для експериментів, і для реальних продуктів.

Джерело

Open Models at Google DeepMind — Cassidy Hardin, Google DeepMind (YouTube)

На конференції AI Engineer Europe в Лондоні інженер GitHub Сем Морроу, який очолює розробку MCP-сервера компанії, розповів про те, як GitHub за рік перетворив експериментальний сервер Model Context Protocol на один із наймасштабніших і водночас найбільш захищених у екосистемі. Центральна тема цієї еволюції — безпека, автентифікація та перехід від локальних, небезпечних токенів до віддаленої архітектури з OAuth 2.1.

Model Context Protocol (MCP) — це спосіб підключати LLM-агентів до зовнішніх сервісів як до «інструментів», не вшиваючи API-логіку безпосередньо в модель. GitHub, як одна з найбільших платформ для розробників, став одним із перших великих гравців, хто спробував зробити MCP-сервер не просто демо-рішенням, а продакшн-сервісом із реальними вимогами до безпеки, масштабування та відповідності корпоративним політикам.

Проблема «диких» токенів: як MCP-агенти відкрили новий клас ризиків

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

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

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

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

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

На цьому тлі стає зрозуміло, чому GitHub вирішив зробити ставку на віддалений MCP-сервер із повноцінною OAuth-моделлю замість того, щоб покладатися на локальні токени.

Від локального до віддаленого: як MCP-специфікація відкрила шлях до безпечнішої архітектури

Публічна історія MCP у GitHub почалася в квітні 2024 року, коли компанія відкрила вихідний код локального MCP-сервера. Приблизно в той самий час у специфікації MCP з’явилася підтримка віддаленого HTTP, що стало ключовим моментом для всієї архітектури.

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

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

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

Це рішення стало фундаментом для наступного кроку — інтеграції з OAuth 2.1.

OAuth 2.1 і PKCE: як GitHub посилив автентифікацію MCP-клієнтів

Віддалений MCP-сервер GitHub працює на базі OAuth 2.1 — сучасної еволюції класичного OAuth 2.0, яка закріплює низку найкращих практик безпеки. Для MCP це критично: клієнти часто є десктопними застосунками або розширеннями, які не можуть безпечно зберігати секрети, як це роблять бекенд-сервіси.

Щоб зробити авторизаційні потоки ще стійкішими, команда MCP GitHub долучилася до вдосконалення власної інфраструктури OAuth. Зокрема, вони допомогли додати підтримку PKCE (Proof Key for Code Exchange) до авторизаційного сервера GitHub.

PKCE — це механізм, який захищає авторизаційний код від перехоплення. Клієнт генерує випадковий секрет (code verifier), обчислює з нього похідне значення (code challenge) і надсилає його разом із запитом на авторизацію. Коли клієнт обмінює авторизаційний код на токен, він має довести, що володіє оригінальним секретом. Навіть якщо хтось перехопить сам код, без verifier він не зможе отримати токен.

Для MCP-клієнтів, які працюють на машинах користувачів і не можуть покладатися на приховані серверні секрети, PKCE стає ключовим елементом безпеки. У поєднанні з OAuth 2.1 це дозволяє:

уникати вбудованих у клієнт секретів;
мінімізувати ризики перехоплення коду;
краще захищати інтерактивні сценарії входу.

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

Однак на цьому шляху команда зіткнулася з очікуваннями спільноти щодо ще однієї функції — динамічної реєстрації клієнтів.

Чому GitHub відмовився від dynamic client registration і що натомість пропонує MCP

Багато розробників, які працюють із OAuth, очікували, що GitHub підтримає dynamic client registration для MCP-клієнтів. Ідея виглядає привабливо: клієнт може автоматично зареєструвати себе на авторизаційному сервері, отримати client_id (і, за потреби, client_secret), не вимагаючи ручної реєстрації застосунку в налаштуваннях GitHub.

Однак GitHub свідомо вирішив не підтримувати цей механізм для свого OAuth-базованого MCP-сервера. Причини виявилися радше інфраструктурними й операційними, ніж суто теоретичними.

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

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

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

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

Натомість екосистема MCP рухається в іншому напрямку — до використання метаданих client ID.

Client ID metadata як новий стандарт для MCP

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

GitHub розглядає можливість підтримати client ID metadata у своєму MCP-сервері. Остаточних обіцянок немає, але всередині команди є явне прагнення це зробити. Очікуваний ефект — значне спрощення процесу входу для користувачів: клієнти зможуть передавати більше інформації про себе без необхідності повноцінної динамічної реєстрації.

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

Авторизація як фільтр інструментів: як GitHub прив’язує MCP-можливості до scope

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

GitHub використовує OAuth і персональні токени доступу (PAT) як джерело інформації про scope — тобто про те, які дії користувачеві дозволені в API. Ці scope прямо впливають на те, які MCP-інструменти взагалі з’являються в інтерфейсі агента.

Якщо користувач входить до MCP-сервера GitHub за допомогою PAT, сервер одразу фільтрує набір доступних інструментів відповідно до scope цього токена. Користувачеві не потрібно нічого додатково налаштовувати: достатньо надати токен, і сервер сам вирішує, які інструменти можна показати, а які — приховати.

Це дає одразу кілька переваг:

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

У випадку OAuth GitHub пішов ще далі, реалізувавши так званий step-up OAuth.

Step-up OAuth: інтерактивне «додання прав» без зриву сесії

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

У MCP-сервері GitHub це працює так: якщо агент намагається викликати інструмент, для якого поточні scope недостатні, сервер не просто повертає помилку. Натомість він повертає так званий scope challenge — запит на розширення прав.

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

Це важливий UX- і безпековий компроміс:

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

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

Від prompt injection до enterprise-профілів ризику: чому безпека MCP — це не лише про токени

Навіть із правильно налаштованим OAuth та обмеженими scope проблема безпеки MCP не зводиться лише до автентифікації. Prompt injection і витік даних через інструменти залишаються реальними ризиками.

Один із прикладів — публікація Invariant Labs, де було продемонстровано коректно реалізовану атаку prompt injection із витоком приватних даних із GitHub через MCP-інструменти. У цьому сценарії інструменти GitHub MCP дійсно можуть бути використані для витоку, якщо користувач увімкнув широкий набір можливостей і надав агенту доступ до приватних репозиторіїв.

Однак важливо, що подібні атаки не є унікальними для MCP чи GitHub. Будь-яка агентна система, яка має доступ до зовнішніх API й приватних даних, стикається з тією ж «летальною тріадою» prompt injection, надмірних привілеїв і відсутності чітких меж між даними та інструкціями.

GitHub має справу з дуже різними профілями ризику користувачів:

від організацій із air-gapped інсталяціями GitHub Enterprise Server у жорстко контрольованих середовищах;
до індивідуальних розробників, які підключають агентів безпосередньо до github.com із повним доступом до свого акаунта.

Завдання MCP-сервера — не нав’язувати єдину модель безпеки, а надати механізми, які дозволяють адаптуватися до різних сценаріїв. Саме тому так багато уваги приділяється:

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

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

Висновок: MCP дорослішає — і безпека стає ключовою частиною дизайну

За трохи більше ніж рік MCP-сервер GitHub пройшов шлях від локального open source-проєкту до віддаленого продакшн-сервісу з продуманою моделлю безпеки. Ключові елементи цієї еволюції:

перехід до remote HTTP, закладений у специфікації MCP ще в квітні 2024 року;
інтеграція з OAuth 2.1 і впровадження PKCE в авторизаційному сервері GitHub;
свідоме рішення відмовитися від dynamic client registration через проблеми масштабованості, rate limiting і ідентичності застосунків;
рух екосистеми MCP у бік client ID metadata як більш керованої альтернативи;
фільтрація інструментів за scope токена та підтримка step-up OAuth, що дозволяє безболісно розширювати права без зриву поточних викликів;
спроба витіснити практику plaintext, довгоживучих, надмірно привілейованих токенів, які сьогодні масово використовуються в MCP «у полі».

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

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

Джерело

https://www.youtube.com/watch?v=0n3MKk7r60w

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

Модель, яку назвали «надто небезпечною», і сигнал для ринку

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

Цей меседж про «надмірну небезпеку» спрацював як тригер для ринку:

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

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

Але ця стратегія працює лише доти, доки страх перетворюється на реальні доходи.

$700 млрд на AI й «потворна математика» окупності

Невелика група публічних техгігантів цього року витратить майже 700 млрд доларів на штучний інтелект. Це капітальні витрати (CapEx) на дата-центри, моделі, інфраструктуру та насамперед — на чипи.

Ключові проблеми:

• Немає видимого «стелі» витрат. Щоб залишатися в AI-гонці, компаніям доводиться постійно збільшувати інвестиції.
• Nvidia задає темп, який ніхто не встигає наздогнати. Виробник випускає дедалі потужніші й ефективніші чипи, але вони також стають дорожчими. Компанії змушені купувати нові покоління, фактично ніколи не «наздоганяючи» оптимальний рівень витрат.
• AI вже дорожчий за людей. За словами віцепрезидента Nvidia з deep learning, вартість обчислень уже випереджає витрати на персонал. Деякі великі гравці, як-от CTO Uber, уже «спалили» весь IT-бюджет 2026 року на AI-токени — оплату використання моделей.

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

Кінець «венчурної субсидії» й неминуче подорожчання AI

Сьогоднішні дешеві підписки на ChatGPT чи Claude — це не ринкова норма, а класичний «венчурний демпінг». Модель знайома за Uber:

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

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

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

Це означає:

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

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

Суспільний спротив: від страху до блокування дата-центрів

Паралельно з біржевою ейфорією формується протилежний тренд — зростаюче роздратування й недовіра до AI серед громадян.

Кілька маркерів настроїв:

• половина американців більше боїться AI, ніж радіє йому;
• серед покоління Z рівень захоплення технологією — лише 22%;
• на тлі загальної напруги фіксуються й радикальні інциденти, включно з атакою із «коктейлем Молотова» на будинок засновника OpenAI Сема Альтмана.

Цей настрій уже має матеріальні наслідки:

• у 2025 році 48 проєктів дата-центрів загальною вартістю понад 150 млрд доларів були заблоковані або відкладені;
• у Міссурі виборці змінили половину міської ради, щоб зупинити будівництво дата-центру на 6 млрд доларів;
• мешканці різних штатів виходять на протести проти нових об’єктів, які мають живити AI-інфраструктуру.

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

Роздрібні інвестори як «хедж від власного звільнення»

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

OpenAI активно розширює коло акціонерів за рахунок роздрібних інвесторів. Ключовий інструмент — платформа Robinhood:

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

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

Дві історії про AI, які ведуть до протилежних результатів

Сьогоднішній AI-бум тримається на двох різних наративах:

• У Уолл-стріт дивляться на те, чим AI може стати — джерелом вибухового зростання продуктивності, нових ринків і монопольних прибутків.
• У споживачів і громад фокус на тому, чим AI є зараз — дорогим, енергоємним, тривожним і часто нав’язаним зверху.

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

Джерело

Is the AI boom about to break? — Axios

У розмові на подкасті 20VC з Гаррі Стеббінгсом співзасновник і CEO AppLovin Адам Форугі описує трансформацію компанії, яка пройшла шлях від публічного приниження до однієї з найефективніших машин прибутку у світовій технологічній індустрії. Після IPO 2021 року капіталізація AppLovin сягнула близько $40 млрд, але вже у 2022‑му впала приблизно на 92% — до менш ніж $4 млрд. Саме в цій точці компанія фактично зупинила розвиток старої рекламної рекомендаційної системи, зробила ставку на нову AI‑архітектуру й почала радикально перебудовувати організацію під епоху машинного навчання.

Результатом став запуск моделі Axon 2 у квітні 2023 року, майже трицифрове зростання виручки у 2024‑му та безпрецедентна рентабельність: основний рекламний бізнес із приблизно 400 співробітниками генерує близько $10 млн EBITDA на одного працівника. За цією статистикою стоїть не лише технологічний прорив, а й жорсткі кадрові рішення, відмова від класичної ролі продакт‑менеджера та глибока інтеграція AI в інженерну й креативну роботу.

Від краху до Axon 2: чому AppLovin «заморозила» стару систему рекомендацій

Падіння вартості AppLovin у 2022 році було не просто ринковою корекцією. Для керівництва це стало сигналом, що попередня технологічна база вичерпала потенціал. Компанія ухвалила радикальне рішення: зупинити більшість R&D‑інвестицій у легасі‑рекомендаційну систему й фактично переписати серце рекламної платформи на новій архітектурі машинного навчання.

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

Кульмінацією цього курсу став запуск Axon 2 у квітні 2023 року. Нова модель стала ядром рекламного бізнесу AppLovin — саме через неї тепер проходить ключова логіка таргетингу, оптимізації ставок і розподілу трафіку. Фактично компанія перетворила Axon 2 на центральний мозок своєї екосистеми.

Після запуску Axon 2 динаміка бізнесу різко змінилася. Фінансові показники та курс акцій почали відновлюватися, а у 2024 році виручка зросла майже тризначними темпами. Для ринку це стало підтвердженням того, що ставка на повну перебудову рекомендаційної системи себе виправдала: нова AI‑архітектура не просто замінила стару, а створила конкурентну перевагу, яку важко відтворити.

Радикальна оптимізація штату: як AI став аргументом для скорочень

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

У результаті в багатьох департаментах штат був зменшений приблизно на 40–50%. Це не були вимушені скорочення через падіння попиту; навпаки, вони відбувалися паралельно з відновленням бізнесу й подальшим зростанням. Логіка полягала в тому, щоб не чекати, поки AI де-факто зробить частину ролей зайвими, а заздалегідь перебудувати структуру під нову реальність.

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

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

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

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

Інженерія в епоху AI: 80–90% коду пишуть моделі, а не люди

Найглибші зміни, однак, торкнулися інженерної організації. AppLovin системно інтегрувала AI в розробку програмного забезпечення до такого рівня, що, за оцінкою керівництва, сьогодні 80–90% коду за обсягом генерується саме AI‑інструментами.

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

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

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

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

Без продакт‑менеджерів: інженери як власники продукту

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

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

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

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

400 людей, $10 млн EBITDA на кожного: як влаштований «двигун» прибутку

У центрі всієї цієї трансформації — основна рекламна продуктова організація AppLovin, яка налічує близько 400 людей. Саме вона генерує більшість EBITDA компанії, забезпечуючи приблизно $10 млн операційного прибутку на одного співробітника — показник, який практично не має аналогів у публічних технологічних компаніях.

Важливо розуміти, що цей показник не «розмивається» іншими активами. AppLovin володіє Adjust — аналітичною компанією, а також Wurl — бізнесом у сфері CTV (connected TV). Обидві структури працюють як окремі бізнеси й не є основними драйверами екстраординарної EBITDA‑на‑голову. Саме ядро рекламної платформи — з Axon 2 як центральною моделлю — формує левову частку прибутковості.

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

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

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

Висновок: AppLovin як прототип AI‑нативної публічної компанії

Історія AppLovin після краху 2022 року — це не лише кейс успішного технологічного «камбеку». Це, по суті, експеримент у тому, як може виглядати публічна технологічна компанія, побудована за принципами AI‑нативності.

Компанія не просто інтегрувала машинне навчання в окремі продукти, а переписала центральну рекомендаційну систему на новій архітектурі, зробила AI основним інструментом інженерної роботи, скоротила процесні й креативні ролі, які можна автоматизувати, і відмовилася від класичної моделі продакт‑менеджменту на користь інженерів‑власників продукту. Усе це вилилося в компактний, але надзвичайно потужний 400‑осібний «двигун» прибутку з EBITDA близько $10 млн на одного працівника.

Для решти ринку це ставить незручні запитання. Наскільки великі справді мають бути команди в епоху, коли 80–90% коду може писати AI? Які ролі є критично важливими, а які існують лише тому, що так «завжди було»? І чи готові компанії, особливо публічні, не просто говорити про AI, а перебудовувати під нього свою структуру, процеси й культуру так само радикально, як це зробила AppLovin?

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

Джерело

YouTube: $160B Market Cap, $5.48B Revenue, $10M EBITDA Per Head: Inside AppLovin’s Profit Engine

Новий десктопний застосунок Claude Code перетворює AI‑асистента для програмування на інструмент, яким можна користуватися без жодних команд у терміналі. Канал Teacher’s Tech показує, як встановити програму, налаштувати її та створити простий веб‑інструмент — рандомний вибірник імен — буквально за кілька хвилин.

Що таке Claude Code і що потрібно для старту

Claude Code — це AI‑асистент для роботи з кодом від Anthropic, який безпосередньо змінює файли у вибраній папці на вашому комп’ютері. Користувач формулює завдання природною мовою, система пропонує зміни у файлах, а ви вирішуєте, приймати їх чи ні.

Ключові вимоги для роботи з десктопною версією:

• Платний план Claude — безкоштовний тариф Claude Code не включає, актуальні умови потрібно перевіряти на сторінці тарифів.
• Комп’ютер на macOS або Windows — окремого застосунку для Linux поки немає.
• Жодних додаткових інструментів — не потрібні Node.js, Git чи попередній досвід програмування. Достатньо вміти встановити застосунок і працювати з папками.

Встановлення та перший запуск: де шукати Claude Code

1. Завантаження застосунку
   Перейти на сторінку завантаження Claude (claude.com/download) і вибрати версію для своєї операційної системи (Mac або Windows).

2. Інсталяція та вхід
   Встановити застосунок як звичайну програму, відкрити його та увійти у свій обліковий запис Claude.

3. Де “ховається” Claude Code
   Claude Code не є окремою програмою — він вбудований у основний десктопний застосунок. Доступ до нього відкривається через іконки‑вкладки у верхній частині бокової панелі:

4. Бабл чату — звичайний чат Claude, як у веб‑версії.
5. Чекліст — Co‑work агент для автономних задач у хмарі.

6. Дужки коду — режим Claude Code для роботи з файлами на комп’ютері.

7. Інтерфейс і базові налаштування

8. У центрі розташована панель з дашбордом: статистика використання (сесії, повідомлення, токени, “streaks”). Для перших кроків це можна ігнорувати.
9. Внизу — ключові елементи:
   • Local — означає, що сесія працює з локальними файлами.
   • Select folder — вибір папки, з якою Claude Code буде працювати.

Моделі, “зусилля” та дозволи: як не витратити ліміт і не зіпсувати файли

Вибір моделі

У випадаючому списку можна обрати модель Claude:

• Opus 4.7 (medium effort) — збалансований варіант для щоденних задач.
• Sonnet та Haiku — “легші” моделі, що споживають менше ліміту, але добре справляються з простими завданнями.
• Opus 1M — версія для дуже великих кодових баз (для невеликих проєктів не потрібна).

Налаштування “effort”

Параметр effort визначає, наскільки “ретельно” модель обробляє запит:

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

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

Режими дозволів на зміну файлів

Один із критично важливих параметрів — permission mode:

• Accept edits — Claude автоматично застосовує зміни до файлів без додаткових запитань.
• Ask permission — безпечніший варіант: перед будь‑якими змінами система зупиняється і просить підтвердження.
• Plan mode — спершу формує план змін, а вже потім переходить до редагування (зручно для великих проєктів).

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

Практика: створення простого веб‑інструменту без коду

Щоб показати, як працює Claude Code у десктопному застосунку, демонструється створення невеликого інструменту — рандомного вибірника імен. Усе відбувається в межах однієї папки на комп’ютері.

Крок 1. Підготовка папки проєкту

1. Створити порожню папку в зручному місці, наприклад у “Документах”, і назвати її, скажімо, name-picker.
2. У Claude Code натиснути Select folder, вибрати цю папку й відкрити її.
3. Переконатися, що назва папки відображається вгорі сесії — це означає, що всі зміни відбуватимуться лише в ній.

Це створює чітку “зону безпеки”: Claude Code не торкається файлів поза вибраною директорією.

Крок 2. Створення базової HTML‑сторінки

Перший запит до Claude формулюється як технічне завдання:

• створити один файл index.html;
• додати текстове поле (textarea) для списку імен (по одному в рядок);
• додати велику кнопку “Pick a Name”;
• при натисканні кнопки — виводити випадкове ім’я великим шрифтом у верхній частині сторінки;
• використати чистий, сучасний дизайн зі світлим фоном;
• усе реалізувати в одному файлі на чистому HTML, CSS та JavaScript, без зовнішніх бібліотек.

Після надсилання запиту Claude пропонує створити файл у вибраній папці. У режимі “Ask permission” користувач підтверджує дію (одноразово або “завжди довіряти” цій робочій області).

Перевага десктопного застосунку — вбудований попередній перегляд: сторінку можна одразу відкрити в інтерфейсі Claude Code, протестувати введення списку імен та перевірити, як працює кнопка. Паралельно у файловому менеджері видно, що в папці з’явився index.html.

Крок 3. Додавання “рулетки” перед вибором імені

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

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

Claude оновлює JavaScript‑логіку в index.html, після чого можна знову протестувати сторінку: при натисканні кнопки імена швидко змінюються, створюючи відчуття напруги перед фінальним результатом.

Крок 4. Візуальний “полірування” інтерфейсу

Фінальний етап — невеликий редизайн і покращення зручності:

• додати дружню назву сторінки на кшталт “And the winner is” у верхній частині;
• змінити кольорову схему: використати м’який бірюзовий (soft teal) як основний акцент;
• зробити кнопку “Pick a Name” більшою та додати легкий hover‑ефект;
• після вибору імені додати поруч невелику кнопку “Pick Again” для повторного розіграшу.

Після оновлення коду сторінка отримує заголовок, нову кольорову палітру, більшу кнопку з ефектом наведення та додаткову кнопку для повторного вибору, що з’являється після завершення “рулетки”.

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

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

Додаткові можливості десктопного застосунку Claude

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

Вбудований термінал

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

Бічний чат

Комбінація клавіш Ctrl + ; відкриває side chat — бічну панель для швидких запитань до Claude, не перериваючи основну сесію. Це зручно, коли потрібно уточнити щось по коду чи отримати пояснення, не змінюючи контекст основного завдання.

Вибір елементів інтерфейсу

Ще одна функція — Select elements (швидка клавіша: Ctrl + Shift + S). Вона дозволяє:

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

Таким чином Claude “розуміє”, про який саме елемент ідеться, коли користувач просить змінити стиль чи поведінку.

Гнучке компонування панелей

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

Історія сесій

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

Ліміти використання та моделі як спосіб економії

Claude Code може швидше витрачати usage allowance (дозволений обсяг використання), ніж звичайний чат, оскільки виконує реальні операції з файлами. Якщо ліміт вичерпується:

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

Додаткових “прихованих” списань немає: при досягненні межі система просто ставить паузу.

Що далі: від простих інструментів до автоматизації

Рандомний вибірник імен — лише базовий приклад. Claude Code у десктопному застосунку може:

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

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

Джерело

Claude Code Desktop App: Beginner’s Guide (No Terminal Needed) — YouTube

У технологічному підприємництві часто припускають, що головний двигун успіху — гроші. Однак розмова на подкаст-каналі 20VC with Harry Stebbings пропонує іншу оптику: найуспішніші фаундери рідко рухаються виключно фінансовими стимулами. Їхні справжні мотиви значно складніші — і стійкіші.

Чому гроші — слабкий довгостроковий мотиватор

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

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

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

Що насправді рухає найкращих фаундерів

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

1. Особисте зростання та розвиток

Багатьох засновників приваблює не стільки результат, скільки процес:

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

Компанія для них — це інструмент саморозвитку, а не лише бізнес-актив.

2. Інтелектуальний виклик

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

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

Такі фаундери залишаються залученими не тому, що «треба заробити», а тому, що їм цікаво розв’язувати все складніші задачі.

3. Натхнення та відчуття сенсу

Важливу роль відіграє внутрішнє відчуття, що робота має значення:

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

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

4. Прагнення перемагати

Ще один потужний мотив — бажання вигравати:

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

Йдеться не про «перемогу заради статусу», а про внутрішню потребу доводити складні справи до успішного завершення.

Як це змінює підхід до відбору людей

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

Один із практичних висновків — варто прямо досліджувати мотивацію в інтерв’ю. Запитання на кшталт:

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

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

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

Джерело

YouTube: Founders don’t tend to be motivated by money

У новій хвилі генеративного AI частина творців контенту обмежується «поставити запит — отримати відповідь». Інші перетворюють моделі на повноцінну операційну систему для бізнесу. Підприємиця та блогерка Марина Могилко (канал Silicon Valley Girl) і експертка з AI та колишня лідерка напрямку штучного інтелекту в Amazon Еллі Міллер демонструють саме другий підхід: вони будують навколо Claude та багатoагентних систем цілісні, самозапускаючі робочі процеси, які масштабують контент і продуктивність без збільшення команд.

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

Claude як продакшн-середовище: коли LLM стає центром редакції

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

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

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

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

Окремий Claude-проєкт для кожного каналу: чому контекст вирішує все

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

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

Найпоказовіший приклад — YouTube-проєкт. Він не існує у вакуумі: Claude під’єднаний до бази даних у Notion, де зібрано ключову інформацію про канал. Там зберігаються:

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

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

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

Від поради до системи: як Claude реалізує стратегію generative engine optimization

Навіть маючи сильну внутрішню AI-інфраструктуру, Могилко не відмовляється від зовнішніх стратегів. Їхня цінність — у свіжому погляді та ідеях, які не завжди народжуються всередині команди чи моделі. Показовий кейс — стратегія GEO, generative engine optimization.

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

Замість того щоб наймати окремого спеціаліста з GEO, команда використала Claude як двигун реалізації. Модель допомогла:

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

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

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

Від реактивного до проактивного AI: як працює система з 36 робочих процесів і сотні агентів

Якщо Claude-проєкти Могилко — це приклад глибокої інтеграції однієї моделі в медіабізнес, то система Еллі Міллер демонструє наступний рівень — багатoагентну архітектуру, де AI не чекає запиту, а сам ініціює роботу.

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

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

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

Саме тому вона розміщує свої робочі процеси в середовищах на кшталт Claude Co-Work і Claude Code, де можна планувати запуск задач за розкладом. Агент не чекає, поки його попросять, — він сам стартує в заданий час, збирає інформацію, обробляє її й приходить до людини вже з результатом.

Приклади проактивних агентів: від ранкового брифінгу до «п’ятничного рев’ю» пошти

Щоб зрозуміти, як виглядає така система в повсякденному житті, варто подивитися на конкретні сценарії, які описує Міллер.

Один із них — ранковий брифінг. Поки вона спить, агент збирає й структурує:

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

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

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

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

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

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

AI як команда віртуальних співробітників: нова норма для продуктивних людей

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

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

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

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

У випадку Могилко відповіддю стали окремі Claude-проєкти з глибоким підключенням до Notion і даних каналу. У випадку Міллер — мережа агентів, запланованих у Claude Co-Work і Claude Code, які працюють за розкладом.

Висновок: AI-системи, а не AI-запити

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

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

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

Джерело

The 8 AI Tools That Will Change How You Make Money — Silicon Valley Girl

Локальні великі мовні моделі (LLM) стають дедалі доступнішими завдяки інструментам, які спрощують їх установку та керування. Один із таких інструментів — OpenClaw. На каналі Tech With Tim показано базовий робочий процес: як підключити модель Gemma 4 до OpenClaw і зробити її доступною локально. Нижче — покроковий розбір цього процесу.

Що таке OpenClaw і навіщо працювати локально

OpenClaw — це інструмент, який дозволяє керувати моделями штучного інтелекту через єдиний інтерфейс. Ключова ідея — підняти локальний «gateway» (шлюз), до якого можна підключати різні моделі й потім використовувати їх у своїх застосунках.

Робота з моделлю локально, а не через хмару, дає кілька очевидних плюсів:

• контроль над даними (нічого не йде на сторонні сервери);
• відсутність залежності від зовнішніх API;
• можливість використовувати власне «залізо» (наприклад, Mac mini чи інший домашній сервер).

У цьому прикладі використовується модель Gemma 4, яку OpenClaw може підхопити як локальну.

Базове налаштування: команда openclaw configure

Після встановлення OpenClaw на машину подальші дії виконуються через термінал.

1. Запуск конфігуратора:
   bash
openclaw configure
   Ця команда відкриває інтерактивне меню налаштувань.

2. Вибір моделі:

3. У меню потрібно перейти до пункту model.
4. Навігація здійснюється стрілками на клавіатурі, вибір — клавішею Enter.

5. У списку моделей має з’явитися встановлена модель (зокрема, Gemma 4).

6. Вибір режиму роботи:

7. Серед доступних варіантів важливо обрати local only.

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

9. Налаштування базової URL-адреси:

10. Поле base URL можна залишити без змін — стандартне значення підходить для типового сценарію.
11. Додаткових правок на цьому етапі не потрібно.

Активація моделей Gemma 4 в OpenClaw

У конфігураторі OpenClaw доступний список моделей, які можна активувати.

• У прикладі обираються:
• Alama Gemma 4 latest
• Gemma 4
• Обидві моделі відзначаються у списку, після чого підтверджується вибір (кнопка confirm або Enter).

Для більшості користувачів основною буде саме Gemma 4, але можна активувати кілька варіантів одночасно. Після підтвердження обрані моделі стають «увімкненими» в конфігурації OpenClaw.

Далі потрібно:

• переконатися, що у полі моделі обрано саме встановлену Gemma 4 (або ту, яку ви інсталювали);
• натиснути Enter, щоб зафіксувати вибір;
• перейти до завершення налаштування, натиснувши continue.

Перезапуск gateway: щоб модель стала доступною

Щоб зміни в конфігурації набули чинності, необхідно перезапустити gateway OpenClaw. Це робиться окремою командою в терміналі:

openclaw gateway restart

Після виконання:

• gateway перезапускається з оновленими налаштуваннями;
• обрані моделі (наприклад, Alama Gemma 4 latest і Gemma 4) стають доступними для використання;
• їх можна викликати безпосередньо через OpenClaw у ваших застосунках або інструментах, які інтегруються з цим шлюзом.

Фактично, на цьому етапі локальна LLM-модель уже інтегрована в інфраструктуру OpenClaw і готова до роботи.

Джерело

YouTube: Watch till the end… — Tech With Tim

Як перетворити хаотичну ідею на чіткий технічний опис: AI‑моделі та диктування як новий етап у проєктуванні застосунків

У 2026 році створення застосунку з допомогою штучного інтелекту може бути або майже безболісним, або повним провалом. Розробник і ютубер Tech With Tim у своєму детальному гайді про дев’ятиетапний процес побудови AI‑додатків показує, що ключова різниця — не в інструментах, а в тому, наскільки структуровано ви плануєте продукт до того, як починаєте писати код. Один із найцікавіших аспектів його підходу — використання поєднання AI‑асистента (на прикладі Claude) та голосового диктування (через Wispr Flow), щоб за 30–45 хвилин перетворити «сиру» ідею на повноцінну специфікацію застосунку.

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

Від «хочу щось зробити» до чіткого бачення: навіщо витрачати 45 хвилин до першого рядка коду

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

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

Далі модель підключається до глибшого планування: допомагає структурувати вимоги, ставить уточнювальні запитання, змушує продумати сценарії використання та крайові випадки. Ці 30–45 хвилин — фактично інтенсивний воркшоп, де AI виконує роль технічного співзасновника, який не боїться ставити незручні запитання на кшталт: скільки користувачів має витримувати система, які типи контенту підтримуються, чи потрібні коментарі, приватні повідомлення, модерація.

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

Claude як технічний редактор: як AI збирає специфікацію Creator Circle

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

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

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

Коли достатньо контексту зібрано, модель генерує структурований документ: «Creator Circle MVP Specification». У ньому з’являються розділи на кшталт огляду, опису основного користувача, «job to be done», переліку фіч, нецілей (тобто того, що свідомо не входить у першу версію), а також пропозиції щодо технологічного стека для фронтенду, бекенду, бази даних і розгортання.

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

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

Запитання замість коду: чому варто змусити AI «допитувати» вашу ідею

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

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

чи потрібна підтримка різних типів медіа — лише текст і зображення, чи також відео;

чи будуть публічні й приватні профілі;

чи потрібні коментарі, репости, прямі повідомлення;

який очікуваний обсяг користувачів і як це вплине на вибір інфраструктури.

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

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

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

Wispr Flow: коли голос стає інтерфейсом для проєктування

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

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

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

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

У поєднанні з Claude це створює цікавий робочий цикл: людина говорить — Wispr Flow перетворює це на структурований текст — Claude ставить уточнювальні питання й формує специфікацію — людина знову відповідає голосом. У результаті за відносно короткий час виходить документ, який зазвичай народжується через кілька днів листування в таск‑трекері чи довгих сесій у Google Docs.

Планування як запобіжник проти «нічного vibe‑кодування»

Уся ця методика — від 30–45‑хвилинної сесії з AI до використання диктування — спрямована на те, щоб зробити розробку менш хаотичною. У 2026 році спокуса «просто відкрити AI‑IDE о другій ночі й почати щось генерувати» величезна: інструменти на кшталт Claude Code чи інших код‑асистентів справді дозволяють за години отримати працюючий прототип. Але без чіткої специфікації це часто закінчується тим, що через кілька днів усе доводиться переписувати.

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

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

Для індустрії це означає поступовий перехід від «AI як магічної кнопки» до «AI як партнера в інженерному мисленні». І саме на етапі специфікації цей перехід видно найчіткіше.

Висновок: AI як прискорювач дисципліни, а не заміна інженера

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

Рекомендація витратити 30–45 хвилин на таку сесію перед першим рядком коду виглядає скромною, але в контексті сучасних AI‑інструментів це може бути найважливіша інвестиція часу в усьому проєкті. Claude у ролі технічного співрозмовника й Wispr Flow як швидкий канал введення думок дозволяють зробити цей етап не лише ефективним, а й природним — ближчим до того, як люди насправді обговорюють ідеї вголос, а не як вони змушені їх формалізувати в документах.

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

Джерело

YouTube: How to Make an App With AI – 9 Steps