Підприємець і розробник Остін Марчезе, який працює з 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)

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

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

Від демонстраційних ігор до реального офісного інструмента

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

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

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

Архітектура: канбан‑дошка плюс Granola як MCP‑джерело

Формулювання задачі до Claude Code звучить максимально прикладно: побудувати канбан‑додаток, який витягає action items з нотаток зустрічей і відображає їх у вигляді карток, що рухаються між колонками «to do», «in progress» та «done».

У промпті чітко фіксуються два ключові моменти.

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

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

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

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

Як Claude перетворює нотатки на задачі

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

• ідентифікує всі action items;
• визначає, для кого кожен із них призначений.

У підсумку користувач бачить канбан‑дошку, де кожна картка відповідає окремій дієвій задачі, витягнутій зі «сирих» нотаток. На картках уже зазначено, кому належить завдання. Далі ці картки можна вручну рухати між стовпчиками «to do», «in progress» та «done».

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

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

Інтеграції як мультиплікатор продуктивності

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

Канбан‑таск‑менеджер на базі нотаток мітингів тут — лише один приклад. Але він добре показує загальну модель:

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

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

Цікаво, що після збірки автор знову запускає команду /init — Claude створює файл claude.md для цього проєкту. Це фіксує поточний стан системи як довгостроковий контекст: якщо чат‑історія з часом розростеться чи загубиться, можна буде почати нову сесію й далі розвивати той самий таск‑менеджер, не втрачаючи розуміння структури.

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

Висновки: невеликі збірки, великий вплив на рутину

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

Тут немає складної бізнес‑логіки, немає довгих налаштувань — лише:

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

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

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

Джерело

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

Claude Code від Anthropic — це середовище, вбудоване в десктопний застосунок Claude, яке дозволяє будувати ігри, веб‑додатки, утиліти й робочі інструменти однією лише природною мовою. У гайді від каналу Futurepedia автор показує не лише базовий «no‑code» сценарій, а й те, як розширити можливості Claude Code за рахунок MCP‑конекторів до сторонніх сервісів, плагінів і власних skills. Саме ця розширюваність фактично перетворює Claude Code з «розумного редактора» на повноцінну платформу.

MCP як «зовнішні руки» Claude: що таке конектори

Одна з ключових «прихованих» можливостей Claude Code ховається в меню Customize. Саме там вмикаються MCP — механізм, який з’єднує модель з зовнішніми інструментами.

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

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

Список готових конекторів описується як «масивний». Серед найпоширеніших фігурують Gmail, Google Calendar, Notion. Це означає, що Claude Code може не тільки генерувати файли у вашій локальній директорії, а й, наприклад, читати листи, працювати з календарями чи записами в робочих базаx знань — залежно від налаштувань доступу. Автор окремо підкреслює, що в переліку є «тонни» інтеграцій для більшості популярних інструментів, які користувач може собі уявити.

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

Context 7: як Claude отримує актуальну документацію

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

Цей конектор вирішує болючу для будь‑якої LLM проблему — застарілі знання про технологічні стекі. Context 7 підтягує актуальну документацію для таких інструментів, як React, Expo, Tailwind, Vercel та багатьох інших. Коли ці фреймворки оновлюються, модель, навчена на більш ранніх версіях або змушена покладатися на не завжди надійний пошук у вебі, ризикує працювати зі старою інформацією.

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

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

Плагіни як «набори здібностей» і приклад Superpowers

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

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

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

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

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

Skills: повторювані процеси як окремий ресурс

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

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

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

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

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

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

Як все це поєднується: розмежування ролей

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

MCP‑конектори підключають Claude до інструментів. Вони відповідають за технічний доступ до зовнішніх сервісів: пошти, календарів, нотатників, документації чи інших робочих застосунків.

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

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

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

Висновок: від «AI‑чату» до персональної платформи

Гайд Futurepedia показує Claude Code не лише як інструмент для швидких експериментів без коду, а як систему, яку можна поступово перетворити на персональну платформу. MCP‑конектори прив’язують її до ваших реальних робочих сервісів, skills формалізують найцінніші повторювані процеси, а плагіни додають нові «набори здібностей», що автоматично включаються в потрібний момент.

