Внезапно в Steam вышел симулятор сетевого инженера Data Center, пока что доступна только демка, но 31го марта должна выйти полная версия.

В IDE от JetBrains добавили поддержу Cursor Agent через протокол ACP (Agent Communication Protocol), так что теперь можно пользоваться нормальной средой типа PyCharm, а не пародией на IDE на базе VS Code.

Инструкция как настроить тут, но перед тем как пробовать стоит обновить IDE до версии 2025.3.3, иначе не будет кнопочек нужных.

Из замеченных особенностей:
- Три основных агента (Agent, Plan, Ask) есть
- Можно выбрать любую модель, но Auto one love
- Нельзя разрешить выполнять все команды (типа Allow all как Cursor)
- Недостаёт вывода выполняемых команд через тул Run Command
- Недостаёт информации о заполненности контекста
- Нельзя отредактировать нужное сообщение. можно только сделать stop а потом rollback

PS. Помимо курсора можно добавить в этот плагин и многие другие кодовые агенты, например qwen code или goose, или opencode и так далее.

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

Например, у @gonzo_ML был хороший разбор статьи Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents? (arxiv:2602.11988). Если совсем кратко, то вывод там неприятный, но логичный - автоматически сгенерированные контекстные файлы на уровне репозитория часто не помогают, а скорее мешают. Они снижают долю успешно решённых задач и одновременно увеличивают стоимость инференса. Модель вместо решения задачи уходит в блуждание по кодовой базе и бесконечное "изучение архитектуры", порождая галюнчики.

Из свеженького, что меня побудило написать этот пост:
- в мой любимый KodaCode добавили поддержку SKILLS.md, и AGENTS.md
- @max_about_ai была здравая мысль про документацию в эпоху AI
- а у @countwithsasha был пост про то, как вообще собирать агента из скиллов

То есть с моей точки зрения рынок постепенно обрастает всем этим зоопарком форматов, манифестов и "магических" markdown-файлов.

Но лично мне вся эта практика с одним условным большим `AGENTS.md` на 10к токенов кажется порочной.

Проблема не в том, что агенту не нужен контекст (без контекста, увы, никак). Проблема в том, что люди пытаются запихнуть в один файл вообще всё подряд - архитектуру, команды запуска, ограничения, стили кодинга, особенности тестирования, бизнес-логику, карту директорий, описание CI, правила коммитов, правила работы с миграциями, требования к безопасности и ещё сверху тысячу строк "полезных пояснений". В итоге на каждом запросе в контекст летят тысячи, а на сложных проектах и десятки тысяч токенов текста, большая часть из которых в конкретный момент просто не нужна.

И вот тут у меня каждый раз возникает простой вопрос - а кому вообще выгодна эта мода на огромные универсальные AGENTS.md? Разработчику точно нет. Агенту тоже не особо. Зато очень выгодно вендору, который продаёт доступ к моделям по API. Чем больше токенов вы стабильно прокидываете в каждый запрос, тем больше вы тратите токенов, тем больше зарабатывает вендор.

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

В Cursor правила можно дробить на небольшие, специализированные и адресные кусочки. Какие-то применять всегда, какие-то только по glob-маскам, какие-то подключать вручную, какие-то держать на уровне монорепы, а какие-то внутри конкретного подпроекта. То есть вместо одного аморфного AGENTS.md вы получаете управляемую систему контекста с дюжиной небольших файлов, из которых подтягивается только то, что действительно относится к текущему файлу, текущей задаче или текущему этапу работы.

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

Чуть более подробно почитать про Cursor Rules можете тут, там я рассказываю как раскладывать правила по .cursor/rules/, как ссылаться из них на документацию и почему такой формат удобнее в реальных проектах, а вот тут ещё один пост, где я показывал как использовать правила, документацию и TDD/BDD-подход в связке с агентом.

Подытожу, документация агентам нужна, правила нужны, скиллы нужны, но всё это должно быть модульным, иначе вместо управляемого контекста вы просто сжигаете токены.

