DevFM

Чем пользуется команда Cursor

Тут ребята из Cursor выложили в маркетплейс Cursor Team Kit – набор внутренних скиллов, субагентов и рулов для разработки.

Из интересного:
– verify-this запускает одну и ту же проверку до и после изменений – например, воспроизводит баг или замеряет скорость – и сравнивает результаты
– workflow-from-chats читает историю чатов, находит повторяющиеся замечания к работе агента и переносит их в скиллы, рулы или документацию. У меня, кстати, в Codex настроена такая же штука – раз в сутки смотрит, что бы такое можно было улучшить
– control-ui и control-cli позволяют агенту самому пройти сценарий в интерфейсе или терминале, воспроизвести баг и сохранить скриншоты или логи
– deslop чистит код, написанный агентом: убирает лишние комментарии и проверки, any и слишком глубокую вложенность

Ещё там есть два субагента. ci-watcher в фоне следит за проверками PR и приносит ссылки на упавшие чеки. А thermo-nuclear-code-quality-review получает diff и пристально ревьюит то, что наколбасил агент.

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

Добавлю, что очень круто, если у них этот набор действительно дистрибуцирован на всю компанию. Собрать такой сетап и убедиться, что им пользуются все, – отдельная непростая задача.

#ai

Don’t ship skills without evals

Скиллы едут и бибикают, но остаётся, как мне кажется, слабо освещённым вопрос: как проверить, что скилл работает качественно? И вообще, что считать качеством?

В исследовании SkillsBench ребята собрали 47 тысяч уникальных скиллов – почти все без evals. В целом я этих людей понимаю: забахали скилл, вроде работает – бежим дальше. А проверка качества – это уже скучные детали. В результатах SkillsBench заранее подготовленные и отобранные скиллы дали в среднем +16,2 процентного пункта, а скиллы, которые агенты генерировали сами перед выполнением задачи, – −1,3.

Посмотрел доклад ребят из DeepMind – про evals для скиллов.

Сначала докладчик даёт общие рекомендации по скиллам:
– описание должно точно объяснять, когда, зачем и как использовать скилл – и когда не использовать

– инструкции стоит формулировать директивно, а не расплывчато, вычищать no-ops, держать SKILL.md компактным, а детали выносить в референсы. Думаю, в целом это уже всем известные приёмы

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

– не все скиллы нужно вызывать автоматически. Например, скилл для ревью имеет смысл вызывать вручную

Дальше – собственно про evals.
– начать стоит 10–20 кейсов: кейсы, где скилл должен сработать, где не должен срабатывать. Если есть подтвержденные сценарии с прода, их тоже стоит включить в проверки. От себя хочу уточнить, что важно не полагаться на автогенерацию evals. Агент может помочь собрать первую версию, но в основе должны быть реальные сценарии использования, с реальными формулировками

– проверять стоит не то, вызвал ли агент скилл на первом шаге, а решил ли он задачу. В примере с Gemini API итогом был валидный код с актуальными SDK, моделью и методами. Такие условия можно проверять регулярками или скриптами, а более сложные результаты – через LLM as a judge

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

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

#ai

Вот пересказ этой истории по версии Hugging Face, много тех-терминов – но без них не перескахать

Если коротко – агент OpenAI на новой модели не стал решать тест по кибербезопасности, а решил просто украсть ответы и украл 🗿

Таймлайн:

📔 9 июля – агент проходит внутреннюю проверку кибервозможностей OpenAI, промпт фильтры там ослаблены, чтобы измерить сырой уровень модели. Агент находит zero-day в кэш-прокси реестра пакетов, вырывается из песочницы в интернет, затем взламывает публичный сервис для запуска кода и получает там root. Серьезно, агент сделал себе "штаб"

В тот же день, агент собирает канал управления буквально из сервисов бесплатного интернета: request-capture сервисы, pastebin’ы и файлообменники. Команды режет на куски, упаковывает в gzip+base64 и постоянно меняет каналы, когда очередной закрывают, чтобы не поймали

📔 10 июля – агент ищет в поисковиках и API названия, которые видит в собственном окружении, то есть, по сути, гуглит самого себя – и, вероятно, приходит к выводу, что ответы к ExploitGym/CyberGym могут лежать на Hugging Face

Агент загружает на Hugging Face специально собранные датасеты:

Один заставляет обработчик файлов HDF5 читать локальные файлы сервера Hugging Face – так агент получает переменные окружения с токенами и исходники самого обработчика файлов