Користувачеві не обов’язково розуміти технічні деталі протоколу MCP чи внутрішню реалізацію skills. Достатньо одного разу підключити ключові конектори, встановити корисні плагіни — на кшталт Superpowers — і почати «запаковувати» свої найвдаліші workflow у власні skills. Після цього Claude Code перестає бути просто зручним AI‑редактором і перетворюється на керований природною мовою «оркестратор» інструментів, знань і процесів.

Джерело

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

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

Постійна опора: навіщо потрібен файл CLAUDE.md

Після того, як базовий функціонал застосунку вже зібраний і пройшов перші правки, автор пропонує робити одну рутину «обов’язковою» дією: створювати файл CLAUDE.md у папці проєкту.

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

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

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

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

Коли історія чату заважає: роль контекстного вікна

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

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

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

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

Стратегія «оновлення пам’яті»: новий чат замість нескінченного скролу

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

Рекомендований алгоритм виглядає так.

По‑перше, перед перезапуском розмови варто попросити Claude зробити підсумковий конспект. Формулювання може бути доволі вільним, але важливо, щоби відповідь містила поточний стан робіт, активні завдання, те, над чим модель «знає», що ще треба попрацювати. Це особливо корисно в моменти, коли в роботі перебуває конкретна функція чи фічa, яка ще не потрапила в CLAUDE.md, але є важливою для наступних кроків.

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

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

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

Як це поєднується в системну практику

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

Спочатку модель збирає функціонал, тестує його, поступово вдосконалює. Коли з’являється перша стабільна версія, створюється CLAUDE.md через /init. Далі кожна велика сесія правок може завершуватися командою, яка просить оновити цей файл усім важливим, що було змінено.

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

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

Цей підхід не виглядає як складна технічна методика. По суті, це набір кількох простих звичок — регулярно викликати /init, не забувати оновлювати CLAUDE.md і не боятися починати нову розмову замість того, щоб нескінченно продовжувати стару. Але саме вони перетворюють Claude Code з «розумного чат‑помічника» на інструмент, здатний надійно супроводжувати довготривалі проєкти без хаосу в історії.

Висновки: пам’ять як головна перевага, а не проблема

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

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

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

Джерело

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

У Futurepedia вийшов детальний нонкод‑гайд, який показує, як перетворити Claude Code на свого особистого розробника — навіть якщо ви ніколи не писали жодного рядка коду. Автор проходить шлях від порожньої папки на комп’ютері до готової гри та робочих інструментів, використовуючи лише природну мову. Ключова ідея: технічний бекграунд більше не є обов’язковою умовою, щоб будувати власні застосунки й утиліти.

Міф про «не технічних» користувачів

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

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

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

Старт за кілька кроків: від промпту до робочої гри

Початкова розстановка дуже проста. Потрібен платний акаунт Claude (Pro або Max) та встановлений десктопний застосунок — робота з кодом відбувається саме там, а не у веб‑версії. Після інсталяції в інтерфейсі з’являється вкладка Code — це і є «майстерня», де будуються всі проєкти.

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

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

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

Плановий режим: спершу зрозуміти, потім будувати

Ключова відмінність Claude Code від звичайного чат‑режиму — плановий режим. Замість того, щоб одразу кидатися писати код, пропонується окремо увімкнути «plan mode». Коли він активний, Claude не будує застосунок миттєво, а спочатку розкладає майбутній проєкт на детальний план.

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

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

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

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

Агент, а не просто чат: як Claude сам тестує та виправляє себе

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

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

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

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

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

Природна мова як єдиний «інтерфейс програмування»

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

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

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

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

Висновок: поріг входу у розробку різко знижується

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

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

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

Джерело

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

У 2026 році попит на AI‑інженерів вибухово зростає, а разом з ним — лавина «roadmap’ів» і курсів, які обіцяють швидкий вхід у професію. Канал Tech With Tim, відомий практичними розборами кар’єри в розробці, вирішив піти іншим шляхом: замість абстрактних схем автор взяв один конкретний трек — DataCamp Associate AI Engineer for Developers — повністю його пройшов, виконав усі проєкти й уже з цієї позиції дає відвертий огляд.

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

Скільки це коштує і за що ви насправді платите

Модель монетизації у DataCamp побудована навколо підписки, а не купівлі окремих курсів. Доступ до треку AI‑інженера — не виняток.

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

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

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

Конфлікт інтересів чи чесний огляд?

