Snapchat сьогодні — один із небагатьох споживчих соціальних продуктів, що не просто вижив, а й закріпився на глобальному ринку. Понад 1 млрд людей щомісяця користуються сервісом, компанія генерує більш як $6 млрд на рік, а щодня користувачі публікують понад 8 млрд фото з AR-лінзами. При цьому ядро дизайн-функції Snap — це крихітна команда з 9–12 людей без посад і формальної ієрархії, яка щотижня проганяє через себе сотні ідей разом із CEO Евана Шпігеля. Як така структура взагалі працює на цьому масштабі — і чому вона не розвалюється під тиском?

Маленька команда для гігантського продукту

На тлі гігантських продуктових організацій великих технологічних компаній структура Snap виглядає майже парадоксально. Соціальний продукт із мільярдом активних користувачів, десятками мільйонів платних підписників Snapchat Plus (сервіс уже перевищив $1 млрд річного revenue run rate), складною рекламною інфраструктурою та AR-екосистемою — і при цьому всього 9–12 людей у ядрі дизайну.

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

У цьому є кілька практичних наслідків.

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

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

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

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

Дизайн без посад: як відсутність ієрархії зменшує політику

Ще одна принципова особливість Snap — повна відсутність титулів у дизайн-команді. Немає «старших», «головних», «VP of Design» усередині цієї групи. Формально всі — просто дизайнери.

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

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

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

Звісно, плоска структура не означає відсутності лідерства. Воно просто реалізується не через посади, а через процес: регулярні сесії з CEO, спільні перегляди робіт, колективне обговорення напрямків. Влада зміщується від формального статусу до якості мислення й здатності вести ідею від ескізу до shipped-функції.

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

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

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

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

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

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

Сотні ідей на тиждень: як CEO перетворює дизайн на високошвидкісний цикл

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

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

Ця філософія працює на кількох рівнях.

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

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

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

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

Дизайн як навмисне «вузьке горлечко» для цілісності продукту

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

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

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

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

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

Діалог інновацій і операцій: як Snap організовує структуру навколо маленького ядра

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

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

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

Шпігель прямо пов’язує таку модель із ідеями з книжки Safi Bahcall «Loonshots», де описується, як організації можуть одночасно підтримувати «божевільні» проривні проєкти й стабільний основний бізнес. Ключова думка там — не намагатися змішати все в одну масу, а створити умови для керованого обміну між двома режимами роботи.

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

Коли софт — не moat: чому структура дизайну стала відповіддю на копіювання

Snap ще 15 років тому зробив висновок, до якого сьогодні приходить усе більше компаній: сам по собі софт не є захисним ровом. Функції легко копіюються. Історії, AR-ефекти, swipe-навігація, камера як головний екран — усе це з’явилося в Snapchat, а потім було відтворене конкурентами.

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

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

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

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

Висновок: уроки Snap для епохи, де AI стирає переваги софту

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

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

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

Джерело

The AI era has made distribution the most important moat | Evan Spiegel (Snapchat CEO)

Подкаст 20VC з Гаррі Стеббінгсом готує новий епізод із співзасновником AppLovin Адамом Форугі. Короткий тизер розмови окреслює кілька ключових тем, які хвилюють засновників технологічних компаній: нерозуміння з боку оточення, специфічну мотивацію підприємців, високу планку фінансових результатів і особисту ціну, яку доводиться платити за масштабні амбіції.

Коли успіх «не вкладається в голову» і викликає підозру

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

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

Засновницький драйв: орієнтація на перемогу, а не на комфорт

Окремий акцент — на так званому «founder mentality». На думку Форугі, воно має бути сфокусоване на погоні за перемогою. Йдеться не про абстрактний успіх, а про постійне прагнення виграти в конкурентній грі: на ринку, у продукті, в ефективності.

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

Винагорода тільки за справжній прорив

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

Такий підхід створює кілька ефектів:

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

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

Особиста ціна: відсутність присутності та страх «вибуху»

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

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

Для багатьох засновників такий страх стає двосічним мечем:

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

Висновок

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

Джерело

Adam Foroughi on 20VC | Coming Soon

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

Навіщо взагалі скорочувати контекст

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

Якщо контекст стає надто великим:

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

Тому можливість скорочувати контекст — це не просто технічна опція, а інструмент керування якістю взаємодії з ШІ.

Команда для ручного скорочення: як це працює

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

Далі можна:

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

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

Summarize from here: підсумок замість повної історії

Один із ключових варіантів при роботі з контекстом — опція «summarize from here». Вона дає змогу:

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

Користувач може також додатково вказати, що саме важливо залишити в цьому підсумку. Наприклад:

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

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

