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

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

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

Щоб агент справді міг щось пам’ятати, потрібні інші механізми. Memory bank, RAG, графи зв’язків між фактами, пошук релевантного минулого під конкретний запит, часові пріоритети, оновлення й перевизначення старих знань. Інакше система просто зберігатиме сліди розмови, але не формуватиме з них корисного знання.

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

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

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

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

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

✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ

Продовжуючи тему.

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

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

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

А далі з’являються вже цілком реальні ризики. Неконтрольовані витрати. Випадкові небезпечні дії. Фальшиве відчуття, ніби результату можна довіряти просто тому, що система звучить упевнено. Prompt injection із зовнішніх джерел. Поступове розростання доступів. І, мабуть, найнеприємніше — відчуття, що все працює нормально рівно до того моменту, поки система не помиляється в по-справжньому важливій точці.

Саме тому зрілість агентної епохи, швидше за все, вимірюватиметься не кількістю «магії», а кількістю дисципліни. Лімітами. Розділенням ролей. Вузькими доступами. Approval для небезпечних дій. Логами. Дашбордами. Структурованою пам’яттю. Перевіркою результату. Можливістю відкату.

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

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

Тому що новий навик епохи — це вже не просто вміння користуватися AI. Новий навик — бути менеджером цифрових виконавців.

✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ

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

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

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

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

Так з’явилися операційні системи.

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

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

З’являються все нові агенти. Один пише код. Інший шукає інформацію. Третій керує інструментами. Четвертий аналізує дані.

Але разом із цим виникають ті самі питання.

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

Фактично ми поступово приходимо до потреби в новому рівні системи.

Не просто агентів.

А операційного середовища для агентів.

Можливо, у найближчі роки з’явиться те, що умовно можна назвати Agent OS — система, яка керує агентами так само, як операційна система керує програмами.

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

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

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

Програм уже багато.

Але сама інфраструктура їхнього управління тільки починає формуватися.

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

✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ

​Вітаю всіх з новим тижнем!
Бажаю, щоб він був спокійним, продуктивним і трохи наблизив кожного з нас до тих цілей, які ми для себе поставили.

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

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

OpenAI випустила GPT-5.4 у двох варіантах — Thinking і Pro.

Якщо коротко, Thinking — це основна версія моделі. Саме вона доступна в звичайній підписці ChatGPT Plus за $20. А Pro — потужніший варіант із більш агресивними режимами reasoning, розрахований на складніші задачі. Він доступний у дорожчих тарифах і через API, де його використання вже коштує значно більше.

При цьому попередня модель, GPT-5.3 Instant, теж нікуди не зникає. Вона залишається швидшим і дешевшим варіантом для простіших задач, де максимальна “глибина мислення” просто не потрібна.

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

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

І це, можливо, важливіше за самі бенчмарки.

Так, у тестах GPT-5.4 виглядає сильно, особливо в coding та agentic-задачах. Але самі по собі бенчмарки не дають головної відповіді. Вони показують, як модель поводиться в контрольованих умовах. Але не до кінця показують, чи можна на неї спертися в реальній роботі, де є контекст, неоднозначність і ціна помилки.

Є й інша сторона цієї історії — вартість.

OpenAI подає GPT-5.4 як ефективнішу модель. Але якщо дивитися на практичне використання, все не так просто. Якщо дуже спрощено, вхідні токени — це все, що ви даєте моделі: ваш запит, інструкції, контекст, документи. Вихідні — це те, що модель генерує у відповідь. І саме вихід у таких моделей коштує найдорожче.

У GPT-5.4 базова версія в API коштує $2.50 за мільйон вхідних токенів і $15 за мільйон вихідних. А GPT-5.4 Pro — уже $30 за вхід і $180 за вихід. Тобто мова йде не просто про сильну модель, а про інструмент із дуже дорогим використанням, якщо запускати його на серйозних робочих задачах.

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

Мені здається, саме тут і проходить реальна межа між ефектною демонстрацією та корисним інструментом.

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

Тому мій висновок поки такий: GPT-5.4 виглядає не стільки як “ще одна сильніша модель”, скільки як спроба OpenAI змістити фокус у бік реальної робочої корисності. Саме тому тут так багато уваги до інструментів, computer use, reasoning і довгих сценаріїв роботи.

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

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

✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ

​Минулого тижня склав сертифікацію Databricks Certified Generative AI Engineer Associate.

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

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

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

1. Майже всюди — RAG

Якщо задача пов’язана з документами, PDF, внутрішньою базою знань або support-ботами, правильна логіка мислення дуже часто виглядає приблизно так: chunking → embeddings → vector search → retrieval → augmented prompt → LLM.

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

2. Проблема часто не в LLM

Ще один характерний мотив: якщо система відповідає погано, правильний крок не завжди полягає в заміні моделі. Проблема часто виникає раніше — у retrieval, chunking, metadata filtering, якості контексту, guardrails або форматі виходу.

Тому практичний висновок доволі простий: якщо RAG працює погано, спочатку варто перевірити retrieved context, а не одразу шукати нову LLM.

3. Для extraction-задач не завжди потрібна “агентність”

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

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

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

4. Guardrails — не додаток, а частина системи

Окремий блок питань стосувався harmful inputs, off-topic запитів, витоку конфіденційних даних і unsafe outputs. І логіка тут зазвичай така: detect → block / refuse / redirect, а не «модель сама розбереться».

Тобто safety подається не як опція, а як частина архітектури.

5. GenAI — це вже інфраструктура

Оскільки йдеться про Databricks, іспит помітно зміщений у бік production-мислення: Provisioned Throughput для великих batch-навантажень, pay-per-token для нижчого трафіку, Vector Search + managed embeddings для RAG, MLflow + Unity Catalog + Model Serving для деплою, inference tables для моніторингу.

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

6. Що зараз справді виглядає актуальним

Якщо звести все до кількох напрямів, то ключовими темами виглядають RAG architecture, chunking strategies, embeddings і vector search, guardrails і safety, structured extraction, evaluation, deployment і monitoring.

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

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

✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ

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

Пам’ятаєте, минулого року в мене вже було кілька постів навколо цієї теми. Спочатку — про те, як OpenAI разом з Oracle фактично заходять у будівництво гігантської обчислювальної інфраструктури. Потім — про Stargate, де до цієї історії підключилися SoftBank і Nvidia. А ще трохи пізніше — про досить показовий момент, коли на тлі всього цього OpenAI почала тиснути руку не лише Nvidia, а й AMD, плануючи закупівлі GPU на десятки мільярдів.

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

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

Але на практиці цього вже недостатньо. У США дедалі більше дата-центрів плануються разом із приватними електростанціями, які працюють фактично в обхід звичної логіки підключення до мережі. За даними, на які посилається The Washington Post, ідеться про десятки таких проєктів, і більшість із них були оголошені саме у 2025 році.

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

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

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

Meta будує в Огайо дві приватні газові електростанції загальною потужністю 400 мегават для дата-центру, який споживатиме близько 1 гігавата. Інший проєкт Meta у Техасі передбачає використання понад 800 невеликих газових генераторів, які мають дати 366 мегават для ще одного дата-центру на 1 гігават.
OpenAI разом з Oracle розвивають у Нью-Мексико проєкт Jupiter, який, як зазначено, також використовуватиме великі газові генератори для живлення дата-центру. Окремо згадується і проєкт у Вайомінгу, де дата-центр планують живити модифікованими реактивними двигунами.

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

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

Тобто проблема не виглядає тимчасовою.

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

Продовження — у наступному пості. Там уже про те, що це означає не лише для техіндустрії, а й для цін, енергетики та самої логіки AI-ринку.
✅ Якщо пост був корисним — став 👍
🔔 ПІДПИСАТИСЯ

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

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

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

Є й ще один шар цієї історії — екологічний.

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

І це, мабуть, один із найнеприємніших моментів.

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

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

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

✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ

​Що ви взагалі знаєте про image generation та visual encoders? 🙂

У сучасному image generation зазвичай говорять насамперед про генеративні моделі — і дуже часто саме про diffusion-підхід як один із ключових механізмів генерації. Як приклади тут можна згадати архітектури Stable Diffusion, Imagen або DALL·E.