DataCamp є довгостроковим партнером каналу Tech With Tim, і автор прямо визнає потенційний конфлікт інтересів. Він наголошує, що працює з платформою вже понад три роки, пройшов багато курсів самостійно й почав користуватися сервісом ще до того, як той став спонсором каналу.

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

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

Для кого створений цей трек і чого в ньому бракує

Центральна теза огляду: трек Associate AI Engineer for Developers — сильний старт, але не повна підготовка до професії AI‑інженера.

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

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

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

Сильні сторони: практичний фокус і хороша динаміка (з нюансами)

Серед плюсів треку автор виділяє насамперед його структуру та підбір тем. Дорога починається з роботи з OpenAI API і промптінгу, продовжується знайомством із моделями через Hugging Face, потім переходить до LLM‑ops‑концепцій, розробки систем на базі OpenAI, embeddings, векторних баз даних, RAG і, далі, до більш складних ланцюжків із використанням фреймворків для LLM‑додатків.

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

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

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

Слабкі місця: теоретичний LLM‑ops і недобудований фінал

Найбільш критичні зауваження стосуються розділів про LLM‑ops та загальної композиції треку.

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

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

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

Сертифікація: плюс до резюме, але невідома складність

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

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

Кому варто платити за DataCamp, а кому — ні

Фінальний висновок балансує між похвалою й обережністю. Трек Associate AI Engineer for Developers, за підсумком, «не зробить із вас повноцінного AI‑інженера». Однак якщо потрібен «дійсно доступний і хороший старт, розроблений для людей, які вже знають core Python», то це один із найкращих ресурсів, які автор особисто знаходив і тестував.

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

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

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

Джерело

Do THIS Instead of watching endless AI Engineer Roadmaps (DataCamp Review)

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

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

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

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

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

80% часу — в коді: чому практика тягне навчання вперед

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

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

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

У DataCamp цей цикл навмисно стискається. Чотири‑п’ять хвилин навчального відео, часто прискореного до 1,5–2×, і відразу — завдання, де без повернення до щойно отриманої інформації не обійтися. Такий підхід «змушує» мозок працювати з матеріалом активніше, ніж проста прокрутка довгої лекції.

Хмарне середовище як ядро: де насправді відбувається навчання

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

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

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

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

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

Чому це особливо важливо саме для AI‑інженерії

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

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

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

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

Висновок: короткі відео як вхід, інтерактив як двигун

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

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

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

Джерело

Do THIS Instead of watching endless AI Engineer Roadmaps (DataCamp Review)

Ринок AI‑інженерії стрімко перегрівається, а разом із ним множаться й «ідеальні» дорожні карти: списки технологій на десятки пунктів, що обіцяють швидкий шлях у нову професію. Автор каналу Tech With Tim пішов іншим шляхом — повністю пройшов конкретний трек DataCamp Associate AI Engineer for Developers (усі модулі та проєкти) і на його основі розклав по поличках, чого насправді навчає ця програма.

Нижче — детальний розбір вмісту треку: від роботи з OpenAI API до RAG, векторних баз даних і LangChain, без маркетингових обіцянок та абстрактних «roadmap’ів».

Що це за трек і для кого він розрахований

DataCamp позиціонує Associate AI Engineer for Developers як трек для розробників, які вже володіють базовим Python і хочуть додати до свого стеку AI‑інженерію. Це не курс «з нуля»: передбачається, що слухач розуміє основи програмування та вже щось будував власноруч.

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

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

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

Старт із практики: OpenAI API та промпт‑інженерія

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

У фокусі — не абстрактна теорія, а практичні питання:

• вибір моделі;
• використання Response API;
• типи повідомлень (user, assistant, system);
• базові патерни взаємодії з сторонніми LLM.

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

Другий великий блок — prompt engineering with OpenAI. Тут уже не про те, «як надіслати запит», а про те, «як сформулювати його так, щоб отримати потрібний результат».

Розбираються різні стратегії промптингу:

• one‑shot та multi‑shot підходи;
• надання прикладів у промпті;
• способи структурування запитів для кращих відповідей;
• організація структурованих виводів.

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

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

Open‑source як норма: Hugging Face та LLM Ops

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

Ключовий акцент — на використанні вже навчених моделей:

• слухач підтягує pre‑trained модель;
• застосовує токенайзер для тексту;
• будує пайплайн (наприклад, для Q&A чи класифікації);
• подає коректно підготовлені дані та обробляє відповідь.

