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

Про те, як народилися GDPval, Frontier Science Olympiad, Frontier Science Research та внутрішній AGI Index, розповідає Теджал Патвардган, керівниця команди frontier evals в OpenAI, у розмові на подкасті компанії. Її команда відповідає за те, щоб зрозуміти, де насправді перебувають найпотужніші моделі й куди вони рухаються.

Від тестів до реальних професій: народження GDPval

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

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

Відправна точка виявилася несподівано приземленою: офіційна статистика праці. У США Bureau of Labor Statistics публікує детальні переліки основних професій і типових завдань у кожній з них. Усередині OpenAI сформулювали запитання майже буквально: якщо є список «топ‑робіт» і «топ‑завдань» — від фінансового аналізу до юридичних меморандумів і написання дослідницьких текстів, — чи можна змусити модель виконувати саме їх, у тому вигляді, як це роблять люди?

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

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

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

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

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

Коли бенчмарк стає надто легким

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

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

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

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

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

AGI Index: внутрішній CPI для штучного інтелекту

У публічному просторі розмови про «AGI‑тести» тривають роками, однак усередині OpenAI вирішили не прив’язуватися до одного-двох сакральних екзаменів. Замість цього з’явився AGI Index — внутрішній інструмент, натхненний класичною економічною статистикою.

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

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

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

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

Frontier Science: від олімпіад до реальних дисертацій

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

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

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

Другий рівень — Frontier Science Research. Тут завдання вже нагадують справжню наукову роботу, а не задачник. OpenAI зібрала корпус незавершених текстів із біології, хімії та фізики від PhD‑дослідників і професорів: фрагменти дисертацій чи статей, які ніколи не публікувалися. Вони стали основою eval‑у.

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

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

Від метрів до ринку праці й науки

Усі ці ініціативи — GDPval, Frontier Science Olympiad, Frontier Science Research, AGI Index — зафіксували один і той самий зсув: від вимірювання «розумності на папері» до спроб оцінити, наскільки моделі насправді корисні в роботі й науці.

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

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

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

Висновок: вимірювати не просто IQ, а вплив

Поступове насичення академічних бенчмарків змусило OpenAI радикально змінити підхід до оцінки моделей. GDPval дав перший інструмент, щоб подивитися на економічний ефект: наскільки добре ШІ справляється з конкретними завданнями з реальних професійних описів. Frontier Science‑ініціативи перевели ту саму логіку в науку: від олімпіад до незавершених дисертацій і далі, до лабораторних експериментів.

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

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

Джерело

Подкаст OpenAI: “Why Tejal Patwardhan stopped underestimating the models – Episode 21”

Коли OpenAI випустила перші версії своїх мовних моделей, академічні тести з природної мови, шкільні іспити й класичні NLP‑бенчмарки ще могли щось сказати про прогрес. Сьогодні для команди frontier evals, яку очолює дослідниця Tejal Patwardhan, це вже радше історичні артефакти, ніж інструменти вимірювання. Моделі стали настільки сильними, що старі шкали просто «зламались» — і довелося переосмислити, як взагалі вимірювати інтелект систем, здатних писати код, керувати комп’ютером і взаємодіяти з наукою та реальним світом.

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

Як моделі «переросли» академічні тести

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

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

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

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

SWE‑bench Verified і межа «насичення»

Одним із символів цього перелому став SWE‑bench. Це був популярний в індустрії тест для оцінки здатності моделей розв’язувати реальні задачі розробників. Здавалося б, серйозна планка: робота з живими Python‑кодобазами, інтегровані тести, реальний девелоперський воркфлоу.

У OpenAI пішли далі і зробили складнішу версію — SWE‑bench Verified. Цей бенчмарк «тестував, наскільки добре модель може взаємодіяти з реальними кодовими базами в Python, як Django, завершувати PR‑и й проходити юніт‑тести». На той момент це був відчутний крок уперед: замість штучних задач — конкретні баг‑репорти, патчі, прогін тестів.

Але навіть він досить швидко втратив гостроту. Patwardhan описує «кризу evals», коли команда тренувала «послідовно кращі моделі, а на SWE‑bench вони виглядали приблизно однаково, бо вже робили це дуже добре». Іншими словами, крива можливостей продовжувала рости, а бенчмарк уже не міг розрізнити рівні.

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

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

Benchmaxxing: спокуса «косметичного прогресу»

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

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

Наслідок очевидний: «користувач отримує модель, яка добре виглядає в маркетинговій презентації, але в реальному використанні “це не зовсім те, на що я розраховував”». Саме тому Patwardhan не вагається: «загалом погано. BenchMaxxing — погано».

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

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

Від шкільних задач до реальної роботи

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

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

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

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

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

Коли бенчмарки ламаються: помилки, меморизація і «хакнуті» eval‑и

Ще одна причина, чому старі тести перестали бути корисними, — їхня крихкість. Patwardhan наводить приклад: оригінальний SWE‑bench виявився наполовину зламаним — «половина задач була або поламана, або недостатньо специфікована». Попри це, на ньому публікувалися результати як на серйозному yardstick для індустрії.

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

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

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

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

Виміряти те, чого ще немає

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

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

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

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

Джерело

OpenAI Podcast — Why Tejal Patwardhan stopped underestimating the models — Episode 21

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

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

Замість скролу й курсів: перший крок — інструменти

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

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

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

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

Перехід у «build mode»: чому споживання не працює

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

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

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

Один день на налаштування: чому «система спочатку, плоди потім»

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

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

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

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

Чому «одним пострілом» не буде — і чим допомагає терпіння

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

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

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