Чому це корисно для розробників

Керування контекстом через Rint і «summarize from here» дає кілька практичних переваг:

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

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

Джерело

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

У центрі сучасної гонки за користувача стоїть не чергова «революційна» фіча, а здатність доставити продукт до людей. Про це переконливо говорить Еван Шпігель, співзасновник і CEO Snap — компанії, якій вдалося зробити те, що майже нікому не вдавалося за останні півтора десятиліття: побудувати й утримати глобальний consumer‑social продукт. Snapchat сьогодні має понад 1 млрд активних користувачів на місяць, генерує понад $6 млрд на рік, а користувачі щодня публікують понад 8 млрд фото з AR‑лінзами.

На цьому тлі Шпігель формулює тезу, яка звучить майже єретично для стартап‑культури: засновники надто зациклені на product–market fit і недостатньо — на дистрибуції. В епоху AI, коли програмні функції копіюються майже миттєво, саме дистрибуція, а не софт, стає головним «рвом» навколо бізнесу.

Від product–market fit до distribution–market fit

Класична стартап‑мантра останніх двох десятиліть: знайди product–market fit. Зроби продукт, який люди справді хочуть, і ринок сам усе відрегулює. У consumer tech це мислення досі домінує: фаундери одержимо перевіряють гіпотези, міряють retention, NPS, час у додатку — і часто зупиняються саме тут.

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

Контекст змінився радикально порівняно з моментом запуску Snapchat 15 років тому. Тоді мобільні телефони й App Store тільки набирали обертів. Люди активно завантажували нові додатки, експериментували, шукали нові сервіси. Instagram з’явився приблизно за рік до Snapchat, і ринок був відкритий до нових гравців.

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

Шпігель формулює це жорстко: більшість у consumer tech продовжує мислити категоріями «чи є в мене product–market fit?», але реальний диференціатор сьогодні — «чи є в мене distribution–market fit?». Хто знаходить нестандартний, стійкий канал дистрибуції, той і виграє.

Як Snapchat виріс, роблячи ставку не на розмір мережі, а на близькі зв’язки

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

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

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

Такий підхід дозволив Snapchat рости навіть у світі, де вже існували значно більші платформи. Користувачам не потрібно було кидати Facebook чи Instagram; їм потрібно було місце, де вони могли б спілкуватися з найближчими без тиску публічності й «ідеального» образу. Дистрибуція йшла не через масові публічні стрічки, а через приватні, емоційно насичені взаємодії.

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

Коли софт більше не захищає: чому фічі стали товаром

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

Шпігель говорить, що Snap усвідомив це ще 15 років тому: програмне забезпечення саме по собі не є «ровом». Функції легко й дешево копіюються, особливо в середовищі, де великі платформи мають величезні ресурси й миттєвий доступ до мільярдів користувачів. Коли Meta запускає Instagram Plus після того, як Snapchat Plus досяг 25 млн підписників і перевищив $1 млрд річного revenue run rate, це не виняток, а правило: будь-яка успішна фіча рано чи пізно буде клонована.

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

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

TikTok і Threads: два сценарії того, як виглядає дистрибуційний прорив

Щоб побачити, як працює дистрибуція в сучасному consumer‑ландшафті, достатньо подивитися на два рідкісні приклади відносно нових успішних платформ: TikTok і Threads. Обидва кейси, на думку Шпігеля, — це історії не стільки про продукт, скільки про те, як було вирішено задачу дистрибуції.

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

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

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

Обидва кейси підкреслюють головну думку Шпігеля: у сучасному consumer tech успіх нових продуктів майже завжди пов’язаний із тим, як вирішено задачу дистрибуції. TikTok купив її за мільярди, Threads отримав у спадок від Meta. Для стартапів без таких ресурсів або бази користувачів це створює надзвичайно жорсткі умови входу.

AI як прискорювач копіювання: чому «ров» зміщується в дистрибуцію

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

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

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

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

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

Нові платформи й старі гравці: хто отримає перевагу в наступній хвилі

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

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

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

Що це означає для фаундерів consumer‑стартапів

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

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

По‑друге, дистрибуція — це не лише маркетинг і не лише платний перформанс. У випадку Snapchat це була інша логіка побудови мережі; у TikTok — агресивне субсидування обох сторін ринку; у Threads — використання існуючої екосистеми Meta. У кожному випадку дистрибуційний прорив був вбудований у саму бізнес‑модель.

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

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

Висновок: ера, коли виграє не найкращий продукт, а той, хто ближче до користувача