Але поруч давно існує інший клас моделей — visual encoders. Вони не генерують зображення, а вчаться їх “розуміти”: витягувати змістовні представлення, які потім використовуються для класифікації, пошуку, сегментації та інших vision-задач. Тут як приклади можна згадати CLIP, DINOv2 і SigLIP.

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

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

Але якщо великі pretrained visual encoders уже навчилися витягувати сильні, змістовні представлення зображень, то, можливо, це знання не потрібно будувати заново всередині генеративної моделі. Його можна спробувати використати повторно.

Саме про це нова наукова робота:
One Layer Is Enough: Adapting Pretrained Visual Encoders for Image Generation

На інтуїтивному рівні проблема виглядає так.

Є visual encoder, який уже добре витягує змістовні представлення зображення. Такі представлення корисні, бо вони містять структуру, семантику і вже навчене “розуміння” картинки.

Але те, що добре працює для аналізу зображення, не обов’язково так само добре працює для його генерації.

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

І тут автори з Apple пропонують досить конкретну відповідь на цю проблему.

Основна ідея роботи в тому, що для адаптації pretrained visual encoder до image generation не обов’язково будувати складну багатошарову надбудову. Автори показують, що достатньо дуже простого адаптера — фактично одного шару, який узгоджує представлення encoder-а з генеративною моделлю.

Це і є головний меседж роботи.

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

І це цікаво не лише як технічний результат.

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

Цінність цього paper-а не лише в конкретному рішенні для image generation. Він добре показує більш загальний принцип: не все, що потрібно з’єднати, потрібно з’єднувати складно.

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

✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ

Якщо використовуєш тільки ChatGPT — ти використовуєш 20% того, що доступно.

Доброго понеділка 👋

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

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

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

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

ChatGPT — універсал-підлиза
Найзручніший вхід у світ AI. Швидко, доступно, закриває 80% щоденних задач. Але попросіть знайти діри у вашій ідеї — і він скоріше за все скаже, що ідея чудова.
chatgpt.com

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

Perplexity — пошук, якому можна довіряти
Це не "що думає AI" — це відповідь із реальними джерелами. Дослідити наукову тему, розібратися з конкурентами, зрозуміти новинний фон по ринку. Одразу видно звідки інформація — і можна перевірити.
perplexity.ai

Gemini — коли потрібна глибока аналітика
Добре справляється з великими масивами даних і задачами, де важлива точність, а не швидкість. Нюанс: попри спільний Google-акаунт, прямого доступу до ваших Docs, Gmail і Drive у нього немає за замовчуванням. Але для аналітики це не заважає.
gemini.google.com

NotebookLM — особистий асистент по вашим документам
Завантажуєте PDF, статті, нотатки — і отримуєте можливість ставити питання по всьому масиву одразу. Для дослідників і викладачів, яким потрібно орієнтуватися у великій кількості матеріалу, це справжня зміна режиму роботи.
notebooklm.google.com

Whisper Flow — думайте вголос, а не друкуйте
Щоб AI відповів добре, йому потрібен контекст. І часто набагато ефективніше просто наговорити свої думки голосом, ніж формулювати довгий текстовий промпт. Проблема в тому, що не всі застосунки мають нормальний голосовий ввід. Whisper Flow вирішує це системно і працює в будь-якому додатку.
superwhisper.com

Granola — зустрічі, які не забираються у вас час
Підключається до дзвінка і після зустрічі у вас вже є summary і список задач. Можна бути повністю присутнім у розмові і не думати про нотатки.
granola.ai

Replit / Lovable — ідея в продукт без розробника
Описуєте словами що хочете — отримуєте працюючий прототип. Для підприємців, яким потрібно швидко перевірити гіпотезу, не чекаючи місяцями на розробку.
replit.com / lovable.dev

Збережіть цей пост і спробуйте хоча б один новий інструмент цього тижня.

Який із них вас зацікавив найбільше?

🔔 ПІДПИСАТИСЯ

І знову про Claude, куди ж без нього 😄

Claude Code тепер має повноцінний computer use — може керувати комп'ютером, браузером і десктопними застосунками прямо під час роботи над кодом. Не просто пише код, а бачить екран і діє як людина за комп'ютером.

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

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