Від чат‑бота до «будь‑якої знаннєвої роботи»

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

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

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

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

Висновок: день роботи проти року відчуття FOMO

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

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

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

Джерело

AI-First Playbook: Do a Team’s Work With AI (2026) | Peter Yang

Пітер Янґ — колишній продакт-менеджер Reddit, Meta та Roblox, який пішов із корпорацій, щоб працювати соло. Сьогодні він веде велику розсилку, записує подкасти й запускає додатки, максимально спираючись на AI‑системи. Але попри майже тотальну автоматизацію, одна тема для нього принципова — не перетворити власну творчість на «AI‑слоп», масовий бездушний контент, який штампує нейромережа.

У розмові на каналі Silicon Valley Girl Янґ детально розбирає, де саме проходить межа між продуктивністю та деградацією смаку, чому останні 10% роботи мають залишатися за людиною й як він сам захищається від навали «слопу» навіть усередині власних AI‑скриптів.

Останні 10%: зона, де AI закінчується і починається автор

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

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

«Може, останні 10% я маю вручну змінити… Я завжди наголошую: останні 10% ти маєш додати свій людський дотик. Не можна просто “AI‑слопіфікувати” все», — каже він.

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

Коли «слоп» стає вірусним — і чому це демотивує

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

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

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

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

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

Страх перед «слопізацією» власних систем

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

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

«Особисто я дуже хвилююся, що все стане “слопі”. AI просто почне додавати речі, я їх не читаю — і все перетворюється на суперслоп, якщо воно супердовге», — зізнається Янґ.

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

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

Як Янґ «очищає» свої AI‑інструкції

Щоб не потонути у власних же AI‑правилах, Янґ вводить ще один рівень захисту — «редактора skills». Це теж окремий skill, але його завдання суто санітарне, без «чарівної» автоматизації.

Він описує його як «дуже базовий». Цей редактор переглядає текст інших skills, шукає дубльовані інструкції або відверто «слопний» контент і намагається їх прибрати. До того ж Янґ прямо просить систему тримати кожен skill в межах однієї сторінки.

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

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

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

Принципи замість хайпу: як не «з’їхати» в гонитву за переглядами

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

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

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

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

Людський дотик як конкурентна перевага

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

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

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

Джерело

AI-First Playbook: Do a Team’s Work With AI (2026) | Peter Yang

Пітер Янґ — колишній продакт-менеджер Reddit, Meta та Roblox — сьогодні самостійно веде велику ньюзлетер‑аудиторію й запускає нові продукти майже повністю на базі AI. У розмові на каналі Silicon Valley Girl він описує власний «AI-first playbook» і пропонує простий, але дуже приземлений фреймворк з п’яти рівнів використання штучного інтелекту — від «поставив питання в чаті й закрив вкладку» до персональної системи агентів, які реально виконують роботу.

Рівень 1: AI як розумніша пошукова система

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

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

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

Рівень 2: AI в повсякденній роботі, але в межах чату

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

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

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

Рівень 3: AI як інструмент прототипування

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

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

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

Рівень 4: персональні додатки замість разових хаків

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

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

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

Рівень 5: персональний агент, що забирає з вас знанняву роботу

П’ятий рівень — те, до чого Янґ підводить усю схему. Тут AI стає «персональним агентом», який намагається максимально автоматизувати й спростити все, що можна.

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

На цьому рівні AI:

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

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

Як перейти від рівнів 1–2 до 5: «припиніть жити в чаті»

Ключова порада Янґа для тих, хто застряг на рівні питань‑відповідей або примітивних проєктів, — кардинальна, але проста: «найпрактичніший крок — перестати користуватися чатботом і почати користуватися Codex або Claude Code».

Його логіка така. Спеціалізовані інструменти на кшталт Codex і Claude Code:

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

Це і є місток від другого рівня (коли ви копіюєте з чату в документи) до п’ятого (коли AI сам змінює документи чи збирає дані).

«Personal OS»: папка як операційна система для життя й роботи

Наступний крок Янґ формулює дуже конкретно. Він радить у Codex або Claude Code створити нову папку, умовно «Personal OS», і почати з побудови тут своєї системи.

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

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

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

Чому варто відмовитися від «проєктів» у звичайних чат‑моделях

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

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

Висновок: від разових відповідей до партнерства

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

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

Ключовий практичний крок, який Янґ пропонує зробити вже цього тижня, — вийти з парадигми «я запитав — він відповів», перейти до Codex або Claude Code, завести свою «Personal OS»‑папку й чесно вивантажити туди всі робочі воркфлови. Далі — будувати навколо них skills, інтеграції й агентів, поступово піднімаючись вище по власній шкалі AI‑адопшну.

Джерело

AI-First Playbook: Do a Team’s Work With AI (2026) | Peter Yang

Соло-підприємець та колишній продуктовий менеджер Reddit, Meta і Roblox Пітер Ян останні роки демонструє радикальний підхід до роботи: замість команди він вибудовує навколо себе систему з AI-інструментів. Одна з найцікавіших її частин — персональний радник, щось на кшталт «chief of staff», який знає його бізнес, принципи й стиль прийняття рішень і допомагає фільтрувати можливості.

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

Текстовий файл як радник: мінімалістичний «скелет» системи

Ядро особистого AI-радника в системі Яна — це всього лише один skill у Codex. Skill, за його визначенням, — це простий текстовий файл з інструкціями. Для персонального радника інструкція максимально пряма: це має бути «trusted life and business adviser» із теплим тоном.

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