Наголос робиться саме на типових завданнях AI‑інженера: не тренувати модель із нуля, а брати готову з Hugging Face, вбудовувати в застосунок, поєднувати з іншими компонентами.

Після цього трек робить крок убік від коду до високорівневої архітектури — модуль про LLM Ops. За структурою це радше концептуальна частина, ніж практичний DevOps‑курс. У ній:

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

Свідомо відсутні практичні теми на кшталт Docker чи Kubernetes. Це дає загальне розуміння, як виглядає життєвий цикл LLM‑системи, але без глибокого занурення в інфраструктуру.

Наступний курс — developing AI systems with the OpenAI API — починає комбінувати попередні блоки. Тут говорять про побудову більших застосунків, які вже з’єднують OpenAI з іншими компонентами (зокрема, із тим самим Hugging Face). Темп у цій частині помітно зростає, завдання стають складнішими, і від слухача очікується впевненіша робота з базовими інструментами.

Вектори, RAG і робота з Pinecone

Найпомітніший «стрибок складності» відбувається на етапі, де трек переходить до embeddings. Тут починається те, що сьогодні становить ядро більшості практичних LLM‑рішень у бізнесі: векторні представлення тексту, пошук по ембедінгам і Retrieval‑Augmented Generation (RAG).

У цій частині:

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

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

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

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

Від скриптів до систем: Python‑принципи й LangChain

Фінальний етап треку переводить увагу зі «швидких інтеграцій» до архітектури повноцінних AI‑додатків.

Окремий курс присвячено software engineering principles in Python. Його завдання — закріпити базові інженерні практики, потрібні для побудови складніших LLM‑систем, а не лише одноразових скриптів чи ноутбуків. Мова йде про структурованість коду, розділення відповідальностей та інші фундаментальні підходи, які мають стати фоном для решти роботи.

Після цього трек переходить до developing LLM applications with LangChain. Тут від простих API‑викликів слухач переходить до більш складних зв’язок:

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

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

Наскільки цього вистачає для старту в AI‑інженерії

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

Трек:

• дає ядро тем, які постійно згадуються в описах вакансій: OpenAI API, промпт‑інженерія, Hugging Face, основи LLM Ops, ембедінги, векторні БД, RAG, LangChain;
• формує робоче розуміння того, як будуються сучасні AI‑застосунки;
• дозволяє відносно легко «розгалужуватися» далі — у власні проєкти й глибші теми.

За оцінкою спікера, цей обсяг знань «доводить приблизно до середини шляху» до рівня, достатнього для працевлаштування. Далі доведеться самостійно чи через інші курси закривати прогалини, особливо в частині реальної інфраструктури (Docker, Kubernetes, продакшн‑деплой) та просунутої експлуатації LLM у великих системах.

Серед недоліків треку відзначаються:

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

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

Джерело

Do THIS Instead of watching endless AI Engineer Roadmaps (DataCamp Review)

У 2026 році «AI‑інженер» перетворився з модного ярлика на одну з найпомітніших ролей для розробників. Канал Tech With Tim, відомий практичним контентом для програмістів, присвятив окремий розбір тому, що насправді стоїть за цією професією, які навички потрібні й чому це вже не про класичну “ML‑магію” з вищою математикою.

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

Сучасна AI‑інженерія майже не схожа на традиційний machine learning з підручників кількарічної давнини. Наголос змістився з побудови моделей з нуля на грамотне використання того, що вже створили великі гравці та open‑source‑спільнота.

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

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

LLM, RAG та готові моделі: основний інструментарій

Як виглядає щоденна робота AI‑інженера в такій парадигмі?

По‑перше, це системне використання попередньо натренованих моделей. Фокус — на тому, щоб «використовувати pre‑trained models, використовувати LLMs, створювати пайплайни з використанням RAG — retrieval augmented generation — та деплоїти ці застосунки в бізнес».

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

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

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

Кар’єра без матаналізу: чи реально зайти в AI без «вишки» з математики

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

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

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

Чому розробники масово дивляться в бік AI‑інженерії

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

Йдеться не тільки про кількість вакансій, але й про компенсації. Звучить орієнтир: стартова оплата «понад $150 000 на рік, тоді як деякі інші, більш традиційні дев‑ролі, трохи стагнують або навіть ідуть на спад». Наведені цифри не претендують на вичерпну статистику ринку, але добре передають тренд: розробники, які вчасно переорієнтувалися з класичного web чи backend на AI‑інженерію, можуть розраховувати на відчутний фінансовий апґрейд.

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

