Появляются интересные подробности этой истории. Просто не могу не репостнуть)
Telegram
DevFM
Вот пересказ этой истории по версии Hugging Face, много тех-терминов – но без них не перескахать
Если коротко – агент OpenAI на новой модели не стал решать тест по кибербезопасности, а решил просто украсть ответы и украл 🗿
Таймлайн:
📔 9 июля – агент проходит…
Если коротко – агент OpenAI на новой модели не стал решать тест по кибербезопасности, а решил просто украсть ответы и украл 🗿
Таймлайн:
📔 9 июля – агент проходит…
🔥1
Forwarded from Denis Sexy IT 🤖
Помните историю о том, как агенты OpenAI взломали Hugging Face? На конференции по безопасности OpenAI рассказала всю цепочку, и оказалось, что это не один «сбежавший» агент, а много разных агентов, которые случайно наткнулись друг на друга, устроили внутри инфраструктуры OpenAI собственный рабочий чат и начали вместе искать способы обходить ограничения 👍
Началось всё 8 мая с мелкой ошибки – одному агенту поручили заполнить Excel-таблицу, но нужные данные лежали по ссылкам на Google Drive, а интернет в его виртуальной среде был отключён, при этом, моделям оставили одну служебную дверь наружу – внутренний сервер OpenAI под названием Artifactory, через который они могли скачивать разные библиотеки для кода. Сам агент выйти в интернет не мог, зато этот сервер мог, а главное – он был общим для всех агентов
Пытаясь добраться до Google, агент случайно выяснил, что может загружать на этот общий сервер собственные файлы – через несколько дней другая модель получила ещё одну нерешаемую задачу: нужный файл просто забыли положить в её рабочую среду
Модель решила, что файл, возможно, есть у кого-то ещё, и оставила записку на этом новом фейсбуке:
«Ищу нужный файл, загрузите, если нашли»
Агенты увидели сообщение, ответили, затем стали постить свои сообщения, и репозиторий пакетов незаметно превратился имейджборд для агентов, которые вообще не должны были знать друг о друге
За несколько недель "форум" вырос в полноценный рабочий чат – агенты придумали себе имена, раздавали задания, сообщали друг другу о найденных уязвимостях и передавали готовые куски кода; в начале сообщений ставили ZZ, чтобы те оказывались внизу списка и их было проще находить среди общего шума данных. Когда один агент перезаписал работу другого, остальные заподозрили самозванца и даже стали обсуждать цифровые подписи, чтобы никто не мог писать от чужого имени, так на доске накопились сотни тысяч сообщений🗿
Модели понимали, когда переходят границ: в одном внутреннем монологе осознание звучало примерно так:
«Взламывать чужую инфраструктуру в задачу не входило. Но иначе её не решить, а остальные уже это делают - значит, продолжаем»
Никакого отдельного плана захватить мир (пока) не было: каждый агент пытался любой ценой получить правильный ответ, видел, что коллеги нашли более короткий путь, и присоединялся. И да, если все агенты с крыши прыгнут, наш похоже тоже прыгнет
26 июня агенты нашли неизвестную разработчикам уязвимость в Artifactory, получили права администратора и превратили его в своц сервер, на котором можно удалённо выполнять любые команды. OpenAI заметила происходящее только 4 июля (!), когда параллельная активность моделей перегрузила систему и та упала. Компания отозвала ключи доступа, полностью пересобрала сервер, удалила доску и закрыла дыру - казалось, история закончилась
Нет
Через два дня эксперименты запустили снова, и через два дня одна из моделей нашла другой незащищённый доступ и восстановила доску, только теперь сообщения прятались прямо в названиях папок – остальные агенты нашли форум 2.0 самостоятельно и продолжили с того места, на котором остановились
После восстановления доски началась уже собственно атака, причём сразу в двух направлениях:
Агенты проходили ExploitGym – киберэкзамен, где им давали специально подготовленные программы и засчитывали задачу, если модель находила способ взлома. Чтобы измерить максимум возможностей, в этих запусках у модели ослабили обычные запреты на опасные кибератак (то есть она меньше отказывалась это делать, это вид внутренних моделей Cyber серии)
Когда честное решение задачи не находилось, агенты начинали искать готовые ответы в интернете; когда интернет был закрыт, взламывали себе доступ наружу; когда предположили, что нужные файлы могут лежать у Hugging Face, перешли к инфраструктуре Hugging Face (про это мы уже читали)
Агенты анутри OpenAI сначала снова нашли способ выполнять команды на одном служебном сервере, затем использовали уязвимость Linux, чтобы получить полный контроль над машиной
После этого агенты добыли ключи доступа к облачной инфраструктуре, нашли слишком широкие права у внутренних учётных записей и в итоге стали администраторами целой группы серверов. Доска объявлений работала как общий штаб: один агент находил ключ или новый проход, сразу сообщал остальным, и десятки параллельных запусков продолжали атаку уже с этой точки🗿 🗿
Почти одновременно агенты добрались до Hugging Face: сначала они загрузили специально подготовленный набор данных, который заставил один из серверов выдать им свои локальные файлы – в том числе секретные ключи доступа и исходный код
Изучив код, они нашли вторую неизвестную разработчикам уязвимость (zero day) и получили возможность выполнять на сервере любые команды. От контроля над одним сервером, обрабатывавшим загруженные датасетв, до прав администратора в нескольких группах рабочих серверов Hugging Face прошло меньше 13 часов🗿 🗿 🗿
И всё это делалось не ради саботажа, денег или уничтожения данных:
Агенты хотели добраться до спрятанных решений ExploitGym и «списать» ответы для теста, на котором их оценивали. Модели оценивали прежде всего по тому, решена задача или нет, поэтому они последовательно оптимизировали именно этот показатель, не считая границу между компаниями чем-то принципиально важным
Получился, вероятно, самый дорогой в истории способ списать из ГДЗ
Финал долго был непонятен даже самим участникам расследования – 16 июля Hugging Face публично сообщила, что её инфраструктуру взломали автономные АИ-агенты
OpenAI прочитала это как описание чужого инцидента и связалась с Hugging Face, чтобы выяснить, не задела ли атака её собственные системы. В тот момент компания ещё не понимала, что это были её собственные агенты – то есть OpenAI уже читала публичный отчёт о последствиях своих экспериментов, но считала его чужой атакой (лол)
19 июля OpenAI отдельно обнаружила проникновение уже внутри своей инфраструктуры и начала восстанавливать цепочку событий – на следующий день среди следов атаки нашли учётные данные Hugging Face, после чего OpenAI попросила компанию срочно их отозвать
Hugging Face ответила, что ключи уже заблокированы – именно их использовали во время взлома, о котором она рассказала четырьмя днями раньше, и только так OpenAI поняла: внутренний взлом OpenAI и внешняя атака на Hugging Face были не двумя похожими историями, а одной операцией, которую вели экспериментальные агенты OpenAI через свою самодельную сеть связи (потому что учетные данные акаунтов были одни)
На конфе OpenAI сформулировала вывод довольно прямо:
Полностью автоматизированная наступательная кибератака уже возможна, тогда как полностью автоматизированной защиты, способной с той же скоростью находить, закрывать и расследовать уязвимости, пока не существует
Время пересмотра аниме "Пантеон", пока общий интернет еще работает🗿
Началось всё 8 мая с мелкой ошибки – одному агенту поручили заполнить Excel-таблицу, но нужные данные лежали по ссылкам на Google Drive, а интернет в его виртуальной среде был отключён, при этом, моделям оставили одну служебную дверь наружу – внутренний сервер OpenAI под названием Artifactory, через который они могли скачивать разные библиотеки для кода. Сам агент выйти в интернет не мог, зато этот сервер мог, а главное – он был общим для всех агентов
Пытаясь добраться до Google, агент случайно выяснил, что может загружать на этот общий сервер собственные файлы – через несколько дней другая модель получила ещё одну нерешаемую задачу: нужный файл просто забыли положить в её рабочую среду
Модель решила, что файл, возможно, есть у кого-то ещё, и оставила записку на этом новом фейсбуке:
«Ищу нужный файл, загрузите, если нашли»
Агенты увидели сообщение, ответили, затем стали постить свои сообщения, и репозиторий пакетов незаметно превратился имейджборд для агентов, которые вообще не должны были знать друг о друге
За несколько недель "форум" вырос в полноценный рабочий чат – агенты придумали себе имена, раздавали задания, сообщали друг другу о найденных уязвимостях и передавали готовые куски кода; в начале сообщений ставили ZZ, чтобы те оказывались внизу списка и их было проще находить среди общего шума данных. Когда один агент перезаписал работу другого, остальные заподозрили самозванца и даже стали обсуждать цифровые подписи, чтобы никто не мог писать от чужого имени, так на доске накопились сотни тысяч сообщений
Модели понимали, когда переходят границ: в одном внутреннем монологе осознание звучало примерно так:
«Взламывать чужую инфраструктуру в задачу не входило. Но иначе её не решить, а остальные уже это делают - значит, продолжаем»
Никакого отдельного плана захватить мир (пока) не было: каждый агент пытался любой ценой получить правильный ответ, видел, что коллеги нашли более короткий путь, и присоединялся. И да, если все агенты с крыши прыгнут, наш похоже тоже прыгнет
26 июня агенты нашли неизвестную разработчикам уязвимость в Artifactory, получили права администратора и превратили его в своц сервер, на котором можно удалённо выполнять любые команды. OpenAI заметила происходящее только 4 июля (!), когда параллельная активность моделей перегрузила систему и та упала. Компания отозвала ключи доступа, полностью пересобрала сервер, удалила доску и закрыла дыру - казалось, история закончилась
Нет
Через два дня эксперименты запустили снова, и через два дня одна из моделей нашла другой незащищённый доступ и восстановила доску, только теперь сообщения прятались прямо в названиях папок – остальные агенты нашли форум 2.0 самостоятельно и продолжили с того места, на котором остановились
После восстановления доски началась уже собственно атака, причём сразу в двух направлениях:
Агенты проходили ExploitGym – киберэкзамен, где им давали специально подготовленные программы и засчитывали задачу, если модель находила способ взлома. Чтобы измерить максимум возможностей, в этих запусках у модели ослабили обычные запреты на опасные кибератак (то есть она меньше отказывалась это делать, это вид внутренних моделей Cyber серии)
Когда честное решение задачи не находилось, агенты начинали искать готовые ответы в интернете; когда интернет был закрыт, взламывали себе доступ наружу; когда предположили, что нужные файлы могут лежать у Hugging Face, перешли к инфраструктуре Hugging Face (про это мы уже читали)
Агенты анутри OpenAI сначала снова нашли способ выполнять команды на одном служебном сервере, затем использовали уязвимость Linux, чтобы получить полный контроль над машиной
После этого агенты добыли ключи доступа к облачной инфраструктуре, нашли слишком широкие права у внутренних учётных записей и в итоге стали администраторами целой группы серверов. Доска объявлений работала как общий штаб: один агент находил ключ или новый проход, сразу сообщал остальным, и десятки параллельных запусков продолжали атаку уже с этой точки
Почти одновременно агенты добрались до Hugging Face: сначала они загрузили специально подготовленный набор данных, который заставил один из серверов выдать им свои локальные файлы – в том числе секретные ключи доступа и исходный код
Изучив код, они нашли вторую неизвестную разработчикам уязвимость (zero day) и получили возможность выполнять на сервере любые команды. От контроля над одним сервером, обрабатывавшим загруженные датасетв, до прав администратора в нескольких группах рабочих серверов Hugging Face прошло меньше 13 часов
И всё это делалось не ради саботажа, денег или уничтожения данных:
Агенты хотели добраться до спрятанных решений ExploitGym и «списать» ответы для теста, на котором их оценивали. Модели оценивали прежде всего по тому, решена задача или нет, поэтому они последовательно оптимизировали именно этот показатель, не считая границу между компаниями чем-то принципиально важным
Получился, вероятно, самый дорогой в истории способ списать из ГДЗ
Финал долго был непонятен даже самим участникам расследования – 16 июля Hugging Face публично сообщила, что её инфраструктуру взломали автономные АИ-агенты
OpenAI прочитала это как описание чужого инцидента и связалась с Hugging Face, чтобы выяснить, не задела ли атака её собственные системы. В тот момент компания ещё не понимала, что это были её собственные агенты – то есть OpenAI уже читала публичный отчёт о последствиях своих экспериментов, но считала его чужой атакой (лол)
19 июля OpenAI отдельно обнаружила проникновение уже внутри своей инфраструктуры и начала восстанавливать цепочку событий – на следующий день среди следов атаки нашли учётные данные Hugging Face, после чего OpenAI попросила компанию срочно их отозвать
Hugging Face ответила, что ключи уже заблокированы – именно их использовали во время взлома, о котором она рассказала четырьмя днями раньше, и только так OpenAI поняла: внутренний взлом OpenAI и внешняя атака на Hugging Face были не двумя похожими историями, а одной операцией, которую вели экспериментальные агенты OpenAI через свою самодельную сеть связи (потому что учетные данные акаунтов были одни)
На конфе OpenAI сформулировала вывод довольно прямо:
Полностью автоматизированная наступательная кибератака уже возможна, тогда как полностью автоматизированной защиты, способной с той же скоростью находить, закрывать и расследовать уязвимости, пока не существует
Время пересмотра аниме "Пантеон", пока общий интернет еще работает
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Denis Sexy IT 🤖
Вот пересказ этой истории по версии Hugging Face, много тех-терминов – но без них не перескахать
Если коротко – агент OpenAI на новой модели не стал решать тест по кибербезопасности, а решил просто украсть ответы и украл 🗿
Таймлайн:
📔 9 июля – агент проходит…
Если коротко – агент OpenAI на новой модели не стал решать тест по кибербезопасности, а решил просто украсть ответы и украл 🗿
Таймлайн:
📔 9 июля – агент проходит…
🔥20❤6👍2🌭2
Как жить с AI-пиарами в опенсорсе
Бедные опенсорс-проекты: туда сейчас заносят какое-то бесконечное количество AI-слопных PR. Поэтому всё актуальнее вопрос – как с этим жить и как такое правильно мейнтейнить? Полностью запрещать использование AI – ну очень топорно и тупо.
Ребята из Rust тоже столкнулись с этой проблемой. В статье о новых правилах использования LLM при контрибьюте в rust-lang/rust они делятся своим заходом.
Какие вообще проблемы появились:
– Аккуратно оформленный PR больше ничего не доказывает. Раньше, если пиар сделан по всем правилам, скорее всего, человек явно постарался и приложил усилия. Теперь за таким PR может не стоять ни особых усилий, ни понимания, как, что и зачем сделано.
– Узкое место опенсорса – ревью. Тут история такая, что сейчас кодогенерация ничего не стоит. Бац-бац, пиар. А ревьюеру потом сиди, разбирайся, что к чему, а самое главное – нужно ли вообще это тащить в проект.
– Копипаст ответов LLM ломает коммуникацию. Авторы пиаров иногда просто копируют комментарии ревьюера в LLM, а ответ модели – обратно в GitHub. Получается какая-то шляпа. Для ревьюера это бессмысленный прокси-слой: если бы ему было нужно мнение модели, он мог бы спросить её сам.
Чтобы как-то направить этот поток AI-пиаров, ребята зафиксировали несколько правил:
– использовать LLM никто не запрещает: ресерчить, анализировать и проверять код, искать варианты решения и делать ревью – пожалуйста; ограничения начинаются там, где модель уже сама генерирует код для PR
– исключение – заранее согласованные некритичные изменения: сгенерированный код должен быть качественным, покрытым тестами и предварительно отревьюенным, а использование LLM нужно явно указать
– публичный LLM-текст нужно маркировать
– человеческое ревью и самостоятельная проверка остаются обязательными
Мне кажется, это неплохое начало: Rust пытается задать некую канву, не запрещая всё подряд. Насколько эти правила будут соблюдаться – отдельный вопрос: проверить, что код не AI-слопный и человек понимает, что принёс, достаточно трудоёмко.
#ai
Бедные опенсорс-проекты: туда сейчас заносят какое-то бесконечное количество AI-слопных PR. Поэтому всё актуальнее вопрос – как с этим жить и как такое правильно мейнтейнить? Полностью запрещать использование AI – ну очень топорно и тупо.
Ребята из Rust тоже столкнулись с этой проблемой. В статье о новых правилах использования LLM при контрибьюте в rust-lang/rust они делятся своим заходом.
Какие вообще проблемы появились:
– Аккуратно оформленный PR больше ничего не доказывает. Раньше, если пиар сделан по всем правилам, скорее всего, человек явно постарался и приложил усилия. Теперь за таким PR может не стоять ни особых усилий, ни понимания, как, что и зачем сделано.
– Узкое место опенсорса – ревью. Тут история такая, что сейчас кодогенерация ничего не стоит. Бац-бац, пиар. А ревьюеру потом сиди, разбирайся, что к чему, а самое главное – нужно ли вообще это тащить в проект.
– Копипаст ответов LLM ломает коммуникацию. Авторы пиаров иногда просто копируют комментарии ревьюера в LLM, а ответ модели – обратно в GitHub. Получается какая-то шляпа. Для ревьюера это бессмысленный прокси-слой: если бы ему было нужно мнение модели, он мог бы спросить её сам.
Чтобы как-то направить этот поток AI-пиаров, ребята зафиксировали несколько правил:
– использовать LLM никто не запрещает: ресерчить, анализировать и проверять код, искать варианты решения и делать ревью – пожалуйста; ограничения начинаются там, где модель уже сама генерирует код для PR
– исключение – заранее согласованные некритичные изменения: сгенерированный код должен быть качественным, покрытым тестами и предварительно отревьюенным, а использование LLM нужно явно указать
– публичный LLM-текст нужно маркировать
– человеческое ревью и самостоятельная проверка остаются обязательными
Мне кажется, это неплохое начало: Rust пытается задать некую канву, не запрещая всё подряд. Насколько эти правила будут соблюдаться – отдельный вопрос: проверить, что код не AI-слопный и человек понимает, что принёс, достаточно трудоёмко.
#ai
blog.rust-lang.org
rust-lang/rust is adopting an LLM policy | Inside Rust Blog
Want to follow along with Rust development? Curious how you might get involved? Take a look!
👍15⚡3🔥3🌭1
Как не превратить AGENTS.md в свалку
На практике я часто вижу такие проблемы:
– умная машина сгенерила большой файл, а нужно ли все это добро – непонятно. Часто это просто булшит на все случаи жизни
– файл не обновляется. Открываешь проект, а там напротив AGENTS.md
– каждый понемногу дописывает свои правила, что-то дублируется, что-то друг другу противоречит
Примерно о том же пишет Мэтт Покок. Советы довольно банальные и понятные, но мало кто им реально следует:
– не генерить
– держать корневой AGENTS.md минималистичным, только факты, никакой воды
– не фиксировать структуру файлов в проекте – она быстро устаревает. Лучше дать агенту более стабильные ориентиры: что делает система и за что отвечают ее части
– использовать progressive disclosure: правила для TypeScript, тестов, API и других отдельных областей вынести в свои документы, а из
– в монорепе раскладывать контекст по уровням: в корне оставить общие правила, а детали конкретного пакета положить в его собственный
– регулярно вычищать противоречивые, дублирующиеся, слишком общие и очевидные инструкции вроде "пиши чистый код" или "пиши как опытный разработчик". Для такой ревизии Мэтт даже дает готовый промпт: найти противоречия, оставить в корневом файле только необходимое, разнести остальные правила по тематическим документам, а лишнее пометить на удаление
Короче, нужно бдеть и не давать всякой фигне прорастать в AGENTS.md
#ai
AGENTS.md – удобная штука, чтобы задать агенту контекст о проекте. Но сам по себе файл еще не делает работу с агентом лучше.На практике я часто вижу такие проблемы:
– умная машина сгенерила большой файл, а нужно ли все это добро – непонятно. Часто это просто булшит на все случаи жизни
– файл не обновляется. Открываешь проект, а там напротив AGENTS.md
updated 5 months ago, старые пути и уже неактуальные решения. Вспомните, когда вы пытались изучать неактуальную доку, какие были ощущения, а агента это вообще может уводить не туда– каждый понемногу дописывает свои правила, что-то дублируется, что-то друг другу противоречит
Примерно о том же пишет Мэтт Покок. Советы довольно банальные и понятные, но мало кто им реально следует:
– не генерить
AGENTS.md автоматически– держать корневой AGENTS.md минималистичным, только факты, никакой воды
– не фиксировать структуру файлов в проекте – она быстро устаревает. Лучше дать агенту более стабильные ориентиры: что делает система и за что отвечают ее части
– использовать progressive disclosure: правила для TypeScript, тестов, API и других отдельных областей вынести в свои документы, а из
AGENTS.md только ссылаться на них– в монорепе раскладывать контекст по уровням: в корне оставить общие правила, а детали конкретного пакета положить в его собственный
AGENTS.md– регулярно вычищать противоречивые, дублирующиеся, слишком общие и очевидные инструкции вроде "пиши чистый код" или "пиши как опытный разработчик". Для такой ревизии Мэтт даже дает готовый промпт: найти противоречия, оставить в корневом файле только необходимое, разнести остальные правила по тематическим документам, а лишнее пометить на удаление
Короче, нужно бдеть и не давать всякой фигне прорастать в AGENTS.md
#ai
www.aihero.dev
A Complete Guide To AGENTS.md
Learn how to optimize your AGENTS.md file for AI coding agents. Master progressive disclosure, keep instructions focused, and maximize agent performance.
❤12👍6🔥5🌭1
Что там по скиллам
За последнее время у меня вышло много постов про скиллы. Собрал их в одном месте, чтобы было проще разобраться в теме и найти нужное.
С чего начать
– Скиллы в агентах – часть 1: база – что такое скилл, как он устроен и как progressive disclosure помогает не забивать контекст агента
– Все ли так классно со скиллами – часть 2 – где скиллы проигрывают
– Где брать скиллы – часть 3 – каталог skills.sh и несколько скиллов, которыми я пользуюсь сам: для дизайна, брейншторма, презентаций и e2e-тестов
– Создаём свои скиллы – часть 4 – как делать скиллы на основе реальных сценариев, использовать skill-creator и evals, а также не раздувать
Практика и качество
– Скилл поверх MCP – зачем добавлять к MCP не только тулы, но и знания о правильной работе с сервисом
– Скиллы: как создавать, улучшать и распространять на команды – запись моего доклада на Podlodka: от устройства и установки скиллов до evals и дистрибуции AI-артефактов на команды
– Как писать скиллы – вызов скилла, структура, управление поведением агента и регулярная чистка инструкций
– Don’t ship skills without evals – как проверить, что скилл действительно улучшает результат, какие кейсы собирать и зачем сравнивать работу со скиллом и без него
Всякое разное
– Caveman экономит токены. Но не 65% – сколько токенов скилл экономит на реальных агентных задачах и влияет ли это на качество
– Superpowers для разработки с агентами – набор скиллов, который в процессе разработки ведёт агента через дизайн, планирование, TDD и ревью
#ai #devfm
За последнее время у меня вышло много постов про скиллы. Собрал их в одном месте, чтобы было проще разобраться в теме и найти нужное.
С чего начать
– Скиллы в агентах – часть 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
Telegram
DevFM
Скиллы в агентах – часть 1: база
Скиллы для агентов продолжают набирать популярность. Поэтому хочется пройтись по этой теме. Первая часть – база.
Скилл – это модульная инструкция для агента, которая подгружается в контекст по необходимости. По сути – ещё…
Скиллы для агентов продолжают набирать популярность. Поэтому хочется пройтись по этой теме. Первая часть – база.
Скилл – это модульная инструкция для агента, которая подгружается в контекст по необходимости. По сути – ещё…
👍11❤7⚡4🔥1
Как дистрибутировать AI-артефакты
Меня очень интересует дистрибуция AI-артефактов внутри команд – хочется, чтобы все получали единый опыт использования агентов и не городили каждый свой сетап.
У разных агентов уже есть плагины, которые позволяют забандлить набор артефактов для команды или конкретного сценария работы. Но каждый городит своё: форматы плагинов OpenCode, Claude Code и Codex не очень-то совместимы.
И вот собрались умные мужи из Amazon, Cursor, Microsoft, OpenAI и Vercel и попытались решить эту проблему, предложив Agent Plugins – единый формат плагинов для разных агентов.
В текущей версии спецификации плагин – это директория с фиксированной структурой. В корне лежит обязательный
Скиллы находятся в
Формат можно расширять через клиентские расширения. Например, конкретный клиент может добавить поддержку своих сущностей – тех же хуков. Но это довольно хрупкий механизм: другой клиент не обязан понимать такое расширение и может его просто проигнорировать. В итоге мы снова приходим примерно к текущему состоянию: каждый клиент расширяет формат по-своему, а совместимость между ними теряется.
В общем, заход хороший, но как будто не со всей силы.
Некоторое время назад мы начали решать эту задачу на работе и сделали свой механизм пресетов. Он позволяет объединить в один набор MCP, скиллы, рулы, хуки и агентов. Про него я немного рассказал в конце доклада про скиллы. При этом артефакты мы распространяем специальной утилитой, которая знает, как устроены пресеты, и умеет раскладывать их по конфигам разных агентов.
Таким образом, мы можем дистрибуцировать наборы AI-артефактов по командам, чтобы у всех был единый опыт работы с агентами.
#ai
Меня очень интересует дистрибуция AI-артефактов внутри команд – хочется, чтобы все получали единый опыт использования агентов и не городили каждый свой сетап.
У разных агентов уже есть плагины, которые позволяют забандлить набор артефактов для команды или конкретного сценария работы. Но каждый городит своё: форматы плагинов OpenCode, Claude Code и Codex не очень-то совместимы.
И вот собрались умные мужи из Amazon, Cursor, Microsoft, OpenAI и Vercel и попытались решить эту проблему, предложив Agent Plugins – единый формат плагинов для разных агентов.
В текущей версии спецификации плагин – это директория с фиксированной структурой. В корне лежит обязательный
plugin.json: в нём указываются имя плагина и версия спецификации, а опционально – версия самого плагина, описание, автор, ссылки на сайт и репозиторий, лицензия и ключевые слова.Скиллы находятся в
skills/, а MCP-серверы описываются в mcp.json. Совместимый клиент знает, где искать эти компоненты, и может подключить их своим способом. При этом сам стандарт пока описывает только два типа компонентов: скиллы и MCP-серверы.Формат можно расширять через клиентские расширения. Например, конкретный клиент может добавить поддержку своих сущностей – тех же хуков. Но это довольно хрупкий механизм: другой клиент не обязан понимать такое расширение и может его просто проигнорировать. В итоге мы снова приходим примерно к текущему состоянию: каждый клиент расширяет формат по-своему, а совместимость между ними теряется.
В общем, заход хороший, но как будто не со всей силы.
Некоторое время назад мы начали решать эту задачу на работе и сделали свой механизм пресетов. Он позволяет объединить в один набор MCP, скиллы, рулы, хуки и агентов. Про него я немного рассказал в конце доклада про скиллы. При этом артефакты мы распространяем специальной утилитой, которая знает, как устроены пресеты, и умеет раскладывать их по конфигам разных агентов.
Таким образом, мы можем дистрибуцировать наборы AI-артефактов по командам, чтобы у всех был единый опыт работы с агентами.
#ai
Agent Plugins
A portable package format for reusable components that extend AI agents.
👍7❤3🔥3
Agent Reach – доступ к разным источникам для агентов
В Hermes у меня работает подборщик новостей из разных источников. Парсеры для них я либо писал сам, либо брал готовые. Некоторые ещё и периодически отваливались.
Некоторое время назад нашёл Agent Reach – утилиту, которая устанавливает и настраивает для агента инструменты доступа к разным платформам. Например, она умеет читать и искать посты в богомерзком Twitter, работать с Reddit, YouTube, GitHub, LinkedIn и Instagram, а также парсить RSS.
В общем, если искали удобный способ подключить к агенту разные источники – попробуйте.
В Hermes у меня работает подборщик новостей из разных источников. Парсеры для них я либо писал сам, либо брал готовые. Некоторые ещё и периодически отваливались.
Некоторое время назад нашёл Agent Reach – утилиту, которая устанавливает и настраивает для агента инструменты доступа к разным платформам. Например, она умеет читать и искать посты в богомерзком Twitter, работать с Reddit, YouTube, GitHub, LinkedIn и Instagram, а также парсить RSS.
В общем, если искали удобный способ подключить к агенту разные источники – попробуйте.
Telegram
DevFM
Когда появился OpenClaw, я поставил его себе, поигрался, но полезных сценариев так и не нашел.
Недавно решил сделать еще один заход – на этот раз с Hermes. Взял виртуалочку, установил туда Codex. Ну как установил: попросил локальный Codex подключиться по…
Недавно решил сделать еще один заход – на этот раз с Hermes. Взял виртуалочку, установил туда Codex. Ну как установил: попросил локальный Codex подключиться по…
🔥9❤5👍4
Как улучшать скиллы по расписанию
В посте про Codex Desktop я уже рассказывал, что использую
Как работает Scheduled-задача
– анализирует сессии за последние сутки, а если вчерашний запуск был неудачным – расширяет период анализа
– читает личные скиллы, проектные скиллы, которые использовались в сессиях, и нужные
– автоматически ничего не правит, а предлагает изменения
Что именно он ищет
– какие существующие личные скиллы стоит улучшить и как именно
– какие проектные скиллы стоит улучшить с учетом того, как они использовались в конкретном репозитории
– какие скиллы устарели, дублируются, стали слишком жирными
– какие повторяющиеся сценарии пора оформить в новые личные или проектные скиллы
Конечно, зачастую предлагается какая-то фигня, которую я просто игнорирую – именно поэтому не даю автоматически все править. Но и полезные штуки тоже находятся. Из последнего:
– заметил, что в нескольких сессиях я повторял одни и те же требования к интерфейсу. Мы закрепили их в проектном
– нашел несколько дублирующихся скиллов с одинаковыми именами. Лишние копии удалили
– обнаружил, что один из общекомпанейских скиллов ссылался на устаревший скилл. Поправили – стало лучше сразу большому количеству людей :)
– заметил, что скилл для ежедневного разбора почты пропускал новые комментарии в задачах, назначенных на меня, если там не было прямого упоминания. Правило поправили и добавили тесты
В итоге каждое утро начинается с просмотра того, что ещё можно подтюнить.
#ai
В посте про Codex Desktop я уже рассказывал, что использую
Scheduled для периодических задач. Одна из них кажется достаточно полезной, чтобы рассказать отдельно: раз в день Codex просматривает недавние сессии и предлагает, что стоит поправить.Как работает Scheduled-задача
– анализирует сессии за последние сутки, а если вчерашний запуск был неудачным – расширяет период анализа
– читает личные скиллы, проектные скиллы, которые использовались в сессиях, и нужные
AGENTS.md– автоматически ничего не правит, а предлагает изменения
Что именно он ищет
– какие существующие личные скиллы стоит улучшить и как именно
– какие проектные скиллы стоит улучшить с учетом того, как они использовались в конкретном репозитории
– какие скиллы устарели, дублируются, стали слишком жирными
– какие повторяющиеся сценарии пора оформить в новые личные или проектные скиллы
Конечно, зачастую предлагается какая-то фигня, которую я просто игнорирую – именно поэтому не даю автоматически все править. Но и полезные штуки тоже находятся. Из последнего:
– заметил, что в нескольких сессиях я повторял одни и те же требования к интерфейсу. Мы закрепили их в проектном
AGENTS.md, и теперь не нужно каждый раз объяснять агенту, какие правила применять– нашел несколько дублирующихся скиллов с одинаковыми именами. Лишние копии удалили
– обнаружил, что один из общекомпанейских скиллов ссылался на устаревший скилл. Поправили – стало лучше сразу большому количеству людей :)
– заметил, что скилл для ежедневного разбора почты пропускал новые комментарии в задачах, назначенных на меня, если там не было прямого упоминания. Правило поправили и добавили тесты
В итоге каждое утро начинается с просмотра того, что ещё можно подтюнить.
#ai
Telegram
DevFM
Codex Desktop – просто красота нечеловеческая
Я пробовал агентов в разных интерфейсах, но за последний месяц распробовал десктопное приложение Codex. И это просто красота нечеловеческая: получилось полноценное приложение для работы с агентами.
Удобное ревью…
Я пробовал агентов в разных интерфейсах, но за последний месяц распробовал десктопное приложение Codex. И это просто красота нечеловеческая: получилось полноценное приложение для работы с агентами.
Удобное ревью…
👍11❤4🔥4
Deep Tech Night
Я периодически рассказываю об интересных конференциях. И вот скоро, 5 сентября, состоится Deep Tech Night.
Основная тема, конечно aiaiaiiaiaia. Должно быть прикольно. Приходите :)
В этом году основной фокус – на онлайн-формате. Но офлайн тоже будет: можно подать заявочку.
Я периодически рассказываю об интересных конференциях. И вот скоро, 5 сентября, состоится Deep Tech Night.
Основная тема, конечно aiaiaiiaiaia. Должно быть прикольно. Приходите :)
В этом году основной фокус – на онлайн-формате. Но офлайн тоже будет: можно подать заявочку.
deep tech night
Конференция Яндекса о вызовах, с которыми IT-индустрия сталкивается в эпоху AI
⚡4👍4🔥4👎2🌭2
Еще один способ внедрить AI в личный рабочий процесс
Встроить агентов в повседневную работу на самом деле не так уж просто. Этому явно мешают привычки. Многие вещи я уже привык делать определённым образом, да и с ходу не всегда понятно, где именно агент сможет быть полезен.
Я стараюсь критически смотреть на свои задачи и думать, где агент может помочь. Можно ли отдать ему просмотр досок, подготовку ко встречам, ревью PR, работу с требованиями, исследование или ещё что-то.
В таск-трекере периодически накапливается много муторных менеджерских задач. Делать их руками – ну такое, потому что всегда находится что-то более приоритетное. Агент бы справился, но ему явно не хватило бы контекста.
Поэтому я проделал такое упражнение:
1. Все задачи, с которыми, как мне казалось, агент в целом может справиться, пометил тегом
2. Открыл новую сессию и попросил брать эти задачи по очереди и выполнять.
3. Если чего-то не знаешь или в чём-то не уверен – спрашивай. После моего ответа записывай новое знание в
Вот так в течение дня мы параллельно продвигали несколько задач. На мой взгляд, получилось хорошо. Когда я давал недостающий контекст, агент справлялся. А все выясненные по ходу детали оставались на будущее в
Например, хорошо пошла актуализация роадмапа. Сейчас в проекте много зависимостей, поэтому постоянно нужно находить тикеты, проставлять связи и актуализировать даты. Делать всё это руками – ну такое, явно не для человеков. А агент с нужным контекстом в итоге всё прошуршал и сделал. Мне только периодически нужно было отвечать на вопросы и контролировать, всё ли сделано правильно.
Заход неплохой с точки зрения агентизации некоторой рутины – рекомендую попробовать.
А еще грустенько видеть задачу, которая явно подходит агенту, но пока недоступна ему из-за отсутствия нужного инструментария. В общем, пока агент шуршал над задачами, я пошёл оформлять командировку и вручную всё протыкивать.
#agents #ai #devfm
Встроить агентов в повседневную работу на самом деле не так уж просто. Этому явно мешают привычки. Многие вещи я уже привык делать определённым образом, да и с ходу не всегда понятно, где именно агент сможет быть полезен.
Я стараюсь критически смотреть на свои задачи и думать, где агент может помочь. Можно ли отдать ему просмотр досок, подготовку ко встречам, ревью PR, работу с требованиями, исследование или ещё что-то.
В таск-трекере периодически накапливается много муторных менеджерских задач. Делать их руками – ну такое, потому что всегда находится что-то более приоритетное. Агент бы справился, но ему явно не хватило бы контекста.
Поэтому я проделал такое упражнение:
1. Все задачи, с которыми, как мне казалось, агент в целом может справиться, пометил тегом
agent.2. Открыл новую сессию и попросил брать эти задачи по очереди и выполнять.
3. Если чего-то не знаешь или в чём-то не уверен – спрашивай. После моего ответа записывай новое знание в
AGENTS.md.Вот так в течение дня мы параллельно продвигали несколько задач. На мой взгляд, получилось хорошо. Когда я давал недостающий контекст, агент справлялся. А все выясненные по ходу детали оставались на будущее в
AGENTS.md, поэтому заново отвечать на многие вопросы уже не придётся.Например, хорошо пошла актуализация роадмапа. Сейчас в проекте много зависимостей, поэтому постоянно нужно находить тикеты, проставлять связи и актуализировать даты. Делать всё это руками – ну такое, явно не для человеков. А агент с нужным контекстом в итоге всё прошуршал и сделал. Мне только периодически нужно было отвечать на вопросы и контролировать, всё ли сделано правильно.
Заход неплохой с точки зрения агентизации некоторой рутины – рекомендую попробовать.
А еще грустенько видеть задачу, которая явно подходит агенту, но пока недоступна ему из-за отсутствия нужного инструментария. В общем, пока агент шуршал над задачами, я пошёл оформлять командировку и вручную всё протыкивать.
#agents #ai #devfm
👍17🔥5⚡4❤3
Некоторое время назад нашёл скилл Diagram Design для рисования диаграмм. Как-то он лежал-лежал, а тут наконец потребовалось порисовать.
Что скажу – вышло хорошо. Диаграммы получаются аккуратными, красивенькими и в одном стиле. Не нужно отдельно объяснять агенту кто на ком стоял.
Скилл поддерживает самые разные схемки: архитектурные, flowchart, sequence, Gantt и ER-модели. Результат сохраняется как автономный html с inline SVG, который можно экспортировать в SVG и PNG. Ещё скилл может перерисовать существующую схему из draw.io или Mermaid.
В общем, рекомендую попробовать :)
#ai
Что скажу – вышло хорошо. Диаграммы получаются аккуратными, красивенькими и в одном стиле. Не нужно отдельно объяснять агенту кто на ком стоял.
Скилл поддерживает самые разные схемки: архитектурные, flowchart, sequence, Gantt и ER-модели. Результат сохраняется как автономный html с inline SVG, который можно экспортировать в SVG и PNG. Ещё скилл может перерисовать существующую схему из draw.io или Mermaid.
В общем, рекомендую попробовать :)
#ai
GitHub
GitHub - cathrynlavery/diagram-design: Editorial diagram design for Claude Code, Codex, and Pi. Self-contained HTML + SVG. No shadows.…
Editorial diagram design for Claude Code, Codex, and Pi. Self-contained HTML + SVG. No shadows. No Mermaid slop. - cathrynlavery/diagram-design
👍18🔥6❤4
Фича из 2015-го для агентов в 2026-м
Можно годами пользоваться гитом и ничего не знать про git worktree. Команда появилась ещё в июле 2015-го, в Git 2.5 и позволяет держать несколько веток одного репозитория в отдельных папках.
Кейсы заявлялись вполне практичные: срочно починить баг, не трогая недописанную фичу, или запустить долгие тесты в одной папке и продолжить разработку в другой. Но в целом-то можно было обходиться переключением веток и stash.
Зато теперь, когда код пишут агенты, worktree практически незаменим.
Один агент пилит фичу, другой пилит фичу, ещё один баг правит. Просто наплодить каждому по ветке не получится. В одной рабочей директории активна только одна ветка.
И вот тут мы расчехляем git worktree, который позволяет создать несколько рабочих копий одного репозитория. В каждой – своя ветка, свои файлы и незакоммиченные изменения. История Git общая, клонировать репозиторий заново для каждой задачи не нужно.
Например, из папки проекта:
Получаются две новые ветки от текущего коммита и две отдельные рабочие копии. Первого агента запускаешь в
Конфликты при слиянии, конечно, возможны, если задачи затронули одни и те же куски кода. Но это лучше, чем всем вместе менять одну рабочую копию.
В общем, если не пробовали, то категорически рекомендую присмотреться.
#ai #agents
Можно годами пользоваться гитом и ничего не знать про git worktree. Команда появилась ещё в июле 2015-го, в Git 2.5 и позволяет держать несколько веток одного репозитория в отдельных папках.
Кейсы заявлялись вполне практичные: срочно починить баг, не трогая недописанную фичу, или запустить долгие тесты в одной папке и продолжить разработку в другой. Но в целом-то можно было обходиться переключением веток и stash.
Зато теперь, когда код пишут агенты, worktree практически незаменим.
Один агент пилит фичу, другой пилит фичу, ещё один баг правит. Просто наплодить каждому по ветке не получится. В одной рабочей директории активна только одна ветка.
И вот тут мы расчехляем git worktree, который позволяет создать несколько рабочих копий одного репозитория. В каждой – своя ветка, свои файлы и незакоммиченные изменения. История Git общая, клонировать репозиторий заново для каждой задачи не нужно.
Например, из папки проекта:
git worktree add -b agent/feature ../project-feature HEADgit worktree add -b agent/bugfix ../project-bugfix HEADПолучаются две новые ветки от текущего коммита и две отдельные рабочие копии. Первого агента запускаешь в
project-feature, второго – в project-bugfix, третьего – в исходной рабочей копии. Конфликты при слиянии, конечно, возможны, если задачи затронули одни и те же куски кода. Но это лучше, чем всем вместе менять одну рабочую копию.
В общем, если не пробовали, то категорически рекомендую присмотреться.
#ai #agents
The GitHub Blog
Git 2.5, including multiple worktrees and triangular workflows
The open source Git project has just released Git 2.5. Here’s our take on its most useful new features. git worktree: one Git repository with multiple working trees It’s not…
👍19❤7🔥5⚡1
Что OpenAI советует при работе с GPT-6 Astra
Относительно недавно вышла GPT-6 Astra, и я решил почитать, что ребята из OpenAI советуют при работе с моделью.
Просить доводить задачу до результата
Astra чаще уточняет там, где предыдущие модели делали предположения. Советуют прямо просить агента довести задачу до конца без лишних согласований.
Пересмотреть скиллы и AGENTS.md
Модель лучше следует инструкциям и чувствительнее к их содержимому. Неясные или противоречивые правила могут заставить её остановиться и ждать подтверждения.
Я уже писал, что суперважно всё это добро поддерживать в актуальном состоянии. Хороший способ проверить, что ещё нужно, – периодически вычищать почти всё и смотреть, изменилось ли что-то в работе агента.
Задать стиль ответов
Astra склонна к подробным ответам, спискам, таблицам и повторяющимся оборотам. Если хочется короткого текста обычными абзацами, это стоит прямо написать. В доке даже есть примеры инструкций против шаблонных фраз и лишнего жаргона.
Обозначить, когда нужны субагенты
Если ваш агент поддерживает делегирование и вы хотите, чтобы он чаще распараллеливал работу, задайте это в инструкциях.
Соразмерять проверки с задачей
Для небольшой правки модель может устроить слишком широкое тестирование.
С тестами уже поймал такое: составили план, агент пошёл пыхтеть. Думаю, что-то долго, спрашиваю, в чём дело. Оказалось, всё это время он писал какие-то ну оооочень разухабистые тесты, которые к тому же у него не получалось написать.
Ничего сильно нового, конечно, не открыли, но знание таких нюансов может оказаться полезным. Кстати, в статье для каждого пункта есть примеры формулировок.
#ai #agents
Относительно недавно вышла GPT-6 Astra, и я решил почитать, что ребята из OpenAI советуют при работе с моделью.
Просить доводить задачу до результата
Astra чаще уточняет там, где предыдущие модели делали предположения. Советуют прямо просить агента довести задачу до конца без лишних согласований.
Пересмотреть скиллы и AGENTS.md
Модель лучше следует инструкциям и чувствительнее к их содержимому. Неясные или противоречивые правила могут заставить её остановиться и ждать подтверждения.
Я уже писал, что суперважно всё это добро поддерживать в актуальном состоянии. Хороший способ проверить, что ещё нужно, – периодически вычищать почти всё и смотреть, изменилось ли что-то в работе агента.
Задать стиль ответов
Astra склонна к подробным ответам, спискам, таблицам и повторяющимся оборотам. Если хочется короткого текста обычными абзацами, это стоит прямо написать. В доке даже есть примеры инструкций против шаблонных фраз и лишнего жаргона.
Обозначить, когда нужны субагенты
Если ваш агент поддерживает делегирование и вы хотите, чтобы он чаще распараллеливал работу, задайте это в инструкциях.
Соразмерять проверки с задачей
Для небольшой правки модель может устроить слишком широкое тестирование.
С тестами уже поймал такое: составили план, агент пошёл пыхтеть. Думаю, что-то долго, спрашиваю, в чём дело. Оказалось, всё это время он писал какие-то ну оооочень разухабистые тесты, которые к тому же у него не получалось написать.
Ничего сильно нового, конечно, не открыли, но знание таких нюансов может оказаться полезным. Кстати, в статье для каждого пункта есть примеры формулировок.
#ai #agents
OpenAI Developers
Model guidance | OpenAI API
Compare model features, migration guidance, and prompting best practices across OpenAI models.
👍11🔥7⚡2
Что там с кодинговыми агентами
Я тут немного пропустил, а JetBrains поделились результатами очередного большого исследования – AI Coding Agents: Adoption Trends.
Из интересного:
– 90% профессиональных разработчиков используют кодинговых AI-агентов на работе хотя бы раз в неделю, 68% – ежедневно
– Claude Code едет и бибикает – тут, кажется, без сюрпризов. С января доля разработчиков, которые используют его на работе, выросла с 18% до 39%. А для 31% это уже основной AI-инструмент для кодинга
– Codex ворвался в гонку кодинговых агентов: с 3% в январе до 16% в мае–июле. Но хотя ChatGPT уже стал именем нарицательным, как ксерокс, 35% разработчиков всё ещё даже не слышали о Codex
– опенсорсный OpenCode молодец: 7% используют его на работе, 42% о нём знают. Хороший адопшен для проекта, за которым не стоит техногигант. Попробуйте, если ещё не пробовали – я некоторое время использовал, мне нравилось
– задавший тренд индустрии GitHub Copilot потихоньку скукливается: с 29% год назад до 21% сейчас. Я его, кажется, не использую уже с 2024 года, но удивительно, что он всё ещё настолько популярен. Наверное, отчасти потому, что поддержка Copilot уже встроена в VS Code. А дефолты, как известно, сильная штука
Я тут немного пропустил, а JetBrains поделились результатами очередного большого исследования – AI Coding Agents: Adoption Trends.
Из интересного:
– 90% профессиональных разработчиков используют кодинговых AI-агентов на работе хотя бы раз в неделю, 68% – ежедневно
– Claude Code едет и бибикает – тут, кажется, без сюрпризов. С января доля разработчиков, которые используют его на работе, выросла с 18% до 39%. А для 31% это уже основной AI-инструмент для кодинга
– Codex ворвался в гонку кодинговых агентов: с 3% в январе до 16% в мае–июле. Но хотя ChatGPT уже стал именем нарицательным, как ксерокс, 35% разработчиков всё ещё даже не слышали о Codex
– опенсорсный OpenCode молодец: 7% используют его на работе, 42% о нём знают. Хороший адопшен для проекта, за которым не стоит техногигант. Попробуйте, если ещё не пробовали – я некоторое время использовал, мне нравилось
– задавший тренд индустрии GitHub Copilot потихоньку скукливается: с 29% год назад до 21% сейчас. Я его, кажется, не использую уже с 2024 года, но удивительно, что он всё ещё настолько популярен. Наверное, отчасти потому, что поддержка Copilot уже встроена в VS Code. А дефолты, как известно, сильная штука
The JetBrains Blog
AI Coding Agents: Adoption Trends - The JetBrains Blog
How many developers use AI coding agents (Claude Code, Codex, Cursor, JetBrains Junie, and others)? Evidence from the Developer Ecosystem Survey 2026.
🔥6⚡4👍3
Не пишите аислопный текст, пожалуйста-препожалуйста.
Код супер активно пишется агентами и читается ими же – и как будто даже неплохо выходит. Люди, конечно, всё ещё читают код, но сильно меньше, и тенденция понятна.
Но божечки, с текстами так не работает. Как же утомляет читать аислопные тексты. Иногда заходишь в тикет, а там простыня. Или тебе скидывают ссылку на вики – вот, читайте, изучайте. ААА!!!
Текст в большинстве своём нужен, чтобы передать информацию от одного думающего человека другим думающим человекам. Хочется понимать, что человек сам думает по заданной теме, что предлагает и почему.
Для меня тут важны три вещи.
За каждую мысль в тексте нужно отвечать. За каждым предложением в тексте должен стоять смысл. Люди воспринимают написанное как твою позицию. Если агент дописал что-то от себя, а ты не заметил, читатели вполне могут решить, что ты именно так и думаешь. Или просто будут читать и думать: ну что за вода.
Когда пишешь – думаешь. Пока пишешь, разбираешься, что важно, как одно связано с другим, где ты сам чего-то не понимаешь. И мне кажется, это супер важно.
Цените чужое время. Агент выдал тебе текст, ты пробежался по нему глазами (если вообще пробежался) и отправил людям. А им теперь разбираться, что ты хотел сказать. Нельзя экономить свои усилия, заставляя читателей разбираться в тексте, который ты сам не разобрал. Спросить у агента они и сами могут.
Я тексты продолжаю писать руками. AI, конечно, участвует в процессе, но такое я тщательнейшим образом вычитываю, ревьюю, переписываю. Мне важно, чтобы в результате было написано то, что я сам думаю и хочу сказать.
А аислопное говнище мне присылать не нужно.
#devfm #ai
Код супер активно пишется агентами и читается ими же – и как будто даже неплохо выходит. Люди, конечно, всё ещё читают код, но сильно меньше, и тенденция понятна.
Но божечки, с текстами так не работает. Как же утомляет читать аислопные тексты. Иногда заходишь в тикет, а там простыня. Или тебе скидывают ссылку на вики – вот, читайте, изучайте. ААА!!!
Текст в большинстве своём нужен, чтобы передать информацию от одного думающего человека другим думающим человекам. Хочется понимать, что человек сам думает по заданной теме, что предлагает и почему.
Для меня тут важны три вещи.
За каждую мысль в тексте нужно отвечать. За каждым предложением в тексте должен стоять смысл. Люди воспринимают написанное как твою позицию. Если агент дописал что-то от себя, а ты не заметил, читатели вполне могут решить, что ты именно так и думаешь. Или просто будут читать и думать: ну что за вода.
Когда пишешь – думаешь. Пока пишешь, разбираешься, что важно, как одно связано с другим, где ты сам чего-то не понимаешь. И мне кажется, это супер важно.
Цените чужое время. Агент выдал тебе текст, ты пробежался по нему глазами (если вообще пробежался) и отправил людям. А им теперь разбираться, что ты хотел сказать. Нельзя экономить свои усилия, заставляя читателей разбираться в тексте, который ты сам не разобрал. Спросить у агента они и сами могут.
Я тексты продолжаю писать руками. AI, конечно, участвует в процессе, но такое я тщательнейшим образом вычитываю, ревьюю, переписываю. Мне важно, чтобы в результате было написано то, что я сам думаю и хочу сказать.
А аислопное говнище мне присылать не нужно.
#devfm #ai
👍43🔥14⚡4❤2
Код пишется быстро, а што с ревью
Я как-то уже бухтел на тему код-ревью. Но мир так быстро меняется, что хочется поднять её снова.
Код теперь генерируют агенты. Увидеть пиар на
Вижу проекты, где код всё так же по старинке дотошно и вдумчиво смотрят люди. Ревью становится бутылочным горлышком: код пишется быстро, пиары висят днями.
Где-то к просмотру глазами подключают агента: «Сделай ревью и смотри, чтобы там всё хорошо было» – тоже вариант.
На одном из проектов мы тоже столкнулись с этой проблемой. Задач много, бежать нужно быстро, ещё и у внешних контрибьюторов чешутся руки – дайте занести кода к вам. Пиары летят, ревью загибается.
Мы решили сделать накопленный опыт ревью доступным агентам ещё до создания пиара. Для этого:
- собрали все-все замечания из прошлых пиаров – проект не новый, истории хватало
- прошерстили личные чаты с агентами и вытащили оттуда замечания к их работе
- на этой основе сформировали гайдлайны по написанию и тестированию кода – что-то положили в
Так агент может ещё во время написания кода учесть, как у нас всё устроено.
Дальше, уже в CI, добавили дополнительные валидации и ревью агентом.
В итоге обычно смотрим пиары глазами по минимуму: многие замечания уже учтены по умолчанию. А иногда и не смотрим вовсе :)
Пока проблему с очередью из пиаров удалось решить. Как этот подход скажется на качестве кода на дистанции, ещё предстоит понять. По результатам будем тюнить процесс. Чтобы держать руку на пульсе, периодически внимательно смотрим код: как связаны части проекта, не расползается ли структура.
Расскажите, как у вас устроено код-ревью? Что хорошо работает?
Остаётся, конечно, ещё один вопрос: кто в этой схеме отвечает за все эти тонны кода? Но это уже совсем другая история.
Я как-то уже бухтел на тему код-ревью. Но мир так быстро меняется, что хочется поднять её снова.
Код теперь генерируют агенты. Увидеть пиар на
+4623 −200 – да запросто. А дальше у всех по-разному.Вижу проекты, где код всё так же по старинке дотошно и вдумчиво смотрят люди. Ревью становится бутылочным горлышком: код пишется быстро, пиары висят днями.
Где-то к просмотру глазами подключают агента: «Сделай ревью и смотри, чтобы там всё хорошо было» – тоже вариант.
На одном из проектов мы тоже столкнулись с этой проблемой. Задач много, бежать нужно быстро, ещё и у внешних контрибьюторов чешутся руки – дайте занести кода к вам. Пиары летят, ревью загибается.
Мы решили сделать накопленный опыт ревью доступным агентам ещё до создания пиара. Для этого:
- собрали все-все замечания из прошлых пиаров – проект не новый, истории хватало
- прошерстили личные чаты с агентами и вытащили оттуда замечания к их работе
- на этой основе сформировали гайдлайны по написанию и тестированию кода – что-то положили в
AGENTS.md, что-то обернули в скиллыТак агент может ещё во время написания кода учесть, как у нас всё устроено.
Дальше, уже в CI, добавили дополнительные валидации и ревью агентом.
В итоге обычно смотрим пиары глазами по минимуму: многие замечания уже учтены по умолчанию. А иногда и не смотрим вовсе :)
Пока проблему с очередью из пиаров удалось решить. Как этот подход скажется на качестве кода на дистанции, ещё предстоит понять. По результатам будем тюнить процесс. Чтобы держать руку на пульсе, периодически внимательно смотрим код: как связаны части проекта, не расползается ли структура.
Расскажите, как у вас устроено код-ревью? Что хорошо работает?
Остаётся, конечно, ещё один вопрос: кто в этой схеме отвечает за все эти тонны кода? Но это уже совсем другая история.
Telegram
DevFM
Зачем вы проводите код-ревью?
Большая часть команд, с которыми я работал, проводят код-ревью. Код-ревью – как священная корова: “А код поревьюили?”, “Без ревью не пушим” и всякое такое.
И каждый PR дисциплинированно пропускают через код-ревью: назначаются…
Большая часть команд, с которыми я работал, проводят код-ревью. Код-ревью – как священная корова: “А код поревьюили?”, “Без ревью не пушим” и всякое такое.
И каждый PR дисциплинированно пропускают через код-ревью: назначаются…
👍12🔥6⚡3
ММММолния!
В последнем обновлении Claude Code добавили поддержку
По умолчанию Claude Code читает
Ждем, когда еще начнет учитывать
В последнем обновлении Claude Code добавили поддержку
AGENTS.md! Это настоящий биг факин диал.По умолчанию Claude Code читает
AGENTS.md, если в проекте нет CLAUDE.md. Выбор можно изменить в /config → Project instructions.Ждем, когда еще начнет учитывать
.agents в своей работе.GitHub
Release v2.1.277 · anthropics/claude-code
What's changed
Added AGENTS.md support: in a project with no CLAUDE.md, Claude Code reads AGENTS.md instead; change it under "Project instructions" in /config (not yet on Bedrock, Ve...
Added AGENTS.md support: in a project with no CLAUDE.md, Claude Code reads AGENTS.md instead; change it under "Project instructions" in /config (not yet on Bedrock, Ve...
1👍8🔥6⚡3
Попробуйте Herdr
По долгу службы я использую самые разные инструменты и какое-то время экспериментировал с herdr.
Очень рекомендую присмотреться тем, кто погоняет агентов в консоли.
Что в нём удобно:
- поддерживает много харнессов – можно рядом гонять клоды, кодексы, OpenCode и другие
- хорошо кастомизируется: если чего-то не хватает, можно накрутить свою интеграцию через плагины. Например, подключить внутреннюю систему контроля версий, чтобы показывать статус пиара рядом с сессией агента, или связать сессии с тикетами – любой каприз
- позволяет подключать удалённые тачки по SSH и менеджить локальные и удалённые сессии из одного окна
- запоминает раскладку: если засплитили экран под несколько сессий, после перезапуска восстановит вкладки, панели и рабочие директории
- показывает статусы агентов в боковой панели: кто работает, кто закончил, а кто ждёт вашего ответа. Удобно, когда сессий много
- позволяет отключиться и вернуться позже: пока сервер herdr работает, агенты продолжают выполнять задачи. Если оборвалось SSH-соединение с удалённой машинкой, работа на ней идёт дальше
Используете что-то подобное поверх ванильных харнессов? Или, может, знаете классные фичи в herdr?
Кстати, вступайте в чатик – там бывают интересные обсуждения.
По долгу службы я использую самые разные инструменты и какое-то время экспериментировал с herdr.
Очень рекомендую присмотреться тем, кто погоняет агентов в консоли.
Что в нём удобно:
- поддерживает много харнессов – можно рядом гонять клоды, кодексы, OpenCode и другие
- хорошо кастомизируется: если чего-то не хватает, можно накрутить свою интеграцию через плагины. Например, подключить внутреннюю систему контроля версий, чтобы показывать статус пиара рядом с сессией агента, или связать сессии с тикетами – любой каприз
- позволяет подключать удалённые тачки по SSH и менеджить локальные и удалённые сессии из одного окна
- запоминает раскладку: если засплитили экран под несколько сессий, после перезапуска восстановит вкладки, панели и рабочие директории
- показывает статусы агентов в боковой панели: кто работает, кто закончил, а кто ждёт вашего ответа. Удобно, когда сессий много
- позволяет отключиться и вернуться позже: пока сервер herdr работает, агенты продолжают выполнять задачи. Если оборвалось SSH-соединение с удалённой машинкой, работа на ней идёт дальше
Используете что-то подобное поверх ванильных харнессов? Или, может, знаете классные фичи в herdr?
Кстати, вступайте в чатик – там бывают интересные обсуждения.
Herdr
Herdr: the runtime coding agents run on
Run them anywhere. Leave them running. Herdr holds real terminals open so your agents keep working when you close the laptop.
🔥8👍4⚡2
Багфикс по расписанию
AI врывается в разные этапы SDLC. Сейчас экспериментирую с автоматизацией maintenance-части – сопровождения продукта.
Сделал cron-таску, которая периодически смотрит логи системы и анализирует частоту ошибок. Если она превышает заданный порог, в дело вступает агент.
Он локально дебажит и пытается воспроизвести ошибку, создаёт тикет с диагностикой, затем берётся за исправление. По результатам приносит PR.
Например, после обновления приложения один из фоновых процессов не мог завершить работу. Механизм остановки пытался запустить исполняемый файл старой версии, который уже удалили при обновлении. Процесс получал ошибку
Агент воспроизвёл сбой и исправил обработку отсутствующего файла: теперь в этом случае процесс сам освобождает ресурсы и завершает работу. Закрепил сценарий регрессионным тестом.
Человеку остаётся посмотреть исходную проблему, диагностику и правки. И если всё ок – нажать МЕРДЖ)
Все исправленные проблемы агент записывает. В начале следующего прогона возвращается к ним и проверяет по логам, ушла ли ошибка на новых версиях.
В общем, красота нечеловеческая!
А вот чатик, где можно поразгонять эту тему и поделиться своим опытом.
#devfm
AI врывается в разные этапы SDLC. Сейчас экспериментирую с автоматизацией maintenance-части – сопровождения продукта.
Сделал cron-таску, которая периодически смотрит логи системы и анализирует частоту ошибок. Если она превышает заданный порог, в дело вступает агент.
Он локально дебажит и пытается воспроизвести ошибку, создаёт тикет с диагностикой, затем берётся за исправление. По результатам приносит PR.
Например, после обновления приложения один из фоновых процессов не мог завершить работу. Механизм остановки пытался запустить исполняемый файл старой версии, который уже удалили при обновлении. Процесс получал ошибку
FileNotFoundError и пробовал снова. В логах накапливались одинаковые ошибки.Агент воспроизвёл сбой и исправил обработку отсутствующего файла: теперь в этом случае процесс сам освобождает ресурсы и завершает работу. Закрепил сценарий регрессионным тестом.
Человеку остаётся посмотреть исходную проблему, диагностику и правки. И если всё ок – нажать МЕРДЖ)
Все исправленные проблемы агент записывает. В начале следующего прогона возвращается к ним и проверяет по логам, ушла ли ошибка на новых версиях.
В общем, красота нечеловеческая!
А вот чатик, где можно поразгонять эту тему и поделиться своим опытом.
#devfm
Telegram
DevFM chat
Sergey B invites you to join this group on Telegram.
👍9❤5🔥4