Недавно 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 так и не нашёл))

Замена уже произошла

С ума сойти, но всего три месяца назад я выпустил актуальный на тот момент для себя ролик про три типа разработки:

https://www.youtube.com/watch?v=N_-GFgesQGk

Он был основан на опыте реальной продуктовой разработки в компании, которую, думаю, знают почти все в РФ.

И вот прошло всего три месяца, а я уже понимаю, что ролик неактуален. Хоть бери и удаляй.

Сейчас только и говорят о замене: заменят тех, заменят этих. И, само собой, больше всего эта тема болит у нас, разработчиков.

Но почему мы вообще говорим о замене в контексте будущего?

Среди нас что, одни инженеры уровня сеньеров, которые не замечают происходящего?

Это не будущее. Это уже прошлое.

Оглянитесь: мастера кодинга уже давно не нужны. Их уже заменили.

Я часто вспоминаю свои праймовые годы, когда ходил по собесам. Выставлял резюме уровня «сделал три лендинга, а на четвёртом обосрался» — и мне при этом звонили по 40 раз в день.

Каждой компании «Рога и копыта» нужны были кодеры. И желательно побольше.

Кофейне с лендингом нужен кодер. Небольшому заводу, которому сайт нужен просто для галочки, — кодер. Интернет-магазину на три товара — кодер.

А сейчас огромного количества этих вакансий просто нет.

Кодеров уже заменили.

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

И, что самое интересное, они счастливы.

У меня есть знакомый — владелец небольшого завода по производству смазок. Раньше он постоянно искал кодеров, нервничал, пытался сэкономить. Ему то что-нибудь ломали, то забывали про бэкапы, то очередной вирус сносил WordPress.

А сейчас он делает всё сам.

Да, он обсирается примерно так же, как те кодеры из прошлого.

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

Агент залезет на прод и исправит.

Да, он снова может обосраться. Но через несколько минут снова пофиксит.

Нет никакой грядущей замены.

Она уже произошла.

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

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

Реальные специалисты никуда не денутся.

Просто мест станет меньше.

Потому что валидировать результат можно гораздо меньшим количеством людей.

Но если вы просто кодер — ваше время уже ушло.

И если вам пока повезло, а ваш работодатель немного отстаёт от времени, держитесь за это место до конца.

И отдельно хочется сказать про кодеров, которые сейчас радуются приходу ИИ.

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

ИИ выдаёт им решения, до которых они раньше просто не могли дойти, и появляется ощущение:

«Фух, я успел. Запрыгнул в последний вагон. Теперь я AI-разработчик».

Я бы особо не радовался.

Через какое-то время мясные прокси тоже исчезнут.

И тот факт, что вы когда-то умели писать код, сам по себе никакого преимущества вам не даст.

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

Скорее всего, появится один или несколько харнес-комбайнов.

Возможно, понадобится специалист, чтобы один раз всё настроить.

А возможно, и нет.

Останется несколько экспертов для валидации результата.

А может, и они не останутся.

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

Но прямо сейчас моя мысль простая:

замена уже наступила.

Кодеры больше не нужны.

Инженеры всё ещё востребованы.

Но есть один важный нюанс: далеко не каждой компании и далеко не каждому продукту вообще нужны инженеры.

Раньше им с головой хватало кодеров. Теперь им с головой хватает агентов.

Вчера OpenAI провели DevDay и навалили столько всего, что отдельные анонсы даже нет смысла разбирать, интереснее посмотреть куда вообще всё движется.

И кажется эпоха «просто дайте мне модель поумнее» потихоньку заканчивается 😁

Самое интересное для меня:

🔵 Dots

По сути свой OpenClaw от OpenAI. Always-on агент на GPT-6 Astra, который может работать в фоне, ходить по подключенным приложениям, пользоваться браузером и параллельно выполнять несколько задач.

Дал задачу и пошел пить кофе, он там сам ковыряется.

Мне кажется примерно такой интерфейс взаимодействия с AI мы и будем видеть все чаще, не чат где ты бесконечно пинаешь модель следующим промптом, а поставил задачу и получил результат.

🔵 GPT-6.1 Sol

Почти Astra по сложным задачам и кодингу, но сильно дешевле:

$2 / 1M input
$10 / 1M output
$0.10 / 1M cached input

🔵 Astra Ultrafast

До 300 токенов/сек в Codex, OpenAI заявляют ускорение до 8x.

В чате мне вообще пофиг печатает модель 50 токенов или 300, я не успеваю читать ни то ни другое 😁

А вот для агентов это уже очень важно.

Подумал → вызвал инструмент → посмотрел результат → подумал → снова инструмент.

И так десятки раз. Тут скорость каждого прохода напрямую превращается в скорость выполнения всей задачи.

Правда и лимиты можно с такой скоростью сожрать веселее))

🔵 Decisions API

Вот тут я прям улыбнулся, быстро подсуетились после Jev 😁

По сути даешь варианты действий:

click / screenshot / finish

и маленькая быстрая модель решает что делать дальше.

Большую и дорогую модель оставляем думать там где действительно надо думать, а всякие простые решения внутри лупа отдаем маленькой и быстрой.

Я как раз последние недели ковыряюсь с Jev и дообучаю свой Qwen под decision model, поэтому особенно забавно увидеть теперь этот паттерн отдельным API у OpenAI.

🔵 Codex и Agents API

А вот тут для меня вообще основное направление.

Codex все меньше выглядит как «модель которая пишет код» и все больше как полноценный agent harness: cloud tasks, несколько агентов, code review, security scanning, окружения, работа с файлами, computer use, управление контекстом.

В Agents API тоже добавили computer use, multi-agent, tool search, compaction контекста.

Плюс появились MCP Events. То есть теперь не обязательно чтобы человек вообще первым написал агенту.

Пришло событие → запустился workflow → агент пошел работать.

И вот если собрать весь DevDay целиком, мне кажется главный анонс вообще не Astra, Sol, Dots или Decisions API по отдельности.

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

У тебя может быть одна модель для кода, другая для vision, третья для сложных рассуждений, маленькая decision model которая за миллисекунды решает кого дернуть дальше, а вокруг всего этого инструменты, память, события и harness который этим управляет.

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

Поэтому мне сейчас намного интереснее не кто кого победил на очередные 2% в бенчмарке, а что мы строим вокруг этих моделей.

Потому что можно взять самую умную LLM в мире и получить очень умный чат.

А можно взять модель попроще, нормально собрать вокруг нее harness и получить систему которая реально работает.

Кажется вот за эту часть сейчас и начинается самое интересное.

А вам из анонсов DevDay что больше всего зашло?

https://youtu.be/BofOazb2elc

За двенадцать лет у меня накопилось гораздо больше поражений, чем побед, и некоторые из них окончательно оформились именно в 2026 году. Я рассказываю, почему перестала работать монетизация PHPeople, как IQ Body прошел путь от 20 тысяч рублей в сутки до архива, что AI сделал с MoonShine и почему после долгой борьбы за автономность я снова оказался в найме. Это не исповедь ради жалости: у каждого закрытого проекта остались люди, навыки и решения, которые до сих пор двигают меня вперед. Посмотрите до финала и напишите в комментариях, какое собственное поражение позже оказалось для вас полезным.