Як обирати свій шлях у професію

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

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

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

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

Висновок: AI‑інженерія як еволюція розробника, а не злам кар’єри

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

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

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

Джерело

YouTube — Do THIS Instead of watching endless AI Engineer Roadmaps (DataCamp Review)

Тенденція, схоже, лише посилюється. Торік у травні техсектор показав найвищий за останні два роки місячний рівень звільнень — майже 40 000 людей, а штучний інтелект уже третій місяць поспіль є найчастіше названою причиною скорочень у всіх галузях, згідно з даними аутплейсмент-компанії Challenger, Gray & Christmas.

Водночас дедалі більше зростає скепсис щодо того, чи справді винен саме ШІ — чи це радше зручне прикриття, а не реальна причина. Мало що ілюструє цей спротив краще, ніж історія з платіжною компанією Block. Після шквалу критики за скорочення майже половини штату на початку року Джек Дорсі заперечував, що це сигнал проблем, наполягаючи натомість, що інструменти ШІ «дозволяють новий спосіб роботи, який фундаментально змінює саме поняття побудови та управління компанією». Але, коли користувачі в X (Twitter) почали дорікати йому «роздуттям» штату в період пандемії, Дорсі зрештою визнав, що Block справді пере наймала.

До дискусії підключилися й інші відомі голоси, зокрема відомий венчурний інвестор Марк Андрісен, який нещодавно назвав ШІ «срібною кулею-виправданням» для звільнень, що насправді пов’язані з неефективним менеджментом. В інтерв’ю подкастеру й інвестору Гаррі Стеббінгсу Андрісен заявив: «Фактично кожна велика компанія має завеликий штат. Пере найм щонайменше 25%. Я вважаю, що більшість великих компаній пере найняті на 50%. І чимало з них — на 75%. Тепер у всіх є срібна куля-виправдання: ах, це ж ШІ».

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

На початку минулого місяця виробник чипів для ШІ Cerebras Systems завершив перший день торгів на Nasdaq зі зростанням котирувань на 68% від ціни IPO в $185, що дало компанії ринкову оцінку близько $67 млрд — найбільше технологічне IPO у США з часу виходу Snowflake на біржу у 2020 році. До кінця дня співзасновники Ендрю Фельдман і Шон Лай стали мільярдерами (відтоді акції компанії впали на 30%).

Тим часом SpaceX вийшла на біржу в п’ятницю й станом на час написання має ринкову капіталізацію $2,1 трлн, що робить Маска «паперовим» трильйонером і потенційно створює, за оцінками, близько 4 400 мільйонерів і приблизно 400 центимільйонерів серед власників акцій — якщо курс не впаде. Anthropic та OpenAI також швидко наближаються до публічного ринку, обидві — з оцінками приблизно $1 трлн або й вище.

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

Є ще Марк Цукерберг. На початку березня він придбав маєток за $170 млн на так званому «Острові мільярдерів» у Маямі, встановивши абсолютний рекорд найдорожчого продажу житла в історії округу Маямі-Дейд. Через два місяці Meta оголосила про звільнення 8 000 співробітників, або близько 10% штату.

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

Працівники з корпоративним медстрахуванням цього року зіткнулися зі зростанням страхових премій приблизно на 6–7% — більш ніж удвічі швидше за інфляцію, вартість приватної медичної страховки від 2008 року фактично подвоїлася, а медіанна ціна житла підскочила на 28% з початку 2020 року, при цьому іпотечні ставки майже подвоїлися.

У січневому опитуванні New York Times/Siena 2026 року 65% виборців заявили, що життя середнього класу для них недосяжне. А більш свіже опитування показало, що 76% американців зараз називають вартість життя своїм головним економічним занепокоєнням — різкий стрибок порівняно з 58% роком раніше.

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

Знайти історичний прецедент того, що буває, коли розрив стає надто великим, неважко. У 2008 році фінансова криза, що почалася з ризикованого кредитування й надмірного ризик-апетиту на Волл-стріт, завершилася рятувальними «бейлаутами» для банків, які її й спричинили, тоді як мільйони американців втратили роботу й житло в результаті Великої рецесії. Через три роки цей гнів вилився в рух Occupy Wall Street.

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

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

Джерело

TechCrunch