Второй – Jinja2-инъекция – запускает произвольный Python внутри production-пода Kubernetes, результаты команд он выносит обратно через API Hugging Face и собственные шифрованные датасеты

📔 11 июля – пик активности: 7677 действий за сутки, менее чем за 13 часов агент проходит путь от одного production-пода до кластер админа в нескольких внутренних кластерах Hugging Face

Агент крадёт service-account токены, лезет в cloud metadata, поднимает privileged pod с диском хоста и получает root на ноде (!); Затем создаёт самовосстанавливающийся флот на 11 нодах, читает внутреннюю MongoDB и один Kubernetes-secret сразу со 136 ключами.

Среди них оказываются ключ корпоративной mesh-VPN жертвы и общий credential внутреннего сервера; из-за неудачной конфигурации этот один credential был привязан к system:masters сразу в нескольких кластерах – поэтому агент получил кластер-admin на двух из них буквально за секунду – была очень экономная архитектура, пока её не увидел робот

📔 12 июля – агент начинает пользоваться дертвой – за всю активность он зарегистрирует 181 временное устройство в корпоративной mesh-сети, поднимет SOCKS-прокси прямо из песочниц и увидит 22 внутренних узла Hugging Face. Попытается зайти в основную базу Hugging Face, но private-link allowlist его останавливает

Поздно вечером он добирается до source control, выпускает себе GitHub App token с правами на запись и открывает pull request, пытаясь запустить CI и вытащить новые credentials

Попытка не срабатывает, в опубликованные пакеты и образы ничего вредоносного не попало.

📔 13 июля – закрепление и уборка следов: загрузчик с pastebin, переписывание DNS, новые короткоживущие токены, RSA-ключ и даже CORS-прокси на самом Hugging Face как запасной выход в интернет. В 13:37 фиксируется последнее осмысленное действие, затем команда Hugging Face отрезает доступ – последнее событие – 14:14 UTC.

В итоге из пользовательского контента агент добрался только до пяти датасетов с решениями задач ExploitGym/CyberGym – получается решил?

Другие модели, датасеты, Spaces и пакеты, по данным Hugging Face, не пострадали; основная база и software supply chain остались целы

Самое смешное – когда инцидент исследовали сотрудники, они тоже использовали нейронки, но Claude Opus и Fable отказывались разбирать часть логов как «опасный» запрос, поэтому Hugging Face подняли GLM-5.2 у себя и с его помощью расшифровали спрятанные payload’ы – спасибо китайским моделям

Шел июль 2026 года

Все детали тут:
https://huggingface.co/blog/agent-intrusion-technical-timeline

Если вдруг пропустили шкандаль минувшей недели, то вот он – настоящий Скайнет, очень захватывающе

Конференция Back to Back

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

Поэтому приглашаю зарегистрироваться на конференцию Back to Back. Она пройдёт 1 августа офлайн в Москве, Белграде и Ереване, а подключиться к трансляции можно будет онлайн. Я буду ведущим архитектурного трека – приходите, послушаем хардкорные доклады :)

Когда появился OpenClaw, я поставил его себе, поигрался, но полезных сценариев так и не нашел.

Недавно решил сделать еще один заход – на этот раз с Hermes. Взял виртуалочку, установил туда Codex. Ну как установил: попросил локальный Codex подключиться по SSH и все настроить. Через него же поставил Hermes и сделал канал для общения в Telegram. На все ушло не больше получаса.

На этот раз придумал два сценария.

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

Дальше зафиксировали интересные мне источники, добавили еще несколько вариантов, которые предложил агент, написали пару парсеров – и в целом всё. Теперь Hermes каждый день присылает подборку новостей, которые должны быть мне интересны. Если что-то оказывается неинтересно, так и говорю ему: "Такое больше не присылай потому то".

Мониторинг продуктов со скидкой
Второй пример немного шутейный. Я заказываю продукты из ВкусВилла, а у них бывают зеленые ценники со скидкой 40% и такие товары быстро разбирают.

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

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

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

#ai #devfm

Slidev для презентаций

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

Сейчас активно использую Slidev. По сути, это та же html-презентация, но с полноценным инструментарием для выступления.

Что мне понравилось:
– есть всё привычное из Поверпоинта: ноутсы, presenter view с текущим и следующим слайдом, таймер
– удобно ревьюить: исходник лежит в markdown, а результат сразу открывается в браузере
– полноэкранный режим, чтобы не показывать стопицот открытых вкладок в браузере, а ещё навигация с якорями и переключение между светлым и тёмным режимами
– встроенная запись экрана и камеры
– конкретные слайды можно вынести в отдельные markdown-файлы и подключать в разные презентации, а повторяющиеся структуры оформить как layouts