Поки що бета. Поки що $200 на місяць за Max план. Поки що не "буде працювати за мене" 😄

🔔 ПІДПИСАТИСЯ

І знову Anthropic. Прямо якась Anthropic week виходить.

Вчора випадково злили частину вихідного коду Claude Code через source maps у npm-пакеті. Я теж подивився. Ось що справді цікаво.

Найкумедніше. За лічені години з'явилися репозиторії де люди вже переписують Claude Code на інші мови. Іронія в тому що роблять це теж не без допомоги самого Claude.

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

Найпрактичніше. В аналітику не йдуть ваш код і локальні файли. Але якщо через Claude Code запускаєте команди — окремі процеси можуть успадковувати environment variables включно з API-ключами, якщо не ввімкнено scrub-режим. Не бекдор, але важливий security detail для тих хто підключає інструмент до продакшен-середовищ.

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

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

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

І це, мабуть, найважливіша новина для всіх хто щось будує сьогодні.

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

🔔 ПІДПИСАТИСЯ

​Останніми днями в стрічці постійно бачу одну й ту саму новину. Anthropic опублікували розбір експерименту, де агенти на базі Claude написали C-компілятор. І реакція була дуже показова: «програмування як професія мертве», «агенти вже самі пишуть код», «розробники більше не потрібні».

Я вирішив не просто прочитати оригінал — а запустити компілятор сам.

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

На це пішло майже 2000 сесій роботи, близько $20 000 витрат на API і приблизно 100 000 рядків коду. У результаті система змогла зібрати Linux 6.9 для кількох архітектур і впоралася з великими проєктами на кшталт FFmpeg і PostgreSQL.

Звучить як революція. Але якщо подивитися уважніше, картина цікавіша.

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

Тепер про мій особистий досвід. Зібрати компілятор на Mac виявилося не зовсім тривіально — довелося внести зміни в код щоб Rust-версія була стабільнішою, і підняти Docker-середовище під це. У процесі знайшов кілька нюансів і відкрив pull request в основний репозиторій. Просту програму на кшталт Hello World він справді збирає. Але на складніших проєктах стає помітно що все працює дуже повільно — і для компілятора це суттєве обмеження.

Зате є момент який мене як досвідченого C++ розробника справді приємно здивував. Структура коду написана дуже добре. Чисті підходи, зрозуміла архітектура, відчуття що це писав досвідчений інженер. Не очікував такого рівня від агентів.

Є ще питання ціни. Близько $20 000 на один експеримент — це вже не «модель сама написала код», а масштабний проєкт з відчутними ресурсами.

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

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

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

Оригінал: anthropic.com/engineering/building-c-compiler
Код: github.com/anthropics/claudes-c-compiler

А ви як сприйняли цю новину — як реальний прорив чи радше як сильний маркетинговий кейс?

🔔 ПІДПИСАТИСЯ

Вітаю з п'ятницею 👋 Ось вам трохи надихаючого — і розважального.

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

Непоганий приклад вайбкодингу. До речі, як ви до нього ставитесь? 😏

Для proof of concept на коліні — працює. Нещодавно за пару годин під вечірній кальян зробили другу лендінг для його бізнесу. І це справді круто.

Але виникає інше питання: якщо це можуть робити всі — чи варто це робити взагалі?

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

Вайбкодинг знижує технічний бар'єр. Але не знижує бар'єр розуміння ринку.

Гарних вихідних — і якщо є ідея для MVP, можливо саме цей вікенд час її перевірити 😄

🔔 ПІДПИСАТИСЯ

MIT Deep Learning Course 🚀

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

MIT випустили безкоштовний вступний курс із глибокого навчання — і це не черговий "AI для всіх".

Тут справжня теорія: архітектури нейромереж від MLP до трансформерів, backpropagation, автоматичне диференціювання, геометрія і інваріантності, теорія узагальнення у високих розмірностях. Плюс практика — комп'ютерний зір, NLP, робототехніка.

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

Збережіть щоб не загубити 👇
youtube.com — MIT Deep Learning