Snapchat — парадоксальний приклад компанії, яка одночасно довела силу продуктових інновацій і продемонструвала їхню крихкість як джерела захисту. Понад 1 млрд MAU, понад $6 млрд річного доходу, 8 млрд AR‑фото щодня — усе це стало можливим завдяки сміливим ідеям. Але сам Шпігель наполягає: справжній «ров» сьогодні — не в коді, а в дистрибуції.

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

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

Джерело

The AI era has made distribution the most important moat | Evan Spiegel (Snapchat CEO)

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

Меґґі Епплтон, staff researcher engineer у команді GitHub Next, яка займається експериментальними й ризикованішими проєктами всередині GitHub, пропонує на це зовсім інший погляд. На її думку, ми стрімко наближаємося до світу, де реалізація — майже розв’язана задача, а справжнім вузьким місцем стає зовсім інше: здатність команд домовлятися, що саме варто будувати й навіщо.

У своєму виступі на каналі AI Engineer вона розбирає, як агентні інструменти змінюють життєвий цикл розробки, чому класичні інструменти на кшталт GitHub, Slack, Jira та Linear погано працюють у такому середовищі й чому «соло-агентна» розробка загрожує командній узгодженості навіть більше, ніж здається на перший погляд.

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

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

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

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

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

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

Вікно імплементації стиснулося до хвилин — і це змінює все

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

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

Агентні інструменти радикально стискають цю часову шкалу. За оцінкою Епплтон, вікно між створенням задачі й появою pull request від агента тепер вимірюється хвилинами. Логіка проста: якщо код можна згенерувати майже миттєво, навіщо довго планувати?

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

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

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

Pull request більше не витягує: старі інструменти не встигають за агентами

Цей зсув у часі оголює фундаментальну проблему: інструменти, якими користуються розробники, створювалися для іншої епохи. GitHub, Slack, Jira, Linear — усі вони проєктувалися під модель, де люди пишуть код, а зміни рухаються відносно повільно.

Епплтон прямо говорить, що в їхньому нинішньому вигляді ці платформи не пристосовані до агентного світу. Вони змушені приймати на себе величезні обсяги виходу від агентів, але їхні базові примітиви — задачі, треди, pull request’и — розраховані на інший темп і іншу структуру роботи.

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

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

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

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

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

Локальні плани агентів і фрагментований контекст: коли кожен грає у свою гру

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

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

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

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

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

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

Найважливіший контекст живе в головах, а не в коді — і агенти самі його не знайдуть

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

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

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

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

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

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

Від соло-продуктивності до колективної: що має змінитися в інструментах

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

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

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

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

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

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

GitHub Next, де працює Епплтон, уже експериментує з такими підходами в дослідницькому прототипі ACE (Agent Collaboration Environment) — мультиплеєрному середовищі для роботи з агентами, яке поєднує чат, спільний хмарний дев-середовище й можливість колективно керувати агентами в реальному часі. Але детальний розбір ACE — окрема тема.

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

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

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

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

Меґґі Епплтон пропонує дивитися на це не як на технічну, а як на організаційну й інструментальну проблему. Реалізація поступово стає розв’язаною задачею; вузьким місцем стає здатність команд створювати й підтримувати спільний контекст.

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

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

Джерело

Collaborative AI Engineering: One Dev, Two Dozen Agents, Zero Alignment — Maggie Appleton, GitHub

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

Що таке Sonnet і чим вона відрізняється

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

Ключові характеристики, на яких робиться акцент:

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

Чому Sonnet радять для 90% щоденних задач

Розробники Anthropic рекомендують Sonnet як основну робочу модель для приблизно 90% щоденних завдань. Логіка такої рекомендації базується на поєднанні трьох факторів:

1. Функціональність
   Sonnet здатна розв’язувати типові задачі розробника: генерація коду, пояснення фрагментів, пошук помилок, пропозиції щодо оптимізації, робота з тестами тощо.

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

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

Для яких сценаріїв Sonnet підходить найкраще

З огляду на описані характеристики, Sonnet логічно розглядати як дефолтний інструмент у таких ситуаціях:

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

• Аналіз великих файлів і фрагментів проєкту
  Завдяки великому контексту можна одночасно «завантажити» значну частину кодової бази для аналізу.

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

• Рутинні задачі в IDE та код-асистентах
  Автодоповнення, підказки, пояснення коду — типові сценарії, де важливі швидкість і вартість, а не максимальна «інтелектуальність» моделі.

Коли варто дивитися в бік інших моделей

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

Джерело

Повний огляд Claude Code – Частина 11 — KODARIK

