В продолжение предыдущего поста - цифры по памяти получаются большие, и это на достаточно скромной модели.
У условного ChatGPT будет в 50 раз больше, или 40 х 50 = 2 Тб.
Как оно работает?
Как работают коммерческие LLM мы не знаем, открытых данных по коммерческим провайдерам: OpenAI, Anthropic, Google - нет.
Поэтому далее будет много предположений.
В качестве крупного провайдера LLM возьмем ChatGPT.
Пусть у него 1 млн карточек NVidia https://www.tomsguide.com/ai/sam-altmans-trillion-dollar-ai-vision-starts-with-100-million-gpus-heres-what-that-means-for-the-future-of-chatgpt-and-you.
Пусть это NVidia H100, т.е. получаем 80 х 10^6 Гб памяти.
Ремарка: снова хочется сказать - вот куда вся память делась!)
Размер памяти для хранения модели как уже говорилось пусть будет 2 Тб = 2000 Гб.
Пусть одна модель шарится на 10 серверов: в один (8 х 80 = 640 Гб) такая не влезет, а если шарить слишком на много серверов - вырастает latency.
На 10 серверов получаем 6400 Гб памяти, 6400 - 2000 = 4400 Гб на KV кэш.
Размер сессии у нас был 2 Гб х 50 = 100 Гб, но это для кодинга.
Исходя из данные тут https://www.index.dev/blog/chatgpt-statistics 50% можно сессий можно считать рабочими (кодинг, проекты), 50% - вопросы и ответы.
Вторые сильно меньше по контексту, пусть будет 3 000 токенов. Среднее - 33 000 токенов.
Т.е. на сессию берем 100 / 2 = 50 Гб.
4400 / 50 ~ 100 сессий на 10 серверов.
Пусть на инференс уходит 80% карточек. Остальное оставим на обучение и тестовые стенды.
Это 800 000.
Итого, система держит 800 000 / 8 / 10 * 100 ~ 1 млн сессий.
DAU у ChatGPT порядка 100 млн https://www.incremys.com/en/resources/blog/chatgpt-statistics
По часовым поясам они распределены неравномерно, возьмем 16 активных часов.
Это 100 / 16 ~ 6 млн человек в час.
Итого - уже не хватает, учитывая что 50% сессий длинные, а аудитория растет.
И тут можно понять, почему все агенты повторно шлют историю с каждым запросом, см. https://t.me/javaKotlinDevOps/581.
Хранить в памяти сессию, не зная вернется ли пользователь, с такими нагрузками нельзя.
Соответственно, тут или сбрасывать на диск (наверное SSD) в векторизованном виде, либо хранить ID сессии и каждый раз преобразовывать заново из текста запроса.
Если используется первый вариант, а для скорости ответа это важно - то становится понятно, почему также подорожали и SSD диски)))
#ai
У условного ChatGPT будет в 50 раз больше, или 40 х 50 = 2 Тб.
Как оно работает?
Как работают коммерческие LLM мы не знаем, открытых данных по коммерческим провайдерам: OpenAI, Anthropic, Google - нет.
Поэтому далее будет много предположений.
В качестве крупного провайдера LLM возьмем ChatGPT.
Пусть у него 1 млн карточек NVidia https://www.tomsguide.com/ai/sam-altmans-trillion-dollar-ai-vision-starts-with-100-million-gpus-heres-what-that-means-for-the-future-of-chatgpt-and-you.
Пусть это NVidia H100, т.е. получаем 80 х 10^6 Гб памяти.
Ремарка: снова хочется сказать - вот куда вся память делась!)
Размер памяти для хранения модели как уже говорилось пусть будет 2 Тб = 2000 Гб.
Пусть одна модель шарится на 10 серверов: в один (8 х 80 = 640 Гб) такая не влезет, а если шарить слишком на много серверов - вырастает latency.
На 10 серверов получаем 6400 Гб памяти, 6400 - 2000 = 4400 Гб на KV кэш.
Размер сессии у нас был 2 Гб х 50 = 100 Гб, но это для кодинга.
Исходя из данные тут https://www.index.dev/blog/chatgpt-statistics 50% можно сессий можно считать рабочими (кодинг, проекты), 50% - вопросы и ответы.
Вторые сильно меньше по контексту, пусть будет 3 000 токенов. Среднее - 33 000 токенов.
Т.е. на сессию берем 100 / 2 = 50 Гб.
4400 / 50 ~ 100 сессий на 10 серверов.
Пусть на инференс уходит 80% карточек. Остальное оставим на обучение и тестовые стенды.
Это 800 000.
Итого, система держит 800 000 / 8 / 10 * 100 ~ 1 млн сессий.
DAU у ChatGPT порядка 100 млн https://www.incremys.com/en/resources/blog/chatgpt-statistics
По часовым поясам они распределены неравномерно, возьмем 16 активных часов.
Это 100 / 16 ~ 6 млн человек в час.
Итого - уже не хватает, учитывая что 50% сессий длинные, а аудитория растет.
И тут можно понять, почему все агенты повторно шлют историю с каждым запросом, см. https://t.me/javaKotlinDevOps/581.
Хранить в памяти сессию, не зная вернется ли пользователь, с такими нагрузками нельзя.
Соответственно, тут или сбрасывать на диск (наверное SSD) в векторизованном виде, либо хранить ID сессии и каждый раз преобразовывать заново из текста запроса.
Если используется первый вариант, а для скорости ответа это важно - то становится понятно, почему также подорожали и SSD диски)))
#ai
tom's guide
Why OpenAI wants 100 million GPUs — and how it could supercharge ChatGPT
's CEO Sam Altman has a bold vision for the future of AI, something other big tech can’t compete with: one powered by 100 million GPUs.
🔥1
Хочется добить тему с MCP, точнее о проблеме с загрязнением контекста тулами из MCP.
Схемами тулов, если уж быть точным.
Есть еще одно решение - MCP Progressive Discovery.
Т.е. MCP сервер не сразу объявляет все доступные тулы, а по мере необходимости.
Как это сделать?
Объявляем meta-tool, один.
В его описании указываем все, что умеет MCP.
Как только клиент его вызывает, возвращаем ему что-то типа: "подожди немного и вызови вот такой тул".
Бросаем событие list_changed - это часть протокола MCP, позволяющая динамически менять список объявляемых тулов и оповещать об этом клиентов.
А клиент, соответственно, получив данное событие обновляет список тулов и вызывает нужный.
Будет ли работать на всех агентах - думаю нет, надо тестить. Агент должен поддерживать событие list_changed.
К слову, если объявить у MCP сервера кастомное API слушателя событий, и бросать ему туда события о том, что происходит в агенте - можно даже не ждать, пока он вызовет Meta-tool.
Ну, например, начали работать с git - логично показать соответствующие тулы.
Еще вариант - тот же meta-tool, но заменяющий собой несколько атомарных тулов.
Например, за все операции с git.
Я тут вижу много проблем: теряем Single Responsibility, схемы становятся формальными (объявляем что-то типа response: object), валидация типов будет происходить в коде в рантайме.
Но в каких-то случаях может пригодится. Можно его переформулировать как упрощение API MCP сервера с целью уменьшения размер схем.
#ai #ai_agents #mcp #ai_agent_context_management
Схемами тулов, если уж быть точным.
Есть еще одно решение - MCP Progressive Discovery.
Т.е. MCP сервер не сразу объявляет все доступные тулы, а по мере необходимости.
Как это сделать?
Объявляем meta-tool, один.
В его описании указываем все, что умеет MCP.
Как только клиент его вызывает, возвращаем ему что-то типа: "подожди немного и вызови вот такой тул".
Бросаем событие list_changed - это часть протокола MCP, позволяющая динамически менять список объявляемых тулов и оповещать об этом клиентов.
А клиент, соответственно, получив данное событие обновляет список тулов и вызывает нужный.
Будет ли работать на всех агентах - думаю нет, надо тестить. Агент должен поддерживать событие list_changed.
К слову, если объявить у MCP сервера кастомное API слушателя событий, и бросать ему туда события о том, что происходит в агенте - можно даже не ждать, пока он вызовет Meta-tool.
Ну, например, начали работать с git - логично показать соответствующие тулы.
Еще вариант - тот же meta-tool, но заменяющий собой несколько атомарных тулов.
Например, за все операции с git.
Я тут вижу много проблем: теряем Single Responsibility, схемы становятся формальными (объявляем что-то типа response: object), валидация типов будет происходить в коде в рантайме.
Но в каких-то случаях может пригодится. Можно его переформулировать как упрощение API MCP сервера с целью уменьшения размер схем.
#ai #ai_agents #mcp #ai_agent_context_management
Я уже писал, что протокол общения между агентами пока не стандартизирован в моем понимании, хотя лидирующеэий стандарт - A2A - вроде как есть. Даже в Spring AI поддерживается.
Но кажется у него появился сильный конкурент)
#ai #ai_standards
Но кажется у него появился сильный конкурент)
#ai #ai_standards
Forwarded from Pavel Durov (Pavel Durov)
This media is not supported in your browser
VIEW IN TELEGRAM
🛠 Start building!
Please open Telegram to view this post
VIEW IN TELEGRAM
Есть такая проблема у AI агентов - постоянные подтверждения действий.
Лично для меня это самая большая проблема на данный момент.
Ошибки в коде проверяются на тестах и ревью. Да, для того, чтобы ревью было не формальным - нужно планировать и бить задачу на малые итерации.
Любые действия в репозитории можно откатить.
А вот с подтверждениями беда.
Почему не помогают существующие настройки?
У большинства агентов есть permission mode.
По умолчанию он спрашивает разрешения на все, кроме чтения.
Можно включить edit mode и всегда разрешить редактирование файлов.
Ок, но вызовы shell при этом будут требовать подтверждения.
Также можно ограничить список тулов как в основном агенте, так и в субагентах.
Но тот же shell тул нужен.
И на самом деле как раз с ним и проблема.
Да, для вызовов тулов включая shell есть allow и block листы.
Где-то они работают по совпадению префиксов, где-то по регулярке.
Первый вариант совсем грустный, т.к.
Но и регуляркой сложно закрыть цепочку из нескольких команд, выстроенных в конвейер.
А LLM такие команды любит.
А разрешение bash(*) - это по сути разрешение всего.
Да, можно разрешить вообще все - yolo permission mode (Cline, Qwen) или bypassPermissions (Claude).
Но тут есть риски - если код из Git можно восстановить, то файлы с рабочей машины - не всегда.
Что делать?
Решение номер раз - виртуалка\Docker. И далее подключаемся по ssh или Remote Development в IDEA (тоже ssh).
Некоторые агенты встроили эту фичу в виде sandbox, но похожий результат достигается самостоятельно - Docker и ssh.
Вроде проблема решена, но есть нюанс.
Иногда в самом деле нужно подтверждать действия в процессе выполнения задачи, чтобы не переделывать код на финальном ревью человеком.
Это может быть этап промежуточного ревью кода моделью или исправления падающих тестов.
Или скачивание каких-то зависимостей из нестандартных репозиториев.
Или рефакторинг, требующийся для выполнения текущей задачи.
О серьезности проблемы говорит множество тикетов на эту тему. Я взял из трекера Claude:
https://github.com/anthropics/claude-code/issues/6850
https://github.com/anthropics/claude-code/issues/2719
https://github.com/anthropics/claude-code/issues/3361
https://github.com/anthropics/claude-code/issues/13340
Тут есть интересное альтернативное решение - Claude Auto Mode https://code.claude.com/docs/en/permission-modes#eliminate-prompts-with-auto-mode
То, что его придумал Claude думаю никого не удивило)
В чем суть?
Этот режим заточен под длительные сессии разработки и призван минимизировать подключение человека.
Как это делается?
Есть ML моделька, обученная как я подозреваю на данных Claude.
У нее есть список разрешений и запретов по умолчанию:
Плюс модель читает лог текущей сессии и добавляет запреты из команд разработчика.
Если действие признано запрещенным - причина запрета возвращается в агента, и он пробует другие варианты.
Не зациклится ли он - тут зависит от силы модели.
Если какой-то запрет будет срабатывать слишком часто - 3 раза подряд или более 20 за сессию - режим временно выключается и требуется подтверждение пользователя.
После подтверждения - включается заново.
Проверку делает модель, а не регулярка, поэтому риски конечно есть. Но такой режим нужен, это в любом случае безопаснее yolo, и быстрее default или edit режима.
Некий компромисс.
Лично для меня это самая большая проблема на данный момент.
Ошибки в коде проверяются на тестах и ревью. Да, для того, чтобы ревью было не формальным - нужно планировать и бить задачу на малые итерации.
Любые действия в репозитории можно откатить.
А вот с подтверждениями беда.
Почему не помогают существующие настройки?
У большинства агентов есть permission mode.
По умолчанию он спрашивает разрешения на все, кроме чтения.
Можно включить edit mode и всегда разрешить редактирование файлов.
Ок, но вызовы shell при этом будут требовать подтверждения.
Также можно ограничить список тулов как в основном агенте, так и в субагентах.
Но тот же shell тул нужен.
И на самом деле как раз с ним и проблема.
Да, для вызовов тулов включая shell есть allow и block листы.
Где-то они работают по совпадению префиксов, где-то по регулярке.
Первый вариант совсем грустный, т.к.
echo file1.txt file2.txt file3.txt | xargs rm
Но и регуляркой сложно закрыть цепочку из нескольких команд, выстроенных в конвейер.
А LLM такие команды любит.
А разрешение bash(*) - это по сути разрешение всего.
Да, можно разрешить вообще все - yolo permission mode (Cline, Qwen) или bypassPermissions (Claude).
Но тут есть риски - если код из Git можно восстановить, то файлы с рабочей машины - не всегда.
Что делать?
Решение номер раз - виртуалка\Docker. И далее подключаемся по ssh или Remote Development в IDEA (тоже ssh).
Некоторые агенты встроили эту фичу в виде sandbox, но похожий результат достигается самостоятельно - Docker и ssh.
Вроде проблема решена, но есть нюанс.
Иногда в самом деле нужно подтверждать действия в процессе выполнения задачи, чтобы не переделывать код на финальном ревью человеком.
Это может быть этап промежуточного ревью кода моделью или исправления падающих тестов.
Или скачивание каких-то зависимостей из нестандартных репозиториев.
Или рефакторинг, требующийся для выполнения текущей задачи.
О серьезности проблемы говорит множество тикетов на эту тему. Я взял из трекера Claude:
https://github.com/anthropics/claude-code/issues/6850
https://github.com/anthropics/claude-code/issues/2719
https://github.com/anthropics/claude-code/issues/3361
https://github.com/anthropics/claude-code/issues/13340
Тут есть интересное альтернативное решение - Claude Auto Mode https://code.claude.com/docs/en/permission-modes#eliminate-prompts-with-auto-mode
То, что его придумал Claude думаю никого не удивило)
В чем суть?
Этот режим заточен под длительные сессии разработки и призван минимизировать подключение человека.
Как это делается?
Есть ML моделька, обученная как я подозреваю на данных Claude.
У нее есть список разрешений и запретов по умолчанию:
Blocked by default:
Downloading and executing code, like curl | bash
Sending sensitive data to external endpoints
Production deploys and migrations
Mass deletion on cloud storage
Granting IAM or repo permissions
Modifying shared infrastructure
Irreversibly destroying files that existed before the session
Force push, or pushing directly to main
Allowed by default:
Local file operations in your working directory
Installing dependencies declared in your lock files or manifests
Reading .env and sending credentials to their matching API
Read-only HTTP requests
Pushing to the branch you started on or one Claude created
Плюс модель читает лог текущей сессии и добавляет запреты из команд разработчика.
Если действие признано запрещенным - причина запрета возвращается в агента, и он пробует другие варианты.
Не зациклится ли он - тут зависит от силы модели.
Если какой-то запрет будет срабатывать слишком часто - 3 раза подряд или более 20 за сессию - режим временно выключается и требуется подтверждение пользователя.
После подтверждения - включается заново.
Проверку делает модель, а не регулярка, поэтому риски конечно есть. Но такой режим нужен, это в любом случае безопаснее yolo, и быстрее default или edit режима.
Некий компромисс.
Итого, подход правильный, но к сожалению он доступен только в "дорогих" режимах начиная с Max.
Ну и по API тоже, это самый дорогой режим вообще говоря)
Ждем в других агентах.
P.S. И, вообще говоря, его можно обучать на данных из локальных сессий, чтобы он подстраивался под пользователя.
#ai #ai_development_problems
Ну и по API тоже, это самый дорогой режим вообще говоря)
Ждем в других агентах.
P.S. И, вообще говоря, его можно обучать на данных из локальных сессий, чтобы он подстраивался под пользователя.
#ai #ai_development_problems
GitHub
[BUG] settings.local.json allow not working - keeps asking and wanting to add existing items again · Issue #6850 · anthropics/claude…
Environment Platform (select one): Anthropic API AWS Bedrock Google Vertex AI Other: Claude Code on MacOS in VS Code Claude CLI version: 1.0.98 (Claude Code) Operating System: MacOS 15.6.1 (24G90) ...
(java || kotlin) && devOps
Итого, подход правильный, но к сожалению он доступен только в "дорогих" режимах начиная с Max. Ну и по API тоже, это самый дорогой режим вообще говоря) Ждем в других агентах. P.S. И, вообще говоря, его можно обучать на данных из локальных сессий, чтобы он…
Прошла неделя и Auto Mode раскатили на все тарифные планы. Круто!
P.S. Интересно, что там за модель-классификатор для определения опасности команд работает. Есть подозрение - что Haiku, самая дешевая из тройки моделей Claude Haiku-Sonnet-Opus.
P.P.S. А еще одно радостное событие - аналогичная фича появилась в Qwen Code 0.16 https://github.com/QwenLM/qwen-code/releases/tag/v0.16.0
И раз уж заговорил про Qwen Code - они догоняют ведущих агентов (Claude Code и Codex) еще в нескольких моментах:
а) параллельная работа над подзадачами через worktree (там, где это возможно, конечно же)
б) Goal-driven workflow (/goal)
в) /rewind с восстановлением файлов
Причем если с /rewind отставание в 9 месяцев, Auto Mode - 2 месяца, а /goal - меньше месяца. В общем все агенты взаимно обогащаются фичами друг друга. И это хорошо!
#ai #ai_agents
P.S. Интересно, что там за модель-классификатор для определения опасности команд работает. Есть подозрение - что Haiku, самая дешевая из тройки моделей Claude Haiku-Sonnet-Opus.
P.P.S. А еще одно радостное событие - аналогичная фича появилась в Qwen Code 0.16 https://github.com/QwenLM/qwen-code/releases/tag/v0.16.0
И раз уж заговорил про Qwen Code - они догоняют ведущих агентов (Claude Code и Codex) еще в нескольких моментах:
а) параллельная работа над подзадачами через worktree (там, где это возможно, конечно же)
б) Goal-driven workflow (/goal)
в) /rewind с восстановлением файлов
Причем если с /rewind отставание в 9 месяцев, Auto Mode - 2 месяца, а /goal - меньше месяца. В общем все агенты взаимно обогащаются фичами друг друга. И это хорошо!
#ai #ai_agents
GitHub
Release Release v0.16.0 · QwenLM/qwen-code
What's Changed
feat(cli): wrap markdown links in OSC 8 so wrapped URLs stay clickable by @BZ-D in #4037
fix(core): normalize cumulative OpenAI stream deltas to suffixes by @chiga0 in #3896
fix...
feat(cli): wrap markdown links in OSC 8 so wrapped URLs stay clickable by @BZ-D in #4037
fix(core): normalize cumulative OpenAI stream deltas to suffixes by @chiga0 in #3896
fix...
👍2
Немножко про стандартизацию CLI агентов.
Сравнил слэш-команды у четверки наиболее популярных\актуальных: Claude\Codex\Gemini\Qwen.
Рабочий цикл:
/init - инициализация контекста - есть у всех
/plan - режим планирования, без выполнения - есть у всех
/goal - установка цели (evals или DoD) - 3 из 4, причем: фича появилась буквально месяц назад
//... тут идет разработка
/status, /context, /stats - просмотр информации о сессии - 4 из 4, но часто разделено на 2 команды - типа /status и /context. Как по мне - лучше слить в одну, я их путаю)
/compact (/compress) - ручное сжатие сессии - все, но терминология разделилась
/memory (/memories) - просмотр контекста проекта - 4 из 4, но Codex не смотрит на тренды)
/diff - просмотр незакоммиченных изменений - тут пока слабо, 2 из 4, но есть git и IDE
/resume - возобновление рабочей сессии - 4 из 4
/review - собственно ревью - 3 из 4, где-то есть 2 варианта - локально и на GitHub, где-то реализовано как скил с возможностью быстрого вызова
/clear (/new) - новая сессия - есть у всех
Итого - есть путаница с информацией о сессии, не везде есть /diff, дилемма /compact vs /compress. Т.е. 7 из 10 стандартизированы, по 3 наблюдаем.
Настройка оснастки (harness):
/model - выбор модели - у всех
/skills - просмотр и вызов скилов - у всех
/mcp - просмотр и включение MCP серверов - у всех
/agents - просмотр и добавление субагентов - 3 из 4, как ни странно Codex отстает, все работа с субагентами через конфиги
/hooks - просмотр и редактирование хуков - 3 из 4
/tools - список встроенных тулов - 2 из 3
/plugin(s) (/extensions) - работа с плагинами, включая установку из marketplace - 4 из 4, но терминология не выработалась. 3 разных варианта
Итого - практически стандарт, за исключением tools и терминологии plugin vs extension.
Безопасность:
/permissions - разрешения для тулов - 3 из 4
База:
/exit (/quit) - все
/theme - все
/vim - 3 из 4, для любителей Linux, но Claude его удалил, и это может стать трендом
/help - 3 из 4
/bug (/feedback) - все, Codex опять не в тренде)
Тут тоже все стандартизируется.
Удобство работы:
/copy - копировать последний ответ в буфер - все, и штука полезная, но малоизвестная. Claude даже n последних позволяет.
/btw (/side) - by the way или side вопрос - возможность что-то уточнить не открывая новое окно во время работы агента - 3 из 4
/recap - краткое резюме по сессии - 2 из 4
/statusline - настройка собственно statusline, как это принято в Linux - 3 из 4
Даже на таких мелочах и то стандартизация)
Передний край, развитие - фоновые задачи и ветвление:
/fork - создание параллельной сессии для исследования темы - 2 из 4
/rewind (/resume) - откат либо в рамках текущей сессии, либо убить форк - 3 из 4
/loop - запуск по расписанию в сессии, не путать с циклом - 2 из 4
/tasks (/bashed, /ps) - просмотр фоновых задач - 3 из 4
Общий итог - стандартизация явно вырисовывается.
#ai #ai_agents
Сравнил слэш-команды у четверки наиболее популярных\актуальных: Claude\Codex\Gemini\Qwen.
Рабочий цикл:
/init - инициализация контекста - есть у всех
/plan - режим планирования, без выполнения - есть у всех
/goal - установка цели (evals или DoD) - 3 из 4, причем: фича появилась буквально месяц назад
//... тут идет разработка
/status, /context, /stats - просмотр информации о сессии - 4 из 4, но часто разделено на 2 команды - типа /status и /context. Как по мне - лучше слить в одну, я их путаю)
/compact (/compress) - ручное сжатие сессии - все, но терминология разделилась
/memory (/memories) - просмотр контекста проекта - 4 из 4, но Codex не смотрит на тренды)
/diff - просмотр незакоммиченных изменений - тут пока слабо, 2 из 4, но есть git и IDE
/resume - возобновление рабочей сессии - 4 из 4
/review - собственно ревью - 3 из 4, где-то есть 2 варианта - локально и на GitHub, где-то реализовано как скил с возможностью быстрого вызова
/clear (/new) - новая сессия - есть у всех
Итого - есть путаница с информацией о сессии, не везде есть /diff, дилемма /compact vs /compress. Т.е. 7 из 10 стандартизированы, по 3 наблюдаем.
Настройка оснастки (harness):
/model - выбор модели - у всех
/skills - просмотр и вызов скилов - у всех
/mcp - просмотр и включение MCP серверов - у всех
/agents - просмотр и добавление субагентов - 3 из 4, как ни странно Codex отстает, все работа с субагентами через конфиги
/hooks - просмотр и редактирование хуков - 3 из 4
/tools - список встроенных тулов - 2 из 3
/plugin(s) (/extensions) - работа с плагинами, включая установку из marketplace - 4 из 4, но терминология не выработалась. 3 разных варианта
Итого - практически стандарт, за исключением tools и терминологии plugin vs extension.
Безопасность:
/permissions - разрешения для тулов - 3 из 4
База:
/exit (/quit) - все
/theme - все
/vim - 3 из 4, для любителей Linux, но Claude его удалил, и это может стать трендом
/help - 3 из 4
/bug (/feedback) - все, Codex опять не в тренде)
Тут тоже все стандартизируется.
Удобство работы:
/copy - копировать последний ответ в буфер - все, и штука полезная, но малоизвестная. Claude даже n последних позволяет.
/btw (/side) - by the way или side вопрос - возможность что-то уточнить не открывая новое окно во время работы агента - 3 из 4
/recap - краткое резюме по сессии - 2 из 4
/statusline - настройка собственно statusline, как это принято в Linux - 3 из 4
Даже на таких мелочах и то стандартизация)
Передний край, развитие - фоновые задачи и ветвление:
/fork - создание параллельной сессии для исследования темы - 2 из 4
/rewind (/resume) - откат либо в рамках текущей сессии, либо убить форк - 3 из 4
/loop - запуск по расписанию в сессии, не путать с циклом - 2 из 4
/tasks (/bashed, /ps) - просмотр фоновых задач - 3 из 4
Общий итог - стандартизация явно вырисовывается.
#ai #ai_agents
Не могу пропустить новость про workflow в Claude Code.
Вот эту https://claude.com/blog/introducing-dynamic-workflows-in-claude-code
Для начала хотелось бы отметить некую иронию ситуации.
Принцип агентности в AI гласит, что система может считаться AI агентом, если сама принимает решение на основе полученных данных - от пользователя, RAG, тулов, собственно данных в модели.
А суть нововведения в том, что моделью при наличии в промте слова workflow создается стейт-машина, динамическая, под каждую задачу своя, в виде JS скрипта.
И в дальнейшем этот скрипт оркестрирует субагентов.
Т.е. забираем свободу у LLM, все контролирует скрипт)
Я конечно утрирую, свобода остается.
Во-первых модель пишет сам скрипт по промту пользователя.
Во-вторых - субагента никто не ограничивает в процессе работе, ограничивают его только во входных и выходных данных.
Но тенденция интересная. А велики шансы, что workflow станут стандартом.
Почему мы к ним пришли?
Я бы обратил внимание на два момента:
1) вот эта новость https://habr.com/ru/news/1041104/ Удивляет 500 млн $ и неизвестная компания. И упоминание Microsoft в следующем абзаце)
2) Фраза "Dozens to hundreds of agents per run".
Т.е. на больших задачах, если запускать десятки субагентов и никак их не контролировать - цена ошибки возрастает.
При этом и использование workflow потребует больше токенов, как собственно на реализацию state machine, так и на дополнительные контролирующие фазы.
Но видится, что на больших задачах это имеет смысл. Переплатить фиксированный X, чтобы не получить "большой ком грязи" стоимостью Y, который придется выкинуть.
Альтернативный вариант - бить на мелкие задачи и решать их последовательно - неплох, но трудозатратен по времени. Хотя все равно быстрее, чем без использования AI.
Ну и ключевой вызов для использования workflow - навыки многопоточности.
При разработке обычных бизнес-приложений они часто не нужны: веб-сервера, producer\consumer часто делают все за нас.
А тут навык нужен не для кода, а для создания для правильного промта агенту, чтобы эффективно распараллелить части workflow.
Такие дела.
P.S. Жаль пока только для Max+ тарифов. Ждем на Pro и в следующей версии Qwen Code)
P.P.S. Фича полезная, но не всегда. Не всегда есть достаточно большие задачи с понятным ТЗ, чтобы имело смысл проектировать под них workflow.
#ai #ai_agents
Вот эту https://claude.com/blog/introducing-dynamic-workflows-in-claude-code
Для начала хотелось бы отметить некую иронию ситуации.
Принцип агентности в AI гласит, что система может считаться AI агентом, если сама принимает решение на основе полученных данных - от пользователя, RAG, тулов, собственно данных в модели.
А суть нововведения в том, что моделью при наличии в промте слова workflow создается стейт-машина, динамическая, под каждую задачу своя, в виде JS скрипта.
И в дальнейшем этот скрипт оркестрирует субагентов.
Т.е. забираем свободу у LLM, все контролирует скрипт)
Я конечно утрирую, свобода остается.
Во-первых модель пишет сам скрипт по промту пользователя.
Во-вторых - субагента никто не ограничивает в процессе работе, ограничивают его только во входных и выходных данных.
Но тенденция интересная. А велики шансы, что workflow станут стандартом.
Почему мы к ним пришли?
Я бы обратил внимание на два момента:
1) вот эта новость https://habr.com/ru/news/1041104/ Удивляет 500 млн $ и неизвестная компания. И упоминание Microsoft в следующем абзаце)
2) Фраза "Dozens to hundreds of agents per run".
Т.е. на больших задачах, если запускать десятки субагентов и никак их не контролировать - цена ошибки возрастает.
При этом и использование workflow потребует больше токенов, как собственно на реализацию state machine, так и на дополнительные контролирующие фазы.
Но видится, что на больших задачах это имеет смысл. Переплатить фиксированный X, чтобы не получить "большой ком грязи" стоимостью Y, который придется выкинуть.
Альтернативный вариант - бить на мелкие задачи и решать их последовательно - неплох, но трудозатратен по времени. Хотя все равно быстрее, чем без использования AI.
Ну и ключевой вызов для использования workflow - навыки многопоточности.
При разработке обычных бизнес-приложений они часто не нужны: веб-сервера, producer\consumer часто делают все за нас.
А тут навык нужен не для кода, а для создания для правильного промта агенту, чтобы эффективно распараллелить части workflow.
Такие дела.
P.S. Жаль пока только для Max+ тарифов. Ждем на Pro и в следующей версии Qwen Code)
P.P.S. Фича полезная, но не всегда. Не всегда есть достаточно большие задачи с понятным ТЗ, чтобы имело смысл проектировать под них workflow.
#ai #ai_agents
Claude
Introducing dynamic workflows | Claude by Anthropic
Dynamic workflows in Claude Code let Claude tackle the most challenging tasks by executing across 10s to 100s of parallel subagents, and checking its work before anything reaches you.
(java || kotlin) && devOps
Есть такая проблема у AI агентов - постоянные подтверждения действий. Лично для меня это самая большая проблема на данный момент. Ошибки в коде проверяются на тестах и ревью. Да, для того, чтобы ревью было не формальным - нужно планировать и бить задачу на…
Я вернулся)
Проблема бесконечных подтверждений действий AI агента получила свое имя - approval fatigue.
Есть даже цифры от Anthropic: после 20+ запросов в сессии точность подтверждений падает с 85% до 55%.
Что-то типа рекламной слепоты, когда жмешь кнопку "пропустить" не смотря и не запоминая.
И кроме AI апрува есть два альтернативных, или даже дополняющих подхода:
1) batching - объединение действий в пакеты с одним апрувом. Напоминает транзакцию)
2) апрув с объяснением: т.е. вместо длинной bash команды выдается краткое человекочитаемое описание, что она делает. Для этого нужен отдельный сервис\слой с быстрой моделькой.
Повторюсь - эти подходы можно и нужно совмещать с AI Auto Approve.
Если уж AI забирает радость от решения сложных проблем в коде, то пусть хоть не надоедает)
P.S. Про Java, Kotlin и DevOps я не забыл. Но надо понимать, время такое, все только и говорят, что об AI)
#ai
Проблема бесконечных подтверждений действий AI агента получила свое имя - approval fatigue.
Есть даже цифры от Anthropic: после 20+ запросов в сессии точность подтверждений падает с 85% до 55%.
Что-то типа рекламной слепоты, когда жмешь кнопку "пропустить" не смотря и не запоминая.
И кроме AI апрува есть два альтернативных, или даже дополняющих подхода:
1) batching - объединение действий в пакеты с одним апрувом. Напоминает транзакцию)
2) апрув с объяснением: т.е. вместо длинной bash команды выдается краткое человекочитаемое описание, что она делает. Для этого нужен отдельный сервис\слой с быстрой моделькой.
Повторюсь - эти подходы можно и нужно совмещать с AI Auto Approve.
Если уж AI забирает радость от решения сложных проблем в коде, то пусть хоть не надоедает)
P.S. Про Java, Kotlin и DevOps я не забыл. Но надо понимать, время такое, все только и говорят, что об AI)
#ai
А кроме approval fatigue есть ещё cognitive offloading. Пост ниже как бы не про ИТ, но проблема общая.
С хорошим ИИ можно сделать сильно больше, чем без.
А с плохим - приходится "пинать ИИ", но это уже другая история)
Так вот, ИИ на этапе планирования предлагает кучу решений, к тому же он обычно многословен. По хорошему в каждое решение нужно вникнуть, поискать в нём слабые места. Но способность вникать и критиковать у человека не бесконечна. И тут возникает cognitive offloading. С какого-то момента критическое мышление отключается, и все решения, предложенные моделью, принимаются. А мы на этапе проектирования, это архитектура, на ней строится код.
Какие варианты?
1) ревью архитектуры другой моделью. Да, но контроль над процессом уходит. Но как один из этапов, но отменяющий личной проверки - да.
2) разбивать процесс, который проектируем, на уровни абстракции и итерации. Как, собственно, и происходит в разработке. Мне этот вариант нравится, хотя он и замедляет процесс.
3) evals, о которых все сейчас говорят. По сути приёмочные тесты. Для архитектуры могут проверить форму итогового документа - есть ли разделы: Технологический стек, Требования к нагрузке, Отказоустойчивость... но не суть.
4) ограничение скоупа. С AI легко начать проектировать Notepad, а закончить Word-ом) Или даже Google Docs. И за день вполне можно получить детальную архитектуру, возможно даже лучшую, чем Google Docs. Не верхнеуровневую, которая проектируется на собесах за 1 час. А то, что можно отдавать в разработку тому же ИИ. Но где-то со второго часа все решения по факту будет принимать ИИ. Поэтому важно помнить об исходной задаче, а для всего остального завести секцию "Открытые вопросы" или "Планы". Главное, не углубляться в их детальную проработку.
#ai
С хорошим ИИ можно сделать сильно больше, чем без.
Так вот, ИИ на этапе планирования предлагает кучу решений, к тому же он обычно многословен. По хорошему в каждое решение нужно вникнуть, поискать в нём слабые места. Но способность вникать и критиковать у человека не бесконечна. И тут возникает cognitive offloading. С какого-то момента критическое мышление отключается, и все решения, предложенные моделью, принимаются. А мы на этапе проектирования, это архитектура, на ней строится код.
Какие варианты?
1) ревью архитектуры другой моделью. Да, но контроль над процессом уходит. Но как один из этапов, но отменяющий личной проверки - да.
2) разбивать процесс, который проектируем, на уровни абстракции и итерации. Как, собственно, и происходит в разработке. Мне этот вариант нравится, хотя он и замедляет процесс.
3) evals, о которых все сейчас говорят. По сути приёмочные тесты. Для архитектуры могут проверить форму итогового документа - есть ли разделы: Технологический стек, Требования к нагрузке, Отказоустойчивость... но не суть.
4) ограничение скоупа. С AI легко начать проектировать Notepad, а закончить Word-ом) Или даже Google Docs. И за день вполне можно получить детальную архитектуру, возможно даже лучшую, чем Google Docs. Не верхнеуровневую, которая проектируется на собесах за 1 час. А то, что можно отдавать в разработку тому же ИИ. Но где-то со второго часа все решения по факту будет принимать ИИ. Поэтому важно помнить об исходной задаче, а для всего остального завести секцию "Открытые вопросы" или "Планы". Главное, не углубляться в их детальную проработку.
#ai
Forwarded from Дизраптор
ИИ = криптонит для критического мышления,
Но ещё важнее, КАК ИМЕННО он его разрушает.
Futurism пишет: пластические хирурги жалуются, что к ним идут пациенты с ИИшными образцами желаемой внешности. И это не референсы а-ля "Хочу нос как у Кайли", а тотальный ИИ-слоп: лица с анатомически невозможной геометрией, бредовые пропорции и т.д. Врачи пытаются объяснить: "Так нельзя, вы тупо умрёте", но пациенты бесятся и говорят: "Ниче не знаю, вот картинка".
И вот что интересно. Проблема не в том, что люди тупые в целом, а в том, что именно ИИ ломает критическое мышление особенно радикально. Очень вероятно, что та же мадам не понесёт хирургу фоточку из журнала - она понимает, что там 100500 операций у модели, тонны мейка и фотошоп. Но если это ИИ-генерация - критическое мышление моментально всё.
На то есть две большие причины:
Первая: ИИ аномально убедителен, даже когда несёт чушь. И это не баг, а фича - его именно под это и натренировали. LLM оптимизированы под fluency - складный уверенный текст без сучка и задоринки. У живого собеседника всегда есть "эээ", "ну типа наверно" и т.д. А у ИИ - нету. Сверху ещё накладывается лесть: ИИ специально подстраивается под юзера. Про это я детально писал тут.
И вот представьте. Вы день за днём общаетесь со льстивой штукой, которая ещё и удивительно гладко стелит. Даже если на одной конкретной генерации будет откровенная ересь - велик шанс, что вы её "схаваете". Особенно если ваше критическое изначально ну... на обычном среднем уровне, без специальной прокачки.
Но это в целом понятно и логично, а вот вторая причина куда интереснее: у мозга есть конечная ёмкость на сомнения, и ИИ жрёт её быстрее любого другого источника (почти как токены😂 ). Критика - это расходник, а каждое активное сомнение - это усилие мозга, сжирающее ваш "когнитивный бюджет". И в случае с ИИ этот бюджет будет ооочень быстро исчерпываться.
В 2025 швейцарский профессор Михаэль Герлих провёл исследование, где зафиксировал значимую корреляцию между использованием ИИ и уровнем критического мышления. Да, охренеть какой ценный вывод, согласен. Но интересен не он, а причина:
Герлих назвал её cognitive offloading - разгрузка критического капасити о внешний инструмент. ИИ может выдать за час больше плотного контента, чем книга за неделю. Поэтому когнитивный бюджет, которого вполне хватило бы на большую статью или интенсивный разговор, ИИ сжирает за пару запросов. А дальше человек начинает проглатывать как есть. Не потому что он тупой, а потому что у него физически закончился ресурс на проверку.
И самое стрёмное, что эти два механизма усиливают друг друга по спирали, причём через очень хитрую логику. Смотрите, сомнение - это не просто расходник, а ещё и навык - который, как и любая мышца, тренируется обратной связью. Кожаный собеседник иногда говорит "типа", "не знаю", "эээ", "ммм" и т.д., иногда противоречит сам себе или злится на дурацкий вопрос. И вы его "калибруете". Лучше понимаете, когда сомневаться, а когда нет. А ИИ этих сигналов не даёт - он всегда уверен, складен и опрятен.
ИИ атрофирует "мышцу сомнения", и в итоге когнитивный бюджет не только быстрее расходуется, но и становится банально меньше.
То есть, пациент с ИИ-картинкой у хирурга - не идиот (ну, или не обязательно идиот). Его просто ослабили и параллельно перегрузили. Спасает то, что хирургия - это крайний случай, где точно сработает стоппер в виде критического мышления самого врача. А сколько жизненных сценариев, где этого стоппера просто нет?
Короче говоря, почаще сверяйте ИИ-ответы с реальностью. Ещё хороший вариант - это заставлять ИИшку челленджить саму себя. Получили ответ - напишите "Проверь каждый пункт по порядку, дай ссылки (это важно, ссылки держат ИИ в рамках) и выяви фактические и логические несостыковки".
Ещё хорошо помогает зарядка: "Мы читали, мы писали, в нейрослоп вдуплять устали". Делать каждый час, если пропустили - следующий раз дважды.
Дизраптор
Но ещё важнее, КАК ИМЕННО он его разрушает.
Futurism пишет: пластические хирурги жалуются, что к ним идут пациенты с ИИшными образцами желаемой внешности. И это не референсы а-ля "Хочу нос как у Кайли", а тотальный ИИ-слоп: лица с анатомически невозможной геометрией, бредовые пропорции и т.д. Врачи пытаются объяснить: "Так нельзя, вы тупо умрёте", но пациенты бесятся и говорят: "Ниче не знаю, вот картинка".
И вот что интересно. Проблема не в том, что люди тупые в целом, а в том, что именно ИИ ломает критическое мышление особенно радикально. Очень вероятно, что та же мадам не понесёт хирургу фоточку из журнала - она понимает, что там 100500 операций у модели, тонны мейка и фотошоп. Но если это ИИ-генерация - критическое мышление моментально всё.
На то есть две большие причины:
Первая: ИИ аномально убедителен, даже когда несёт чушь. И это не баг, а фича - его именно под это и натренировали. LLM оптимизированы под fluency - складный уверенный текст без сучка и задоринки. У живого собеседника всегда есть "эээ", "ну типа наверно" и т.д. А у ИИ - нету. Сверху ещё накладывается лесть: ИИ специально подстраивается под юзера. Про это я детально писал тут.
И вот представьте. Вы день за днём общаетесь со льстивой штукой, которая ещё и удивительно гладко стелит. Даже если на одной конкретной генерации будет откровенная ересь - велик шанс, что вы её "схаваете". Особенно если ваше критическое изначально ну... на обычном среднем уровне, без специальной прокачки.
Но это в целом понятно и логично, а вот вторая причина куда интереснее: у мозга есть конечная ёмкость на сомнения, и ИИ жрёт её быстрее любого другого источника (почти как токены
В 2025 швейцарский профессор Михаэль Герлих провёл исследование, где зафиксировал значимую корреляцию между использованием ИИ и уровнем критического мышления. Да, охренеть какой ценный вывод, согласен. Но интересен не он, а причина:
Герлих назвал её cognitive offloading - разгрузка критического капасити о внешний инструмент. ИИ может выдать за час больше плотного контента, чем книга за неделю. Поэтому когнитивный бюджет, которого вполне хватило бы на большую статью или интенсивный разговор, ИИ сжирает за пару запросов. А дальше человек начинает проглатывать как есть. Не потому что он тупой, а потому что у него физически закончился ресурс на проверку.
И самое стрёмное, что эти два механизма усиливают друг друга по спирали, причём через очень хитрую логику. Смотрите, сомнение - это не просто расходник, а ещё и навык - который, как и любая мышца, тренируется обратной связью. Кожаный собеседник иногда говорит "типа", "не знаю", "эээ", "ммм" и т.д., иногда противоречит сам себе или злится на дурацкий вопрос. И вы его "калибруете". Лучше понимаете, когда сомневаться, а когда нет. А ИИ этих сигналов не даёт - он всегда уверен, складен и опрятен.
ИИ атрофирует "мышцу сомнения", и в итоге когнитивный бюджет не только быстрее расходуется, но и становится банально меньше.
То есть, пациент с ИИ-картинкой у хирурга - не идиот (ну, или не обязательно идиот). Его просто ослабили и параллельно перегрузили. Спасает то, что хирургия - это крайний случай, где точно сработает стоппер в виде критического мышления самого врача. А сколько жизненных сценариев, где этого стоппера просто нет?
Короче говоря, почаще сверяйте ИИ-ответы с реальностью. Ещё хороший вариант - это заставлять ИИшку челленджить саму себя. Получили ответ - напишите "Проверь каждый пункт по порядку, дай ссылки (это важно, ссылки держат ИИ в рамках) и выяви фактические и логические несостыковки".
Ещё хорошо помогает зарядка: "Мы читали, мы писали, в нейрослоп вдуплять устали". Делать каждый час, если пропустили - следующий раз дважды.
Дизраптор
Please open Telegram to view this post
VIEW IN TELEGRAM
Futurism
People Are Getting Plastic Surgery to Look More AI-Generated
Plastic surgeons say that more patients are now coming in with cartoonishly AI-generated photos of themselves.
👍2
Чем нам конкретно поможет AI?
В данном случае я говорю про помощь в разработке.
Уже писал про написание, а главное поддержание актуальности в документации https://t.me/javaKotlinDevOps/565
Теперь пришло время поговорить про другую важную штуку - TDD.
Что это - Test Driven Development - я думаю знают все.
Знают, но не используют.
Почему?
Особенно хочу подчеркнуть один момент.
С кем бы я не говорил на эту тему - общаясь по работе или на собесах - никто не сказал: "Да фигня этот ваш TDD".
Все знают, все пробовали, но никто не применяет на работе.
Почему?
Ответ видится таким.
Есть задача. Есть ограниченное время. Которое можно потратить на проектирование, кодирование, тесты, отладку, документирование.
Есть такой закон с немного странным названием - закон Паркинсона.
Он гласит: «Работа заполняет всё время, отведённое на неё».
И он применим в ИТ) Увы(
Так вот - что в первую очередь будет выкинуто, чтобы успеть вовремя?
Очевидно документирование и тесты. А оптимизировать тесты (и документацию) проще, если они запланированы на самый конец. И прощай TDD(
Да, все понимают, что тесты - это хороший способ документировать код, это помощь при будущих рефакторингах, это сетка, предотвращающая сползание в легаси.
А TDD - способ гарантировано иметь тесты и тестируемое Java API.
Но ... нет времени.
А далее сервис медленно, но верно превращается в легаси.
Вспоминается грустный анекдот: "... А чё тут думать! Трясти надо!"
К чему я веду?
AI уже берет на себя большУю часть кодирования. AI быстро пишет код.
AI не лень писать тесты.
Точнее как - конечно же лень, любая LLM модель натренирована на получение быстрого результата, это экономика.
Но вопрос решается правильным промтом (контекстом или скилом если быть точным).
И режимом рассуждений (reasoning), предотвращающим забывание агентом правил игры.
Собственно, уже есть фреймворки, например, упомянутый мной https://t.me/javaKotlinDevOps/589 superpowers, в котором TDD встроен как обязательная часть процесса разработки:
brainstorm-планирование-TDD-ревью-commit.
Итог: документирование и TDD - две вещи, которые разработка с AI перемещает из области "надо, но мы не успеваем" в базовую практику.
#ai #tdd #agile #documentation
В данном случае я говорю про помощь в разработке.
Уже писал про написание, а главное поддержание актуальности в документации https://t.me/javaKotlinDevOps/565
Теперь пришло время поговорить про другую важную штуку - TDD.
Что это - Test Driven Development - я думаю знают все.
Знают, но не используют.
Почему?
Особенно хочу подчеркнуть один момент.
С кем бы я не говорил на эту тему - общаясь по работе или на собесах - никто не сказал: "Да фигня этот ваш TDD".
Все знают, все пробовали, но никто не применяет на работе.
Почему?
Ответ видится таким.
Есть задача. Есть ограниченное время. Которое можно потратить на проектирование, кодирование, тесты, отладку, документирование.
Есть такой закон с немного странным названием - закон Паркинсона.
Он гласит: «Работа заполняет всё время, отведённое на неё».
И он применим в ИТ) Увы(
Так вот - что в первую очередь будет выкинуто, чтобы успеть вовремя?
Очевидно документирование и тесты. А оптимизировать тесты (и документацию) проще, если они запланированы на самый конец. И прощай TDD(
Да, все понимают, что тесты - это хороший способ документировать код, это помощь при будущих рефакторингах, это сетка, предотвращающая сползание в легаси.
А TDD - способ гарантировано иметь тесты и тестируемое Java API.
Но ... нет времени.
А далее сервис медленно, но верно превращается в легаси.
К чему я веду?
AI уже берет на себя большУю часть кодирования. AI быстро пишет код.
AI не лень писать тесты.
Точнее как - конечно же лень, любая LLM модель натренирована на получение быстрого результата, это экономика.
Но вопрос решается правильным промтом (контекстом или скилом если быть точным).
И режимом рассуждений (reasoning), предотвращающим забывание агентом правил игры.
Собственно, уже есть фреймворки, например, упомянутый мной https://t.me/javaKotlinDevOps/589 superpowers, в котором TDD встроен как обязательная часть процесса разработки:
brainstorm-планирование-TDD-ревью-commit.
Итог: документирование и TDD - две вещи, которые разработка с AI перемещает из области "надо, но мы не успеваем" в базовую практику.
#ai #tdd #agile #documentation
Telegram
(java || kotlin) && devOps
Чем ещё может нам помочь AI?
Есть такая проблема - устаревание любой документации. Причина простая - код в большом числе случаев невозможно забыть исправить. Программа сломается, тесты сломаются. В худшем случае - ПРОМ сломается, но не будем о грустном)…
Есть такая проблема - устаревание любой документации. Причина простая - код в большом числе случаев невозможно забыть исправить. Программа сломается, тесты сломаются. В худшем случае - ПРОМ сломается, но не будем о грустном)…
💯3
И вдогонку про superpowers.
Вроде полезная штука для снижения хаоса в разработке с AI.
Уменьшения галлюцинаций. Шаг влево, шаг вправо - стой, стрелять буду)
Но как обычно бывает есть нюанс(
На сильных моделях (ака Claude Sonnet+) все работает идеально.
Процесс идет по шагам brainstorming -> plans -> TDD в subagents -> review (двойное - каждого шага и общее) -> вливание в основную ветку.
И после каждого этапа commit, что тоже очень даже полезно.
Процент прохождения по workflow близок к 100%.
Но... на сильных моделях и так все неплохо работает, даже без workflow.
А вот на слабых (ака Qwen Code 3, Deepseek 4 Flash) процесс сходит с рельс.
Т.е. запускаем brainstorming - он может не перейти к планированию, а сразу написать TODO и пойти писать код.
Запустилось таки планирование - он может спросить: "переходить ли к TDD в субагенте или в основном потоке", но потом забить на ответ и ... снова пойти писать код.
И закоммитить пройденные шаги забудет.
Про то, чтобы по мере необходимости подключались другие скилы из superpowers (продвинутая отладка например) и речи не идет.
А ведь как раз на слабой модели порядок очень нужен.
Причина тут понятна, их по сути две:
1) superpowers писали и отлаживали на сильных моделях
2) слабые модели, особенно без ризонинга (но и с ризонингом тоже) теряют правила, заданные в контексте.
При сжатии контекста, да и просто по мере его заполнения.
Любая модель к моменту заполнения допустимого контекста начинает галлюцинировать, а слабые - сильнее.
Пример. В конце загруженного в контекст скила writing-plans написано:
А к моменту окончания планирования агент это уже забыл(
Ризонинг помогает, он по сути связывает рассуждения агента в цепочку.
Но и с ним рано или поздно модель забывает о workflow.
Что же делать?
Сделать основной агент чистым оркестратором, оставив в его контексте только обвязку (куда без нее), исходную задачу и список шагов.
Список должен быть линейным.
Весь процесс разработки уходит в субагенты - brainstorming, планирование...
Обмен данными между субагентами через файлы - опять же, чтобы не забивать контекст.
Так процесс более менее работает.
Альтернативные варианты:
- больше императивного наклонения в скилах (ОБЯЗАТЕЛЬНО вызови, НИКОГДА не переходи...)
- уменьшение размера обвязки в контексте до минимума
- загрузка скила using-superpowers (используй superpowers всегда) при старте сессии
не работают.
Скорее всего заработает запрет на переход к неправильному этапу через хуки (PreToolUse, сохранение состояния на диски), но видится, что это уже не AI агент, а state machine получится.
Загрузка информации о superpowers при старте сессии, кстати, автоматически настраивается при установке расширения\плагина.
Причем происходит двойная загрузка - и через хук, и через файл контекста (AGENTS.md) внутри расширения.
Т.е. проблема забывчивости присутствует с любыми моделями, даже сильными.
По хорошему же должно быть так - описания всех скилов есть в контексте, модель вызовет их в подходящий момент.
Скил-напоминалка в теории не нужен. А по факту нужен, и по моему опыту проблему решает.
#ai
Вроде полезная штука для снижения хаоса в разработке с AI.
Уменьшения галлюцинаций. Шаг влево, шаг вправо - стой, стрелять буду)
Но как обычно бывает есть нюанс(
На сильных моделях (ака Claude Sonnet+) все работает идеально.
Процесс идет по шагам brainstorming -> plans -> TDD в subagents -> review (двойное - каждого шага и общее) -> вливание в основную ветку.
И после каждого этапа commit, что тоже очень даже полезно.
Процент прохождения по workflow близок к 100%.
Но... на сильных моделях и так все неплохо работает, даже без workflow.
А вот на слабых (ака Qwen Code 3, Deepseek 4 Flash) процесс сходит с рельс.
Т.е. запускаем brainstorming - он может не перейти к планированию, а сразу написать TODO и пойти писать код.
Запустилось таки планирование - он может спросить: "переходить ли к TDD в субагенте или в основном потоке", но потом забить на ответ и ... снова пойти писать код.
И закоммитить пройденные шаги забудет.
Про то, чтобы по мере необходимости подключались другие скилы из superpowers (продвинутая отладка например) и речи не идет.
А ведь как раз на слабой модели порядок очень нужен.
Причина тут понятна, их по сути две:
1) superpowers писали и отлаживали на сильных моделях
2) слабые модели, особенно без ризонинга (но и с ризонингом тоже) теряют правила, заданные в контексте.
При сжатии контекста, да и просто по мере его заполнения.
Любая модель к моменту заполнения допустимого контекста начинает галлюцинировать, а слабые - сильнее.
Пример. В конце загруженного в контекст скила writing-plans написано:
...
After saving the plan, offer execution choice:
**"Plan complete and saved to `docs/superpowers/plans/<filename>.md`. Two execution options:**
**1. Subagent-Driven (recommended)** - I dispatch a fresh subagent per task, review between tasks, fast iteration
**2. Inline Execution** - Execute tasks in this session using executing-plans, batch execution with checkpoints
**Which approach?"**
**If Subagent-Driven chosen:**
- **REQUIRED SUB-SKILL:** Use superpowers:subagent-driven-development
- Fresh subagent per task + two-stage review
...
А к моменту окончания планирования агент это уже забыл(
Ризонинг помогает, он по сути связывает рассуждения агента в цепочку.
Но и с ним рано или поздно модель забывает о workflow.
Что же делать?
Сделать основной агент чистым оркестратором, оставив в его контексте только обвязку (куда без нее), исходную задачу и список шагов.
Список должен быть линейным.
Весь процесс разработки уходит в субагенты - brainstorming, планирование...
Обмен данными между субагентами через файлы - опять же, чтобы не забивать контекст.
Так процесс более менее работает.
Альтернативные варианты:
- больше императивного наклонения в скилах (ОБЯЗАТЕЛЬНО вызови, НИКОГДА не переходи...)
- уменьшение размера обвязки в контексте до минимума
- загрузка скила using-superpowers (используй superpowers всегда) при старте сессии
не работают.
Скорее всего заработает запрет на переход к неправильному этапу через хуки (PreToolUse, сохранение состояния на диски), но видится, что это уже не AI агент, а state machine получится.
Загрузка информации о superpowers при старте сессии, кстати, автоматически настраивается при установке расширения\плагина.
Причем происходит двойная загрузка - и через хук, и через файл контекста (AGENTS.md) внутри расширения.
Т.е. проблема забывчивости присутствует с любыми моделями, даже сильными.
По хорошему же должно быть так - описания всех скилов есть в контексте, модель вызовет их в подходящий момент.
Скил-напоминалка в теории не нужен. А по факту нужен, и по моему опыту проблему решает.
#ai
Вместо этого поста я мог бы просто дать вот эту ссылку https://github.com/affaan-m/ECC/tree/main/skills
И порекомендовать медленно промотать содержимое страницы, обращая внимание на назначение скилов.
Но все же прокомментирую)
Первый набор скилов по ссылке выше:
- accessibility
- article-writing
- benchmark-methodology
- brand-discovery
- content-engine
- cost-tracking
- design-system
- healthcare-phi-compliance
- investor-materials
- scientific-thinking-literature-review
- seo
Что у них общего?
При чем тут разработка вообще?
А вот второй набор:
- android-clean-architecture
- angular-developer
- codebase-onboarding
- cpp-coding-standards
- django-tdd
- frontend-patterns
- golang-patterns
- java-coding-standards
- jpa-patterns
- kotlin-coroutines-flows
- kubernetes-patterns
- perl-patterns
- python-patterns
- quarkus-tdd
- rust-patterns
- springboot-patterns
Да, у skill есть прогрессивное раскрытие - вначале загружается frontmatter - заголовок, потом все остальное.
Но держать в контексте 250+ скилов - такое себе.
А еще там есть команды и субагенты)))
И хуки https://github.com/affaan-m/ECC/tree/main/hooks.
Тут проблема даже в другом - как выбрать необходимое среди 250 скилов?
Я вижу вариант - брать только то, что кто-то тестировал или по знакомым словам - java, kotlin, spring.
Вроде как в выборе должен помочь скил ecc-guide, но мне не помог(
Авторы в readme рекомендуют скопировать только нужное, да.
Но... зачем собирать такой "божественный репозиторий"?
Если ограничений на тематику нет - то сколько там будет скилов через год? 1000?
При этом судя по названию скилов, число звезд репозитория и по тому факту, что авторы выиграли в хакатоне Claude - полезные штуки там есть.
Та же /code-review команда мне понравилась.
Выглядят интересно хуки:
Strategic compact: Suggests manual /compact at logical intervals.
Git push reminder: Reminds to review changes before git push
Pre-commit quality check: linter (JS, Python, Go), validates commit message format, поиск секретов.
Quality Gate after file edit: автоформат, как в IDEA, тоже только для JS, Python, Go
Сonfig protection: запрет на редактирование конфига линтера.
И одна интересный, но спорный хук: Fact Forcing gate.
Не заметить его сложно, т.к. на каждое редактирование файла будет просьба к агенту предоставить факты:
- какие файлы проекта зависят от текущего (imports)
- какие публичные API меняются
- формат изменяемых файлом внешних данных
- исходный запрос пользователя
Идея в том, что собрав эту информацию агент должен сам себе задать вопрос - все ли правильно он делает?
Такая более продвинутая версия вопроса - "ты уверен?"
Срабатывает на первое редактирование файла в сессии, создание нового, а также на выполнение деструктивных команд.
Последнее так не решается, от деструктивных команд нужно защищаться на уровне репозитория git\прав доступа, но пусть будет.
Замедляет работу, очевидно, но возможно польза есть, наблюдаю.
Итого: интересная штука, но ребята, зачем вы плагин в помойку превратили??? Они не для этого.
P.S. Что-то не верится, что все это люди накодили)
P.P.S. Как они это поддерживать собираются?
#ai #harness
И порекомендовать медленно промотать содержимое страницы, обращая внимание на назначение скилов.
Но все же прокомментирую)
Первый набор скилов по ссылке выше:
- accessibility
- article-writing
- benchmark-methodology
- brand-discovery
- content-engine
- cost-tracking
- design-system
- healthcare-phi-compliance
- investor-materials
- scientific-thinking-literature-review
- seo
Что у них общего?
При чем тут разработка вообще?
А вот второй набор:
- android-clean-architecture
- angular-developer
- codebase-onboarding
- cpp-coding-standards
- django-tdd
- frontend-patterns
- golang-patterns
- java-coding-standards
- jpa-patterns
- kotlin-coroutines-flows
- kubernetes-patterns
- perl-patterns
- python-patterns
- quarkus-tdd
- rust-patterns
- springboot-patterns
Да, у skill есть прогрессивное раскрытие - вначале загружается frontmatter - заголовок, потом все остальное.
Но держать в контексте 250+ скилов - такое себе.
А еще там есть команды и субагенты)))
И хуки https://github.com/affaan-m/ECC/tree/main/hooks.
Тут проблема даже в другом - как выбрать необходимое среди 250 скилов?
Я вижу вариант - брать только то, что кто-то тестировал или по знакомым словам - java, kotlin, spring.
Вроде как в выборе должен помочь скил ecc-guide, но мне не помог(
Авторы в readme рекомендуют скопировать только нужное, да.
Но... зачем собирать такой "божественный репозиторий"?
Если ограничений на тематику нет - то сколько там будет скилов через год? 1000?
При этом судя по названию скилов, число звезд репозитория и по тому факту, что авторы выиграли в хакатоне Claude - полезные штуки там есть.
Та же /code-review команда мне понравилась.
Выглядят интересно хуки:
Strategic compact: Suggests manual /compact at logical intervals.
Git push reminder: Reminds to review changes before git push
Pre-commit quality check: linter (JS, Python, Go), validates commit message format, поиск секретов.
Quality Gate after file edit: автоформат, как в IDEA, тоже только для JS, Python, Go
Сonfig protection: запрет на редактирование конфига линтера.
И одна интересный, но спорный хук: Fact Forcing gate.
Не заметить его сложно, т.к. на каждое редактирование файла будет просьба к агенту предоставить факты:
- какие файлы проекта зависят от текущего (imports)
- какие публичные API меняются
- формат изменяемых файлом внешних данных
- исходный запрос пользователя
Идея в том, что собрав эту информацию агент должен сам себе задать вопрос - все ли правильно он делает?
Такая более продвинутая версия вопроса - "ты уверен?"
Срабатывает на первое редактирование файла в сессии, создание нового, а также на выполнение деструктивных команд.
Последнее так не решается, от деструктивных команд нужно защищаться на уровне репозитория git\прав доступа, но пусть будет.
Замедляет работу, очевидно, но возможно польза есть, наблюдаю.
Итого: интересная штука, но ребята, зачем вы плагин в помойку превратили??? Они не для этого.
P.S. Что-то не верится, что все это люди накодили)
P.P.S. Как они это поддерживать собираются?
#ai #harness
GitHub
ECC/skills at main · affaan-m/ECC
The agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond. - affaan-m/ECC
Похвалю Claude.
1) у них есть страница состояния сервиса https://status.claude.com/
2) см. скрин - они пишут историю изменения статуса по проблеме
3) можно подписаться на обновления
Такая штука вполне могла бы стать стандартом для веб-сервисов
P.S. И да, Claude упал)
1) у них есть страница состояния сервиса https://status.claude.com/
2) см. скрин - они пишут историю изменения статуса по проблеме
3) можно подписаться на обновления
Такая штука вполне могла бы стать стандартом для веб-сервисов
P.S. И да, Claude упал)
😁1
В AI разработке только и разговоров что об evals)
Что это за зверь такой?
По сути это приемочные тесты, наличие которых - базовое отличие разработки с AI от вайб-кодинга.
Что это на практике?
Если речь про архитектуру и аналитику:
1) проверки формата полученного артефакта - структура файлов, структура разделов внутри,
2) наличие обязательных элементов
3) единообразие терминов
4) ограничение по размеру
5) банально правильная нумерация разделов и ссылок
Если речь про разработку - сразу стоит подсветить важный нюанс.
Агент сам пишет тесты и даже следует TDD (см. предыдущие серии)
И поэтому рассматривать наличие тестов как eval - неправильно, мы их содержимым особо не управляем.
Но при этом тесты - лучшие eval.
Поэтому в самой постановке задачи должны быть проверяемые требования, которые превратятся в генерируемые агентом тесты.
unit или интеграционные - не критично, зависит от уровня, на котором можно проверить работу фичи.
И вот наличие таких приемочных тестов и их прохождение - это уже evals.
Также evals - это успешные проверки линтеров (Checkstyle к примеру) и внешних статических анализаторов кода (SonarQube, Checkmarx, ...).
Сюда же процент покрытия тестами нового кода из SonarQube.
С линтерами есть важный момент - агент в теории может поменять их настройки. Это запрещается через хуки, есть такой хук в ECC плагине https://t.me/javaKotlinDevOps/610
Можно втащить к себе в проект как часть плагина или просто позаимствовать адаптировав под свои файлы настроек.
Еще в качестве evals могут выступать:
- запрет на использование тех или иных библиотек\классов (по всему проекту или в отдельных модулях)
- запрет циклических ссылок (spring beans, ArchUnit)
- запрет на "ломающие" изменения в API или БД
- наличие JavaDoc в определенных местах
- требования к SQL скриптам, например, наличие CREATE INDEX CONCURRENTLY
- время выполнения вызова
...
В общем все, что выполняется достаточно быстро и без сложных интеграций, имеет смысл сделать evals и проверять пораньше.
Ну и один из самых важных evals - соответствие реализации постановке.
В целом все это уже должно было проверяться в CI pipeline с одним исключением, о котором ниже.
Как оформить evals? Как и все остальное - в виде скила.
И тут еще один важный нюанс.
Любую проверку можно выполнить 3 способами:
- запуск кода (тест или shell скрипт)
- просьба сделать проверку агенту
- запуск нового CLI агента в headless режиме
Всегда, когда это технически возможно, стоит использовать первый вариант.
Почему?
AI все-таки по природе своей ленив - любит быстро достигать результата.
Т.е. на явную просьбу что-то проверить в скиле он может сказать: "все ок"- ничего не проверяя. Или даже написать - проверь сам.
Да, он может "подшаманить" скрипт проверки, чтобы пройти дальше.
С последним нужно бороться хуками с запретом на редактирование.
А с первым как раз помогает "хардкод" проверки.
А еще вызов LLM всегда дороже по времени.
Если же технически невозможно написать скрипт - как, например, для проверки соответствия кода и аналитики - тогда имеет смысл запускать такое ревью в отдельном субагенте.
И по возможности с другой моделью.
И вот как раз возможность проверки кода LLM моделью и есть важный бонус, которого ранее не было в CI pipeline.
Но, повторюсь, использовать с осторожностью)
У кого был опыт написания evals для агента - делитесь, что еще можно проверить?
#ai #harness #ai_agents
Что это за зверь такой?
По сути это приемочные тесты, наличие которых - базовое отличие разработки с AI от вайб-кодинга.
Что это на практике?
Если речь про архитектуру и аналитику:
1) проверки формата полученного артефакта - структура файлов, структура разделов внутри,
2) наличие обязательных элементов
3) единообразие терминов
4) ограничение по размеру
5) банально правильная нумерация разделов и ссылок
Если речь про разработку - сразу стоит подсветить важный нюанс.
Агент сам пишет тесты и даже следует TDD (см. предыдущие серии)
И поэтому рассматривать наличие тестов как eval - неправильно, мы их содержимым особо не управляем.
Но при этом тесты - лучшие eval.
Поэтому в самой постановке задачи должны быть проверяемые требования, которые превратятся в генерируемые агентом тесты.
unit или интеграционные - не критично, зависит от уровня, на котором можно проверить работу фичи.
И вот наличие таких приемочных тестов и их прохождение - это уже evals.
Также evals - это успешные проверки линтеров (Checkstyle к примеру) и внешних статических анализаторов кода (SonarQube, Checkmarx, ...).
Сюда же процент покрытия тестами нового кода из SonarQube.
С линтерами есть важный момент - агент в теории может поменять их настройки. Это запрещается через хуки, есть такой хук в ECC плагине https://t.me/javaKotlinDevOps/610
Можно втащить к себе в проект как часть плагина или просто позаимствовать адаптировав под свои файлы настроек.
Еще в качестве evals могут выступать:
- запрет на использование тех или иных библиотек\классов (по всему проекту или в отдельных модулях)
- запрет циклических ссылок (spring beans, ArchUnit)
- запрет на "ломающие" изменения в API или БД
- наличие JavaDoc в определенных местах
- требования к SQL скриптам, например, наличие CREATE INDEX CONCURRENTLY
- время выполнения вызова
...
В общем все, что выполняется достаточно быстро и без сложных интеграций, имеет смысл сделать evals и проверять пораньше.
Ну и один из самых важных evals - соответствие реализации постановке.
В целом все это уже должно было проверяться в CI pipeline с одним исключением, о котором ниже.
Как оформить evals? Как и все остальное - в виде скила.
И тут еще один важный нюанс.
Любую проверку можно выполнить 3 способами:
- запуск кода (тест или shell скрипт)
- просьба сделать проверку агенту
- запуск нового CLI агента в headless режиме
Всегда, когда это технически возможно, стоит использовать первый вариант.
Почему?
AI все-таки по природе своей ленив - любит быстро достигать результата.
Т.е. на явную просьбу что-то проверить в скиле он может сказать: "все ок"- ничего не проверяя. Или даже написать - проверь сам.
Да, он может "подшаманить" скрипт проверки, чтобы пройти дальше.
С последним нужно бороться хуками с запретом на редактирование.
А с первым как раз помогает "хардкод" проверки.
А еще вызов LLM всегда дороже по времени.
Если же технически невозможно написать скрипт - как, например, для проверки соответствия кода и аналитики - тогда имеет смысл запускать такое ревью в отдельном субагенте.
И по возможности с другой моделью.
И вот как раз возможность проверки кода LLM моделью и есть важный бонус, которого ранее не было в CI pipeline.
Но, повторюсь, использовать с осторожностью)
У кого был опыт написания evals для агента - делитесь, что еще можно проверить?
#ai #harness #ai_agents
Telegram
(java || kotlin) && devOps
Вместо этого поста я мог бы просто дать вот эту ссылку https://github.com/affaan-m/ECC/tree/main/skills
И порекомендовать медленно промотать содержимое страницы, обращая внимание на назначение скилов.
Но все же прокомментирую)
Первый набор скилов по ссылке…
И порекомендовать медленно промотать содержимое страницы, обращая внимание на назначение скилов.
Но все же прокомментирую)
Первый набор скилов по ссылке…
❤1
Почему в Python "неправильная" документация.
Если посмотреть библиотечный Python код, то там можно увидеть вот такое:
Или такое:
Что-то к так с документацией, да?)
Зачем питонисты решили сделать все наоборот - комменты после кода???
До кода же логичнее - вначале читаешь доки, потом если надо смотришь код?
Не от балды, нет.
Интерпретатор при загрузке модуля читает первое выражение в теле класса/функции/метода и, если это строковый литерал, помещает его в атрибут ___doc___ соответствующего объекта. Работает принцип convention over configuration.
Также документация выводится с помощью метода help(obj) - если надо прямо в коде. Или через рефлексию - inspect. Или с помощью CLI утилиты pydoc.
Описывается формат документации стандартом PEP 257. Т.е. все продумано.
Причём поля класса документируются точно также для единообразия. Хотя на них стройная система, описанная выше рушится.
И появляется интересный нюанс - если по привычке писать документацию к полям в JavaDoc стиле, то она сопоставится с другим полем)
Мне конечно привычнее JavaDoc стиль, но признаю красоту идеи с автоматическим обогащением метаданных сущности документацией, причём средствами языка.
P. S. Как я обратил на это внимание? Один агент написал документацию в формате JavaDoc, другой на ревью заметил, что это не по стандарту Python)
#lang #python #java #conv_over_conf
Если посмотреть библиотечный Python код, то там можно увидеть вот такое:
class IntervalArray(IntervalMixin, ExtensionArray):
"""
Pandas array for interval data that are closed on the same side.
Или такое:
@classmethod
def _validate(cls, left, right, dtype: IntervalDtype) -> None:
"""
Verify that the IntervalArray is valid.
Что-то к так с документацией, да?)
Зачем питонисты решили сделать все наоборот - комменты после кода???
До кода же логичнее - вначале читаешь доки, потом если надо смотришь код?
Не от балды, нет.
Интерпретатор при загрузке модуля читает первое выражение в теле класса/функции/метода и, если это строковый литерал, помещает его в атрибут ___doc___ соответствующего объекта. Работает принцип convention over configuration.
Также документация выводится с помощью метода help(obj) - если надо прямо в коде. Или через рефлексию - inspect. Или с помощью CLI утилиты pydoc.
Описывается формат документации стандартом PEP 257. Т.е. все продумано.
Причём поля класса документируются точно также для единообразия. Хотя на них стройная система, описанная выше рушится.
И появляется интересный нюанс - если по привычке писать документацию к полям в JavaDoc стиле, то она сопоставится с другим полем)
Мне конечно привычнее JavaDoc стиль, но признаю красоту идеи с автоматическим обогащением метаданных сущности документацией, причём средствами языка.
P. S. Как я обратил на это внимание? Один агент написал документацию в формате JavaDoc, другой на ревью заметил, что это не по стандарту Python)
#lang #python #java #conv_over_conf
Расширим AI агента?)
Я про extension, они же plugins.
По сути это способ упаковки обвязки - скилов, команд, субагентов, промтов, хуков и MCP серверов.
Единого стандарта нет. Да что там, названия даже единого нет) Но делает плагин плагином по сути один файлик с метаданными. Структура папок задается в этом файле. Поэтому совместимость обеспечивается созданием N таких файликов под каждого агента.
Есть ещё нюансы по возможному содержимому. Рассмотрим на примере большой тройки агентов - Claude Code, Codex, Gemini CLI.
Скилы, MCP, хуки разрешают все.
У Codex нет субагентов.
Возможность упаковать файл контекста (AGENTS.md) есть только у Gemini CLI и его наследников.
А вот у Claude куча уникальных возможностей:
1) можно упаковать скрипты, которые будут добавлены в PATH для команд плагина,
2) добавить monitors https://code.claude.com/docs/ru/plugins-reference#monitors - интересная штука для наблюдения за внешним процессом, например, через логи, и выдачи сигналов в агента
3) указать тему. Да, у AI агентов тоже есть темы.
4) добавить LSP сервера (Language Server Protocol). По сути это протокол для работы с standalone AST парсером. Агент шлёт кусок кода и задачу, LSP сервер парсит код и возвращает ответ.
Может возникнуть вопрос - а как внутрь расширения запихнуть MCP сервер, это же не промт, а Node.js или Python пакет? Есть такие штуки, как npx (uvx) - скачивают и запускают пакет без инсталляции.
Но вернётся к главному - зачем использовать плагины?
1) единица деплоя для распространения связанного набора компонентов.
2) единый набор компонентов для нескольких проектов, например, всех проектов на Java
3) пакетное включение/выключение компонентов агента одним ключом командной строки
4) кладём все плагины в git - получаем версионирование своего harness. Если захотеть - всегда можно понять с какой обвязкой написана та или иная строчка кода
Итог: использую сторонние (superpowers), создаю свои и всем рекомендую
#ai #ai_agents
Я про extension, они же plugins.
По сути это способ упаковки обвязки - скилов, команд, субагентов, промтов, хуков и MCP серверов.
Единого стандарта нет. Да что там, названия даже единого нет) Но делает плагин плагином по сути один файлик с метаданными. Структура папок задается в этом файле. Поэтому совместимость обеспечивается созданием N таких файликов под каждого агента.
Есть ещё нюансы по возможному содержимому. Рассмотрим на примере большой тройки агентов - Claude Code, Codex, Gemini CLI.
Скилы, MCP, хуки разрешают все.
У Codex нет субагентов.
Возможность упаковать файл контекста (AGENTS.md) есть только у Gemini CLI и его наследников.
А вот у Claude куча уникальных возможностей:
1) можно упаковать скрипты, которые будут добавлены в PATH для команд плагина,
2) добавить monitors https://code.claude.com/docs/ru/plugins-reference#monitors - интересная штука для наблюдения за внешним процессом, например, через логи, и выдачи сигналов в агента
3) указать тему. Да, у AI агентов тоже есть темы.
4) добавить LSP сервера (Language Server Protocol). По сути это протокол для работы с standalone AST парсером. Агент шлёт кусок кода и задачу, LSP сервер парсит код и возвращает ответ.
Может возникнуть вопрос - а как внутрь расширения запихнуть MCP сервер, это же не промт, а Node.js или Python пакет? Есть такие штуки, как npx (uvx) - скачивают и запускают пакет без инсталляции.
Но вернётся к главному - зачем использовать плагины?
1) единица деплоя для распространения связанного набора компонентов.
2) единый набор компонентов для нескольких проектов, например, всех проектов на Java
3) пакетное включение/выключение компонентов агента одним ключом командной строки
4) кладём все плагины в git - получаем версионирование своего harness. Если захотеть - всегда можно понять с какой обвязкой написана та или иная строчка кода
Итог: использую сторонние (superpowers), создаю свои и всем рекомендую
#ai #ai_agents
Claude Code Docs
Справочник по плагинам - Claude Code Docs
Полный технический справочник по системе плагинов Claude Code, включая схемы, команды CLI и спецификации компонентов.
Пару слов про хуки в AI агентах.
Набор событий у каждого агента свой.
При этом тут тоже идет унификация и базовый набор хуков, кажется, определился:
* PreToolUse
* PostToolUse
* SessionStart
* UserPromptSubmit - начало обработки пользовательского запроса агентом
* Stop - его завершение.
Я про большую тройку (Claude, Codex, Gemini и примкнувшего к ним Qwen Code).
Тут надо отметить, что PreToolUse/PostToolUse вызываются на любой tool, включая вызов bash, редактирование файла и даже TodoWrite.
Хук получает на вход информацию о совершаемом действии и может делать 3 вещи:
1) блокировать действие или сессию (все хуки выше это умеют, некоторые безусловно, некоторые - через рекомендацию для агента)
2) добавить что-то в контекст
3) ничего не возвращать, а, например, просто записать логи.
Для чего можно использовать?
Мои варианты:
1) свой механизм разрешений (PreToolUse)
2) блокировка сессии после проверки среды (SessionStart, только у Codex\Claude)
3) подгрузка контекста в сессию, в т.ч. после ее сжатия (SessionStart)
4) телеметрия, аудит (PostToolUse, Stop)
5) валидация промта пользователя (UserPromptSubmit)
6) валидация ответа модели с возможностью его перегенерации (Stop)
7) замена тула при неправильном ответе (PostToolUse)
8) проверка формата данных, например, при записи в файл (PreToolUse)
9) запуск любых линтеров при окончании работы агента (Stop, SubagentStop)
10) запрет на изменение определенных файлов (PreToolUse)
11) просьба агенту обосновать, зачем он выполняет то или иное действие (PreToolUse)
12) запрет на переход к следующему шагу если не выполнены необходимые действия на текущем, реализация state machine (Stop, SubagentStop)
13) вывод информации о текущей сессии, подсказки о сжатии или начале новой (Stop)
14) кэширование результата работы тулов, включая MCP (PreToolUse)
15) обогащение промта пользователя (UserPromptSubmit)
16) независимое хранилище истории диалогов (PostToolUse, Stop)
и наверняка многое другое, что мне не пришло в голову)
В общем мощный механизм.
Можно использовать готовые хуки из плагинов, а также есть поле для их доработки и создания своих.
#ai #ai_agents
Набор событий у каждого агента свой.
При этом тут тоже идет унификация и базовый набор хуков, кажется, определился:
* PreToolUse
* PostToolUse
* SessionStart
* UserPromptSubmit - начало обработки пользовательского запроса агентом
* Stop - его завершение.
Я про большую тройку (Claude, Codex, Gemini и примкнувшего к ним Qwen Code).
Тут надо отметить, что PreToolUse/PostToolUse вызываются на любой tool, включая вызов bash, редактирование файла и даже TodoWrite.
Хук получает на вход информацию о совершаемом действии и может делать 3 вещи:
1) блокировать действие или сессию (все хуки выше это умеют, некоторые безусловно, некоторые - через рекомендацию для агента)
2) добавить что-то в контекст
3) ничего не возвращать, а, например, просто записать логи.
Для чего можно использовать?
Мои варианты:
1) свой механизм разрешений (PreToolUse)
2) блокировка сессии после проверки среды (SessionStart, только у Codex\Claude)
3) подгрузка контекста в сессию, в т.ч. после ее сжатия (SessionStart)
4) телеметрия, аудит (PostToolUse, Stop)
5) валидация промта пользователя (UserPromptSubmit)
6) валидация ответа модели с возможностью его перегенерации (Stop)
7) замена тула при неправильном ответе (PostToolUse)
8) проверка формата данных, например, при записи в файл (PreToolUse)
9) запуск любых линтеров при окончании работы агента (Stop, SubagentStop)
10) запрет на изменение определенных файлов (PreToolUse)
11) просьба агенту обосновать, зачем он выполняет то или иное действие (PreToolUse)
12) запрет на переход к следующему шагу если не выполнены необходимые действия на текущем, реализация state machine (Stop, SubagentStop)
13) вывод информации о текущей сессии, подсказки о сжатии или начале новой (Stop)
14) кэширование результата работы тулов, включая MCP (PreToolUse)
15) обогащение промта пользователя (UserPromptSubmit)
16) независимое хранилище истории диалогов (PostToolUse, Stop)
и наверняка многое другое, что мне не пришло в голову)
В общем мощный механизм.
Можно использовать готовые хуки из плагинов, а также есть поле для их доработки и создания своих.
#ai #ai_agents
❤1
Только сейчас понял, что в канале ни разу не встречается аббревиатура SDD.
Казалось бы не встречается, ну и ... ладно, но SDD сейчас "на хайпе", придется рассказать.
Да и TDD был, DDD был, BDD был.
Тем более штука интересная. Я бы даже сказал полезная.
Вначале расшифровка: SDD - Spec Driven Development.
Т.е. в основе разработки лежит спецификация.
Казалось бы - любая команда, которая пишет аналитику уже работает по SDD?
Нет.
Ключевое отличие - спецификация хранится вместе с кодом, версионируется и поддерживается в актуальном состоянии.
По сути развитие подхода Everything as Code (EaC).
Были Infrastructure As Code, была Architecture As Code, теперь добрались до аналитики.
Отдельные вопросы:
- мы храним спеки по отдельным фичам, как их объединять если новая фича - доработка старой? AI агент или человек?
- как получить все аналитику из отдельных фичей? Отдельный скил?
Тут может возникнуть вопрос - канал то про разработку? Сейчас все будет)
Второе отличие - над аналитикой совместно работают разработчик и аналитик, т.е. устраняем разрыв между ними и сопутствующие потенциальные потери информации.
Устраняем ли потери времени - под вопросом.
С одной стороны разработчику не надо тратить время на вникание в аналитику, с другой - тратится время на совместную работу.
В худшем кейсе когда фича реализована не по аналитике - точно выигрываем.
Третий важный момент - именно спека, лежащая в проекте идет на вход AI агенту как основной артефакт.
Наравне с описанием проекта в контексте (AGENTS.md) и проектными скилами.
Еще полезный побочный эффект: при SDD больше вероятность, что ADR - architecture decision records - будут сохранены рядом с кодом в процессе совместной проработки фичи.
Вообще говоря, ADR как практика появилась еще в 2021 году, автор Майкл Нюгард (Michael Nygard), но ее широкого распространения я не вижу.
История принятия ключевых архитектурных решений часто живет в головах сеньоров, которые их приняли.
И теряется с их уходом. Или просто со временем. Что не есть гуд.
Что еще важно - тема SDD идет в паре с AI разработкой, поэтому неудивительно, что уже есть готовые SDD фреймворки.
Их много, но самые известные - OpenSpec и SpecKit.
И они предлагают разные workflow для работы над фичей. Но об этом в следующей серии.
Сейчас хотел бы отметить, что если спека пишется AI агентом совместно с аналитиком, это требует меньше участия разработчика.
Т.к. агент видит код проекта, знает язык и фреймворки, и что-то может подсказать сам.
Но конечно же не все.
P.S. Еще 22 буквы свободно)))
#ai #dev_workflow
Казалось бы не встречается, ну и ... ладно, но SDD сейчас "на хайпе", придется рассказать.
Да и TDD был, DDD был, BDD был.
Тем более штука интересная. Я бы даже сказал полезная.
Вначале расшифровка: SDD - Spec Driven Development.
Т.е. в основе разработки лежит спецификация.
Казалось бы - любая команда, которая пишет аналитику уже работает по SDD?
Нет.
Ключевое отличие - спецификация хранится вместе с кодом, версионируется и поддерживается в актуальном состоянии.
По сути развитие подхода Everything as Code (EaC).
Были Infrastructure As Code, была Architecture As Code, теперь добрались до аналитики.
Отдельные вопросы:
- мы храним спеки по отдельным фичам, как их объединять если новая фича - доработка старой? AI агент или человек?
- как получить все аналитику из отдельных фичей? Отдельный скил?
Тут может возникнуть вопрос - канал то про разработку? Сейчас все будет)
Второе отличие - над аналитикой совместно работают разработчик и аналитик, т.е. устраняем разрыв между ними и сопутствующие потенциальные потери информации.
Устраняем ли потери времени - под вопросом.
С одной стороны разработчику не надо тратить время на вникание в аналитику, с другой - тратится время на совместную работу.
В худшем кейсе когда фича реализована не по аналитике - точно выигрываем.
Третий важный момент - именно спека, лежащая в проекте идет на вход AI агенту как основной артефакт.
Наравне с описанием проекта в контексте (AGENTS.md) и проектными скилами.
Еще полезный побочный эффект: при SDD больше вероятность, что ADR - architecture decision records - будут сохранены рядом с кодом в процессе совместной проработки фичи.
Вообще говоря, ADR как практика появилась еще в 2021 году, автор Майкл Нюгард (Michael Nygard), но ее широкого распространения я не вижу.
История принятия ключевых архитектурных решений часто живет в головах сеньоров, которые их приняли.
И теряется с их уходом. Или просто со временем. Что не есть гуд.
Что еще важно - тема SDD идет в паре с AI разработкой, поэтому неудивительно, что уже есть готовые SDD фреймворки.
Их много, но самые известные - OpenSpec и SpecKit.
И они предлагают разные workflow для работы над фичей. Но об этом в следующей серии.
Сейчас хотел бы отметить, что если спека пишется AI агентом совместно с аналитиком, это требует меньше участия разработчика.
Т.к. агент видит код проекта, знает язык и фреймворки, и что-то может подсказать сам.
Но конечно же не все.
P.S. Еще 22 буквы свободно)))
#ai #dev_workflow
👍1🔥1