С огромным удовольствием прослушал аудиокнигу Сценарии будущего. Как жить и работать в мире захваченном нейросетью и роботами за авторством Руслана Юсуфова.

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

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

Поздравляю всех подписчиц канала с 8 марта!

Нейросети захватывают мир - что делать?

Прочел на Хабре пост "L в аббревиатуре LLM означает «ложь»" и там в очередной раз поднимается популярная в узких кругах тема. Автор рассуждает о том, что нейросети никуда не годятся, что они лишь переосмысляют уже придуманное до них, что разработчики с ИИ только плодят технический долг, а самый правильный путь это отказаться от агентов, вайбкодинга и прочих новых инструментов разработки.

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

В комментариях подсказали, что этот пост перевод The L in "LLM" Stands for Lying, поэтому вопрос про похожесть текста на сгенерированный снимается.

Другой забавный момент в том, что у данной публикации очень большое количество положительных реакций и комментариев, автор прям очень удачно попал в сердечко читателей Хабр. Нюанc только в том, что он не предложил альтернативу, что делать на меняющемся рынке?

И вот это, на мой скромный взгляд, показательная история.

Потому что перед нами нео-луддиты. Не в старом смысле, где люди шли и ломали станки, а в новом. Очень легко ворчать, писать осуждающие тексты, делать вид, что прогресс переоценен, а все новое - это игрульки и ерунда. Суть, впрочем, не меняется. Когда технология начинает резко менять рынок, всегда находятся те, кто пытается не адаптироваться, а объявить саму перемену ошибкой, а создателей виноватыми (в силу возраста или из-за страха потерять уютное место, не суть важно).

И особенно занятно наблюдать это в моей любимой АйТишечке, инженеров годами учили быть (почти) машиной, учили писать (почти) "идеальный" код максимально быстро, вписываться в процессы, ревьюить перфоманс, где-то даже строками кода. А потом внезапно пришли настоящие машины и выяснилось, что они это делают быстрее и в умелых руках даже лучше. И тут у части людей вместо рефлексии началась teh drama.

Хотя для меня решение очевидно. Если значимую часть рутины теперь можно спихнуть на агентов и нейронки, то это не горе, а радость. Можно меньше заниматься механической работой и больше думать, проектировать, проверять, собирать системы, делать продукты, строить агентов, автоматизировать свою работу. То есть заниматься как раз более интересными вещами, а не вот этим вот всем. Кстати, очень рекомендую почитать пост "[Bus Factor] Почему ваша незаменимость — это архитектурная уязвимость (SPOF), а не повод для гордости" на Хабр.

Страдают ИХМО от этого, как мне видится, прежде всего те, кто пришел в IT только ради денег или привык к уютному месту, где можно было делать минимум работы и при этом жить очень неплохо, а прогресс постучал в дверь и намекнул, что так будет не всегда, и вероятность того, что первым делом заменят самых незаменимых с каждым днём всё выше и выше, и вот похоже это многих беспокоит сильнее всего.

Поэтому вся эта риторика про "не надо ваших агентов", "откажитесь от новых инструментов", "все это ненастоящая разработка" звучит не столько как взвешенная критика, а скорее как страх перемен. В этом смысле происходящее очень хорошо ложится на темы из книги "Сценарии будущего", о которой я рассказывал намедни. Там как раз много про то, что вероятные сценарии развития технологий сопровождаются социальными потрясениями, попытками объявить новый этап неправильным и бороться с ним. Но при этом важно осознавать, что прогрессу в целом абсолютно все равно, нравится он кому-то или нет, он просто есть.

Лично я стараюсь смотреть на тенденцию трезво, не быть незаменимым и заранее стелить себе соломку, да, мир меняется, да, общество меняется, всё меняется, что делать? Мой выбор учиться, учиться учиться, перестраиваться, заходить в новые инструменты и осваивать нейронки на уровне практики и теории.

Песочница

