Когда проект разрастается до сотен Markdown-файлов, десятков спецификаций, инструкций для Claude Code, Codex и других агентов, проблема уже не в том, как написать хороший промт. Проблема в том, как не потерять все эти правила, версионировать их, переносить между проектами и гарантировать, что очередной агент вообще прочитал нужную инструкцию.
VibeVM пытается решить именно эту задачу. Проще всего представить VibeVM как Maven, npm или pip, только зависимостями выступают не столько библиотеки, сколько спецификации, правила разработки, рабочие процессы, навыки агента, инструменты и MCP-серверы. Мне такое сравнение нравится, хотя оно немного упрощает систему. VibeVM не просто скачивает пачку Markdown. Он строит воспроизводимый граф контекста, фиксирует версии и определяет, что агент должен прочитать при старте.
Что именно делает VibeVM
Обычный проект с ИИ-агентом довольно быстро начинает обрастать файлами вроде AGENTS.md, CLAUDE.md, правилами коммитов, архитектурными документами, инструкциями по тестированию и десятками специальных промтов. Пока файлов пять, проблемы нет. Когда файлов пятьсот, разработчик постепенно превращается в библиотекаря, который не знает, какую именно книгу агент вчера прочитал перед тем, как сломать авторизацию.
VibeVM превращает такую документацию в зависимости. Проект получает файл vibe.toml, где перечислены требуемые пакеты. Команда vibe install разрешает зависимости, загружает пакеты, фиксирует конкретные версии и формирует набор материалов для агента.
| Элемент | Роль |
|---|---|
vibe.toml |
Описывает проект и его прямые зависимости |
vibe.lock |
Фиксирует точные версии, происхождение и отпечатки пакетов |
vibevm/vibespecs/ |
Хранит собственные спецификации проекта |
vibevm/vibedeps/ |
Содержит установленные зависимости |
| boot lane | Определяет порядок материалов, которые агент читает при старте |
Последний пункт особенно интересен. VibeVM не предлагает просто засунуть двадцать мегабайт документации в системный промт и молиться на большое контекстное окно. Система формирует упорядоченную загрузочную цепочку. Стабильные и обязательные инструкции читаются сначала, остальные материалы агент может получать по мере необходимости.
У спецификаций появляются адреса вида spec://.... Вместо расплывчатого «посмотри правила обработки ошибок» агенту можно указать конкретное правило или секцию. На больших кодовых базах такая адресация выглядит куда разумнее бесконечного копирования фрагментов Markdown из одного промта в другой.
Пакеты тоже не ограничены промтами. Текущая модель предусматривает восемь типов: flow, feat, stack, tool, lang, mcp, doc и app. Пакет может описывать рабочий процесс, функцию продукта, технологический стек, язык разработки или даже поставлять исполняемый инструмент.
Реестры при этом довольно простые. VibeVM не требует отдельного аналога npmjs.com. Реестр может жить в Git-хостинге, а пакет получает координату вроде org.vibevm.world/wal. Версия фиксируется в lock-файле примерно с той же идеей, ради которой существуют package-lock.json, Cargo.lock и другие подобные механизмы.
Как попробовать VibeVM
На Linux, macOS и WSL разработчики предлагают установочный сценарий:
curl -fsSL https://vibevm.org/install.sh | bash
vibe --version
Для Windows используется PowerShell:
irm https://vibevm.org/install.ps1 | iex
vibe --version
vibe self doctor
Команды вида
curl | bashиirm | iexудобны, но сразу исполняют загруженный из сети код. На рабочей машине я бы сначала посмотрел содержимое установочного сценария или использовал опубликованный дистрибутив. То же правило относится к пакетам и агентам с правом запускать команды. Чем автономнее агент, тем важнее ограничивать права и проверять источники зависимостей.
После установки можно создать тестовый проект:
vibe init hello-vibe
vibe install org.vibevm.world/wal --path hello-vibe
vibe list --path hello-vibe
vibe tree --plain --path hello-vibe
vibe check --path hello-vibe
vibe tree здесь полезнее всего для первого знакомства. Команда показывает не красивую маркетинговую схему, а фактическое дерево зависимостей и то, какой контекст должен получить агент.
На главной странице разработчики предлагают более крупный набор:
vibe install org.vibevm.world/redbook
С большими наборами появляется главный налог Spec-Driven Development. Спецификации тоже занимают контекст. Если подключить огромное дерево правил, часть доступного окна модели исчезнет ещё до начала реальной работы. Никакой пакетный менеджер законов математики здесь не отменяет.
Поэтому я бы не начинал с принципа «установим вообще всё». Сначала несколько действительно общих правил, затем vibe tree, проверка загрузочного контекста и только потом расширение набора.
Самого ИИ внутри VibeVM сейчас нет. Алгоритмические операции выполняет CLI, а действия, которым требуется рассуждение, передаются внешнему агенту. VibeVM умеет подключать навык и MCP-интерфейс для совместимых клиентов. В актуальной документации автоматическая настройка описана для Claude Code, Claude Desktop, Cursor, OpenCode и Codex.
Разделение мне кажется правильным. Модель отвечает за рассуждение, агент управляет инструментами, а VibeVM пытается отвечать за правила, зависимости и воспроизводимость контекста. Менять Claude на Codex при такой архитектуре значительно проще, чем когда половина рабочего процесса зашита в особенности одного клиента.
Где заканчивается рабочий продукт и начинаются обещания
Здесь я бы особенно осторожно относился к красивой формуле «напишем огромную задачу, отправим агента работать на месяц и вернёмся за готовым продуктом». Нынешний VibeVM сам по себе такого агента не создаёт.
Долгосрочной оркестрацией должен заниматься Zap, отдельный проект семейства VibeVM. Запланированы параллельные агенты, устойчивое состояние, вопросы, переживающие перезапуск, отдельные Git worktree и управление длинными цепочками работы. Но публичный roadmap прямо разделяет доступный сегодня Developer Preview 1 и будущие этапы. Zap пока обозначен как проект в разработке.
Поэтому VibeVM сегодня я бы называл инфраструктурой для длинных агентных задач, а не движком длинных задач. Разница существенная. Хорошо подготовленный контекст помогает агенту не забывать архитектуру проекта через двадцать сессий, но сам по себе не заставляет модель месяц автономно принимать правильные решения.
Есть ещё один забавный момент. Текущая версия называется 1.0.0, однако привычный смысл «единички» здесь применять нельзя. Публичный roadmap называет текущий этап Developer Preview 1, а README репозитория ещё жёстче предупреждает, что релиз остаётся alpha и совместимость пока не обещана. Ломающие изменения могут приезжать без миграции.
То есть экспериментировать уже можно. Строить вокруг нынешних форматов критичную корпоративную платформу и рассчитывать десять лет не менять конфигурацию я бы пока не стал.
Интерфейс тоже соответствует стадии проекта. Основная поверхность сейчас терминальная. vibe tree показывает структуру текстом. Плагины для IntelliJ IDEA и Visual Studio Code стоят дальше в дорожной карте.
На этом фоне появление JetBrains Air действительно попадает в интересный момент. JetBrains уже развивает Air как многовендорную среду для агентной разработки и переносит агентный рабочий процесс внутрь своих IDE. Air умеет работать с Codex, Claude и другими агентами, запускать задачи в отдельных средах и показывать изменения разработчику. VibeVM теоретически хорошо ложится под такой верхний уровень как независимый слой спецификаций и контекста.
Но официальной интеграции VibeVM с Air я пока не считаю существующим продуктовым преимуществом. Архитектуры хорошо сочетаются на бумаге. Реальная ценность появится после работающей интеграции, а не после красивой стрелочки на схеме.
Кому VibeVM уже имеет смысл попробовать
Для маленького проекта с одним AGENTS.md, десятком исходников и парой запросов к Codex VibeVM скорее добавит церемоний. Пакетный менеджер документации не нужен человеку, у которого документации три страницы.
Картина меняется, когда один и тот же набор правил используется в нескольких репозиториях, спецификации исчисляются сотнями файлов, над проектом работают разные агенты или приходится постоянно объяснять новой модели архитектуру, правила тестирования и ограничения продукта. Здесь версия спецификации становится такой же реальной зависимостью, как версия библиотеки.
Особенно интересен VibeVM для команд, которые уже дошли до Spec-Driven Development собственными силами и внезапно обнаружили папку с тысячей Markdown-файлов. Обычно следующий шаг там выглядит печально: самописные скрипты копирования, несколько несовместимых AGENTS.md, ссылки на устаревшие документы и один человек, который каким-то чудом помнит, где лежит настоящее правило.
VibeVM предлагает более инженерный ответ. Спецификации получают имена, версии, зависимости, отпечатки, адреса и воспроизводимую процедуру загрузки. По сути разработчики пытаются применить сорок лет опыта пакетных менеджеров к новому типу исходного материала, который внезапно появился благодаря ИИ.
Именно здесь я вижу главную ценность проекта. Не в обещании «ИИ теперь всё напишет сам», а в гораздо более скучной вещи. Когда программировать начинают агенты, инфраструктуре приходится управлять уже не только кодом и библиотеками, но и знаниями, которыми руководствуется агент.
Пока VibeVM остаётся очень ранним и довольно радикальным экспериментом. Форматы могут ломаться, IDE-интеграции ещё впереди, Zap пока не превращает месячную разработку в кнопку «сделать хорошо», а большой стек спецификаций способен съесть заметную часть контекстного окна.
Но направление мне кажется здравым. Если ваш «промт» уже превратился в репозиторий из тысяч файлов, хранить его как случайную пачку Markdown становится примерно так же разумно, как складывать зависимости Java-проекта вручную в папку libs. Я бы начал с маленького тестового проекта, нескольких пакетов и vibe tree. Если после этого структура выглядит понятнее, а не сложнее, VibeVM уже решает реальную проблему.
FAQ
VibeVM заменяет Claude Code или Codex?
Нет. Claude Code, Codex и другие системы выполняют работу агента. VibeVM управляет спецификациями, пакетами, контекстом и частью инфраструктуры вокруг агента.
Чем VibeVM лучше обычного AGENTS.md?
Для небольшого проекта преимуществ может почти не быть. VibeVM становится интереснее, когда правил много, между ними появляются зависимости, одни спецификации используются в нескольких проектах, а версии нужно фиксировать и обновлять контролируемо.
Можно ли хранить собственные закрытые спецификации?
Да. Архитектура предусматривает частные реестры. Для корпоративных правил такой режим выглядит логичнее публикации спецификаций в открытом реестре.
Работает ли VibeVM без интернета?
Уже загруженные пакеты можно использовать через локальное хранилище и режим
vibe install --offline. Если нужной зависимости в локальном кэше нет, установка завершится ошибкой, а не тихо подменит пакет чем-то другим.
Почему версия 1.0.0 ещё не означает стабильность?
Разработчики прямо предупреждают о ранней стадии проекта и возможности несовместимых изменений. При оценке зрелости VibeVM сейчас разумнее смотреть на статус Developer Preview и предупреждения репозитория, а не только на номер версии.
Подойдёт ли VibeVM небольшой локальной модели?
Зависит от размера подключённых спецификаций и способа их загрузки. Большой пакет правил способен занять значительную часть контекстного окна. Для маленьких моделей разумнее собирать минимальный стек и активно пользоваться адресной загрузкой материалов вместо постоянной загрузки всего корпуса.
Есть ли у VibeVM графический интерфейс?
Основной рабочий интерфейс текущей версии остаётся терминальным. IDE-плагины для IntelliJ IDEA и Visual Studio Code присутствуют в дальнейшей дорожной карте.
Может ли VibeVM оставить агента программировать на месяц?
Сам VibeVM такую задачу не решает. Он может подготовить воспроизводимый контекст для длинной разработки. Управлять продолжительной параллельной работой агентов должен будущий Zap или другой внешний оркестратор.