🔔 ПІДПИСАТИСЯ

​Вітаю друзі з понеділком і бажаю продуктивного тижня 👋

Сподіваюсь зараз ви зробили собі каву і відкрили канал прочитати щось цікаве. Як провели вже теплі вихідні?

Я провів їх розбираючи код Claude Code 😄

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

Claude Code зсередини виглядає не як "AI-інструмент". Він виглядає як маленька операційна система. І нейромережева модель там — лише один невеликий компонент.

Навколо неї повноцінний runtime зі своїми правилами: окремий шар пам'яті який працює як routing layer а не сховище фактів, orchestration який вирішує коли і як викликати модель, verify-loop який перевіряє дії перед виконанням, compression контексту щоб агент не захлинувся у власній історії, і безпекові обмеження які не дають системі зробити щось незворотнє.

Це змінює саму оптику того що таке сучасний AI-агент.

Більшість уявляють агента як LLM до якої прикрутили tools: shell, files, web, git. Але як тільки бачиш реальну систему зсередини стає зрозуміло: справжня складність не в тому щоб дати моделі більше інструментів. Справжня складність — в інфраструктурі навколо неї.

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

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

Якщо ми наберемо 500 підписників — обіцяю зробити повний розбір. Порекомендуйте канал другу або колезі якому це може бути корисно 🙏

🔔 ПІДПИСАТИСЯ

Лауреат премії Тюрінга визнав, що AI його здивував 🤯

Дональду Кнуту 88 років. Це автор The Art of Computer Programming, професор Стенфорда і один з найавторитетніших постатей в історії computer science.

Цього місяця він опублікував невелику замітку під назвою Claude's Cycles.

Починаючи з фразы "Shock! Shock!"

Claude Opus допоміг знайти розв’язання задачі, над якою Кнут сам думав уже кілька тижнів. У тексті він прямо називає це різким проривом в автоматичному доведенні та творчому розв’язанні задач. 🧐

І саме це вражає найбільше.

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

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

І тому особливо цікаво бачити, як людина з такою репутацією академічної стриманості починає текст словами "Shock! Shock!".

Читати Есе

🔔 ПІДПИСАТИСЯ

​Нова безкоштовна модель від Nvidia 🎉

Доброго ранку. Буду старатися щосереди давати вам розбори нових наукових статей. Середина тижня — хороший час, щоб трохи розім’яти мозок. ☕️

Сьогодні якраз є хороший привід. 🤔

Nvidia випустила Nemotron 3 Super — відкриту модель, яку явно робили як рушій для агентних задач: довгий контекст, tool use, багатокрокове міркування.

Модель побудована як гібрид Mamba + Transformer + MoE.

Transformer — це вже класика LLM: саме він зробив можливим той стрибок, який ми побачили у GPT-подібних моделях. Його сильна сторона — точні зв’язки всередині тексту, але довгий контекст обходиться дорого з точки зору пам’яті та обчислень.

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

MoE (mixture of experts) — це підхід, у якому на кожному кроці працює не вся модель цілком, а лише потрібні “експерти”. Ідея проста: зберегти потужність великої моделі, але не платити повну ціну за кожен токен. У Nvidia тут ще й Latent MoE: токен спочатку стискається, а вже потім надсилається до експертів. За рахунок цього модель може підключати більше спеціалізованих блоків приблизно за ту саму обчислювальну ціну.

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

Саме так Nvidia і описує backbone Nemotron 3 Super:
оригінал статті Nvidia

Модель доступна для скачування на
Hugging Face.

Для кого і для яких задач це може бути корисно?

Передусім — для великих компаній і команд, які хочуть будувати свої внутрішні агентні системи на власній інфраструктурі, а не просто ходити у зовнішній API. Це може бути корисно для корпоративних асистентів, RAG по великих масивах документації, engineering/copilot-систем, support і ticket automation, а також для сценаріїв, де моделі потрібно тримати довгий контекст, викликати інструменти й працювати з багатокроковими задачами.

Тобто Nemotron виглядає не як модель “просто для чату”, а радше як база для enterprise-agent stack.

🔔 ПІДПИСАТИСЯ