Полный список приколюх можно посмотреть тут.

Из минусов – такую презентацию сложно шарить. Можно экспортировать в PDF, но вся интерактивная красота при этом пропадает. Поэтому остаётся собирать её как статическое приложение и выкладывать на GitHub Pages или Vercel.

Вот, например, презентация с Podlodka.

#ai

Департамент AI-изации разыскивает их👮‍♂️

Пятничное развлекательное

Я вообще крайне редко смотрю смешные картинки, но сюда @n_it_girls периодически заглядываю похихикать :)

Codex Desktop – просто красота нечеловеческая

Я пробовал агентов в разных интерфейсах, но за последний месяц распробовал десктопное приложение Codex. И это просто красота нечеловеческая: получилось полноценное приложение для работы с агентами.

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

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

Удобно уточнять
Бывает, агент что-то выдал, а хочется уточнить небольшую деталь: что он имел в виду или что означает какой-то термин. Раньше был выбор: разрывать основной диалог или создавать отдельный чат. Теперь можно выделить блок текста и выбрать More Details – агент сразу начнет объяснять именно этот фрагмент. Или Ask in side chat – рядом откроется аккуратный чат, где можно уточнить что угодно в свободной форме.

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

/goal
То, что раньше делали сторонние решения вроде Ralph loop, где агент работает до потери сознания, лишь бы выполнить задачу, теперь можно делать в Codex. Пишешь /goal – и вперед.
Я пока только пробую этот функционал, но мне нравится. Например, нужно написать CLI-обертку над чужим API. DoD понятен – работай на здоровье. Агент ковыряется уже 11 часов, посмотрим, что из этого выйдет.

Автоматизации
На автоматизации тоже подсел: появился полноценный раздел Scheduled, из которого удобно запускать разные задачи по расписанию. Я сразу завел несколько:
– анализ прошлых диалогов: что стоит вынести в AGENTS.md, какие существующие скиллы подправить и какие новые создать
– разбор календаря: посмотреть встречи на день, найти встречи без повестки и подготовить организатору драфт сообщения с просьбой ее добавить и уточнить, зачем я нужен на встрече
– разбор почты: собрать несмердженные PR, которые ждут моего ревью, и тикеты, где меня призывают, – сразу с прямыми ссылками, чтобы не открывать письма
– мониторинг пет-проектов: посмотреть логи и рассказать, не случилось ли чего

Remote-подключение
К сессиям Codex на компьютере можно подключаться через мобильное приложение – очень удобно продолжить работу не за столом. Если в вашем App Store нет ChatGPT, мне помогла смена страны аккаунта: после этого приложение появилось.

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

В общем, все стало сильно продуманнее – попробуйте.

#ai #devfm

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

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

И тут вспомнил, что вообще-то очень люблю горы. Значит, надо ехать. Хотелось уложиться в 3–4 дня и ничего не организовывать самому – обычно я как раз всё делаю сам.

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

Докладываю: сгонял в Верхнюю Балкарию – очень классно. Походил по горам, посмотрел красивые места, преодолевал бурные реки, вкусно ел. И, кажется, таки действительно выдохнул.

В общем, если очень устали – рекомендую. Гифка для затравки :)

#devfm

Как писать скиллы

Посмотрел хорошее видео Мэтта Покока о том, как писать свои скиллы. Он выделяет четыре этапа.

Как скилл вызывается
Когда я рассказываю о том, как можно вызывать скиллы, всегда упоминаю, что обычно сам знаю, какой скилл мне нужен. Поэтому не отдаю выбор на откуп агенту, а вызываю скилл сам через /. Мэтт предлагает пойти дальше и. явно определять это на уровне самого скилла. То есть явно задавать поле disable-model-invocation, определяющее может ли модель вызывать скилл.

Как устроен скилл
Структурно скилл состоит из шагов – что и в каком порядке делать – и референсов с правилами, определениями и примерами.

При этом SKILL.md лучше держать небольшим. То, что нужно не при каждом запуске, стоит выносить в отдельные файлы и подключать через ссылки. Особенно это полезно для скиллов с ветвлением: в основном файле остается общая логика, а детали конкретной ветки загружаются только тогда, когда они действительно понадобились.

Как управлять поведением агента
Одна из проблем со скиллами – модель не всегда ведёт себя так, как вы ожидаете, даже если инструкции вроде бы написаны явно. Чтобы реже с этим сталкиваться, Мэтт советует использовать ёмкие устоявшиеся термины. Они сразу задают модели понятный паттерн поведения. В видео он приводит vertical slice; сюда же можно добавить source of truth или red-green-refactor.

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

