Огляд інструментів 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

У спільноті AI-інженерів зараз активно обговорюють, як зробити будь-який API по-справжньому доступним для агентів — не лише через HTTP чи CLI, а як «рідний» інструмент у середовищі моделей. Один із тих, хто працює над цим на передовій, — Метт Кері, інженер Cloudflare, який займається MCP (Model Context Protocol) та агентами. На базі досвіду компанії з її гігантським API він окреслює досить конкретне бачення того, яким стане MCP у найближчі роки: безстанні сервери, програмне викликання інструментів через виконання коду, перетворення одноразових планів агентів на стійкі автоматизації та глибока інтеграція MCP у TypeScript‑фреймворки.

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

Безстанні MCP‑сервери: чому пам’ять агента не повинна жити в процесі

Одна з ключових ідей Cloudflare — зробити безстанність базовим патерном для MCP‑серверів. Компанія вже побудувала TypeScript‑SDK для MCP і рухається до того, щоб саме такий підхід став «за замовчуванням».

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

Cloudflare натомість прагне зробити MCP‑сервери максимально схожими на класичні HTTP‑сервіси: кожен запит — самодостатній, сервер не зберігає довготривалий контекст, а будь-яка пам’ять агента живе поза процесом. Це означає, що:

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

Паралельно Cloudflare говорить і про безстанні «agent loops» на боці клієнтів MCP. Ідея в тому, щоб сам цикл планування й виконання дій агентом був організований так, що стан можна вмикати чи вимикати у «хмарно‑нативний» спосіб. Пам’ять, історія, довготривалі профілі користувачів — усе це має бути відокремлено від конкретного процесу, який виконує інструмент чи код.

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

• тримати довготривалу пам’ять у спеціалізованих сховищах (векторні бази, KV, БД),
• масштабувати обробку запитів без прив’язки до сесій,
• легше будувати мультиагентні системи, де кілька агентів працюють з одними й тими самими даними, але через різні MCP‑сервери.

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

Від схем інструментів до коду як головного примітиву

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

Cloudflare очікує, що клієнти MCP поступово перейдуть до програмного викликання інструментів, де головний тул — це примітив виконання коду. Замість десятків чи сотень окремих схем інструментів агент отримує можливість написати фрагмент коду (наприклад, TypeScript), який використовує повноцінний SDK, і передати його в єдиний «code‑execution» інструмент.

У такій моделі:

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

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

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

Одноразові плани агентів як довготривалі автоматизації

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

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

У моделі, яку описує Cloudflare, клієнт MCP має вміти:

• зберегти згенерований скрипт як окремий артефакт,
• дати йому ім’я, опис, можливо, параметри,
• запускати його повторно без повного перепланування,
• прив’язувати до розкладу, подій або тригерів — фактично як cron‑завдання.

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

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

Для розробників це означає, що:

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

Паралельні пісочниці й жорсткий rate limiting: як не дозволити агентам «зламати» ваш API

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

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

У моделі з динамічними воркерами або іншими ізольованими середовищами кожен запуск коду — це окремий «міні‑процес», який може:

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

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

Тому в майбутній екосистемі MCP стають критичними кілька речей:

• глобальні й пер‑клієнтні rate limits на рівні API;
• обмеження на кількість одночасних пісочниць, у яких може виконуватися код;
• політики доступу до мережі з кожної пісочниці (whitelist доменів, заборона зовнішніх запитів за замовчуванням);
• контроль за часом виконання й ресурсами (CPU, пам’ять) кожного скрипта.

Cloudflare вже будує таку модель навколо своїх динамічних воркерів: пісочниці можна конфігурувати так, щоб вони не бачили process.env, не мали доступу до мережі або могли звертатися лише до певних доменів. У поєднанні з rate limiting це створює кероване середовище, де агенти можуть писати й виконувати код, але не можуть випадково (або навмисно) вивести API з ладу.

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

MCP як прапорець у фреймворку: MCP = true для всього стеку

Щоб MCP став по-справжньому масовим, його підтримка має з’явитися там, де живе основна логіка сучасних веб‑додатків, — у фреймворках. Cloudflare планує, щоб підтримка MCP‑серверів перетворилася на легкий middleware або навіть на простий прапорець у великих TypeScript‑фулстек‑фреймворках.

Ідея полягає в тому, щоб:

• MCP TypeScript‑SDK став настільки малим і самодостатнім, що його можна було б вбудувати без суттєвого оверхеду;
• фреймворки на кшталт Next.js могли нативно експонувати всі свої API не лише через HTTP, а й через MCP;
• розробнику було достатньо додати щось на кшталт MCP = true у конфігурацію, щоб увімкнути цей режим.

У такому сценарії один Next.js‑додаток може одночасно:

• обслуговувати тисячі HTTP‑ендпоінтів для класичних клієнтів,
• експонувати ті самі ендпоінти як MCP‑інструменти або як частину SDK для кодового викликання,
• використовувати одну й ту саму кодову базу, типи й бізнес‑логіку.

MCP‑шар у цьому випадку стає тонким middleware, який:

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

Cloudflare очікує, що коли SDK стане достатньо легким, великі API‑провайдери й постачальники сервісів доступності зможуть «увімкнути MCP» для всього свого API одним прапорцем. Це, у свою чергу, стимулюватиме їх переходити до «codemode»‑підходу, де повний API стає доступним агентам через типізований SDK і примітив виконання коду.

Для екосистеми це означає:

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

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

Сьогодні кількість по‑справжньому зрілих MCP‑клієнтів невелика. Cloudflare прямо визнає, що екосистема ще молода, але очікує її швидкого зростання в міру того, як реалізація клієнтів спрощуватиметься.

Кілька факторів мають прискорити цей процес:

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

У такому світі клієнт MCP — це не обов’язково окремий «спеціалізований» застосунок. Це може бути:

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

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

Висновок: MCP рухається до моделі «код + безстанність + фреймворки»

Вектор, який окреслює Cloudflare, доволі чіткий. Майбутнє MCP — це:

• безстанні сервери, які не тримають пам’ять агента в процесі;
• безстанні agent loops, де стан вмикається й вимикається як хмарний ресурс;
• програмне викликання інструментів через примітив виконання коду й типізовані SDK;
• перетворення одноразових агентних планів на стійкі міні‑скрипти й cron‑подібні автоматизації;
• жорсткі rate limits і контроль ресурсів, щоб паралельні пісочниці не ламали API;
• глибока інтеграція MCP у TypeScript‑фреймворки, аж до моделі «MCP = true» у конфігурації.

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

Джерело

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

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

Від одного промпта до трьох референсів

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

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

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

Один генератор замість трьох різних інструментів

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

SeeDengs 2.0 у складі Freepik намагається об’єднати ці етапи в один цикл генерації:

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

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

Коли AI‑відео перестає «виглядати як AI»

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

Саме на цьому кроці результат починає відходити від типового «AI‑почерку»:

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

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

Джерело

YouTube: This AI Hack Changed How I Make Videos

У розмові на подкасті 20VC засновник і CEO Replit Амджад Масад окреслює неприємну для багатьох AI‑оптимістів тезу: моделі для кодування наближаються до стелі своїх можливостей. Не до повної зупинки прогресу, а до асимптотичного плато на S‑кривій, де кожне наступне покращення стає дедалі дорожчим і менш відчутним.

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

S‑крива кодування: від вибухового росту до асимптотичного плато

Масад описує еволюцію моделей для кодування як класичну S‑криву. Перші покоління систем на кшталт GPT‑3 дали відчутний стрибок: автодоповнення коду, генерація шаблонів, прискорення рутини. Наступні хвилі, включно з GPT‑3.5, ще раз змістили планку, але вже не так драматично. Далі — поступове згладжування.

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

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

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

Як Replit обігнав GPT‑3.5 у кодуванні — і чому це було тимчасово

Ще у 2023 році Replit вирішив перевірити, наскільки далеко можна зайти з доменною оптимізацією. Компанія натренувала власні внутрішні моделі для кодування, орієнтовані саме на задачі програмування в середовищі Replit. Результат: ці моделі перевершили GPT‑3.5 на тодішніх кодових бенчмарках.

Цей епізод важливий з двох причин.

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

По‑друге, перевага виявилася тимчасовою. Коли на ринок вийшли нові, значно потужніші моделі на кшталт Claude Opus, розрив скоротився або зник. Масад прямо визнає: намагатися конкурувати з компаніями, які витрачають «десятки, якщо не сотні мільярдів доларів» на розвиток агентів і базових моделей, було б для Replit хибною стратегією.

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

Коли вартість ще не головне: пріоритет продуктивності до моменту плато

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

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

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

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

Саме так Масад інтерпретує, наприклад, кроки Intercom у сфері підтримки клієнтів: компанія може вирішити, що в її домені фронтирні моделі вже не дадуть радикального прориву, і тому варто інвестувати у власну систему, яка краще пристосована до її даних і процесів.

Intercom, 3–6 місяців переваги й чому це може вирішити долю контракту

Для ілюстрації сили спеціалізації Масад наводить приклад Intercom. Компанія публічно заявила, що її власна, спеціально натренована модель для підтримки клієнтів перевершує фронтирні моделі на цьому завданні протягом періоду 3–6 місяців.

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