Нова безкоштовна AI-модель від Google 👑

А якщо вам не потрібна велика важка модель для складного enterprise-стека, така як Nemotron 👆, то варто подивитися на інший бік ринку.

Google представила Gemma 4 — нову лінійку відкритих моделей. Google позиціонує її як сімейство open models, які можна запускати на різному залізі від серверів і ноутбуків до телефонів.

Gemma 4 вже можна спробувати через Google AI Studio, а сама модель доступна й через Hugging Face. Тобто це вже цілком практичний інструмент, з яким можна експериментувати.

Google роблять акцент на multimodal-можливостях, long context, code generation, function calling та agentic workflow, а менші моделі прямо орієнтовані на edge-пристрої.

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

Окремо варто звернути увагу на акцент Google на intelligence-per-parameter. Йдеться про те, щоб робити моделі кориснішими на одиницю обчислень.

🔔 ПІДПИСАТИСЯ

​А чи знали ви що всі ми довгий час займалися збором і розміткою даних? 🧐

​Добрий ранок! ☕️ Уже багато років я займаюся навчанням моделей штучного інтелекту. І знаєте що в цьому найскладніше?

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

І в цьому сенсі історія AI дуже показова. Перцептрон запропонували ще у 1957 році. Але по-справжньому потужне навчання стало можливим значно пізніше — коли з'явились обчислення, інфраструктура і, найголовніше, великі обсяги даних.

reCAPTCHA. Оригінальна версія від Луїса фон Ана використовувала відповіді користувачів для розпізнавання відсканованих слів із книжок та газет які погано читав OCR. Людина проходила CAPTCHA — система отримувала безкоштовну human annotation для текстового датасету. Пізніше Google розвинув цю ідею далі: технологія Street View і reCAPTCHA почали працювати разом для точнішого розпізнавання адрес і об'єктів на картах.
Джерело: Google Security Blog

Pokémon GO. Niantic відкрито писали що гравці можуть сканувати реальні локації через камеру смартфона, а ці відео використовуються для побудови dynamic 3D maps цих місць. Тобто гра ставала інтерфейсом для збору spatial data — і гравці робили це добровільно, просто граючи.
Джерело: Niantic

Мені здається тут є сильний урок для всіх хто робить AI-продукти.

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

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

А ви знаєте інші приклади такого підходу?

🔔 ПІДПИСАТИСЯ

​Добрий ранок! ☕️

Якщо ви ще не взялися за великодні паски — ось вам тема на той час поки тісто підходить. 🐣

Ми тут постійно обговорюємо нові моделі: Qwen, Gemma, Nemotron, DeepSeek та інші. І думаю у багатьох виникає логічне питання: окей, Павло розповів про цікаву модель — а що далі? Куди її "вставляти" і як із нею працювати?

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

І тут локальні моделі перестають бути "темою для гіків".

Один із найпростіших способів почати — LM Studio. Безкоштовний додаток. Хто працює на Mac з M-процесором — пощастило, вони чудово підходять для локального інференсу LLM. Завантажуєш модель у кілька кліків, відкриваєш чат і тестуєш. За вечір можна прогнати 3-5 моделей і зрозуміти яка підходить саме вам. За потреби піднімаєш локальний сервер і підключаєш до своїх інструментів через OpenAI-compatible API.

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

Gemma 4 26B від Google — відповіла чудово. Коротко, чітко, з прикладом. Найкращий результат із трьох.

Nemotron 3 Nano 4B — відповідь по суті правильна, але українська мова явно не її сильна сторона. Отримав суміш української і російської в одній відповіді.

Qwen 3.5 9B — з увімкненим thinking думав майже дві хвилини і нічого не видав. Після того як thinking вимкнув — відповів нормально і українську тримає.

Дуже швидко з'являється інше відчуття від open-source моделей. Уже не абстрактне "десь є сильна модель" а цілком практичне: "ось ця мені реально підходить для моїх задач".

Якщо тема зайде — окремо зберу короткий гайд: з чого почати в LM Studio, які моделі першими протестувати і якими промптами їх краще порівнювати.

А ви запускали щось локально? Які враження?

🔔 ПІДПИСАТИСЯ