Для запуску цього радника Ян використовує опис навичок угорі файла: коли користувач «застряг на рішенні», «працює над складною проблемою» чи «просить поради на рівні інтуїції», Codex має викликати саме цей skill. Інколи це спрацьовує автоматично, інколи доводиться вручну викликати радника через команду на кшталт /personal advisor, але принцип один: конкретний запит тригерить конкретний набір інструкцій.

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

Друга пам’ять: навіщо learnings.md, якщо в моделі вже є memory

Codex, як і інші сучасні системи, має вбудовану пам’ять. Але Ян додає до цього ще один шар — окремий файл learnings.md. Завдання цього файла подвійне: по-перше, зняти частину навантаження з контекстного вікна моделі, по-друге, зробити накопичені інсайти видимими для нього самого.

Learnings.md — це звичайний текстовий документ у тій самій робочій папці Codex. AI отримує чіткі інструкції: після кожної розмови розпізнавати патерни й «навчання», які з’явилися, і питати, чи варто додати їх до learnings.md. Йдеться не про протоколи бесід, а саме про стратегічні висновки, які можуть допомогти в майбутніх рішеннях.

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

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

питання → відповідь із урахуванням минулих learnings → виділення нових learnings → опційне збереження.

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

Фільтр від «AI-слопу»: контроль над складністю та «чистотою» навичок

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

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

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

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

Принципи як «операційна система» для рішень

Файл learnings.md — не єдине джерело довготривалої пам’яті. У центрі всієї системи радника лежить ще один документ — односторінковий план у Google Docs, який описує бізнес, цілі та принципи Яна.

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

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

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

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

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

Як працює «chief of staff» у щоденних рішеннях

Сукупність цих елементів — skill радника, learnings.md, принципи в Google Doc — дає на виході поведінку, дуже схожу на роботу особистого chief of staff. AI:

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

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

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

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

Історія Яна показує, що «AI chief of staff» не обов’язково вимагає дорогих кастомних моделей чи складних агентських систем. У його випадку це проста зв’язка: Codex, один навик-радник, файл learnings.md і односторінковий документ із цілями та принципами.

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

Джерело

AI-First Playbook: Do a Team’s Work With AI (2026) | Peter Yang

Пітер Янґ, колишній продуктовий менеджер Reddit, Meta та Roblox, сьогодні веде одноосібний бізнес: велика розсилка, подкаст, YouTube й кільканадцять власних застосунків — без команди. Ключовий інструмент, на якому тримається його «медіахолдинг-соло», — не ноу-код платформи й не черга асистентів, а Codex, середовище від Anthropic для побудови AI‑агентів та «скилів».

Замість докручувати стандартні чати, Янґ посадив Codex у центр усіх контент‑процесів: від чернетки до публікації та аналітики. Ось як йому вдалося замінити рутинну роботу команди контентників однією системою.

Один день без зустрічей: як народжується «особистий CMS на стероїдах»

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

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

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

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

Автопостинг без офіційних API: як Codex обійшов обмеження платформ

Одна з найвидиміших трансформацій — публікації в соцмережах. Раніше Янґ користувався окремими SMM‑сервісами на кшталт Typefully, але вони працювали не всюди. Частина платформ, наприклад Substack Notes, взагалі не пропонують публічних API для постингу.

Codex став єдиним «центром постингу». Зараз усі пости на X, LinkedIn, Threads та Substack виходять через нього напряму. Там, де немає інтеграцій, агент працює як «розвідник браузера».

Для Substack Notes Янґ просто сформулював бажане: хоче планувати пости й не заходити туди вручну. Далі Codex, маючи доступ до браузера, сам «винюхав» внутрішні API, які сервіс використовує для публікацій. Після цього агент навчився або викликати ці ендпоінти, або імітувати дії користувача через керування комп’ютером.

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

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

Від голосового «потоку свідомості» до вірусного посту

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

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

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

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

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

Аналітика замість інтуїції: що робити, коли LinkedIn любить «збірники лінків»

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

Codex під’єднаний до аналітики різних соцмереж, а також до того самого Typefully, яке Янґ раніше використовував як окремий інструмент. Агент може порівнювати перформанс постів, шукати патерни, формулювати висновки.

Один з показових прикладів — LinkedIn. Аналіз контенту показав: тут краще працюють пости‑збірники, де в одному записі міститься багато лінків, наприклад до різних туторіалів. Вони дають кращий результат, ніж серія окремих постів з одним посиланням кожен.

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

Щотижневий фінансовий і контент‑бриф: звіт, який колись займав годину

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

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

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

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

Замість десятка ролей — один власник системи

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

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

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

Висновок: системи важливіші за окремі промпти

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

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

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

Джерело

AI-First Playbook: Do a Team’s Work With AI (2026) | Peter Yang

Підприємець і розробник Остін Марчезе, який працює з Claude Code у власних проєктах та бізнесах клієнтів, пропонує дивитися на роботу з AI не як на підбір «чарівних промптів», а як на правильну організацію самої роботи моделі. Один із ключових важелів такої організації — паралельні сесії Claude, або ж «sub‑агенти». Саме вони, за його досвідом і практикою творця Claude Code Бориса Черні, здатні радикально змінити, як стартують і масштабуються проєкти.

У центрі цієї ідеї — дуже проста фраза в Claude Code: «launch sub agents». За нею стоїть новий спосіб мислити про продуктивність, паралелізм і навіть про те, які завдання взагалі має сенс братися робити.

Від односмугової дороги до п’ятисмугової: чому послідовний режим гальмує

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

