Mistral, європейський розробник моделей штучного інтелекту, вивів свою ідею AI‑асистента для програмістів прямо в термінал. Новий інструмент Mistral Vibe — це CLI‑орієнтований AI‑кодер, який працює поверх моделі Devstral 2 і дозволяє збирати власний «штат» спеціалізованих агентів та субагентів для різних етапів розробки. На практиці це означає, що замість одного універсального бота, який намагається робити все, розробник отримує керовану систему з окремими агентами для тестів, рев’ю, деплою чи фронтенду — з чітко налаштованими правами, контекстом і обмеженнями.
Встановлення в один рядок і запуск однією командою
Mistral Vibe задуманий як інструмент, який не вимагає складної інфраструктури. Щоб почати роботу, достатньо виконати одну команду з документації — доступні як Python‑команда, так і bash‑варіант. Обидва сценарії встановлюють CLI‑клієнт без додаткових кроків налаштування.
Після інсталяції вхід до середовища відбувається через просту команду vibe у терміналі. Перший запуск пропонує авторизуватися або створити безкоштовний акаунт. Далі користувач може обрати, як саме запускати моделі: локально на власному обладнанні або через хмарні тарифи Mistral — від безкоштовного рівня до pro та командних планів, інтегрованих із підпискою на чат‑сервіси компанії.
Ключовий момент: Vibe не прив’язує розробника до хмари. Завдяки відкритості Devstral 2 та наявності меншої моделі Devstral Small 2, інструмент підтримує як локальні сценарії, так і гібридні конфігурації, де частина навантаження йде в хмару, а частина — обробляється на власних серверах чи робочих станціях.
Devstral 2: відкритий кодовий двигун з акцентом на ефективність
У центрі Mistral Vibe — модель Devstral 2, спеціалізований кодовий LLM, який компанія позиціонує як state‑of‑the‑art для задач програмування. Модель вийшла приблизно за три місяці до запису відео й одразу була представлена як відкритий проєкт: її можна форкати, модифікувати та запускати самостійно, без vendor lock‑in, характерного для багатьох закритих платформ.
За заявленими метриками Devstral 2 досягає близько 72,2% на бенчмарку SWE‑bench, який оцінює здатність моделі розуміти та виправляти реальні помилки в коді. При цьому модель використовує менше параметрів, ніж багато конкурентів, але орієнтується на той самий клас задач — повноцінну роботу як кодового агента.
Окремий акцент зроблено на вартості. Для кодових навантажень Devstral 2 описується як приблизно в сім разів більш економічна, ніж Claude Sonnet. Для розробників, які активно використовують AI‑асистентів — запускають кілька агентів, тримають відкритими кілька термінальних сесій, постійно генерують та рефакторять код — це перетворюється на відчутну різницю в рахунках за інференс.
Паралельно Mistral пропонує Devstral Small 2 — компактнішу модель з меншим числом параметрів. Вона може працювати локально або через API, що робить її придатною для сценаріїв з обмеженими ресурсами, on‑prem‑розгортань і тих випадків, коли важливіша швидкість відповіді та контроль над інфраструктурою, ніж максимальна якість.
У підсумку Vibe дає розробнику вибір: використовувати повноцінну Devstral 2 у хмарі, запускати Devstral Small 2 локально, комбінувати обидва варіанти або взагалі підняти власний інстанс Devstral 2, форкнувши відкритий репозиторій.
Автоматичний контекст проєкту: git, дерево файлів і стан репозиторію
Одна з ключових відмінностей Mistral Vibe від класичних чат‑інтерфейсів — глибока інтеграція з реальним проєктом. Якщо запустити vibe безпосередньо з директорії репозиторію, інструмент автоматично читає git‑історію та індексує кодову базу. Це дає агентам одразу кілька важливих переваг.
По‑перше, вони отримують уявлення про структуру файлів, модулів і директорій без необхідності вручну «пояснювати» їм, де що лежить. По‑друге, доступ до git‑статусу дозволяє розуміти, які файли змінені, які ще не закомічені, які гілки використовуються. По‑третє, історія комітів дає контекст еволюції проєкту, що може бути корисним для рефакторингу або аналізу регресій.
Це автоматичне індексування особливо важливе в багатoагентному сценарії. Коли в системі з’являються спеціалізовані субагенти — наприклад, окремий агент для написання тестів чи для рев’ю — усі вони мають спільне уявлення про дерево файлів і стан репозиторію. Це зменшує кількість «пояснювальної» взаємодії з боку розробника та дозволяє одразу переходити до постановки задач.
При цьому Vibe залишається термінальним інструментом: усі дії — від запуску до навігації між агентами — виконуються з командного рядка, що добре вписується в звичні робочі процеси бекенд‑розробників, DevOps‑інженерів і тих, хто більшість часу проводить у CLI.
Вбудовані агенти: базовий набір ролей для щоденної роботи
Одразу після встановлення Mistral Vibe пропонує п’ять вбудованих агентів, які покривають типові сценарії розробки. Це default, plan, accept_edits, auto_approve та explore. Кожен із них має власну роль і поведінку, а викликаються вони через параметр --agent у команді запуску.
Наприклад, default виступає універсальним асистентом для загальних задач кодування. plan орієнтований на побудову планів робіт, розбиття великих задач на кроки та формування послідовності дій. accept_edits та auto_approve пов’язані з управлінням змінами у файлах і автоматичним підтвердженням дій агента, тоді як explore фокусується на дослідженні кодової бази, навігації та аналізі структури.
Цей набір можна розглядати як стартовий «штат» для проєкту. Він дозволяє одразу почати працювати з кодом, не створюючи власних конфігурацій. Але справжній потенціал Vibe розкривається тоді, коли розробник починає визначати власні агенти та субагенти під конкретні етапи пайплайну.
Кастомні агенти в TOML: конфігурація як код
Mistral Vibe будує систему агентів навколо конфігураційних файлів у форматі TOML. У межах кожного проєкту створюється директорія .vibe/agents, де зберігаються описи як основних агентів, так і субагентів. Це фактично перетворює дизайн AI‑асистентів на частину кодової бази.
У конфігураційному файлі агенту задаються ключові параметри: ім’я, опис, інструкції, які визначають його роль, а також налаштування безпеки й обмежень. Серед них — можливість виклику інструментів, право змінювати файли, доступ до bash‑команд чи мережі, максимальна кількість кроків у діалозі, ліміт вартості сесії.
Така модель дозволяє створювати, наприклад, агента‑тестувальника, який має право читати й змінювати файли та запускати тести, але не може виконувати git‑команди чи звертатися до мережі. Або агента‑рев’юера, який аналізує якість коду, але працює лише в режимі читання, не вносячи жодних змін.
Оскільки .vibe/agents живе всередині репозиторію, конфігурації агентів автоматично розділяються між усіма учасниками команди. Це означає, що один розробник може налаштувати набір агентів під конкретний проєкт, закомітити їх у git, і всі інші отримають той самий «AI‑шар» разом із кодом. У результаті AI‑інфраструктура стає частиною спільного середовища розробки, а не особистою локальною надбудовою.
Субагенти: окремі процеси з успадкованим контекстом проєкту
Найцікавіша частина архітектури Vibe — субагенти. На відміну від основних агентів, які взаємодіють із користувачем безпосередньо, субагенти створюються як допоміжні «робітники» для виконання конкретних задач у межах проєкту. У конфігурації TOML вони позначаються типом sub_agent.
Ключова ідея полягає в тому, що субагент успадковує контекст проєкту, але не історію спілкування. Коли субагент запускається, він отримує доступ до дерева файлів, структури кодової бази, git‑статусу та іншої проєктної інформації, яку Vibe зібрав під час індексації. Водночас він не бачить попередні повідомлення, інструментальні виклики чи редагування файлів, які відбувалися в основній сесії.
Це розв’язує одразу дві проблеми. По‑перше, зменшується ризик «розмивання контексту», коли один універсальний агент намагається одночасно тримати в пам’яті архітектуру, історію змін, тести, специфікації та довгі обговорення з розробником. По‑друге, кожен субагент стартує з відносно «чистим» контекстним вікном — умовно на рівні 10–20% заповнення, а не 80–90%, як це часто буває в довгих сесіях з одним агентом.
У технічному сенсі субагенти працюють як незалежні процеси з власними контекстними вікнами. Вони можуть виконуватися асинхронно й паралельно: кілька субагентів одночасно пишуть тести, аналізують різні частини кодової бази чи готують зміни до деплою. Оскільки кожен із них має власні обмеження на кількість кроків, вартість і права доступу, розробник отримує контрольовану багатoагентну систему, а не «чорну скриньку», яка робить усе сама.
Тонке налаштування прав: від файлового доступу до мережі
Ще один важливий аспект роботи з субагентами у Vibe — детальне керування дозволами. У конфігурації TOML можна задати, до яких інструментів має доступ кожен субагент і в якому режимі він може діяти.
Наприклад, для агента, який відповідає за написання тестів, логічно дозволити читання й запис файлів, а також запуск тестових команд у терміналі. Водночас йому можна заборонити виконання git‑операцій, доступ до мережі чи будь‑які дії, пов’язані з деплоєм. Для агента‑рев’юера можна обмежитися лише читанням файлів і аналізом коду, повністю відключивши можливість змінювати репозиторій.
Окремо налаштовується поведінка щодо автоапруву. Деяким агентам можна дозволити автоматично застосовувати зміни без додаткового підтвердження користувача, якщо вони працюють у чітко окресленому «пісочному» середовищі. Іншим — навпаки, вимагати явного схвалення кожної дії, особливо якщо йдеться про потенційно ризиковані операції.
Такі обмеження не лише підвищують безпеку, а й покращують продуктивність. Агенти, які працюють у вузько визначених рамках, менше «розсіюються» на несуттєві деталі, швидше досягають поставлених цілей і рідше роблять несподівані кроки за межами своєї ролі.
Паралельна робота субагентів і командна спільність
Модель субагентів у Vibe природно підштовхує до сценаріїв, де кілька спеціалізованих процесів працюють одночасно. Один субагент може генерувати й запускати тести для бекенду, інший — аналізувати фронтенд‑код на предмет проблем з UX чи продуктивністю, третій — готувати зміни до деплою, перевіряючи конфігураційні файли та скрипти.
Оскільки всі вони успадковують один і той самий проєктний контекст, але не ділять між собою історію діалогу, кожен субагент залишається сфокусованим на своїй задачі. При цьому результат їхньої роботи зберігається в тих самих файлах репозиторію, які потім проходять через звичні для команди процеси — код‑рев’ю, CI/CD, тестування.
Факт, що конфігурації агентів і субагентів зберігаються в .vibe/agents усередині репозиторію, робить цю систему спільним ресурсом для всієї команди. Новий розробник, який клонує репозиторій, отримує не лише код, а й готовий набір AI‑інструментів, налаштованих під конкретний проєкт: від базових агентів до спеціалізованих субагентів для тестів, рев’ю чи міграцій бази даних.
У результаті Mistral Vibe перетворюється не просто на «розумний автодоповнювач», а на шар оркестрації AI‑процесів поверх кодової бази, який можна версіонувати, рев’ювати й розвивати так само, як і будь‑який інший компонент інфраструктури.
Висновок: AI‑агенти як частина інфраструктури розробки
Mistral Vibe демонструє, як ідея багатoагентних AI‑систем може виглядати в інструменті, орієнтованому на розробників, які живуть у терміналі. Просте встановлення, запуск однією командою, автоматичне індексування git‑репозиторію та відкритий кодовий двигун Devstral 2 створюють базу для щоденного використання.
Над цією базою вибудовується більш складний рівень: вбудовані агенти для типових задач, конфігуровані через TOML кастомні агенти та субагенти, тонке налаштування прав і обмежень, паралельне виконання незалежних процесів. Усе це зберігається в репозиторії й розділяється між учасниками команди, перетворюючи AI‑асистентів на ще один керований елемент інженерної інфраструктури.
Для розробників, які шукають спосіб масштабувати використання AI у своїх проєктах без вибуху витрат і без втрати контролю над процесом, така модель виглядає логічним наступним кроком: не один універсальний агент, а керована екосистема спеціалізованих субагентів, які працюють поруч із кодом і живуть разом із ним у git.