Пыхник’26 — 2 октября расскажу про осознанное использование AI.

Скидка 15% по промокоду CUTCODE-26!

👉 Программа и билеты

Но все еще скидка 15% по промокоду CUTCODE-26!

Недавно Jev взлетел в популярности, и если у вас есть Jev API, но вы ещё не знаете, как его тестить, можете использовать этот список.

1. jev-ultrafast
Скоростной браузерный Agent, сделанный с помощью Browser Use. Jev на каждом шаге только решает «что делать, какой элемент кликнуть», а для набора текста зовёт маленькую модель. Поиск рейса в Google Flights занимает около 7 секунд.
https://github.com/browser-use/jev-ultrafast

2. fast-jev-compaction
Сжатие контекста для Claude Code. Перед каждым вызовом инструмента Jev решает, что ещё полезно, а бесполезное удаляет, оставляя оригинал без переписывания.
https://github.com/tamaratran/fast-jev-compaction

3. json-render
Генеративный UI-фреймворк от Vercel Labs. В экспериментах Jev не пишет JSON по токенам, а только выбирает компоненты, свойства и макет.
https://github.com/vercel-labs/json-render

4. typesafe-mcp
Идеально для тех, кто только получил API. Подключает Jev в Claude Code, Claude Desktop, Codex и Pi, чтобы в любой момент делать Choice / Score / Noul.
https://github.com/itsmostafa/typesafe-mcp

5. jev-mcp
Готовый набор инструментов для Agent: проверка фактов, фильтрация контента, семантическая сортировка, классификация и извлечение информации.
https://github.com/jkudish/jev-mcp

6. SemDecide
Делает Jev в виде командной строки. В Shell прямо классифицирует, оценивает, фильтрует — подходит для интеграции с краулерами, CI и пайплайнами данных.
https://github.com/sharziki/semdecide

7. jev-codex-router
Сначала Jev оценивает сложность текущей задачи программирования, а потом решает уровень модели, глубину рассуждений и режим скорости.
https://github.com/0xNatoshi/jev-codex-router

8. Winnow
Сборка мусора контекста для Claude Code. Когда Read / Bash / Grep выдают кучу всего, Jev сначала решает, что действительно связано с текущей задачей.
https://github.com/GhalebDweikat/winnow

9. jev-review
Перед код-ревью прогоняет через Jev, чтобы вытащить высокорискованные изменения, а потом отдаёт на более дорогую большую модель или человеку. С локальной доской.
https://github.com/devagrawal09/jev-review

10. Blink
Делает Jev навигатором по кодовой базе. На каждом уровне директории решает, какие файлы наиболее релевантны текущей проблеме, и идёт глубже.
https://github.com/ellipsis-dev/blink

11. agent-desktop
Автоматизация десктопа. Читает дерево системной доступности, решает, какой кнопкой, меню или полем ввода кликнуть дальше.
https://github.com/lahfir/agent-desktop

12. typesafe-mario
Пусть Jev играет в «Супер Марио». Без скриншотов, прямо читает структурированное состояние из RAM симулятора, а потом решает бежать, прыгать или уворачиваться.
https://github.com/fhshaik/typesafe-mario

13. jev-drone
Управление дроном с помощью Jev. Низкоуровневый полётный контроллер по-прежнему отвечает за стабильность и безопасность, а Jev — только за подъём, торможение, преодоление препятствий и другие высокоуровневые решения.
https://github.com/RomanSlack/jev-drone

14. OneVOneJev
1v1 FPS в браузере. На каждом тике решения нужно определять позиционирование, обзор, прицеливание, стрельбу и прыжки.
https://github.com/emrickgarrett/OneVOneJev

15. jev-trader
Высокочастотный маркет-мейкинг на тестнете Monad. Jev по спреду и направлению сделок решает, покупать или продавать дальше, задержка модели около 81 мс.
https://github.com/jarrodwatts/jev-trader

16. Prism
Не даёт Jev напрямую размещать ордера. Он оценивает состояния вроде toxic flow, рыночного давления, возврата к среднему, а потом отдаёт на исходную стратегию.
https://github.com/irfndi/prism-liquidity-agent

17. neo4jev
Запихивает Jev в граф знаний. На каждом узле решает, какое ребро стоит пройти дальше, и идёт по пути.
https://github.com/jexp/neo4jev