Марчезе порівнює це з «односмуговою дорогою»: «You’re running one Claude session at a time, sequentially, like a single-lane highway». Користувач буквально змушує весь процес йти в один потік, тоді як модель уже має інфраструктуру для паралельної роботи.

У цей час, зауважує він, можна було б мати «п’ятисмугову трасу»: «you could have had five Clauds doing five different tasks in parallel, like a five-lane highway». Замість одного довгого, послідовного ланцюга — кілька окремих, незалежних гілок роботи, які виконуються одночасно.

Саме так, за словами Марчезе, звик працювати творець Claude Code Борис Черні: «This is what Boris Cherney, the creator of Claude Code, swears by. Multiple Clauds at once, each focused on one task end-to-end». Ключова ідея не лише в швидкості, а в тому, що кожен агент «бачить» лише свою задачу і доводить її до кінця, не змішуючись з іншими контекстами.

Що таке sub‑агенти в Claude Code і чому вони поводяться як окремі моделі

Технічно sub‑агент у Claude Code — це не спеціальна «нова модель», а окрема сесія Claude, яку головний агент запускає паралельно. Формула, якою користується Марчезе, проста: «Sub agents are separate Claude sessions running in parallel. Each has its own context window, prompt, and permissions».

Тут важливі відразу три характеристики.

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

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

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

Марчезе підкреслює, що користувачам не потрібно налаштовувати всі ці сесії вручну. Достатньо у фіналі промпту дати вказівку «launch sub agents» — і головний агент сам розіб’є задачу на частини. Він окремо зауважує, що Claude технічно здатен запускати паралельні сесії «і так», без явної команди, але «Claude out of the box underutilizes sub agents». Головний агент часто поводиться як «я сам усе зроблю», залишаючись у власному контексті там, де паралелізація дала б значно кращий результат.

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

Багатокутний код‑рев’ю: коли незалежні думки дійсно незалежні

Один із найяскравіших сценаріїв, які Марчезе виділяє для sub‑агентів, — це отримання кількох незалежних поглядів на один і той самий об’єкт. Він описує це як режим «multiple perspectives», коли «five sub agents analyzing the same thing in parallel give you a diverse opinion».

Ключова проблема зі спробами зробити це «в лоб» у межах однієї розмови в тому, що модель починає «якоритися» на попередніх відповідях: «If you ask the same thing five times in one single chat, the model anchors on its previous’s response, and it all converges to the same thing». Замість п’яти різних поглядів користувач фактично отримує один, який поступово уточнюється.

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

Тут особливо важлива риса архітектури sub‑агентів: «For both of these, each sub-agent runs with its assigned task without seeing the others, meaning the results of the individual sub-agents won’t impact the others, which is a massive unlock». Відсутність взаємного впливу між сесіями гарантує, що модель не буде підганяти нові висновки під уже сформовану відповідь.

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

Друга категорія сценаріїв, яку Марчезе виділяє окремо, — це завдання, що раніше просто не потрапляли в список «реалістичних». Він описує це як «opens the door for new possibilities»: наявність керованих паралельних агентів раптово робить економічно доцільними операції, які в послідовному режимі виглядають надто повільними або громіздкими.

Показовий епізод — власний пошук домену для сервісу buildpartner.ai. Щоб відібрати варіанти, Марчезе «launched 10 different sub-agents to check 10,000 plus domains. Each agent focus on different groups». Кожен агент отримував свою підмножину доменів, перевіряючи їх паралельно з іншими.

У послідовному режимі такий перебір був би малоймовірним: «This is something that I just would have never done because it would have taken too long for a single agent to do, and it just would have been too much back and forth». Паралельні сесії не просто прискорили процес — вони перетворили задачу з «нереалістичної» на буденну.

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

Прискорення рутини: коли «launch sub agents» просто робить усе швидше

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

Марчезе формулює це максимально прямо: «If your tasks are independent of each other, just launch sub-agents». Йдеться про випадки, коли результат одного кроку не впливає на хід іншого, а тому немає жодної причини ганяти їх у послідовному режимі.

З практичного погляду в Claude Code це виглядає дуже просто: «it’s as simple as writing this at the end of your prompt. Launch five sub-agents to handle this». Користувач описує сукупне завдання, а в кінці повідомлення вказує кількість потрібних «клонів» Claude, які мають підхопити роботу.

Марчезе відверто називає цей підхід одним зі своїх улюблених, зокрема через те, «how lazy you can be with it». Система сама розподіляє шматки роботи між під‑агентами, дозволяючи мінімізувати ручне розкладання задачі на кроки.

Проте він одразу ж озвучує й головне обмеження: «No matter how many sub-agents you launch, if you aren’t crystal clear about what they should be doing, you’re going to be disappointed with the output». Паралелізм не компенсує нечітких інструкцій; навпаки, розмножує їхні наслідки. Без добре продуманого технічного опису чи плану, який задає єдине коректне рішення, навіть десяток паралельних агентів не гарантує результату.

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

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

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

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

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

Підхід, який описує Остін Марчезе, зсуває фокус роботи з Claude Code з «одного розумного співрозмовника» до мережі скоординованих агентів. Формула «launch sub agents» виявляється не просто корисним трюком, а новою базовою операцією: від багатокутного код‑рев’ю до масштабного перебору варіантів і прискорення незалежних задач.

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

Джерело

YouTube — Type This Into Claude, It’ll Make You Build 10x Faster.

У подкасті Confluent Developer архітектор даних Джон Міллер (Enid Technologies) та технологічний менеджер з фінансового сектора Ерік Брода обговорюють свою концепцію Agentic Mesh — наступний рівень еволюції розподілених систем, де тисячі «мікросервісів з мозком» працюють як повноцінні учасники бізнес‑процесів. Вони пропонують дивитися на агентів не як на персональні помічники, а як на керовану, безпечну екосистему з чіткими правилами доступу, ідентичностями та аудитом.