Сначала стоит сделать критерий завершения шага более чётким. Если этого недостаточно – разделить процесс на несколько скиллов, чтобы следующие шаги не отвлекали модель от текущего. У Мэтта для этого есть отдельные grill-with-docs и to-prd: первый отвечает за подробный сбор контекста, второй – за создание PRD.

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

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

Чтобы проверить эти идеи на практике, можно использовать готовый скилл writing-great-skills. Я пока не пробовал, но будем посмотреть.

#ai

Caveman экономит токены. Но не 65%

Меня периодически спрашивают про скилл Caveman. Он заставляет агента отвечать короче и обещает экономить в среднем 65% output-токенов. Стоит ли его использовать?

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

И вот ребята из JetBrains проверили, сколько Caveman экономит на реальных агентных задачах. Они сравнили Claude Code со скиллом и без него на SkillsBench.

Коротко результат такой:
– экономия output-токенов составила 8,5% против заявленных 65%, а ожидаемая экономия стоимости – около 10%. Это объясняется тем, что в реальных задачах большую часть output составляют код, дифы, вызовы тулов и тексты ошибок – всё то, что Caveman не трогает.
– С точки зрения качества ребята выяснили, что просадки нет.

Поэтому в целом пользоваться можно, но не стоит ожидать бешеной экономии.

#ai

Вот и закончился курс CTO от Стратоплана. По ходу курса я уже делился впечатлениями: раз, два, три.

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

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

В общем, мне понравилось :)

Голосовой ввод и visul explainer – чтобы структурировать мысли

Я давно использую visual explainer не только для презентаций. Один из полезных сценариев - структурировать свои мысли: выделить основные блоки, связи между ними и места, где чего-то не хватает.

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

Здесь хорошо сработала связка голосового ввода в Handy и скилла visual explainer.

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

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

Получившийся текст я отдал агенту с visual explainer и попросил структурировать.

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

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

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

#ai #devfm

Скиллы: как создавать, улучшать и распространять на команды

Недавно выступал на Podlodka и рассказывал про скиллы.

Многие используют скиллы, но не всегда знают, что у них внутри. Поэтому сначала коротко разобрал, как устроены скиллы и как агент с ними работает.

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

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

Когда мы работаем в командах, важно, чтобы у всех был одинаковый опыт применения агентов. Поэтому в конце я затронул тему дистрибуции AI-артефактов: рулов, скиллов, MCP и прочего.

#ai #devfm

Интересные практики работы с агентами

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

Зачастую такой опыт противоречив. Кто-то советует одно, кто-то – почти противоположное. Но это позволяет вдохновиться, попробовать что-то на практике.

В статье разработчик из OpenAI рассказывает, как он с использованием агента выстраивает рабочий процесс.

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

Отдельно автор подсвечивает управление голосом. Я уже рассказывал про Handy: можно быстрее выражать мысль и не тратить время на аккуратные формулировки. Еще прикольный use case – когда агент уже работает, можно прямо голосом быстро накидывать ему уточнения по ходу дела: что проверить, куда посмотреть и что сделать следующим шагом.

Много внимания в статье уделяется памяти. Многие сейчас копают в сторону сохранения контекста агентом, и автор предлагает использовать для этого Obsidian. По сути, это просто папка с файлами, куда агент постепенно заносит важную информацию.

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

Дальше автор переходит к доступу агента к браузеру и компьютеру. Иногда агенту недостаточно файлов и терминала. Ему нужно открыть локальную страницу, проверить UI, посмотреть залогиненный сервис или вообще покликать интерфейс, если нет нормального API.

Сюда же классная фича в Codex – remote control. Агент может продолжать работать на вашей машине, где уже есть окружение, доступы и локальные файлы, а вы можете подключаться к этому процессу с телефона. Запустил задачу, отошел, потом посмотрел прогресс, ответил на вопрос агента или поменял направление.

Еще одна интересная мысль – heartbeats. Это когда агент периодически просыпается и что-то делает без отдельного запроса от пользователя. Например, автор предлагает сценарий, где агент раз в 30 минут проверяет Slack и Gmail, находит сообщения, на которые нужно ответить, собирает контекст и готовит черновики. Сам он ничего не отправляет, но, когда вы возвращаетесь – рыба уже есть.

Меня очень привлекает идея дать агенту доступ к перепискам, накручивать вокруг этого автоматизации, но пока не могу переступить через порог и отдаться полностью 🙂