За останні місяці локальні мовні моделі зробили стрибок у якості й зручності використання. На каналі Tech With Tim вийшов детальний гайд про те, як запускати такі моделі на власному комп’ютері через Ollama і підключати їх до системи автоматизації OpenClaw. У фокусі — вибір конкретних моделей, насамперед Gemma 4 та Gwen 3.6, і те, як за допомогою правильної конфігурації майже повністю відмовитися від дорогих хмарних сервісів на кшталт GPT‑5 чи Anthropic Opus.

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

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

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

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

На протилежному боці — закриті моделі на кшталт Anthropic Opus або GPT‑5.x. Вони залишаються повністю під контролем провайдерів. Доступ до них здійснюється виключно через хмарні API, а запуск на власному комп’ютері технічно й юридично неможливий. Провайдери свідомо «гейтять» ці моделі, монетизуючи кожен запит і інтеграцію, зокрема й у такі системи, як OpenClaw.

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

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

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

Ключова перевага Gemma 4 у контексті OpenClaw — підтримка режимів, необхідних для агентних систем і складних автоматизацій. Модель уміє викликати інструменти, працювати в режимах tools і thinking, а не лише відповідати в стилі звичайного чат‑бота. Для OpenClaw це критично: платформа не обмежується діалогом, а оркеструє послідовності дій, виклики зовнішніх API, роботу з файлами та іншими сервісами.

Якщо модель не вміє коректно працювати з tool calling, вона фактично випадає з поля зору OpenClaw як повноцінний «агент». Тому при виборі локальної моделі важливо дивитися не тільки на розмір і якість тексту, а й на наявність цих режимів. Gemma 4 цю вимогу задовольняє, що й робить її базовою рекомендацією.

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

Як співвіднести розмір Gemma 4 з вашим «залізом»

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

На сучасних Mac з чипами M‑серії ключовим параметром є обсяг уніфікованої пам’яті. Це спільний пул для CPU, GPU та інших компонентів, з якого модель отримує свій «шматок». Якщо, наприклад, на MacBook доступно 32 ГБ пам’яті, це не означає, що модель може зайняти всі 32. Частину забирає система, інші процеси, графічний інтерфейс. У реалістичному сценарії верхня межа для однієї моделі буде помітно нижчою.

У наведеному прикладі з 32 ГБ пам’яті як максимально доцільний варіант розглядається модель, що займає близько 20 ГБ. Це дозволяє уникнути ситуації, коли система починає активно свопити дані на диск, а продуктивність падає до неприйнятного рівня.

На Windows і Linux із відеокартами Nvidia картина інша. Там вирішальним стає не системна RAM, а відеопам’ять (VRAM) GPU. Саме вона використовується для розміщення ваг моделі й обчислень. Якщо, скажімо, у системі стоїть RTX 4090 з 24 ГБ VRAM, то саме ці 24 ГБ і є верхньою межею для розміру моделі. Якщо ж відеокарта старіша й має лише 8 ГБ VRAM, вибір моделі доведеться обмежити значно меншими варіантами.

У випадку Gemma 4 доступні кілька варіантів, які мають приблизні розміри 7 ГБ, 9 ГБ, 18 ГБ і 20 ГБ. Ці цифри безпосередньо пов’язані з кількістю параметрів: чим більше параметрів, тим кращою зазвичай є якість відповіді, але тим більший файл моделі й тим вищі вимоги до пам’яті.

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

У демонстраційному сценарії використовується Gemma 4 31B як приклад моделі, яку можна запускати на машині з 32 ГБ пам’яті. Водночас показано, що 9‑гігабайтний варіант Gemma 4 на тому ж обладнанні відповідає дуже швидко, що робить його привабливим вибором для інтерактивної роботи або сервісів, де латентність критична.

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

Gwen 3.6: потужна альтернатива з вищими вимогами

Поряд із Gemma 4 розглядається ще одна модель — Gwen 3.6. Вона також позиціонується як сильний локальний варіант, сумісний з OpenClaw. Однак ключова відмінність полягає в розмірі: Gwen 3.6 більша за Gemma 4.

Це автоматично піднімає планку вимог до обладнання. Там, де Gemma 4 ще може працювати на відносно скромній конфігурації, Gwen 3.6 потребуватиме більшої кількості RAM або VRAM. Для користувачів із обмеженим бюджетом або ноутбуками без потужних GPU це може стати вирішальним фактором.

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

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

Від Ollama до OpenClaw: як підключити локальні моделі й замінити хмару

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

Ollama — це безкоштовний рушій, який встановлюється на машину й відповідає за завантаження та запуск локальних моделей. Після інсталяції через одну команду з офіційного сайту користувач може завантажити потрібний варіант Gemma 4, використовуючи команду на кшталт ollama pull, а потім перевірити список доступних моделей через ollama list. Для швидкого тесту перед інтеграцією можна запустити інтерактивну сесію в терміналі за допомогою ollama run і переконатися, що модель працює стабільно й із прийнятною швидкістю.

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

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

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

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

