VibeVM Developer Preview 1
https://vibevm.org
Что это? Это как maven/npm/pip - но для спецификаций и прочих промтов. Позволяет контролировать сложность и делиться результатом, когда у тебя объемы текста на языке программирования Markdown стали измеряться десятками тысяч строк и тысячами файлов. Эта штука нужна, если тебе хочется написать большую обьемную задачу, отправить агента работать месяц, и потом вернуться за готовым результатом.
Философское: почему сейчас
В последнее время я подумывал, чтобы вообще всё это не выкладывать и закрыть тему. Пока что я реализовал от силы 5% функциональности, и сложность растет экспоненциально. Это безумие.
Но потом посмотрел на коллег и долго думал.
Посмотрите на Тео или Бриджмайнда - они публикуют свой нейрослоп прямо в прод и им норм. Чем я хуже? Кто я такой, чтобы спорить с трендом?
Второй факт: в конце недели JetBrains собирается выложить новую итерацию своего Air, который на этот раз должен нормально работать в графическом режиме в IDE. VibeVM по идее должен быть идеальной средой для Air. У меня нет никаких инсайдерских превью, что будет уметь новый Air. Но подозреваю что всё то же самое что мой Zap (все еще не выпущенный). Запуск под Air сразу же даст максимальные преимущества.
На прошлой неделе на конференции DotNext я рассказал про VibeVM. Туда забежали первые пользователи. У них уже что-то работает, есть вопросы в личку. Давайте будем честны: если у живых людей возникли вопросы, значит проект перешел из этапа "запускается на моем компьютере" в состояние "теперь с этим мучаются другие люди".
Теперь ваша очередь превозмогать вместе со мной!
Что почитать
- Посмотреть сайт: https://vibevm.org
- Английский мануал: https://vibevm.org/doc/org.vibevm.core/vibevm-docs/1.0.0/start/what-vibevm-is
- Русский мануал (нейроперевод, но достаточно приличный): https://vibevm.org/doc/ru/org.vibevm.core/vibevm-docs/1.0.0/start/what-vibevm-is
- Общий вижен проекта, зачем всё это: https://vibevm.org/vision (русская версия: https://vibevm.org/ru/vision)
- Роадмап, что будет в ближайшем будущем: https://vibevm.org/roadmap
- Как я пишу код внутри VibeVM (и как можете писать вы, но это совершенно не обязательно): https://vibevm.org/why/ai-native/
Чего оно не умеет и не должно
- Внутри VibeVM нет агента. Это инструмент, который готовит контекст к использованию любого агента. Я обычно проверяю Claude, Codex, Qwen Code, OpenCode, GigaCode.
- Чем больше спецификаций вы загрузите - тем больший контекст вам нужен. Демо-пакет "vibe install org.vibevm.world/redbook" требует около 20к токенов контекста просто по факту своей загрузки. Вы еще ничего не написали, а у вас уже минус 20к. Такова судьба всего современного spec driven development, поделать с этим ничего нельзя. Но внутри есть тонна оптимизаций для экономии токенов, про которые я расскажу потом.
- Выводы: если у вас Claude Code или Codex на тарифе ProMax x20 - эта штука сделана специально для вас. Если у вас маленький Qwen 35B A3B с контекстом 128K, то вам нужно ждать следующей версии (Developer Preview 2) в которой будут оптимизации для маленьких моделей (скорей всего будут).
Что оно умеет
- Управлять спецификациями - как в виде пакетов, так и в виде локальной директории со спецификациями
Чего оно не умеет
- Все еще нет плагинов для IDE. Есть только команда "vibe tree" которая в текстографическом режиме работает в терминале. Это весь UI на данный момент. Не то чтобы VibeVM вообще был нужен UI, конечно - наш UI это любой редактор с Markdown: Zed, VSCode, IDEA.
- Оно все еще не умеет работать пакетным менеджером для Linux. Это первая же задача для Developer Preview 2. Если вам зачем-то нужен докерный образ на Алпайне, то он есть Докерхабе.
Где получить помощь и поддержку
- Самая лучшая помощь - это ваш ИИ агент. Возьмите исходник VibeVM, запустите туда Claude/Codex/OpenCode/GigaCode/etc и спросите - что эта штука делает, и как на ней реализовать ваши желания.
- Чат поддержки: https://t.me/vibevm_chat
- Канал поддержки: https://t.me/vibevm
https://vibevm.org
Что это? Это как maven/npm/pip - но для спецификаций и прочих промтов. Позволяет контролировать сложность и делиться результатом, когда у тебя объемы текста на языке программирования Markdown стали измеряться десятками тысяч строк и тысячами файлов. Эта штука нужна, если тебе хочется написать большую обьемную задачу, отправить агента работать месяц, и потом вернуться за готовым результатом.
Философское: почему сейчас
В последнее время я подумывал, чтобы вообще всё это не выкладывать и закрыть тему. Пока что я реализовал от силы 5% функциональности, и сложность растет экспоненциально. Это безумие.
Но потом посмотрел на коллег и долго думал.
Посмотрите на Тео или Бриджмайнда - они публикуют свой нейрослоп прямо в прод и им норм. Чем я хуже? Кто я такой, чтобы спорить с трендом?
Второй факт: в конце недели JetBrains собирается выложить новую итерацию своего Air, который на этот раз должен нормально работать в графическом режиме в IDE. VibeVM по идее должен быть идеальной средой для Air. У меня нет никаких инсайдерских превью, что будет уметь новый Air. Но подозреваю что всё то же самое что мой Zap (все еще не выпущенный). Запуск под Air сразу же даст максимальные преимущества.
На прошлой неделе на конференции DotNext я рассказал про VibeVM. Туда забежали первые пользователи. У них уже что-то работает, есть вопросы в личку. Давайте будем честны: если у живых людей возникли вопросы, значит проект перешел из этапа "запускается на моем компьютере" в состояние "теперь с этим мучаются другие люди".
Теперь ваша очередь превозмогать вместе со мной!
Что почитать
- Посмотреть сайт: https://vibevm.org
- Английский мануал: https://vibevm.org/doc/org.vibevm.core/vibevm-docs/1.0.0/start/what-vibevm-is
- Русский мануал (нейроперевод, но достаточно приличный): https://vibevm.org/doc/ru/org.vibevm.core/vibevm-docs/1.0.0/start/what-vibevm-is
- Общий вижен проекта, зачем всё это: https://vibevm.org/vision (русская версия: https://vibevm.org/ru/vision)
- Роадмап, что будет в ближайшем будущем: https://vibevm.org/roadmap
- Как я пишу код внутри VibeVM (и как можете писать вы, но это совершенно не обязательно): https://vibevm.org/why/ai-native/
Чего оно не умеет и не должно
- Внутри VibeVM нет агента. Это инструмент, который готовит контекст к использованию любого агента. Я обычно проверяю Claude, Codex, Qwen Code, OpenCode, GigaCode.
- Чем больше спецификаций вы загрузите - тем больший контекст вам нужен. Демо-пакет "vibe install org.vibevm.world/redbook" требует около 20к токенов контекста просто по факту своей загрузки. Вы еще ничего не написали, а у вас уже минус 20к. Такова судьба всего современного spec driven development, поделать с этим ничего нельзя. Но внутри есть тонна оптимизаций для экономии токенов, про которые я расскажу потом.
- Выводы: если у вас Claude Code или Codex на тарифе ProMax x20 - эта штука сделана специально для вас. Если у вас маленький Qwen 35B A3B с контекстом 128K, то вам нужно ждать следующей версии (Developer Preview 2) в которой будут оптимизации для маленьких моделей (скорей всего будут).
Что оно умеет
- Управлять спецификациями - как в виде пакетов, так и в виде локальной директории со спецификациями
Чего оно не умеет
- Все еще нет плагинов для IDE. Есть только команда "vibe tree" которая в текстографическом режиме работает в терминале. Это весь UI на данный момент. Не то чтобы VibeVM вообще был нужен UI, конечно - наш UI это любой редактор с Markdown: Zed, VSCode, IDEA.
- Оно все еще не умеет работать пакетным менеджером для Linux. Это первая же задача для Developer Preview 2. Если вам зачем-то нужен докерный образ на Алпайне, то он есть Докерхабе.
Где получить помощь и поддержку
- Самая лучшая помощь - это ваш ИИ агент. Возьмите исходник VibeVM, запустите туда Claude/Codex/OpenCode/GigaCode/etc и спросите - что эта штука делает, и как на ней реализовать ваши желания.
- Чат поддержки: https://t.me/vibevm_chat
- Канал поддержки: https://t.me/vibevm
Forwarded from Откровения от Олега
Сегодня был анонс VibeVM 1.0.0
Но пока вы спите, агенты готовят огромную карту на 1.1.0
Где будут отвечены все очевидные вопросы типа "в speckit есть миграции, а в вайбе нету". Или например, "я делаю агента, как мне получить промежуточный IR в хорошем машиночитаемом виде"
stay tuned
Но пока вы спите, агенты готовят огромную карту на 1.1.0
Где будут отвечены все очевидные вопросы типа "в speckit есть миграции, а в вайбе нету". Или например, "я делаю агента, как мне получить промежуточный IR в хорошем машиночитаемом виде"
stay tuned
👍3❤2🔥2
Выпущен хотфикс VibeVM 1.0.1
Обновление делается командой:
Что случилось? Начал адаптировать первый большой продукт - FPF Анатолия Левенчука
И тут оказалось, что он креативно использует греческие буквы, а парсер к этому не готов. Конкретно:
1. Конвертер Markdown в XML падал на вложенном пункте списка, если текст пункта начинался с не-ASCII символа, например с греческой буквы. Такой отступ учитывался дважды, и обрезка строки попадала в середину символа.
Впрочем, на латинице была та же ошибка, но она молча теряла чекбоксы во вложенных пунктах. Короче, это хорошо, что греческие буквы всё доломали до конца.
2. Вложенные зонтичные пакеты не ставились в проекты с языком спецификаций XML.
Сборка загрузоччика убирала дубли за один проход, а цепочке "зонтик, пакет, его зависимость" нужен повтор до неподвижной точки.
В Markdown-проектах ошибка была еще хуже: текст пакетов попадал в ленту дважды. Это деньги за токены.
И одна ошибка, никак не относящаяся к парсеру:
3. vibe search ничего не находил в реестре по умолчанию (GitHub, GitVerse).
В ходе одного из рефакторингов в августе, индекс реестра пакетов был переделан на обычные плейнтекст файлы вместо API. В перспективе это нужно, чтобы положить весь индекс на дешевый S3.
Я не до конца мигрировал клиент, который пытался ходить на старые урлы и получал 404. Иногда это 404 убивало вообще всю возможность искать.
Теперь клиент сам может скачивать и читать индексный файл. Поскольку код на сервере и клиенте один и тот же, клиент сам может отсортировать результаты - ничуть не хуже, чем сервер.
Обновление делается командой:
vibe self update
Что случилось? Начал адаптировать первый большой продукт - FPF Анатолия Левенчука
И тут оказалось, что он креативно использует греческие буквы, а парсер к этому не готов. Конкретно:
1. Конвертер Markdown в XML падал на вложенном пункте списка, если текст пункта начинался с не-ASCII символа, например с греческой буквы. Такой отступ учитывался дважды, и обрезка строки попадала в середину символа.
Впрочем, на латинице была та же ошибка, но она молча теряла чекбоксы во вложенных пунктах. Короче, это хорошо, что греческие буквы всё доломали до конца.
2. Вложенные зонтичные пакеты не ставились в проекты с языком спецификаций XML.
Сборка загрузоччика убирала дубли за один проход, а цепочке "зонтик, пакет, его зависимость" нужен повтор до неподвижной точки.
В Markdown-проектах ошибка была еще хуже: текст пакетов попадал в ленту дважды. Это деньги за токены.
И одна ошибка, никак не относящаяся к парсеру:
3. vibe search ничего не находил в реестре по умолчанию (GitHub, GitVerse).
В ходе одного из рефакторингов в августе, индекс реестра пакетов был переделан на обычные плейнтекст файлы вместо API. В перспективе это нужно, чтобы положить весь индекс на дешевый S3.
Я не до конца мигрировал клиент, который пытался ходить на старые урлы и получал 404. Иногда это 404 убивало вообще всю возможность искать.
Теперь клиент сам может скачивать и читать индексный файл. Поскольку код на сервере и клиенте один и тот же, клиент сам может отсортировать результаты - ничуть не хуже, чем сервер.
👍1
Forwarded from Откровения от Олега
First Principles Framework (FPF) появился в репозиториях VibeVM
Это всё что нужно сделать :)
ТЕХНИЧЕСКИЕ ДЕТАЛИ
Размер корпуса FPF огромный. Одна только FPF-Spec.md весит 15 мегабайт. Мегабайт: Гитхаб отказывается этот файл показывать в веб-интерфейсе. Чтобы загружать контексты такого размера целиком, нужно быть миллиардером.
И вот тут на помощь приходит VibeVM. Всё дерево пакетов FPF, включая FPF-Spec, Foundational Thinking и Engineering занимает всего лишь 132 тысячи токенов. Ясно, что дальше оно будет разрастаться, по мере чтения новой информации.
Благодаря чему это достигается?
Во-первых, формат материализации - XML. Это позволяет оставить документацию в формате Markdown (т.е. оставить в покое тот текст, который написал автор), но LLM работает уже с его XML представлением, и поэтому хорошо ориентируется по тексту. Именно для этого компилятор Markdown -> XML и был сделан. Для огромных корпусов Markdown, где LLM не может четко определять границы правил внутри Markdown.
Про размеры в токенах. Все спецификации мелко порезаны на целых 37 пакетов. У каждого есть минимальный статический загрузчик, и вот все эти загрузчики в сумме и дают 132 тысячи токенов. В этой "приоритетной линии" лежат оглавления разделов, чтобы агент мог навигироваться по материалу без загрузки полного содержимого пакетов.
Дальше навигация делается spec://-ссылками с динамической загрузкой. Их около 22 тысяч: не катастрофически много, но и не очень мало. Достаточно умный агент все еще может по ним навигироваться.
Для генерации содержимого пакетов применяется скрипт: при обновлении исходного материала на гитхабе, пакеты быстро регенерируются почти без необходимости использовать LLM. Тут очень повезло, что Анатолий уже написал свои спецификации так, что они почти полностью ложатся на модель VibeVM. Иногда мысли у людей сходятся.
В 1.1.0 (на подлёте от недели до месяца) будут специальные оптимизации для FPF. Ну и другим спецификациям такого размера они будут нужны. По сути, текущая комбинация статического загрузчика с динамическими ссылками внутри - это хак, который используется за отсутствием прямой декларации более мощной идеи. С фичами из 1.1.0 можно подумать над еще большей компрессией и динамикой для агентов, которые не могут держать большой контекст в 200к токенов.
vibe install ai.lev/fpf
Это всё что нужно сделать :)
FPF (First Principles Framework) - язык паттернов для строгого мышления в инженерии, исследованиях и менеджменте: набор именованных, связанных между собой паттернов, которые помогают командам и AI-агентам сохранять устойчивыми смыслы, утверждения, свидетельства и решения, пока работа переходит между людьми, инструментами и во времени. По форме это скорее техническая спецификация, чем книга по менеджменту: определения, паттерны и правила проверки. Сейчас FPF - уже не одна спецификация, а экосистема: трансдисциплинарное ядро FPF Core плюс доменные фреймворки (DPF), например для инженерии и нарративизации. При этом автор подчёркивает, что FPF - не агентный фреймворк и не методология программирования, а фреймворк знаний и рассуждений, применимый от производства и строительства до медицинских технологий и образования. Проект открыт на GitHub (github.com/ailev/FPF) под лицензией CC BY 4.0 и развивается в режиме «вечной альфы»: уже используется в рабочих проектах, но продолжает меняться.
Анатолий Левенчук — научный руководитель Школы системного менеджмента и директор по исследованиям Русского отделения международного совета по системной инженерии (INCOSE), с более чем тридцатилетним стажем стратегического и методологического консультирования по инженерии и менеджменту. Профессионально занимается методологией системной и программной инженерии, системного менеджмента, стратегирования и технологического предпринимательства; среди его интересов — искусственный интеллект, глубокие нейросети, онтология, эпистемология и рациональность. Ведёт блог "Лабораторный журнал" (ailev.livejournal.com). Автор серии учебников, включая двухтомник "Системное мышление 2024" и "Методологию 2025".
ТЕХНИЧЕСКИЕ ДЕТАЛИ
Размер корпуса FPF огромный. Одна только FPF-Spec.md весит 15 мегабайт. Мегабайт: Гитхаб отказывается этот файл показывать в веб-интерфейсе. Чтобы загружать контексты такого размера целиком, нужно быть миллиардером.
И вот тут на помощь приходит VibeVM. Всё дерево пакетов FPF, включая FPF-Spec, Foundational Thinking и Engineering занимает всего лишь 132 тысячи токенов. Ясно, что дальше оно будет разрастаться, по мере чтения новой информации.
Благодаря чему это достигается?
Во-первых, формат материализации - XML. Это позволяет оставить документацию в формате Markdown (т.е. оставить в покое тот текст, который написал автор), но LLM работает уже с его XML представлением, и поэтому хорошо ориентируется по тексту. Именно для этого компилятор Markdown -> XML и был сделан. Для огромных корпусов Markdown, где LLM не может четко определять границы правил внутри Markdown.
Про размеры в токенах. Все спецификации мелко порезаны на целых 37 пакетов. У каждого есть минимальный статический загрузчик, и вот все эти загрузчики в сумме и дают 132 тысячи токенов. В этой "приоритетной линии" лежат оглавления разделов, чтобы агент мог навигироваться по материалу без загрузки полного содержимого пакетов.
Дальше навигация делается spec://-ссылками с динамической загрузкой. Их около 22 тысяч: не катастрофически много, но и не очень мало. Достаточно умный агент все еще может по ним навигироваться.
Для генерации содержимого пакетов применяется скрипт: при обновлении исходного материала на гитхабе, пакеты быстро регенерируются почти без необходимости использовать LLM. Тут очень повезло, что Анатолий уже написал свои спецификации так, что они почти полностью ложатся на модель VibeVM. Иногда мысли у людей сходятся.
В 1.1.0 (на подлёте от недели до месяца) будут специальные оптимизации для FPF. Ну и другим спецификациям такого размера они будут нужны. По сути, текущая комбинация статического загрузчика с динамическими ссылками внутри - это хак, который используется за отсутствием прямой декларации более мощной идеи. С фичами из 1.1.0 можно подумать над еще большей компрессией и динамикой для агентов, которые не могут держать большой контекст в 200к токенов.
🔥1
Forwarded from Откровения от Олега
VibeVM 1.0.1 → 1.0.4
КАК ОБНОВИТЬСЯ
Обновиться:
Удалить старые версии, если не нужны:
Откат на старые версии:
ФИЧИ
Установка MCP-репозиториев одной строчкой:
Поддержка Claude Code, Codex, Qwen Code, Open Code (у разных агентов разные форматы конфигураций).
Ставить и удалять можно в несколько агентов по-отдельности.
Для скриптов есть неинтерактивный вариант указать
Важная деталь: Vibe сохраняет набор серверов, выбранный для каждого агента. Если в новой версии пакета появился ещё один сервер, он не будет автоматически добавлен всем клиентам. Уже выбранные серверы обновляются, исчезнувшие объявления убираются, а расширение набора остаётся осознанным действием пользователя.
Если используется флаг -g, то больше нет никаких технических предупреждений о форматах материализации и прочей диагностической фигне. Локальный пакет - это часть продукта, которую надо отлаживать. Глобальный пакет, установленный с модификатором -g, - это сам по себе продукт. Вы как пользователь не должны его отлаживать и пялиться в диагностику, он должен просто работать.
БАГОФИЧИ
vibe init раньше был заточен под пакеты-проекты.
Теперь он сразу собирает все данные: группу, имя, и тип пакета.
Для новичков коротко напоминает как устроены имена пакетов (что группа называется как reversed fully qualified domain name, RFQDN).
БАГФИКСЫ
1) Часть действий, которые приводили к "залипанию" интерфейса на долгих файловых операциях или скачивании чего-то - теперь рисуют анимированные спиннеры загрузки и всё объясняют. В тексте написано о процессе выбора версии, чтения метаданных, поиска источника скачивания, и поиска рабочего checkout, и так далее. Это работает без флага
2) Улучшены JSON ответы для неграфических режимов. Анимированные спиннеры рисуются для людей - а структурные JSON это их аналог для агентов.
3) Запускаторы приложений с флагом -g больше не глючат на Linux, пытаясь запускать .cmd и .ps1 скрипты из Windows.
4) Исправлен баг Markdown-компилятора на вложенных списках с многобайтовыми символами. Ошибка была в вычислении позиции текста: отступ учитывался дважды, и срез строки мог попасть внутрь символа. На ASCII это проявлялось менее заметно — неправильно обрабатывались вложенные checkbox-пункты.
5) Исправлен баг IR-компилятора на вложенных статических зависимостях. Пакет-зонтик может включать другой пакет, который, в свою очередь, статически включает общую основу. При статической компиляции такого дерева должен включаться static hoisting, дедуплицирующий и поднимающий наверх в полосе загрузки такие общие фрагменты. Раньше, в XML-проектах такой граф иногда приводил к ошибке установки. Обработку сделали линейной: она продолжается до получения устойчивого результата, с учетом раскрывающихся вложенных связей.
6) Наконец, и это самое позорное: оказывается, был сломан
КАК ОБНОВИТЬСЯ
Обновиться:
vibe self updateУдалить старые версии, если не нужны:
vibe self gc -> "Prune all instances except active"Откат на старые версии:
vibe self ls чтобы посмотреть какие есть, vibe self use <name> чтобы выбрать нужнуюФИЧИ
Установка MCP-репозиториев одной строчкой:
vibe install -g mcp:ai.lev/fpf-mcpПоддержка Claude Code, Codex, Qwen Code, Open Code (у разных агентов разные форматы конфигураций).
Ставить и удалять можно в несколько агентов по-отдельности.
Для скриптов есть неинтерактивный вариант указать
--agent и --serverВажная деталь: Vibe сохраняет набор серверов, выбранный для каждого агента. Если в новой версии пакета появился ещё один сервер, он не будет автоматически добавлен всем клиентам. Уже выбранные серверы обновляются, исчезнувшие объявления убираются, а расширение набора остаётся осознанным действием пользователя.
Если используется флаг -g, то больше нет никаких технических предупреждений о форматах материализации и прочей диагностической фигне. Локальный пакет - это часть продукта, которую надо отлаживать. Глобальный пакет, установленный с модификатором -g, - это сам по себе продукт. Вы как пользователь не должны его отлаживать и пялиться в диагностику, он должен просто работать.
БАГОФИЧИ
vibe init раньше был заточен под пакеты-проекты.
Теперь он сразу собирает все данные: группу, имя, и тип пакета.
Для новичков коротко напоминает как устроены имена пакетов (что группа называется как reversed fully qualified domain name, RFQDN).
БАГФИКСЫ
1) Часть действий, которые приводили к "залипанию" интерфейса на долгих файловых операциях или скачивании чего-то - теперь рисуют анимированные спиннеры загрузки и всё объясняют. В тексте написано о процессе выбора версии, чтения метаданных, поиска источника скачивания, и поиска рабочего checkout, и так далее. Это работает без флага
--verbose, по дефолту.2) Улучшены JSON ответы для неграфических режимов. Анимированные спиннеры рисуются для людей - а структурные JSON это их аналог для агентов.
3) Запускаторы приложений с флагом -g больше не глючат на Linux, пытаясь запускать .cmd и .ps1 скрипты из Windows.
4) Исправлен баг Markdown-компилятора на вложенных списках с многобайтовыми символами. Ошибка была в вычислении позиции текста: отступ учитывался дважды, и срез строки мог попасть внутрь символа. На ASCII это проявлялось менее заметно — неправильно обрабатывались вложенные checkbox-пункты.
5) Исправлен баг IR-компилятора на вложенных статических зависимостях. Пакет-зонтик может включать другой пакет, который, в свою очередь, статически включает общую основу. При статической компиляции такого дерева должен включаться static hoisting, дедуплицирующий и поднимающий наверх в полосе загрузки такие общие фрагменты. Раньше, в XML-проектах такой граф иногда приводил к ошибке установки. Обработку сделали линейной: она продолжается до получения устойчивого результата, с учетом раскрывающихся вложенных связей.
6) Наконец, и это самое позорное: оказывается, был сломан
vibe search по центральному реестру пакетов. У меня на сборщике было несколько клиентов для центрального реестра, и в дистрибутив подмешался старый. Схема файлов два месяца назад была совсем другая, поэтому по всем путям вместо ответа поиска отдавался 404. Пересобрал с новым модулем поиска, все заработало.❤2
Forwarded from Откровения от Олега
MCP-сервер для First Principles Framework появился в репозитории VibeVM
Важно: требуется версия VibeVM 1.0.4 и выше. Обновление:
У нас уже есть пакет, который устанавливает всё локально, если хочется сделать FPF частью своего проекта (
Но что если хочется просто задавать вопросы агенту, из любого места на файловой системе, без какого либо настроенного проекта?
Этот пакет приносит MCP-сервер, который может точечно отвечать на вопросы.
У этого есть и плюсы, и минусы.
Плюсы
Плюс в том, что база там всегда самая новая. Локальный пакет нужно специально пересобирать, и он будет пересобираться где-то раз в неделю. MCP всегда отвечает самые свежие данные (по крайней мере, данные той свежести, которые решил туда налить создатель системы - Анатолий Левенчук).
Плюс в том, что контекст твоего проекта не заливают десятки тысяч токенов, необходимых для навигации по "обычному" пакету FPF. Если у вас маленькая локальная моделька с маленьким контекстом, это важно.
Плюс в том, что ответы могут доставляться куда быстрее, и в более четком формате, удобном для чтения. Запрос по очень ограниченному контексту обычно более быстрый, чем запрос по "вот тебе весь мой компьютер, скажи что-нибудь, о Великий Вычислитель".
Минусы в том, что такой точечный подход лишает агента способности моментально получить доступ к любым знаниям из базы, используя свою интуицию. Потому что локальной базы нет. Очевидно. Вероятно, ответы через MCP будут более простыми.
Это всегда некий выбор, что вам на самом деле нужнее. Теперь в репозиториях лежат оба варианта. Можно выбрать лучший для вашего случая.
vibe install -g mcp:ai.lev/fpf-mcp
Важно: требуется версия VibeVM 1.0.4 и выше. Обновление:
vibe self update.У нас уже есть пакет, который устанавливает всё локально, если хочется сделать FPF частью своего проекта (
vibe install ai.lev/fpf)Но что если хочется просто задавать вопросы агенту, из любого места на файловой системе, без какого либо настроенного проекта?
Этот пакет приносит MCP-сервер, который может точечно отвечать на вопросы.
У этого есть и плюсы, и минусы.
Плюсы
Плюс в том, что база там всегда самая новая. Локальный пакет нужно специально пересобирать, и он будет пересобираться где-то раз в неделю. MCP всегда отвечает самые свежие данные (по крайней мере, данные той свежести, которые решил туда налить создатель системы - Анатолий Левенчук).
Плюс в том, что контекст твоего проекта не заливают десятки тысяч токенов, необходимых для навигации по "обычному" пакету FPF. Если у вас маленькая локальная моделька с маленьким контекстом, это важно.
Плюс в том, что ответы могут доставляться куда быстрее, и в более четком формате, удобном для чтения. Запрос по очень ограниченному контексту обычно более быстрый, чем запрос по "вот тебе весь мой компьютер, скажи что-нибудь, о Великий Вычислитель".
Минусы в том, что такой точечный подход лишает агента способности моментально получить доступ к любым знаниям из базы, используя свою интуицию. Потому что локальной базы нет. Очевидно. Вероятно, ответы через MCP будут более простыми.
Это всегда некий выбор, что вам на самом деле нужнее. Теперь в репозиториях лежат оба варианта. Можно выбрать лучший для вашего случая.
Forwarded from Откровения от Олега
Как-то так выглядит схема спроектированных, но еще не сделанных ченжей в VibeVM1.1.0
Кажется, у нас день независимости. Дальше от нас ничего не зависит. Вернемся через пару недель и посмотрим, чего там напишет агент.
Кажется, у нас день независимости. Дальше от нас ничего не зависит. Вернемся через пару недель и посмотрим, чего там напишет агент.
Forwarded from Откровения от Олега
Выпущено обновление VibeVM 1.0.5
Починен баг:
Починен баг:
vibe uninstall <package-name> не удалял транзитивные зависимости. Теперь удаляет.Forwarded from Откровения от Олега
Выпущено обновление VibeVM 1.0.7
Раньше кэш работал только с бинарями, а из исходников пересобиралось каждый раз заново. Больше нет.
Если обязательно нужно пересобрать игнорируя кэш, то
===
Спасибо чатланину @sir_lexx, который принес заявку на фичу!
vibe self update
vibe self update
vibe self update
Раньше кэш работал только с бинарями, а из исходников пересобиралось каждый раз заново. Больше нет.
Если обязательно нужно пересобрать игнорируя кэш, то
vibe update --force. Это нужно например, если поменялись какие-то переменные окружения, и по файлам непонятно - это старая сборка или нет. Это нормально.===
Спасибо чатланину @sir_lexx, который принес заявку на фичу!
Forwarded from Откровения от Олега
В VibeVM произошла дурацкая проблема: мы подошли к границе сложности задач, с которыми GPT Astra не знает что делать :))) То есть, она смотрит на фичу и говорит "ой, кажется это невозможно"
Кажется, пора переписывать ядро на Lean и проверять его алгоритмически
Вот и проверим, насколько она сильна в "новой математике". Ну или Скам Альтман опять нам лапшу на уши навесил.
Кажется, пора переписывать ядро на Lean и проверять его алгоритмически
Вот и проверим, насколько она сильна в "новой математике". Ну или Скам Альтман опять нам лапшу на уши навесил.
Перешел к формальному моделированию и доказательству всех важных алгоритмов, для этого используется язык Lean.
Иначе невозможно понять, будет ли работать достаточно сложная штука. Особенно в агентах.
Иначе невозможно понять, будет ли работать достаточно сложная штука. Особенно в агентах.
Lean Language
Lean Programming Language
Lean is an open-source programming language and proof assistant that enables correct, maintainable, and formally verified code.
❤1