Від окремого агента до екосистеми

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

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

Тут відбувається принциповий зсув оптики. Якщо персональний «кодинг‑агент» — це інструмент розробника, що працює під його обліковим записом і з його правами, то enterprise‑агент — це окремий суб’єкт у системі. Він виконує завдання в рамках регламентованих процесів, підконтрольний IT та безпеці і підпорядковується корпоративним політикам.

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

Ідентичності, ролі й довіра як частина мешу

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

Він перераховує, що має бути «обгорнуто» навколо кожного агентного мікросервісу, аби перетворити його на повноцінного гравця ентерпрайз‑рівня. «Агентам потрібні identity, access controls, щоб їх можна було discoverable, observable, operable… кожну дію й інформацію треба аудіювати».

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

Брода формулює це так: «Ми віримо, що це не просто частина агента, а частина мешу. Це identity fabric, authorization fabric, trust fabric, які ви маєте реалізувати».

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

Така централізація дозволяє:

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

Бізнес‑процес як форма‑фактор мешу

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

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

Це означає, що:

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

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

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

Безпека проти «необмежених» агентів

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

«Ми вважаємо, що якщо у вас є необмежені агенти, які можуть доступатися до Bash чи інтернету… жоден Chief Security Officer не дозволить вам таке», — каже Брода.

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

Звідси висновок: свобода агента повинна бути жорстко обмежена контекстом задачі. «Ви повинні мати дуже розвинений фреймворк навколо задачі агента і конкретних skills і tools, до яких можна доступитися лише на час виконання задачі».

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

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

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

Explainability, аудит і token‑облік як вбудовані властивості

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

«Ми намагаємось скласти всі ці концепції в open‑source capability… воно дає explainability, observability, traceability, audit logs і token accounting в реальному часі», — розповідає він.

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

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

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

Окремо Брода згадує token accounting — облік токенів у реальному часі на рівні задач і бізнес‑процесів. Ідеться не просто про рахунок із платформи LLM, а про те, щоб бачити, скільки ресурсів споживає кожна частина процесу й кожен агент. Це продовжує лінію їхньої попередньої дискусії про «minimum viable context»: контекст для агента має бути не лише релевантним, а й економним у сенсі токенів.

Вбудований облік дозволяє:

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

Від концепції до open source‑фреймворку

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

Ціль цього проєкту — дати розробникам та архітекторам інструменти, щоб:

• розгортати агентів у вигляді контейнеризованих мікросервісів;
• підключати їх до подієвої шини для масштабованої взаємодії;
• централізовано керувати ідентичностями, ролями, скілами та інструментами;
• отримувати explainability, observability, traceability, audit logs і token accounting «з коробки».

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

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

Висновок

Agentic Mesh у трактуванні Міллера та Брода — це не стільки про окремих агентів, скільки про те, як перетворити їх на керовану інфраструктуру: із чіткими ідентичностями, ролями, контрольованими інструментами, прозорими діями й вимірюваними витратами. Форма‑фактором стає бізнес‑процес, а не чат‑інтерфейс; пріоритетами — безпека, аудит і explainability, а не «максимальна свобода» агентів.

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

Джерело

Agent Mesh: A Microservice With a Brain ft John Miller & Eric Broda | Confluent Developer

У подкасті Confluent Developer архітектор даних і AI‑систем Джон Міллер (Enid Technologies) та технологічний керівник з фінансового сектору Ерік Бродa (Agentic Mesh Company) розповідають, як мислити пам’ять у світі enterprise‑агентів. Їхня мета — побудувати агентів, які є повноцінними учасниками бізнес‑процесів, а не просто «розумними чатботами». Ключова частина цієї амбіції — системна робота з пам’яттю та контекстом.

Мюллер і Бродa пропонують розкладати пам’ять агентів на п’ять окремих типів і зводити все до того, що вони називають minimum viable context — мінімально життєздатний контекст, який агент отримує під час виклику LLM. Саме від цього, на їхню думку, залежить, чи зможуть агентні системи масштабуватися до рівня реальних корпоративних процесів.

Без пам’яті агент лише «вигадує»

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

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

Саме тут вступає в гру деталізована модель пам’яті, яку пропонують автори agentic mesh.

Статична пам’ять: те, з чим приходить модель

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

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

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

Довготривала enterprise‑пам’ять: «як у нас тут прийнято»

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

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

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

Семантична пам’ять: онтології, поняття та політики поверх них

Третій тип — семантична пам’ять. Вона відповідає за концепти, визначення, онтології й політики, накладені на ці поняття.

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

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

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

Спільна пам’ять між агентами: бачити розмови одне одного

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

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

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

У їхній концепції agentic mesh саме ця спільна пам’ять є частиною «фабрик» довіри й ідентичності, які оточують агентів у ентерпрайзі. Але навіть без заглиблення в mesh очевидно, що без shared memory масштабування до багатoагентних сценаріїв ризикує розвалитися в хаос дублювання зусиль.

Minimum viable context: пам’ять підганяє токен‑бюджет

П’ятий, ключовий елемент — те, як усі попередні типи пам’яті врешті потрапляють у контекст виклику LLM. Тут Бродa вводить поняття minimum viable context.