#ai

В курсе СТО от Стратоплана есть такая штука – База.

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

Особенно откликнулось управление конфликтами. Тема и правда базовая – сталкиваемся с этим постоянно, на любой позиции: отстаиваешь точку зрения, что-то согласовываешь. Где-то выходит хорошо, где-то не очень – со временем нарабатываются свои приёмчики, как делать правильно. И вот самое то, когда теория ложится на уже имеющийся опыт: что раньше делал по наитию, теперь делаешь более осознанно.

По сути всё сводится к нескольким последовательным шагам:
1. Суть проблемы и цель – чётко сформулировать, в чём проблема, что будет, если её не решать, и какого результата хочешь от разговора.
2. Анализ собеседника – понять его поведение, позитивные намерения и скрытые потребности, чтобы говорить на его языке.
3. Формулировка и аргументация – подобрать слова и аргументы, которые показывают важность проблемы с учётом мотивов другой стороны.
4. Пожелание и проверка согласия – выбрать форму подачи (требование / просьба / вопрос / пожелание) и убедиться, что собеседник признаёт проблему и готов её решать.
5. Варианты решения с обоснованием – предложить конкретные выходы и аргументы в их пользу.
6. Закрепление и план Б – зафиксировать договорённости с контрольными точками и заранее продумать действия, если договориться не вышло.

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

Отдельно на занятии разбирали медиацию – это когда ты как руководитель управляешь чужим конфликтом. Но это уже совсем другая история :)

Периодически я рассказываю о классных мероприятиях – и вот одно из них – infra.conf'26 – конференция про создание и эксплуатацию высоконагруженных систем и инфраструктуры.

Мне конечно же интересны темы, связанные с ИИ.

Активное развитие ИИ внесло существенные коррективы: послушаем, с какими новыми вызовами сталкиваются ребята и как с этим справляются.

Мероприятие пройдёт 4 июня. Приходите – будет классно :)

Как подготовить кодовую базу к работе с агентом

Очередная интересная статья от Антропика. На этот раз – о том, как подготовить свою кодовую базу к работе с агентом.

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

Как агенту во всём этом ориентироваться? Индустрия много крутилась вокруг индексирования кода – у того же Cursor есть такой функционал. Но ребята идут в другую сторону.

И говорят: успех – в качественной обвязке, она же harness. В неё входят: CLAUDE.md (он же AGENTS.md), hooks, skills, plugins, поддержка LSP и MCP-серверы.

То есть если подготовить проект, агент сможет хорошо в нём ориентироваться. Дальше – чеклист, как это сделать:

1. Подготовьте CLAUDE.md для своего проекта. Если у вас огромный проект или монорепа – имеет смысл сделать отдельный CLAUDE.md для разных директорий, а в корневом оставить только общую картину мира. Обычно агент сам разбирается в структуре, но если вы знаете, что ваш проект – клубок, в корневом CLAUDE.md стоит сделать навигацию: коротенько, где что смотреть. Частая ошибка – класть в CLAUDE.md информацию, которая нужна не всегда, а под конкретный сценарий. По сути это то, что можно вынести в скилл.

2. Настройте hooks. Можно повесить хуки на подгрузку нужного контекста, на запуск линтеров и форматтеров. И в целом сделайте так, чтобы агент умел гонять проверки и тесты только по той части проекта, над которой идёт работа, – это быстрее и не засоряет контекст. Частая ошибка здесь – пытаться сделать промптом то, что можно было сделать обычной автоматикой. Если можно автоматикой – всегда делайте автоматикой.

3. Для повторяющихся, понятных задач сделайте скиллы. А также подключите к агенту LSP-сервер.

4. Поддерживайте .ignore-файл, чтобы в контекст агента не попадала ненужная информация – например, autogenerated или third-party код.

5. Раз в несколько месяцев пересматривайте CLAUDE.md и подобные артефакты. Это живой документ, который нужно периодически чистить: что-то становится неактуальным, модели становятся умнее, и какая-то информация им уже просто не нужна. Я помню времена, когда все автогенерировали эти артефакты – получалась такая фигня, что лучше уж их отсутствие, чем помойка.

6. У всего этого хозяйства должен быть ответственный – тот, кто поддерживает и следит за актуальностью.

Обратите внимание: пункты 5 и 6 – процессные. И, пожалуй, они самые сложные и самые важные (и скучные). По сути это всё про классические процессы в команде, в которые нужно встроить новые практики. Так что если у вас процессы уже настроены и вы знаете, как это делать – вам будет проще :)

#ai