Масад пояснює це через практику так званих bake‑off — порівняльних тестів, які проводять великі корпоративні замовники. Коли підприємство обирає інструмент на роки вперед, воно часто запускає паралельні пілоти з кількома постачальниками, вимірює якість, швидкість, точність, інтеграцію в робочі процеси. У таких умовах навіть відносно невелика перевага в продуктивності може стати вирішальною.

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

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

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

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

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

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

Але коли:

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

— тоді картина змінюється. З’являється сенс:

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

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

Replit, bake‑off і чому виграє не той, хто дешевший, а той, хто кращий

Replit працює в сегменті, де конкуренція особливо жорстка: інструменти для розробників і «vibe‑coding» платформи, які обіцяють автоматизувати значну частину програмування. За словами Масада, корпоративні клієнти Replit регулярно влаштовують bake‑off, порівнюючи його продукт з «усім, що тільки можна уявити» на ринку.

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

У такій моделі:

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

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

Коли власні моделі стають логічним кроком

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

Він описує кілька умов, за яких fine‑tuning на приватних даних стає особливо привабливим:

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

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

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

У такому сценарії компанія може:

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

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

Висновок: плато як нова можливість, а не кінець інновацій

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

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

• глибоко розуміють свою предметну область;
• мають унікальні дані;
• готові інвестувати у власні, спеціалізовані моделі й fine‑tuning.

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

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

Джерело

Replit CEO: Why the SaaS Apocalypse is Justified & Why Coding Models are Plateauing | Amjad Masad

Локальні великі мовні моделі за останні місяці зробили стрибок у якості: з’явилися відкриті моделі, які вже не виглядають іграшками порівняно з хмарними GPT чи Claude, і при цьому здатні працювати на звичайних персональних машинах. Канал Tech With Tim у великому гайді про Ollama та OpenClaw розбирає, що саме потрібно від комп’ютера, аби локальний AI був не тягарем, а реальною альтернативою хмарі.

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

Локальний AI — не для всіх: коли це взагалі має сенс

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

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

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

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

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

Нові Mac з M‑серією: чому вирішує об’єднана пам’ять

На сучасних Mac з чипами M‑серії (M1, M2, M3 тощо) ключовий параметр для локальних моделей — це не «оперативка» окремо й не VRAM відеокарти, а об’єднана пам’ять (unified memory). Саме її показує пункт «Пам’ять» у вікні «Про цей Mac», і саме вона є спільним ресурсом для CPU, GPU та нейромодулів.

Локальна модель фактично «з’їдає» значну частину цієї об’єднаної пам’яті. Важливо розуміти, що вона не може забрати собі все: системі, додаткам, браузеру, IDE також потрібен простір. Якщо, наприклад, Mac має 32 ГБ unified memory, реалістично розраховувати, що під модель можна виділити приблизно до 20 ГБ, залишивши решту для системи та робочих програм.

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

Є ще один важливий нюанс: вік Mac. Для машин, яким 6–8 років, запуск сучасних локальних моделей майже завжди означає повільну, фруструючу роботу. Навіть якщо формально пам’яті начебто достатньо, старі CPU та GPU, повільніші SSD і загальна архітектура не дозволяють розкрити потенціал моделей. У таких випадках хмарні сервіси часто дають кращий досвід: швидші відповіді, стабільність, відсутність необхідності боротися з обмеженнями старого заліза.

Тому для власників Mac логіка така: якщо це відносно новий M‑серійний ноутбук або десктоп із достатнім обсягом unified memory, локальні моделі — реальний варіант. Якщо ж це стара машина, краще не будувати на ній серйозні очікування щодо локального AI.

Windows і Linux: VRAM важливіша за системну RAM

На Windows‑ПК та Linux‑машинах із дискретними відеокартами Nvidia картина інша. Тут головним обмеженням стає не системна оперативна пам’ять, а відеопам’ять (VRAM) на GPU.

Локальні моделі, оптимізовані під такі конфігурації, намагаються максимально завантажити саме відеокарту. Вони можуть використовувати майже 100% доступної VRAM, і саме цей обсяг визначає, яку модель ви зможете запустити без катастрофічних лагів. Якщо у вас RTX 4090 з 24 ГБ VRAM, це один рівень можливостей. Якщо ж у системі стоїть старіша карта з 8 ГБ VRAM, це зовсім інший клас моделей.

Системна RAM у цьому сценарії відіграє другорядну роль. Вона, звісно, потрібна для ОС і супутніх процесів, але саме VRAM стає вузьким горлечком для LLM. Тому власникам Windows‑ПК, які хочуть серйозно працювати з локальними моделями, варто в першу чергу дивитися на відеокарту, а не лише на загальний обсяг оперативної пам’яті.