Ідея в тому, щоб зібрати статичну, enterprise‑, семантичну й спільну пам’ять в єдиний контекст, але зробити це токен‑обізнано й ощадливо. Контекст в LLM залишається дефіцитним ресурсом, і автори прямо кажуть: усе це потрібно «зварити» в token‑aware штуку, яка подає правильний контент у правильний час з урахуванням бюджету токенів.

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

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

«Віртуальне управління пам’яттю» для агентів

Міллер описує це як свого роду «virtual memory management» для агентів. Він згадує, що вони багато писали й говорили про те, що таке minimum viable context для агента, який має відповісти на запитання чи виконати задачу.

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

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

Як це під’єднати до агентів на базі coding‑моделей

Розмова відбувається на тлі більшої дискусії про використання coding‑агентів на кшталт Claude Code чи Codex як «двигуна» всередині enterprise‑агента. Бродa й Міллер розглядають їх як дуже здатних «працівників», які можуть виконувати складні, довготривалі завдання, виходячи далеко за межі суто програмування.

Але саме тому, підкреслює Бродa, їх потрібно оточити інфраструктурою — від ідентичності й доступів до пам’яті. У цьому контексті minimum viable context і п’ять типів пам’яті перетворюються на обов’язковий шар між сирою потужністю coding‑агента і реальним бізнес‑процесом.

Звідси з’являється ще один термін — agentic knowledge fabric, або AKF. Це назва для зв’язуючого шару, який об’єднує різні типи пам’яті та механізми доступу до знань. Бродa окреслює його скоріше як концептуальну парасольку: саме тут зосереджуються інструменти на кшталт онтологій, знаннєвих графів, політик, RAG‑подібних підходів — усе, що дозволяє побудувати семантичну й enterprise‑пам’ять, а потім «упакувати» її в токен‑обізнаний контекст.

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

З усього сказаного Міллер і Бродa роблять чіткий висновок: про пам’ять агентів у ентерпрайзі потрібно думати системно й багаторівнево. Є, як вони формулюють, «п’ять різних типів пам’яті, і вам потрібно думати про всі них». Статична, enterprise‑, семантична й спільна пам’ять створюють матеріал, з якого збирається minimum viable context — той самий мінімальний, але достатній зріз знань, що потрапляє до LLM у кожному конкретному виклику.

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

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

Джерело

Agent Mesh: A Microservice With a Brain ft John Miller & Eric Broda | Ep. 33 | Confluent Developer

У подкасті Confluent Developer архітектор даних і AI‑систем Джон Міллер (Enid Technologies) та технологічний топменеджер із фінансової індустрії Ерік Бродa обговорюють те, що вони називають наступним кроком еволюції розподілених систем: enterprise‑агенти, побудовані навколо Claude Code/Codex і розгорнуті як мікросервіси. Йдеться не про черговий персональний помічник для розробника, а про «мікросервіс із мозком», здатний стати повноцінним учасником бізнес‑процесу.

Мікросервіс із мозком: чому просто LLM замало

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

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

Щоб LLM не залишався розумною, але пасивною службою, до нього потрібен «гарнес» — цикл управління завданнями, планування, виклики інструментів, робота з помилками. Саме тому в Agentic Mesh пропонують іншу точку опори: брати не «голу» модель, а вже готові coding agents на кшталт Claude Code чи Codex і робити їх ядром enterprise‑агентів.

Claude Code і Codex як упряж для LLM

Ключова ідея підходу Міллера й Броди звучить прямо: «Ми поміщаємо LLM, small language models, large language models і все між ними в мікросервіси, але також поміщаємо Cloud Code в мікросервіс, у контейнер. Те саме робимо з Codex».

На їхню думку, тут є якісна відмінність. LLM надають «інтелект», здатність міркувати й оперувати природною мовою. А Claude Code чи Codex, навпаки, приносять у систему те, що Бродa описує як «упряж, який дозволяє їм робити дуже переконливу, довготривалу роботу».

Тобто coding agents уже містять усередині ті самі цикли, керування завданнями та довготривалу активність, які довелося б окремо програмувати навколо сирого LLM. Замість того, щоб щоразу винаходити агентний фреймворк із нуля, автори Agentic Mesh використовують готові можливості Claude Code/Codex і «перепаковують» їх у мікросервісний формат.

Бродa наголошує: «Ми насправді знайшли спосіб дуже безпечно упакувати Cloud Code або Codex… і, до речі, я називаю їх coding agents, це не пейоратив, вони можуть значно більше». У такій упаковці агент перестає бути просто інтерфейсом до LLM і стає компонентом, здатним виконувати «дуже складні, довготривалі, комплексні завдання».

Від персонального інструмента до учасника бізнес‑процесу

Сьогодні Claude Code, Codex та інші coding agents живуть переважно в особистому просторі розробників. Міллер і Бродa визнають: «Coding agents, любимо їх, фантастичні, неймовірні речі, ми використовуємо їх щодня, але ось проблема: це персональні ресурси… під вашим власним user ID».

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

У концепції enterprise‑агентів, яку описують автори Agentic Mesh, все навпаки. «Ці агенти надзвичайно здібні і можуть функціонувати… вони можуть брати участь у бізнес‑процесі. Простий LLM — ні. Вам треба писати повний гарнес, лупінг і все інше», — пояснює Бродa.

Його теза проста: якщо розмістити Claude Code чи Codex у контейнері як мікросервіс і забезпечити їм правильне оточення, вони стають не лише помічниками програміста, а реальними виконавцями в бізнес‑процесах. Не чат‑ботами, а «учасниками процесу», які працюють поруч з іншими сервісами й людьми.

Обгортка, яка дає право говорити з іншими системами