Похоже я нашёл первый случай когда несколько агентов работающих параллельно это хорошая идея, встречайте игру Pax Historia.

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

Далее перед пользователем открывается игровая политическая карта и слева чатик, пользователь пишет своё действие, потом нажимает кнопку промотки времени, происходят события и можно почитать, что получилось и как наши действия повлияли на политическую карту. Самое занятное, что другие страны (агенты) тоже живут своей жизнью и одновременно с вашими действиями выполняют какие-то свои (у них происходят разные события укладывающиеся в парадигму данного агента и его сценария).

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

Crab People

Последовал примеру Валерия @neuraldeep и поднял себе на домашней малинке PicoClaw, решил начать с простых задач, типа работы с github и поиска в сети, очень приятно и легко всё настраивается, хотя возможно людям без опыта работы с linux будет местами сложновато, так как надо будет прописывать allow list команд который можно выполнять, но это в любом случае в разы более качественный и удобный проект нежели OpenClaw.

Запустил всё ессно в docker-конейнере.

Чуть поразбирался с этим проектом, он состоит из 3х контейнеров:
- onboard - хитрый контейнер который генерит пустой конфиг
- gateway - контейнер который запускает ботов, без web-интерфейса
- launcher - контейнер который включает в себя все функции gateway, плюс имеет web-интерфейс

В админке (launcher) скажем так не очень много возможностей предусмотрено, хотя вполне достаточно и наверно больше и не требуется, однако, авторизации нет, так что его в формате сайтика за пределы сети выпускать не стоит, поэтому я пока еду на клиенте (gateway).

Ещё пока разбираюсь, но пользоваться приятно.

Обычно я редко пишу про релизы новых языковых моделей, но это случай выдающийся, вчера компания Nvidia зарелизила NVIDIA Nemotron v3, это линейка MoE моделей, на 120B параметров всего и 12B активных.

Нашему внимания представлены несколько вариантов сжатия, самый любопытный из них лично для меня nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4, так как этот формат является почти полным аналогом MXFP4 (подробнее тут).

Позиционируется данная модель как решение для продвинутых on-prem агентов (циферки и правда впечатляют), а так же как конкурент:
- openai/gpt-oss-120b (MoE, у которой лишь 5B активных и только MXFP4)
- Qwen/Qwen3.5-122B-A10B (MoE у которой 10B активных, но нет MXFP4 версий, только BF16, F16 и FP8)

Ну и так вот, примечательно в новом Немотроне то, что у неё 12B активных, что почти является рубиконом эмерджентности (13B параметров), плюс нативная поддержка FP4, а это значит для её запуска на контексте в 128к (но продел до 1m) токенов хватит 86Гб VRAM, почти как gpt-oss-120b.

О чём молчат Антропики (про скилы, опять)

Концепция Skills, которую предложили Антропики не так давно, мне очень нравится, я несколько раз писал на эту тему (раз, два, три), часто пользуюсь готовыми скилами, а какие-то пишу сам, но есть у них один фатальный недостаток, о котором, к моему большому удивлению, мало кто задумывается, эту проблему можно описать как кроссплатформенность компилируемых бинарных файлов.

К примеру, у меня есть скил, который вызывает некий бинарник, скомпилированный под x86/64, и есть Raspberry Pi на процессоре ARM64, допустим, я хочу установить этот скил, он устанавливается, но по факту бесполезен, так как архитектура бинарника и моего процессора не совпадает, можно придумать и другой пример, скажем, бинарь собран под Linux, но пользователь хочет установить скил на Windows.

Из вероятных решений, которые приходят на ум, это процедура установки, когда агент сам скачивает бинарник через условный curl/wget под нужную архитектуру (в момент первого вызова), сам закидывает в папку с бинарниками и выполняет полезную работу, но что-то подобных скилов мне ещё пока не попадалось, все, что видел, предлагают отдельно выполнить установку бинаря и отдельно ставить скил на систему, в которой нужный бинарь уже есть.

А как вы решаете эту проблему?

OpenAPI to CLI это врапер между API и консолью