Економіка локальних моделей: як OpenClaw допомагає позбутися хмарних рахунків

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

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

Можливість одночасно використовувати кілька локальних моделей у OpenClaw додає ще один рівень оптимізації. Наприклад, можна налаштувати систему так, щоб більші моделі включалися лише для складних завдань, а більшість запитів оброблялися компактними конфігураціями на кшталт 7–9‑гігабайтної Gemma 4. Це зменшує навантаження на апаратну частину й дозволяє ефективніше використовувати ресурси.

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

Висновок: локальні моделі плюс OpenClaw як новий базовий стек

Ситуація, коли якісні мовні моделі були доступні лише як хмарний сервіс із високою ціною за використання, поступово змінюється. Сімейство Gemma 4, модель Gwen 3.6 та інші відкриті LLM демонструють, що потужний AI можна запускати на власному обладнанні, а не лише в дата‑центрах великих компаній.

У поєднанні з Ollama як рушієм для локального запуску й OpenClaw як платформою для інструментів і агентів, ці моделі перетворюються на повноцінну альтернативу хмарним API. Вибір правильної конфігурації — від 7‑ до 20‑гігабайтних варіантів Gemma 4, а також зважене використання більшої Gwen 3.6 — дозволяє адаптувати систему під конкретне «залізо» й робочі сценарії.

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

Джерело

YouTube: Local Models Got a HUGE Upgrade – Full Guide (Ollama/OpenClaw)

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

Прогноз як команда, а не факт

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

• Прогноз погоди не впливає на дощ.
• Прогноз щодо людини — впливає на її життя.

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

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

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

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

Ринки прогнозів, алгоритми і спокуса маніпуляції

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

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

Той, хто має достатньо ресурсів, може не просто «вгадувати» майбутнє, а впливати на нього:

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

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

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

Алгоритмічна несправедливість: коли майбутнє не можна спростувати

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

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

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

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

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

Особливо гостро це проявляється в страхуванні. Індивідуалізовані прогнози ризику:

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

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

Між безпекою й авторитаризмом: що робити з «неминучим» майбутнім

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

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

Історичні паралелі тут промовисті:

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

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

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

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

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

Як не стати заручником «тиранічних» прогнозів

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

Звідси кілька практичних орієнтирів:

• Не плутати прогноз із фактом. Будь-яке твердження про майбутнє — це завжди гіпотеза, а не опис реальності.
• Розпізнавати приховані накази. Коли вам кажуть, що «всі перейдуть на X» або «інакше ніяк», варто запитати: кому це вигідно і які альтернативи замовчуються?
• Остерігатися риторики неминучості. «Іншого шляху немає» — це політична позиція, а не науковий факт.
• Захищати простір для спротиву. Там, де прогнози загрожують правам і свободам, доречна не адаптація, а свідоме протистояння.

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

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

Джерело

Beware the Power of Prediction | Carissa Véliz | TED

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

Стратегічні задачі: планування та архітектура — зона для Claude Opus

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

Йдеться про такі типи задач:

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

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

Реалізація функціоналу: для щоденної розробки — Claude Sonnet

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

Типові задачі для Sonnet:

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

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

Прості правки: коли достатньо Haiku — або взагалі без агентів

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

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

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

Висновок: відповідність моделі задачі — ключ до ефективності

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

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

Source

Повний огляд Claude Code – Частина 13 — KODARIK

У розмові на каналі The Pragmatic Engineer з Мартіном Клеппманном, автором книжки Designing Data-Intensive Applications, йдеться про те, що надійність великих технічних систем часто підривають неочевидні й навіть кумедні фактори. Ці історії з реальних постмортемів показують: серйозні збої можуть початися з абсолютно буденних речей — від морських хижаків до… корів.

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

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

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

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

Чому «рідкісні збої» — небезпечна ілюзія

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

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

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

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

Надійність як робота з «дивними» крайовими випадками

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

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

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

Джерело

Martin Kleppmann: Amusing ways large systems fail — The Pragmatic Engineer

Онлайн‑інструмененти на базі ШІ дедалі частіше переходять на модель оплати за використання, і розуміння лімітів стає критично важливим для розробників. У свіжому огляді від каналу KODARIK розбирається, як саме влаштована система лімітів у Claude Code на тарифі Pro та чому економія токенів має значення.

Два типи лімітів: п’ятигодинний і тижневий

У Claude Code тариф Pro за $20 працює не просто з абстрактним «лімітом токенів», а з двома окремими обмеженнями:

• П’ятигодинний ліміт
• Тижневий ліміт

Інтерфейс сервісу показує обидва показники внизу екрана:

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

Наприклад, можна бачити ситуацію, коли:

• п’ятигодинний ліміт використано лише на 1%;
• тижневий — уже на 87%.

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

Що означає «умовна кількість токенів на 5 годин»

Логіка роботи п’ятигодинного ліміту виглядає так:

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

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

Чому важливо підбирати моделі під завдання

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

Ключові наслідки:

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

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

Що відбувається після вичерпання ліміту

Якщо умовна кількість токенів, виділена на п’ятигодинний період, вичерпана:

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

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

Джерело

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

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

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

Ollama як базовий шар для локальних моделей

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

Ollama — це безплатний застосунок, який встановлюється на комп’ютер і дозволяє завантажувати та запускати локальні AI‑моделі. Він працює як на macOS, так і на Windows та Linux, а також може бути розгорнутий на віртуальному приватному сервері. Ключова ідея проста: замість того, щоб щоразу звертатися до хмарних моделей на кшталт GPT‑5 чи Anthropic Opus (які взагалі не можна запускати локально через політику провайдерів), користувач отримує локальний «двигун», що працює з відкритими моделями.

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

Саме Ollama стає рекомендованим інструментом для тих, хто хоче:

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

Встановлення та оновлення Ollama: один рядок у терміналі

Одна з причин, чому Ollama швидко набирає популярність, — максимально спрощений процес інсталяції. Незалежно від того, чи йдеться про macOS, Windows, Linux або VPS, базовий сценарій однаковий: користувач відкриває термінал і запускає одну команду, скопійовану з офіційного сайту Ollama.

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

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

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

Завантаження моделей: ollama pull і вибір варіанта Gemma 4

Після встановлення Ollama наступний крок — завантажити конкретну модель. Саме тут у гру вступає команда ollama pull. Вона відповідає за те, щоб «витягнути» з репозиторію потрібний варіант моделі й зберегти його локально.

У якості прикладу розглядається сімейство Gemma 4 — одна з найновіших і найперспективніших локальних моделей на момент запису гайда. Gemma 4 цікава тим, що підтримує виклик інструментів (tool calling) і різні режими роботи, включно з «tools» та «thinking». Це критично для інтеграції з OpenClaw та іншими агентними платформами, де модель має не лише відповідати на запити, а й ініціювати дії через зовнішні інструменти.

У лінійці Gemma 4 доступні кілька варіантів, що відрізняються кількістю параметрів і розміром файлу. Серед згаданих конфігурацій — моделі приблизно на 2, 4, 26 і 31 мільярд параметрів, із розмірами близько 7, 9, 18 і 20 ГБ відповідно. Логіка проста: що більше параметрів, то вища якість і складність моделі, але тим більший обсяг пам’яті вона потребує.

Перед виконанням ollama pull користувач має визначитися з тим, який саме варіант Gemma 4 відповідає його апаратним можливостям. На практиці це означає, що розмір моделі має бути меншим за доступний обсяг пам’яті:

• на сучасних Mac з чипами M‑серії обмеженням є обсяг уніфікованої пам’яті (RAM, спільної для CPU та GPU);
• на Windows і Linux з відеокартами Nvidia ключовим параметром стає обсяг відеопам’яті (VRAM), а не системної RAM.

Наприклад, на Mac із 32 ГБ уніфікованої пам’яті як верхню межу можна розглядати модель, що займає близько 20 ГБ. У такій конфігурації автор гайда орієнтується на Gemma 4 31B як максимально великий варіант, який ще можна комфортно запускати. Водночас для більшості користувачів компромісним вибором стає модель на кшталт Gemma 4 із розміром близько 9 ГБ: вона дає відчутно кращу якість, ніж найменші варіанти, але не вимагає топового заліза.

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

Керування локальними моделями: ollama list та ollama run

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

Команда ollama list виводить перелік усіх моделей, які вже завантажені локально. Це свого роду «інвентаризація» — вона дозволяє швидко перевірити, чи справді потрібна модель є в системі, які версії доступні, і не дублювати завантаження. Для користувачів, що експериментують із кількома варіантами Gemma 4 або комбінують її з іншими моделями на кшталт Gwen 3.6, це особливо зручно: можна бачити повну картину локального «зоопарку» моделей.

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

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

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

Серверний режим і доступність API: ollama serve та запуск у фоні

Щоб локальна модель стала частиною більшого інструментарію — наприклад, щоб її можна було під’єднати до OpenClaw замість хмарної LLM, — одного лише інтерактивного терміналу замало. Потрібен серверний режим, у якому Ollama відкриває локальний API‑ендпоінт, до якого можуть звертатися інші програми.