Щоб coding agent став повноцінним елементом enterprise‑архітектури, його доводиться «обгорнути». «Те, що ми робимо, — використовуємо ці можливості, але обгортаємо їх і дозволяємо їм комунікувати… ми беремо Claude Code і обгортаємо його комунікаційним гарнесом», — каже Бродa.

Ця обгортка робить кілька речей водночас.

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

По‑друге, поверх контейнеризованого Claude Code/Codex накладається набір enterprise‑вимог — ідентичність, ролі, доступи, спостережуваність, аудит. Бродa окреслює це як цілі пласти «identity fabric, authorization fabric, trust fabric», які мають бути частиною не окремого агента, а загального «mesh»‑шару.

По‑третє, обмежується й регламентується доступ до інструментів. Бродa прямо застерігає від моделі «необмежених агентів», яким дозволено довільно запускати Bash чи виходити в інтернет. На його переконання, жоден керівник безпеки не схвалить подібну архітектуру.

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

«Наше завдання — дозволити агентам безпечно знаходити одне одного»

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

За цією фразою стоїть кілька важливих припущень.

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

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

Третє — безпека й контроль не можуть бути додумками «після факту». Тому замість того, щоб просто дати Claude Code або Codex більше свобод, як це часто відбувається в експериментах із персональними агентами, автори Agentic Mesh з самого початку будують інфраструктуру навколо ідентичностей, дозволів, explainability, логів і токен‑обліку.

У цій логіці enterprise‑агент — це не «ще один бот», а новий тип мікросервісу: контейнеризований coding agent із LLM‑«мозком», обгорнутий комунікаційним і безпековим гарнесом, інтегрований у подієву архітектуру й чітко вбудований у бізнес‑процеси.

Підсумок: коли персональні coding agents виростають із «домашніх» умов

Міллер зізнається, що коли вони з Бродою почали публічно говорити про такий підхід, це виглядало як «крик із гори», який мало хто чув: більшість спільноти зосереджувалася на персональних coding agents та чат‑ботах. Лише зараз, каже він, розмова починає зміщуватися до питання, як перетворити Claude Code/Codex із приватних інструментів у керованих, спостережуваних і безпечних гравців корпоративних процесів.

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

Джерело

Agent Mesh: A Microservice With a Brain ft John Miller & Eric Broda | Ep. 33 | Confluent Developer

У подкасті Confluent Developer архітектори розподілених систем Джон Міллер (Enid Technologies) та Ерік Бродa (автор книжки про Agentic Mesh) обговорюють, як агенти на базі LLM перетворюються з персональних «код‑асистентів» на повноцінних учасників бізнес‑процесів. Їхня теза радикальна для традиційної enterprise‑архітектури: агент у такому світі — це вже не чат‑бот, а «мікросервіс з мозком», під’єднаний до подієвої шини на кшталт Kafka.

Від мікросервісів до «розумних мікросервісів»

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

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

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

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

LLM плюс coding‑агенти як новий «мозок» сервісу

Уявлення про «мозок» агента в цій моделі не зводиться до одного лише LLM‑виклику. Міллер і Бродa розрізняють дві складові: власне велику мовну модель та окремий клас так званих coding‑агентів.

LLM, у їхньому описі, має «інтелект», але сам по собі не дає механізмів для тривалих, керованих процесів. Для цього потрібен «harness» — петля керування, планування, виконання кроків, відстеження стану. Цю роль вони пропонують делегувати агентам на кшталт Claude Code чи Codex, які спочатку з’явилися як інструменти для програмістів, але дедалі очевидніше виходять за межі суто коду.

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

У підсумку всередині одного контейнера опиняються:

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

Таким чином, замість того щоб кожній команді з нуля писати повний агентний «loop» поверх LLM, автори Agentic Mesh пропонують використати готовий, уже «обгорнутий» у мікросервіс інтелектуальний компонент.

Від особистих асистентів до учасників бізнес‑процесів

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

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

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

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

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

Звідси виникають класичні для enterprise‑світу вимоги, які вони переносять на агентів: ідентичність, доступи, можливість спостереження, операційне управління, прозорість рішень, аудит кожної дії та облік витрат (зокрема «token accounting»). Суттєва частина того, що вони називають mesh, стосується саме цієї «ідентифікаційно‑довірчої» обгортки довкола агентів, а не лише їхнього коду.

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

Після того як агент визначено як «мікросервіс з мозком», природним є питання: як саме його інтегрувати в існуючу інфраструктуру? Відповідь авторів Agentic Mesh максимально «по‑ентерпрайзному» консервативна.

«Як це зробити? Помістити їх у контейнер, деплоїти як мікросервіс, наприклад, і надати дуже надійний комунікаційний бекбон», — окреслює Бродa базову форму. Вони не пропонують ламати організаціям DevOps‑процеси, CI/CD або принципи управління мікросервісами. Навпаки, агенти мають вписатися у вже відпрацьовані патерни.

Головна відмінність — у комунікаційній моделі. Тут Бродa і Міллер відверто «упереджені»: «Ми досить упереджені в цьому. Ми вважаємо, що event‑based communications — це шлях. Такі речі як Confluent Kafka… це комунікаційна тканина для агентів».

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

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

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

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

Від Twitter‑дискусій до enterprise‑реальності

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

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

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

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

Підсумок

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

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

Джерело

Agent Mesh: A Microservice With a Brain ft John Miller & Eric Broda | Ep. 33 | Confluent Developer