Не так давно я публиковал проект openapi-to-mcp, который позволяет любой API сервер с нормальной OpenAPI/Swagger спецификацией конвертировать в MCP сервер. Но теперь я развил эту идею в сторону консоли и сделал openapi-to-cli, который по OpenAPI/Swagger спецификации генерит удобную CLI над тем же самым API.

Как это работает

Допустим в спецификации API есть такие эндпоинты:
- GET /messages
- POST /messages
- GET /status
- GET /users

В момент добавления профиля openapi-to-cli конвертирует их в команды CLI примерно такого вида:
- npx openapi-to-cli messages_get
- npx openapi-to-cli messages_post
- npx openapi-to-cli status
- npx openapi-to-cli users

Каждая такая команда это по сути HTTP запрос к API серверу, параметры запроса попадают через опции CLI, а ответ API печатается обратно в терминал, подробную справку по каждой команде можно почитать добавив -h или --help на конце.

Быстрый старт через npx

Самый простой способ попробовать:

npx openapi-to-cli profiles add default \
  --api-base-url http://127.0.0.1:8080 \
  --openapi-spec https://raw.githubusercontent.com/readmeio/oas-examples/refs/heads/main/3.1/json/petstore-simple.json

Эта команда:
1. качает пакет openapi-to-cli, если его еще нет в кэше
2. создает профиль default для вашего API
3. скачивает и кэширует OpenAPI спеку под .ocli/specs/default.json
4. записывает настройки профиля в .ocli/profiles.ini

Список доступных команд можно посмотреть вызвав:

npx openapi-to-cli commands

После этого можно ходить в API из терминала, например вот так:

npx openapi-to-cli messages --limit 10

Есть короткая команда ocli, она заменяет npx openapi-to-cli, но нужно ставить глобально через через:

npm -g openapi-to-cli

Подробная справка на странице проекта.

Исходники: https://github.com/EvilFreelancer/openapi-to-cli
Пакет: https://www.npmjs.com/package/openapi-to-cli

Забудь про MCP и tools — конвертируй 100 000 API методов в один CLI инструмент на лету

Все сейчас пишут MCP-серверы и tools для агентов
На каждый API endpoint — отдельный tool с описанием, параметрами, схемой
10 методов? Ок
100? Уже больно
845 (GitHub API)? Удачи (да да можно делать поиск и тулов и MCP) но какой же это зоопарк и как его поддерживать?

Но так же мы поняли новый тренд это cli обертки
От сюда мы с @evilfreelancer пошли другим путём: берём любой OpenAPI spec (JSON/YAML) и конвертируем его в CLI команды на лету Без кодогенерации.
Без компиляции
Один бинарник — любое API

Что это даёт:

→ ocli search --query "create pull request" --limit 5 — BM25-поиск по 845 эндпоинтам за 7мс
→ ocli search --regex "repos.*pulls" — regex по путям, именам, описаниям
→ Несколько профилей одного API с разными наборами эндпоинтов (include/exclude)
→ Несколько API серверов в одном инструменте

Почему CLI, а не MCP tools для агентов?

100 MCP tools → ~50 000 токенов на описания в контексте
100 CLI команд → 1 tool "execute_command" + поиск нужной команды

Объективно я счита что агентов больше таскают команды вызвать, нежели разбираться с тонне контекста tools

Агент вызывает ocli search, находит нужную команду, выполняет её
Один tool_exec вместо тысяч
Контекстное окно свободно для работы, а не для описаний инструментов.

Сделал быстрый тест на реальных API:
- GitHub API — 845 endpoints, 11MB spec, JSON
- Box API — 258 endpoints, YAML

BM25 поиск — порт из Go (picoclaw) на TypeScript с Robertson IDF smoothing.

npm install -g git+https://github.com/EvilFreelancer/openapi-to-cli.git#feat/command-search

ocli profile add github

ocli search --query "upload file" --limit 5

GitHub: https://github.com/EvilFreelancer/openapi-to-cli