У типовому сценарії, коли зовнішній інструмент (зокрема OpenClaw) намагається підключитися до локальної моделі через Ollama, може виникнути ситуація, коли з’єднання не встановлюється. Якщо OpenClaw не може «достукатися» до сервера Ollama, це означає, що той просто не запущений у режимі сервісу. Рішення в такому випадку — виконати команду ollama serve.

ollama serve запускає сервер Ollama, який слухає локальний порт і надає API для запитів. Після цього OpenClaw або будь-який інший клієнт, налаштований на роботу з локальним ендпоінтом, може надсилати запити до моделі, отримувати відповіді й використовувати їх у власній логіці. Це ключовий крок для переходу від «іграшкового» використання в терміналі до реальної інтеграції в робочі процеси.

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

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

Локальні моделі як альтернатива хмарі: роль Ollama в екосистемі

У ширшому контексті Ollama виступає не лише як утиліта для завантаження й запуску моделей, а як ключовий елемент стратегії відмови від повної залежності від хмарних провайдерів. Хмарні моделі на кшталт GPT‑5 чи Anthropic Opus залишаються закритими й не можуть бути запущені локально: доступ до них суворо контролюється через платні API. Це створює як фінансові, так і технічні обмеження, особливо для проєктів із великими обсягами запитів.

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

Саме тут важливою стає дисципліна роботи з інструментами на кшталт Ollama. Правильне встановлення через офіційну команду, своєчасне оновлення, усвідомлений вибір моделі (наприклад, відповідного варіанта Gemma 4), контроль локального набору моделей через ollama list, тестування продуктивності через ollama run і коректний запуск серверного режиму через ollama serve — усе це перетворює локальну LLM із експерименту на стабільний компонент інфраструктури.

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

Висновок: від однієї команди до робочої локальної LLM

Щоб запустити локальну модель сьогодні, не потрібно бути фахівцем із машинного навчання чи DevOps. Достатньо кількох чітких кроків, у центрі яких — Ollama. Один рядок у терміналі з офіційного сайту встановлює або оновлює інструмент. Команда ollama pull завантажує обраний варіант моделі, наприклад Gemma 4 у конфігурації, що відповідає можливостям вашого заліза. ollama list дозволяє контролювати локальний набір моделей, а ollama run — миттєво перевірити їхню роботу в інтерактивному режимі.

Коли ж постає завдання інтегрувати локальну модель у складнішу систему, на кшталт OpenClaw, у гру вступає серверний режим. Якщо зовнішній інструмент не бачить локальну модель, варто переконатися, що запущено ollama serve або що застосунок Ollama працює у фоні через системний лаунчер. Після цього локальна LLM стає повноцінним API‑сервісом, який можна використовувати в автоматизаціях, агентах і внутрішніх інструментах.

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

Джерело

Local Models Got a HUGE Upgrade – Full Guide (Ollama/OpenClaw)

OpenAI показала новий сценарій використання workspace-агентів у ChatGPT: Codex-потужний агент Slate, який автоматизує перевірку запитів на програмне забезпечення, дотримання політик і створення IT‑тикетів.

Що таке Slate і навіщо він потрібен

Slate — це агент для команд, який бере на себе рутинну частину процесу погодження нового софту. Він:

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

Ключовий елемент роботи — так звані skills (навички). Це структуровані інструкції, які описують найкращі практики й правила, за якими агент має діяти. Завдяки skills Slate працює послідовно й передбачувано, а не як «чорна скринька», що щоразу приймає рішення по‑новому.

Як агент використовує skills і зовнішні системи

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

• Веб-дослідження: пошук інформації про запитаний інструмент, його можливості та репутацію.
• Перевірку списків затвердженого ПЗ: звіряння з внутрішнім переліком дозволених сервісів і програм.
• Оцінку додаткових критеріїв: відповідність політикам безпеки, ліцензування, сумісність з поточним стеком.
• Аналіз сигналів із систем: використання даних з інструментів на кшталт Jira чи інших корпоративних систем для ухвалення рішення.

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

Якщо потрібне втручання людини чи технічна дія (наприклад, закупівля ліцензій або додавання нових користувачів), Slate автоматично ескалує запит до IT‑команди.

Інтеграція зі Slack і Jira: сценарій роботи

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