Це стосується і локальних серверів, і віртуальних приватних серверів (VPS) під Linux. Якщо планується запускати моделі на віддаленій машині, критично важливо, щоб там був GPU Nvidia з достатнім обсягом VRAM. Без цього навіть найкраща CPU‑конфігурація не компенсує брак відеопам’яті.

У підсумку для Windows і Linux формула проста: обираючи залізо під локальний AI, починайте з GPU і його VRAM. Саме вона визначає, які моделі вам доступні і з якою швидкістю вони працюватимуть.

Чому старі машини програють і коли краще залишитися в хмарі

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

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

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

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

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

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

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

Як підібрати розмір моделі під своє залізо

Навіть маючи відповідний Mac або потужний Windows‑ПК із сучасною відеокартою, легко помилитися на етапі вибору конкретної моделі. Від розміру моделі безпосередньо залежать якість відповідей, швидкість роботи та стабільність системи.

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

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

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

на Windows і Linux — з обсягом VRAM на GPU, який модель зможе використати майже повністю.

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

модель не займає весь обсяг RAM чи VRAM під нуль;

система не починає активно свопити на диск;

відповіді генеруються з прийнятною швидкістю.

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

На Windows‑ПК із 8 ГБ VRAM вибір буде обмежений меншими варіантами моделей. Якщо ж у системі 24 ГБ VRAM, як у RTX 4090, можна дозволити собі значно більші моделі, не жертвуючи швидкістю.

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

Локальні моделі як частина стратегії, а не самоціль

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

Але за цією простотою стоїть жорстка апаратна реальність. На Mac усе впирається в unified memory, на Windows і Linux — у VRAM Nvidia‑карт. Старі машини майже завжди програють, а неправильний вибір розміру моделі може звести нанівець усі переваги локального підходу.

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

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

Джерело

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

У корпоративних командах щоп’ятничні звіти з метриками часто перетворюються на ручну, повторювану роботу: зібрати дані, оновити таблиці, побудувати графіки, написати короткий аналіз. У відео OpenAI показано, як у Workspace ChatGPT налаштувати агента, який бере ці завдання на себе: підтягує дані з Google Drive, рахує показники, будує діаграми, формує текстовий звіт і працює за розкладом.

Підключення до даних: Google Drive як джерело правди

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

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

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

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

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

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

Один із запропонованих підходів — створити окрему «навичку» (skill) для розрахунку метрик. Такі навички:

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

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

Автоматизація за розкладом: щоп’ятниці без нагадувань

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

• задається розклад (Friday cadence);
• вказується стартове повідомлення — достатньо короткої команди на кшталт «run analysis».

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

Прозорість роботи: історія активності та кроки агента

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

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

У демонстраційному сценарії агент:

1. Зчитує дані з електронної таблиці.
2. Запускає код для розрахунку метрик і побудови графіків.
3. Об’єднує результати в структурований readout — готовий до поширення в команді.

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

Джерело

Workspace agents in ChatGPT: Weekly metrics reporting agent — OpenAI

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

Три рівні: від простої класифікації до справжніх агентів

Щоб не загубитися в термінах, варто розділити сучасні AI-продукти на три умовні рівні.

Рівень 1: Класифікація, а не генерація

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

За описом у блозі Google, цей фільтр просто визначає, чи є лист спамом, чи ні. Тобто працює з бінарною класифікацією на кшталт «true/false». Результат — це не новий текст, зображення чи відео, а лише мітка або категорія.

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

• клас (наприклад, «спам / не спам»),
• число,
• ймовірність,

то це не генеративний ШІ і тим більше не агент.

Рівень 2: Генеративний AI без автономності

Другий рівень — генеративний AI, який створює новий контент, але не діє автономно.

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

Однак така система:

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

Тобто це потужний інструмент, але ще не агент у повному розумінні.

Рівень 3: Справжні агентні системи

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

Прикладом є Google Antigravity, де користувач може дати завдання на кшталт «створи сайт», а система:

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

Подібний підхід використовує й Cowork від Anthropic: це не просто генерація тексту, а робота в режимі «співробітника», який може самостійно думати та ітерувати.

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

10-секундний тест: що саме видає продукт?

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

1. Якщо вихід — це:
2. клас («так/ні», «спам/не спам»),
3. число,
4. ймовірність,

то це не генеративний AI. Це рівень 1 — класифікація.

1. Якщо вихід — це:
2. новий текст,
3. нові зображення,
4. нове відео,

які раніше не існували, — це генеративний AI (рівень 2).

1. Якщо система:
2. сама планує кроки,
3. ітерує результат без постійних вказівок користувача,
4. наближається до цілі, виконуючи складні завдання (наприклад, написання коду, побудова сайту),

тоді можна говорити про справжній агентний продукт (рівень 3).

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

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

Для бізнесу це означає:

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

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

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

Source

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