У світі AI-інструментів для програмістів склалася майже стандартна модель: один «розумний» агент у вашому IDE чи терміналі, який має вміти все — від проєктування архітектури до написання тестів і деплою. Канал Tech With Tim на прикладі нового CLI-інструмента Mistral Vibe показує, чому цей підхід починає буксувати і чому майбутнє серйозних девелоперських процесів — за оркестрацією кількох спеціалізованих агентів, а не за одним універсальним «асистентом на всі випадки».
Як працює типовий AI-асистент і чому він захлинається в контексті
Більшість мейнстримних AI-інструментів для кодування побудовані навколо однієї сутності — загального призначення агента, який живе в одному чаті й має обробляти всі завдання розробника. У цей єдиний діалог з часом потрапляє все: початковий опис задачі, обговорення архітектури, проміжні рішення, фрагменти коду, конфіги, тести, логи, результати запуску команд, історія рефакторингів.
На коротких сесіях це працює прийнятно. Але щойно мова заходить про реальні проєкти, де розробка триває годинами чи днями, починаються типові симптоми:
агенту доводиться одночасно «тримати в голові» план системи, деталі реалізації, попередні виклики інструментів, зміни у файлах, тести, специфікації та побічні обговорення. Контекстна історія розростається, і кожна нова репліка стає дорожчою в обчислювальному сенсі та менш надійною в плані якості відповіді.
У якийсь момент модель починає «забувати» важливі деталі, плутати вимоги, суперечити власним попереднім рішенням. Це явище часто описують як розмивання або «розчинення» контексту: формально токени ще вміщаються в контекстне вікно, але корисна інформація тоне в шумі з історії інструментальних викликів, проміжних відповідей і зайвих пояснень.
Розробники на практиці стикаються з тим, що довгі сесії з одним агентом закінчуються необхідністю «обнулити» чат: видалити історію, переформулювати задачу, знову пояснити структуру проєкту. Частина попередньої роботи фактично втрачається, а разом із нею — і накопичений «контекст» взаємодії.
Це не лише незручно, а й економічно неефективно. Чим більше історії тягнеться за кожним новим запитом, тим дорожче обходиться інференс моделі, особливо якщо йдеться про хмарні сервіси з оплатою за токени.
Спеціалізовані субагенти: від «універсального солдата» до команди фахівців
Альтернативний підхід пропонує дивитися на AI-агентів не як на одного універсального помічника, а як на команду спеціалістів, кожен з яких відповідає за чітко окреслену ділянку роботи.
У класичній команді розробки є люди, які займаються бекендом, фронтендом, тестуванням, рев’ю коду, деплоєм. Кожен має свою зону відповідальності, власні інструменти й спосіб мислення. Такий поділ праці зменшує хаос, підвищує передбачуваність і дозволяє масштабувати команду.
Те саме можна зробити й з AI: замість одного «мегаагента» створити кілька субагентів, кожен із яких:
отримує власні інструкції, заточені під конкретну роль — наприклад, «писати юніт-тести для FastAPI-бекенду», «перевіряти стиль і безпеку змін у Python-коді» чи «готувати зміни до деплою»;
має окремий набір дозволених інструментів і дій — хтось може лише читати файли й запускати тести, інший має право змінювати код, але не чіпати git чи мережу;
працює в ізольованому контекстному вікні, не обтяженому всією історією попередньої взаємодії з головним агентом.
Ключова ідея тут не в тому, щоб «натренувати кращу модель», а в тому, щоб грамотно організувати роботу вже наявних моделей. Оркестрація стає не менш важливою, ніж якість самого LLM.
У Mistral Vibe, який використовується як демонстраційний інструмент, субагенти реалізовані як окремі процеси з власними контекстними вікнами. Вони автоматично успадковують проєктний контекст — дерево файлів, git-статус, структуру кодової бази, — але не тягнуть за собою історію чату, попередні виклики інструментів і проміжні правки. Це дозволяє кожному субагенту стартувати з «чистішого» контексту, зосередженого на поточному завданні, а не на всій історії взаємодії.
Контекст як ресурс: чому ізоляція субагентів працює краще
Щоб зрозуміти перевагу субагентів, варто подивитися на контекстне вікно моделі як на обмежений ресурс. У єдиного агента цей ресурс витрачається на все одразу: опис задачі, код, логи, історію рішень, пояснення, інструкції. Кожен новий крок додає ще більше токенів, і в якийсь момент корисна інформація починає витіснятися.
У багатoагентній схемі цей ресурс розподіляється інакше. Головний агент може відповідати за загальний план: визначити, що потрібно зробити, розбити роботу на кроки, викликати потрібних субагентів. Коли настає час писати тести, у гру вступає спеціалізований тестувальний субагент. Він отримує доступ до структури проєкту, файлів, git-статусу, але не обтяжений усією історією попередніх обговорень.
У результаті:
контекстне вікно субагента заповнене переважно релевантною інформацією — файлами, які стосуються тестів, поточним станом коду, специфікаціями;
ризик «забування» важливих деталей зменшується, оскільки немає зайвого шуму з попередніх сесій;
модель приймає рішення більш послідовно в межах своєї ролі — наприклад, тестувальний агент не починає раптово переписувати архітектуру чи змінювати бізнес-логіку.
У Mistral Vibe це реалізовано через механізм успадкування контексту: субагент знає про проєкт, але не знає про всі попередні кроки головного агента. Він стартує з контекстним вікном, заповненим на 10–20%, а не на 80–90%, як це часто буває в довгих сесіях з одним агентом. Це дає запас для подальших дій без ризику швидкого розмивання контексту.
Важливий наслідок такого підходу — можливість запускати кілька субагентів паралельно. Наприклад, один пише тести для бекенду, інший аналізує фронтенд на предмет проблем з UX, третій готує зміни до деплою. Кожен працює у власному контексті, не заважаючи іншим, а головний агент або сам розробник координує їхню роботу.
Оркестрація важливіша за інструмент: чому це не лише про Mistral Vibe
У відео Mistral Vibe використовується як конкретний приклад реалізації багатoагентного підходу. Це відносно новий CLI-інструмент від Mistral, який запускається прямо з термінала командою vibe після встановлення одним Python- або bash-рядком із документації. Під капотом він використовує модель Devstral 2 — відкритий кодовий LLM, орієнтований на програмування, який, за заявленими показниками, приблизно в сім разів ефективніший за Claude Sonnet за вартістю для кодових навантажень, має 72,2% на бенчмарку SWE-bench і при цьому містить менше параметрів, ніж багато конкурентів.
Однак принципово важливо інше: стратегія використання кількох спеціалізованих агентів не прив’язана жорстко до цього інструмента. Вона значною мірою tooling-agnostic — її можна реалізувати в багатьох популярних AI-асистентах для коду, які дозволяють налаштовувати ролі, інструкції, доступ до інструментів і контекст.
У випадку Mistral Vibe агенти й субагенти описуються в TOML-конфігураціях у папці .vibe/agents всередині проєкту. Є п’ять вбудованих агентів — default, plan, accept_edits, auto_approve, explore, — а також можливість створювати власні. Субагент визначається через тип sub_agent у конфігурації й запускається як незалежний процес із власним контекстним вікном, успадковуючи лише проєктний контекст.
В інших інструментах структура може відрізнятися, але логіка залишається спільною: створення окремих «персон» з чіткими інструкціями, обмеженими правами й власним контекстом. Це може бути окремий «режим тестування», «режим рев’ю», «режим деплою» — неважливо, як це називається в конкретному продукті. Важливо, що кожен режим працює як окремий агент, а не як ще одна репліка в переповненому чаті.
Саме тому в центрі уваги має бути не стільки вибір «правильного» інструмента, скільки дизайн робочого процесу. Оркестрація — визначення, які агенти потрібні, які завдання вони виконують, як обмінюються результатами — стає ключовою компетенцією для команд, що хочуть максимально використати потенціал AI у розробці.
Менше когнітивного шуму для людини: як субагенти змінюють досвід розробника
Багато дискусій про AI-агентів зосереджені на продуктивності моделей, вартості токенів чи швидкості інференсу. Але не менш важливий аспект — когнітивне навантаження на самого розробника.
Робота з одним універсальним агентом часто перетворюється на довгий, розгалужений чат, у якому важко відстежити, що саме відбувається. Агент то планує архітектуру, то раптово починає переписувати фронтенд, то запускає тести, то пропонує деплой. Розробнику доводиться постійно тримати в голові, на якому етапі процесу він перебуває, які дії вже виконані, які ще ні, і що саме зараз «намагається зробити» модель.
Субагенти знімають частину цього навантаження завдяки прозорішому розподілу ролей. Коли є окремий агент для тестів, окремий — для рев’ю, окремий — для деплою, стає очевидно, хто за що відповідає в кожен момент часу. Якщо ви запускаєте тестувальний субагент, ви очікуєте від нього лише написання й запуску тестів, а не несподіваних змін у бізнес-логіці чи конфігурації CI/CD.
Це спрощує ментальну модель взаємодії з AI. Замість одного «чорного ящика», який «робить усе», ви маєте набір інструментів із чіткими назвами й поведінкою. Це ближче до звичного для розробників світу: окремі CLI-команди, окремі сервіси, окремі пайплайни.
У Mistral Vibe це проявляється, наприклад, у можливості створити субагент, який займається лише написанням автоматизованих тестів для FastAPI-бекенду. Йому можна дати доступ до читання й запису файлів, запуску тестів, але заборонити роботу з git чи мережею. Такий «пісочний майданчик» не лише підвищує безпеку, а й робить поведінку агента передбачуванішою для розробника.
Ще один важливий аспект — асинхронність. Коли кілька субагентів можуть працювати паралельно у фоновому режимі, розробник отримує можливість делегувати рутинні завдання, не втрачаючи контролю над загальною картиною. Один агент може розширювати функціональність застосунку, інший — одночасно генерувати тести, третій — готувати звіт про якість коду. Людина при цьому виступає радше як координатор, ніж як виконавець усіх дрібних кроків.
Від демо до практики: коли варто переходити на багатoагентний підхід
Питання не в тому, чи потрібні субагенти взагалі, а в тому, коли їх використання починає давати відчутний виграш. Для невеликих скриптів або разових задач один універсальний агент цілком достатній. Але щойно мова заходить про:
проєкти з помітною кодовою базою, де є бекенд, фронтенд, тести, CI/CD;
довгі сесії розробки, де історія взаємодії з AI вимірюється не десятками, а сотнями повідомлень;
командну роботу, де кілька людей взаємодіють з одним і тим самим AI-інструментом;
вимоги до прозорості та контрольованості змін у коді,
багатoагентний підхід починає виглядати не як «просунута фіча», а як практична необхідність.
У демонстраційному проєкті з FastAPI-бекендом і фронтендом на HTML/JS Mistral Vibe спочатку використовується як універсальний агент для розширення застосунку й побудови складнішої структури директорій. Але наступний логічний крок — винести рутинні завдання, на кшталт написання тестів, у спеціалізовані субагенти. Це типовий сценарій для реальних команд: спочатку AI використовується як «розумний автодоповнювач», потім — як універсальний асистент, а далі — як оркестрована система з кількох агентів.
Важливо, що перехід до такої системи не вимагає повної зміни інструментарію. Якщо обраний вами AI-асистент дозволяє налаштовувати ролі, інструкції й доступ до інструментів, ви вже можете почати експериментувати з поділом на субагентів. Mistral Vibe лише демонструє, як це може виглядати в терміналі з відкритою кодовою моделлю Devstral 2, яку за бажання можна форкнути, модифікувати й запускати локально або через API (зокрема у вигляді меншої Devstral Small 2).
Висновок: AI-розробка входить у епоху команд, а не солістів
Еволюція AI-інструментів для кодування рухається від простих підказок до повноцінних агентів, а тепер — до систем із кількох спеціалізованих субагентів. Модель «один агент робить усе» виявляється обмеженою не лише через технічні фактори на кшталт розміру контекстного вікна, а й через організаційні: складність контролю, зростання когнітивного навантаження, непрозорість процесів.
Поділ на субагентів дозволяє:
краще використовувати обмежений контекст моделей, ізолюючи завдання в окремі вікна;
зменшити ризик розмивання контексту й непослідовних рішень;
зробити роботу з AI більш передбачуваною й зрозумілою для розробників;
масштабувати AI-підтримку розробки за рахунок паралельної роботи кількох агентів.
Mistral Vibe з Devstral 2 показує, як це може виглядати в терміналі: субагенти як окремі процеси з успадкованим проєктним контекстом, але без історії чату, конфігурації в TOML-файлах, можливість тонко налаштовувати права й інструкції. Але головний урок виходить за межі конкретного інструмента: майбутнє AI у розробці — це не один «суперагент», а добре спроєктована команда спеціалізованих агентів, оркестрованих під ваш робочий процес.