Как жить с AI-пиарами в опенсорсе

Бедные опенсорс-проекты: туда сейчас заносят какое-то бесконечное количество AI-слопных PR. Поэтому всё актуальнее вопрос – как с этим жить и как такое правильно мейнтейнить? Полностью запрещать использование AI – ну очень топорно и тупо.

Ребята из Rust тоже столкнулись с этой проблемой. В статье о новых правилах использования LLM при контрибьюте в rust-lang/rust они делятся своим заходом.

Какие вообще проблемы появились:
– Аккуратно оформленный PR больше ничего не доказывает. Раньше, если пиар сделан по всем правилам, скорее всего, человек явно постарался и приложил усилия. Теперь за таким PR может не стоять ни особых усилий, ни понимания, как, что и зачем сделано.
– Узкое место опенсорса – ревью. Тут история такая, что сейчас кодогенерация ничего не стоит. Бац-бац, пиар. А ревьюеру потом сиди, разбирайся, что к чему, а самое главное – нужно ли вообще это тащить в проект.
– Копипаст ответов LLM ломает коммуникацию. Авторы пиаров иногда просто копируют комментарии ревьюера в LLM, а ответ модели – обратно в GitHub. Получается какая-то шляпа. Для ревьюера это бессмысленный прокси-слой: если бы ему было нужно мнение модели, он мог бы спросить её сам.

Чтобы как-то направить этот поток AI-пиаров, ребята зафиксировали несколько правил:
– использовать LLM никто не запрещает: ресерчить, анализировать и проверять код, искать варианты решения и делать ревью – пожалуйста; ограничения начинаются там, где модель уже сама генерирует код для PR
– исключение – заранее согласованные некритичные изменения: сгенерированный код должен быть качественным, покрытым тестами и предварительно отревьюенным, а использование LLM нужно явно указать
– публичный LLM-текст нужно маркировать
– человеческое ревью и самостоятельная проверка остаются обязательными

Мне кажется, это неплохое начало: Rust пытается задать некую канву, не запрещая всё подряд. Насколько эти правила будут соблюдаться – отдельный вопрос: проверить, что код не AI-слопный и человек понимает, что принёс, достаточно трудоёмко.

#ai

Как не превратить AGENTS.md в свалку

AGENTS.md – удобная штука, чтобы задать агенту контекст о проекте. Но сам по себе файл еще не делает работу с агентом лучше.

На практике я часто вижу такие проблемы:
– умная машина сгенерила большой файл, а нужно ли все это добро – непонятно. Часто это просто булшит на все случаи жизни
– файл не обновляется. Открываешь проект, а там напротив AGENTS.md updated 5 months ago, старые пути и уже неактуальные решения. Вспомните, когда вы пытались изучать неактуальную доку, какие были ощущения, а агента это вообще может уводить не туда
– каждый понемногу дописывает свои правила, что-то дублируется, что-то друг другу противоречит

Примерно о том же пишет Мэтт Покок. Советы довольно банальные и понятные, но мало кто им реально следует:
– не генерить AGENTS.md автоматически
– держать корневой AGENTS.md минималистичным, только факты, никакой воды
– не фиксировать структуру файлов в проекте – она быстро устаревает. Лучше дать агенту более стабильные ориентиры: что делает система и за что отвечают ее части
– использовать progressive disclosure: правила для TypeScript, тестов, API и других отдельных областей вынести в свои документы, а из AGENTS.md только ссылаться на них
– в монорепе раскладывать контекст по уровням: в корне оставить общие правила, а детали конкретного пакета положить в его собственный AGENTS.md
– регулярно вычищать противоречивые, дублирующиеся, слишком общие и очевидные инструкции вроде "пиши чистый код" или "пиши как опытный разработчик". Для такой ревизии Мэтт даже дает готовый промпт: найти противоречия, оставить в корневом файле только необходимое, разнести остальные правила по тематическим документам, а лишнее пометить на удаление

Короче, нужно бдеть и не давать всякой фигне прорастать в AGENTS.md

#ai

Что там по скиллам

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

С чего начать
– Скиллы в агентах – часть 1: база – что такое скилл, как он устроен и как progressive disclosure помогает не забивать контекст агента
– Все ли так классно со скиллами – часть 2 – где скиллы проигрывают agents.md, почему они не заменяют MCP и для каких задач подходят лучше всего
– Где брать скиллы – часть 3 – каталог skills.sh и несколько скиллов, которыми я пользуюсь сам: для дизайна, брейншторма, презентаций и e2e-тестов
– Создаём свои скиллы – часть 4 – как делать скиллы на основе реальных сценариев, использовать skill-creator и evals, а также не раздувать SKILL.md

Практика и качество
– Скилл поверх MCP – зачем добавлять к MCP не только тулы, но и знания о правильной работе с сервисом
– Скиллы: как создавать, улучшать и распространять на команды – запись моего доклада на Podlodka: от устройства и установки скиллов до evals и дистрибуции AI-артефактов на команды
– Как писать скиллы – вызов скилла, структура, управление поведением агента и регулярная чистка инструкций
– Don’t ship skills without evals – как проверить, что скилл действительно улучшает результат, какие кейсы собирать и зачем сравнивать работу со скиллом и без него