18. jev-curate
С помощью Jev фильтрует данные для обучения. JSONL / Parquet сначала оценивает по качеству, релевантности и рискам, а потом решает, что пускать в дальнейшее обучение.
https://github.com/AkashPriyadarshii/jev-curate

19. Canny
Защита от упрямства Coding Agent, который твердит, что всё сделал. Смотрит вывод инструментов, diff кода и результаты тестов, а потом оценивает, насколько заявление о завершении надёжно.
https://github.com/qkal/Canny

20. killmyidea
Вводишь идею стартапа, Jev оценивает по нескольким измерениям и в итоге выдаёт KILL, FIX или SHIP.
https://github.com/monteduro/killmyidea

Новый ролик на канале 👀

LLM может очень уверенно нести полную чушь - и самое опасное, что заметить это получается не всегда.
В ролике разобрал, как не отдавать нейросетям своё критическое мышление и использовать их с пользой, а не вслепую.

Если работаете с ИИ - советую посмотреть:
https://youtu.be/xUYpYUKTtn0

Ошибка, которую одобрили все

Интересную ситуацию сегодня анализировал.

Есть продукт, где LLM интегрирована практически в каждый этап пайплайна. Сегодня обнаружилась занятная история:

— на этапе разработки допустили ошибку
— на QA эту ошибку покрыли автотестом как правильное поведение
— code review с LLM тоже ничего не нашёл
— в итоге весь пайплайн успешно прошёл, а LLM на каждом этапе при наличии спеки провалидировала результат и пропустила дальше

Я начал раскручивать цепочку назад, чтобы понять, где именно появилась ошибка.

И в итоге дошёл до самого начала — ТЗ.

Изначальная задача была про обработку заказов. Заказы приходят из внешнего мира через шину, мы их сохраняем и маппим под структуру нашего сервиса. Никакой классификации заказов в первоначальном ТЗ не было.

Задачу сделали, написали тесты, всё работает.

Через некоторое время прилетает маленькая задача со скудным ТЗ: забыли учесть, что через ту же шину приходят ещё и возвраты, поэтому у товарных позиций возврата нужно проставлять соответствующий статус.

И вот здесь начинается самое интересное.

Из контекста предметной области довольно логично следует, что возврат — это не просто другой статус товарной позиции. Нужно ещё разобраться с тем, что сейчас на продажу и возврат создаются отдельные заказы.

Но в ТЗ этого нет.

Разработчик увидел простую задачу и практически полностью делегировал её LLM. А LLM сделала ровно то, что попросили: проставила статус.

Code review с LLM прошло — противоречий ТЗ нет.

QA написал автотесты — и они тоже проверяют ровно то поведение, которое описано в ТЗ.

В итоге получился прекрасный комбайн, где каждый этап что-то валидирует, всё зелёное, все довольны — а система делает неправильную вещь 😁

И самое интересное: рой агентов здесь, скорее всего, тоже ничего бы не изменил.

Можно поставить одного агента писать код, второго — тесты, третьего — ревьюить, четвёртого — проверять соответствие спеке. Они могут идеально проверить друг друга и коллективно приехать ровно туда, куда их отправила неправильная или неполная постановка.

Можно делегировать написание кода, автотестов, ревью, приведение ТЗ к единой структуре и ещё кучу механической работы.

Но нельзя ментально выйти из процесса.

Кто-то всё равно должен понимать контекст на каждом этапе и проверять не только «соответствует ли результат ТЗ», но и задаваться вопросом: а правильную ли проблему мы вообще сейчас решаем?

И после таких историй я ещё меньше понимаю рассказы в духе: «сижу PM/CTO, запустил рой агентов, они там сами разработали продукт, а я иногда смотрю на результат».

Без человека, который действительно погружён в контекст, такой рой может оказаться просто очень эффективным способом быстро и качественно сделать не то 😁

В общем, интересный сегодня был анализ.

А ещё я был на созвоне в кафешке, после созвона оставил наушники на столе и спокойно ушёл.

Потом тоже анализировал свою беспечность и пытался найти, на каком этапе пайплайна произошла ошибка.

Но тут, в отличие от истории выше, root cause так и не нашёл))