Штучний інтелект дедалі глибше інтегрується у девелоперські процеси — від автодоповнення в IDE до повноцінних асистентів, що аналізують репозиторій. Канал IBM Technology розібрав концепцію AI-пейрпрограмування (AI pair programming) як нового стандарту роботи розробників у звичному «inner loop» — циклі від ідеї до рев’ю коду.

Не «автогенератор коду», а напарник у команді

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

• IDE та редактори коду
• чат-інтерфейси
• агенти, здатні робити масштабні зміни в кодовій базі

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

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

Що реально вміють AI-асистенти для коду

Сучасні інструменти AI-кодування виходять далеко за межі простих підказок по синтаксису. Вони можуть:

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

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

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

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

• Генерувати тести й документацію
  Створювати unit-тести, інтеграційні сценарії та супровідні описи одночасно з кодом, а не «коли буде час».

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

• Прискорювати навчання
  Відповідати на глибинні технічні питання щодо нових фреймворків і концепцій, давати приклади й контрприклади.

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

Як AI вбудовується в розробницький «inner loop»

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

1. Планування та дизайн

На старті нової фічі розробник формулює:

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

AI може:

• запропонувати загальний підхід
• накидати можливий стек технологій
• перетворити словесний опис архітектури на перший чернетковий дизайн

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

2. Написання коду

На етапі імплементації можливі два сценарії:

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

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

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

3. Тестування, дебаг і документація

На цій фазі AI допомагає:

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

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

4. Безперервне вдосконалення

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

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

Три ключові ефекти для команд розробки

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

1. Підвищення якості коду

Постійний напівавтоматичний рев’ю-контур:

• зменшує кількість багів
• раніше виявляє дизайн-флейви
• підвищує стабільність і надійність систем

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

2. Краще поширення знань

AI виступає «провідником знань» усередині коду:

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

Таким чином, зменшується ризик утворення закритих «силосів» експертизи.

3. Більше задоволення від розробки

Автоматизація повторюваних задач звільняє час для:

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

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

Чому без людського контролю все руйнується

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

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

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

Як змінюється роль розробника

AI не скасовує попиту на навички програмування, а переформатовує їх:

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

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

Джерело

What Is AI Pair Programming? AI Coding Tools for Developers — IBM Technology

Інструмент Claude Code від Anthropic перетворює AI‑модель на повноцінного «співробітника», який створює файли на вашому комп’ютері, тестує застосунки і виправляє помилки самостійно. У великому відеогайді на каналі Futurepedia показано, як із нуля не лише зібрати проєкт без коду, а й довести його до публічного деплою. Окремий блок присвячений тому, як підключити GitHub і в кілька кроків викотити свій застосунок на Vercel — із діагностикою помилок за скріншотами та повною підтримкою з боку Claude.

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

Підготовка: Git як обов’язковий фундамент

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

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

Запуск виглядає максимально просто: достатньо ввести одну інструкцію — «check if I have Git installed, if not, install it for me». Claude перевіряє наявність Git локально, а якщо його немає, пропонує послідовні кроки інсталяції з урахуванням конкретної операційної системи. Користувачеві залишається відкрити вбудований термінал, який викликається через ту саму панель, що й вікно прев’ю, і послідовно копіювати‑вставляти команди, які генерує Claude.

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

GitHub: хмарний хаб, до якого отримує доступ Claude

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

Усе, що потрібно зробити користувачеві, — «просто попросити Claude підключитися до GitHub, щоб він міг пушити код від вашого імені і провести вас через усе, де потрібне ручне введення». Далі вступає в дію зв’язка Claude + GitHub CLI (офіційний інструмент командного рядка GitHub).

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

1. Claude пояснює, що треба зробити, і пропонує чотириетапну схему налаштування.
2. Перший крок — встановлення Homebrew (на Mac), для чого в термінал копіюється довга команда. Claude нагадує, куди саме її вставити і що робити з запитом пароля.
3. Далі Claude просить дозвіл запустити команду для інсталяції GitHub CLI. Користувач натискає «Allow», інсталяція проходить автоматично.
4. Останній крок — автентифікація GitHub CLI в обліковому записі GitHub. Claude дає конкретну команду для термінала і заздалегідь виписує, які саме відповіді вибрати в інтерактивному діалозі: використати github.com, протокол HTTPS, авторизація через веб‑браузер.

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

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

Автопаблікація: Claude сам створює репозиторій і відправляє код

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

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

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

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

Vercel: один клік від GitHub до живого домену

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

Схема виглядає максимально прямолінійно. Спочатку потрібно створити акаунт Vercel і залогінитися через GitHub. Після цього платформа автоматично пропонує інтегруватися з обліковим записом GitHub: в інтерфейсі з’являється блок «import Git repository», де достатньо натиснути «continue with GitHub», підтвердити установку інтеграції й обрати, до яких репозиторіїв надати доступ.

Після підключення в списку з’являються всі репозиторії користувача. Для демонстраційного проєкту обирається відповідний репозиторій, натискається «import», після чого Vercel відкриває сторінку з параметрами деплою. У відео ці налаштування не змінюються — одразу натискається «deploy».

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

Коли деплой ламається: скріншот у Claude як інструмент налагодження

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

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

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

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

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

Від локального експерименту до публічного продукту

Розглянутий ланцюжок — Git, GitHub, Vercel — у поєднанні з Claude Code створює для нетехнічного користувача повний робочий конвеєр. Claude бере на себе не лише написання коду, а й рутину інфраструктурної частини: встановлення та перевірку Git, налаштування GitHub CLI, створення репозиторію, перший пуш, а потім і діагностику помилок деплою за скріншотами.

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

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

Джерело

YouTube — From Zero to Claude Code in 19 Minutes (no code)