Всякое разное
– Caveman экономит токены. Но не 65% – сколько токенов скилл экономит на реальных агентных задачах и влияет ли это на качество
– Superpowers для разработки с агентами – набор скиллов, который в процессе разработки ведёт агента через дизайн, планирование, TDD и ревью

#ai #devfm

Как дистрибутировать AI-артефакты

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

У разных агентов уже есть плагины, которые позволяют забандлить набор артефактов для команды или конкретного сценария работы. Но каждый городит своё: форматы плагинов OpenCode, Claude Code и Codex не очень-то совместимы.

И вот собрались умные мужи из Amazon, Cursor, Microsoft, OpenAI и Vercel и попытались решить эту проблему, предложив Agent Plugins – единый формат плагинов для разных агентов.

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

Скиллы находятся в skills/, а MCP-серверы описываются в mcp.json. Совместимый клиент знает, где искать эти компоненты, и может подключить их своим способом. При этом сам стандарт пока описывает только два типа компонентов: скиллы и MCP-серверы.

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

В общем, заход хороший, но как будто не со всей силы.

Некоторое время назад мы начали решать эту задачу на работе и сделали свой механизм пресетов. Он позволяет объединить в один набор MCP, скиллы, рулы, хуки и агентов. Про него я немного рассказал в конце доклада про скиллы. При этом артефакты мы распространяем специальной утилитой, которая знает, как устроены пресеты, и умеет раскладывать их по конфигам разных агентов.

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

#ai

Agent Reach – доступ к разным источникам для агентов

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

Некоторое время назад нашёл Agent Reach – утилиту, которая устанавливает и настраивает для агента инструменты доступа к разным платформам. Например, она умеет читать и искать посты в богомерзком Twitter, работать с Reddit, YouTube, GitHub, LinkedIn и Instagram, а также парсить RSS.

В общем, если искали удобный способ подключить к агенту разные источники – попробуйте.

Как улучшать скиллы по расписанию

В посте про Codex Desktop я уже рассказывал, что использую Scheduled для периодических задач. Одна из них кажется достаточно полезной, чтобы рассказать отдельно: раз в день Codex просматривает недавние сессии и предлагает, что стоит поправить.

Как работает Scheduled-задача
– анализирует сессии за последние сутки, а если вчерашний запуск был неудачным – расширяет период анализа
– читает личные скиллы, проектные скиллы, которые использовались в сессиях, и нужные AGENTS.md
– автоматически ничего не правит, а предлагает изменения

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

Конечно, зачастую предлагается какая-то фигня, которую я просто игнорирую – именно поэтому не даю автоматически все править. Но и полезные штуки тоже находятся. Из последнего:
– заметил, что в нескольких сессиях я повторял одни и те же требования к интерфейсу. Мы закрепили их в проектном AGENTS.md, и теперь не нужно каждый раз объяснять агенту, какие правила применять
– нашел несколько дублирующихся скиллов с одинаковыми именами. Лишние копии удалили
– обнаружил, что один из общекомпанейских скиллов ссылался на устаревший скилл. Поправили – стало лучше сразу большому количеству людей :)
– заметил, что скилл для ежедневного разбора почты пропускал новые комментарии в задачах, назначенных на меня, если там не было прямого упоминания. Правило поправили и добавили тесты

В итоге каждое утро начинается с просмотра того, что ещё можно подтюнить.

#ai

Deep Tech Night

Я периодически рассказываю об интересных конференциях. И вот скоро, 5 сентября, состоится Deep Tech Night.

Основная тема, конечно aiaiaiiaiaia. Должно быть прикольно. Приходите :)

В этом году основной фокус – на онлайн-формате. Но офлайн тоже будет: можно подать заявочку.

Еще один способ внедрить AI в личный рабочий процесс

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

Я стараюсь критически смотреть на свои задачи и думать, где агент может помочь. Можно ли отдать ему просмотр досок, подготовку ко встречам, ревью PR, работу с требованиями, исследование или ещё что-то.

В таск-трекере периодически накапливается много муторных менеджерских задач. Делать их руками – ну такое, потому что всегда находится что-то более приоритетное. Агент бы справился, но ему явно не хватило бы контекста.

Поэтому я проделал такое упражнение:

1. Все задачи, с которыми, как мне казалось, агент в целом может справиться, пометил тегом agent.
2. Открыл новую сессию и попросил брать эти задачи по очереди и выполнять.
3. Если чего-то не знаешь или в чём-то не уверен – спрашивай. После моего ответа записывай новое знание в AGENTS.md.

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

Например, хорошо пошла актуализация роадмапа. Сейчас в проекте много зависимостей, поэтому постоянно нужно находить тикеты, проставлять связи и актуализировать даты. Делать всё это руками – ну такое, явно не для человеков. А агент с нужным контекстом в итоге всё прошуршал и сделал. Мне только периодически нужно было отвечать на вопросы и контролировать, всё ли сделано правильно.

Заход неплохой с точки зрения агентизации некоторой рутины – рекомендую попробовать.

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

#agents #ai #devfm