1. Співробітник надсилає запит у Slack. Наприклад, йому потрібен високоякісний інструмент для запису відео‑демо.
2. Slate приймає запит і запускає свій skill. Агент досліджує запитаний інструмент, порівнює його можливості з уже затвердженими аналогами в компанії.
3. Формує відповідь користувачу. У Slack зʼявляється рекомендація: чи варто використовувати цей інструмент, чи є краща альтернатива з наявного стеку.
4. Автоматично створює Jira‑тикет. Якщо для надання доступу потрібна участь IT (наприклад, закупити додаткові ліцензії або розширити кількість місць), агент самостійно відкриває відповідний тикет із чітко прописаними наступними кроками.

Таким чином, високочастотні та часочутливі запити на ПЗ обробляються без постійної участі IT та закупівельних команд, а користувачі швидше отримують інструменти, необхідні для роботи.

Чому це важливо для команд IT та закупівель

Автоматизація ревʼю програмного забезпечення через workspace-агенти дає кілька помітних ефектів:

• Зменшення навантаження на IT і procurement. Типові запити обробляються без участі людини, фахівці підключаються лише до складних або нетипових кейсів.
• Швидше розблокування користувачів. Співробітники менше чекають на погодження інструментів, що напряму впливає на продуктивність.
• Послідовне дотримання політик. Skills фіксують правила й найкращі практики, тому процес стає відтворюваним і контрольованим.
• Прозорі наступні кроки. Автоматично створені Jira‑тикети містять чіткі інструкції, що зменшує кількість уточнень і непорозумінь.

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

Джерело

Відео: Workspace agents in ChatGPT: Software review agent — https://www.youtube.com/watch?v=7ZVYmoqqnCg

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

Британський інженер і викладач Метт Поко́к, відомий за своїми матеріалами про TypeScript та AI-асистовану розробку, намагається відповісти саме на це запитання. На воркшопі «AI Coding For Real Engineers», який триває близько двох годин і орієнтований на практику, він показує не лише техніки роботи з LLM, а й те, як побудувати сам формат сесії: від логістики залу до того, як ставити запитання й не «вбити» модель гігантським контекстом. Наступного дня Поко́к виходить уже в ролі ключового доповідача з розширеною версією своїх ідей, але саме воркшоп дає рідкісну можливість побачити, як ці ідеї працюють у живому середовищі.

Дві години замість «магічного шоу»: чому формат має значення

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

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

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

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

Публічний репозиторій як «поле бою»: як організовано практику

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

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

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

Такий підхід одразу задає кілька рамок.

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

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

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

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

Два зали, один воркшоп: як працює стримінг і асинхронне Q&A

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

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

Поко́к відверто говорить, що не любить традиційні Q&A-сесії саме через їхню недемократичність: слово отримують найгучніші й найнапористіші, тоді як решта аудиторії лишається статистами. Щоб уникнути цього, воркшоп використовує асинхронний інструмент для запитань — за принципом Slido.

Учасникам пропонують «зайти в асинхрон» — відкрити посилання на Q&A-сервіс, поставити свої запитання й голосувати за чужі. Уже на старті в інтерфейсі з’являється характерне запитання з залу: «Чому ми маємо чекати до 15:45? Зал переповнений, двері зачинені». Поко́к погоджується з емоцією й фактично демонструє, що цей канал справді працює: питання з’являються, читаються й обговорюються в реальному часі.

Такий формат дає кілька важливих переваг.

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

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

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

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

Від «чатиків» до робочих процесів: для кого насправді цей воркшоп

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

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

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

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

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

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

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

«Мементо» для LLM: чому контекст краще скидати, ніж стискати

Ще одна ключова ідея, яка проходить через воркшоп, — ставлення до контексту як до чогось радикально крихкого й одночасно повністю керованого. Поко́к порівнює LLM із головним героєм фільму «Memento», який постійно втрачає пам’ять і повертається до базового стану.

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

Поко́к показує типовий життєвий цикл однієї сесії:

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

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

потім — фаза імплементації, де відбувається власне написання коду;

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

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

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

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

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

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

Воркшоп як прототип майбутніх процесів розробки

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

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

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

Стримінг в оверфлоу-зал і асинхронне Q&A через Slido-подібний інструмент нагадують розподілені команди, де учасники перебувають у різних часових поясах і просторах, але мають спільний інформаційний канал і механізм пріоритизації запитань.

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

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

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

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

Формат події — дві години живої роботи з публічним репозиторієм, стримінгом в оверфлоу-зал і асинхронним Q&A — демонструє, як можна масштабувати навчання й взаємодію, не втрачаючи відчуття залученості. А фокус на «розумній» і «тупій» зонах LLM, мінімальному системному промпті, очищенні контексту й контролі за кількістю токенів показує, що успіх залежить від того, наскільки уважно інженери ставляться до обмежень моделей.

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

Джерело

https://www.youtube.com/watch?v=-QFHIoCo-Ko