Junior AI PM

#иное
Комьюнити-эфир 12 августа. Живая дискуссия про AI coding

Без докладов и презентаций -> просто собираемся и обсуждаем, как сейчас реально работаем с AI-разработкой

🎙 Максим Ключников -> техлид и автор канала Этихлид, много экспериментирует с AI в разработке и инженерных процессах
https://t.me/etechlead

🎙 Денис Киселёв -> AI SOLO founder, автор канала про AI-разработку, агентов и инженерные инструменты
https://t.me/deksden_notes

🎙 Артем Летюшев -> Tech PM в Twinby и гильдмастер AI Engineers Guild
https://t.me/junior_pm

Поговорим про свежие модели и tokens per task, спеки, архитектуру, ADR и AI SDLC. Дальше как пойдёт

Ссылка на событие https://luma.com/lwm1coqr

📍 Google Meet: https://meet.google.com/bzz-aeoo-vio
🗓 12 августа, среда
🕖 19:00–20:00 мск

#кейс_стади
Разбор с СEO, вайбкодом и Едрит

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

Первое
Показать свою ветку CTO и поставить задачу ее опровергнуть. И не с позиции "я сделал лучше вас", а "вот решение, которое по моей текущей оценке закрывает то же самое за две недели 1 человеком". Можно остановить менее важные задачи, подключить сильных инженеров и прогнать тот же набор проверок. Если решение развалится -> отлично, CEO получит конкретные причины, чего он не понимал. Если после недели допила оно сравнимо -> вопрос становится очень неприятным

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

Третье
С этого момента подобные решения принимаются иначе. Есть жесткое внешнее ограничение -> CTO приносит несколько вариантов со сроками, рисками и стоимостью: быстро закрыть потребность, сделать нормально, строить платформу. Какой риск купить -> решает CEO. Архитектура не существует отдельно от экономики, особенно когда на другой стороне контракт и инвестиционные деньги

Четвертое
CTO должен принести отчет, причем не нейрослоп HTML-бандл от клодкода, а понятные 2 странички с хронологией проекта, где были проблемы, что для них делали и почему не уложились в сроки. Отдельно информация как им управляли и контролировали. По отчету станет прозрачно осознавал ли техдир важность проекта и делает ли менеджмент в компании полезную нагрузку

Отдельно меня удивило, сколько людей вообще начали обсуждать, правильно ли CEO втихаря вайбкодит и должен ли он лезть в работу разработчиков. Это взгляд из своей профессиональной колокольни. В условиях кейса CEO уже вайбкодит, уже достаточно погружен и получил новую информацию о собственной компании. Спорить с условиями задачи вместо принятия решения -> уходить от самой задачи. Тем более я постоянно общаюсь с C-level продуктовых компаний и это уже совсем не экзотика, когда даже фаундер собирает себе что-то

И дальше самое важное -> реакция CTO. Ошибка в архитектуре допустима. Сорванный срок тоже иногда допустим. Недопустимо, когда критичный для бизнеса срок сорван, последствия воспринимаются как данность, альтернативное решение никто не хочет проверять, а объяснение заканчивается на вам не понять разработку. Если CTO сам разбирает ситуацию, показывает где ошибка CEO и меняет систему -> доверие можно восстановить. Если защищает статус-кво -> я бы ставил CTO испытательный срок

#мнение
Сейчас Codex лучше Claude Code

Здравствуй, неподгоревший читатель. Этот пост про то что сейчас рабочая лошадка из фронтир моделей. Также ответ на Пашино https://t.me/evilfreelancer/1846

Если нужен один дефолт -> GPT-5.6 Terra в Codex Pro с medium usege без Fast mode. Мое глубокое субъективное имхо на 3 августа 2026. По кредитной шкале при одинаковом токенном профиле Sol : Terra : Luna = 25 : 10 : 1: Terra жжет в 2,5 раза меньше Sol. При этом на SWE-Bench Pro (если он для вас аргумент) у нее 63,4% против 64,6% -> отдали 1,2 п.п. качества, получили 2,5x емкости лимита

Ближайший аналог у Claude -> Sonnet 5, но его стоит доставать под мутный скоуп и широкий рефакторинг. А также по личным расчетам через
ccusage стоимость задачи $0.50–1.5+ (с ретраями) и порядка 2% лимита на тарифе в $100 против $1–3 у Sonnet 5

Арифметика дальше проверок была на отдельном аккаунте с $20 подписками:

- На Plus фикс в 400 строк через Sol Medium на 5000 строковом проекте на расте съел 15% пятичасового лимита;
- Luna Extra High за 25 минут написала 2500 строк с тестами за 5% недели, следующие этапы жрали по 2–6%, а ревью Sol и исправление найденного добра -> еще 4% + 5%
- Сопоставимый блок на Opus 5 High съел 35% пятичасового и 4–5% недельного лимита.

В интернете примерно тоже самое говорят. Там таже Terra Medium уничтожила всю неделю Plus за шесть часов, пока пользователь Pro гонял Sol Extra High по 6–8 часов в день больше недели без упора в кап. Главный множитель -> тариф, контекст и число переделок. Luna дешевая, пока после нее не приходится звать взрослую модель с веником и как тут жалуются

Еще сильнее модели влияет агентная оболочка. Некий Composio прогнал один Kimi K3 через три оболочки на 28 одинаковых задачах: успехи почти равны — 22/28 у Kimi Code, 21/28 у Hermes, 20/28 у Claude Code; медиана расхода -> 61k, 67k и 340k токенов, время -> 297, 179 и 348 секунд. Claude Code сжег в 5,6 раза больше токенов ради почти того же результата. В следующем тесте Codex против Claude Code на 26 задачах Claude взял 19/26, Codex 17/26, но тратил 347 против 236 секунд -> примерно 7,6 против 10 успешных задач в час. Claude точнее на 7,7 п.п., Codex производительнее на 32%. Серия твитов отсюда

При этом Claude Max способен быть безумно выгодным: один жосткий пользователь прогнал через Claude Code 21,5 млрд токенов, заплатив около $1000 за подписки https://x.com/wecko_ai/status/2083783073800585326. Но миллиарды токенов не равны миллиардам пользы: длинная история, повторные чтения, кеш и сабагенты прекрасно превращают Max в тыкву за одну жирную сессию

И лайфхак: обычный чат с Sol Extra High и Codex расходуют разные пулы, поэтому подключаем GitHub, включая разрешенный приватный репозиторий, делаем ресерч, архитектуру и прототип в чате, а готовый план отправляем Terra в Codex.

P.S. Sol Extra High под пиво -> Terra в шахту, Fable 5/gpt 5.6 Sol бесполезные релизы. От @vozzynebot подсказали https://cursor.com/evals, но тут опять все вопрос веры и личной практики

#кейс_стади
Задача на подумать для менеджера

Ты фаундер и CEO сервиса доставки продуктов Едрит. Компании пять лет. За последние полтора года разработка выросла с 4 до 51 человек, ФОТ апнулся почти 10 раз, а средний срок заметной фичи с 2 недель до 2 месяцев (точно вы не знаете). Новые разработчики, тимлиды и архитекторы появляются регулярно. Больше деливери и качественнее почему-то не становится. Чувство развода скоро доконает

Последние девять месяцев ты много вайбкодишь: получили доступ к репозиторию, разобрался в монолите и уже довел до прода шесть небольших изменений, там сям - фильтры в админке, вебхуки, ретраи и внутренние инструменты. Код после вас ревьюили и местами переделывали, но ничего ужасного не находили. Разработчиком вы себя не считаете, но outbox, идемпотентность и контракт API понимаете не только по объяснениям NotebookLM

Ты договорился о запуске с крупной сетью супермаркетов Дастархан. До 1 сентября нужно подключить 120 магазинов. От запуска зависит годовой контракт и следующий транш инвестиций

Сеть должна присылать в Едрит JSON с остатками и ценами, а сервис отправлять ей заказы и изменения статусов. Нужны по сути 4-5 ручек, подпись запросов, маппинг SKU, ретраи и журнал ошибок. В монолите уже есть две похожие интеграции, аутбокс и воркеры можно пошарить

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

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

Код ты никому не показываешь. Его не ревьюили разработчики, не проверяли QA и безопасники. Только твой верный Codex. Ты можешь не знать части требований, неправильно понимать нагрузку или пропустить редкий сценарий, который всплывет только на проде. Поэтому ждешь результат команды

Команда выпускает интеграцию через пять месяцев. Сеть переносит запуск, компания теряет месяц оборота, инвесторам приходится объяснять задержку. После релиза ты сравниваешь код. Команда добавила отдельный сервис, 14 таблиц, 3 новых топика, собственный формат событий и DSL для маппинга. Получилось около +9 тысяч строк. Из универсальных возможностей пока используется только одна интеграция

В своей ветке 1 300 строк вместе с тестами. Она использует старый outbox и существующий интерфейс адаптеров. JSON на выходе одинаковый, основные сценарии тоже. Более того, в версии команды вы находите два бага, которые в вашей закрыты тестами

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

У тебя натурально горит **па. Через два дня квартальная встреча с CTO и тимлидами. Твои действия?

#рецепт
В чём настоящая ценность Agent Skills. Часть 2

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

Главный подвох: настоящий прикол не только в SKILL.md, а в связке Skill + Agent Harness. Harness - это рантайм вокруг модели: поиск skills, выбор нужного, загрузка инструкций, запуск tools/MCP/shell, права, traces, approvals. Хороший инженерный разбор есть у Addy Osmani: https://addyosmani.com/blog/agent-harness-engineering/

1) Progressive disclosure - причина почему скиллы масштабируются

Агент не должен держать в контексте всю корпоративную библиотеку знаний. Сначала он видит только name + description, потом при выборе грузит SKILL.md, а уже после этого читает references/, assets/, examples/ или исполняет scripts/

Именно поэтому skill лучше гигантского AGENTS.md на 3000 строк. AGENTS.md - always-on фон, skill - on-demand способность. У Codex это описано тут: https://developers.openai.com/codex/skills, у Claude Code тут: https://code.claude.com/docs/en/skills (с CC конечно есть нюансы)

Практический совет: в SKILL.md оставляй короткую процедуру, а длинные политики, API-доки, JQL-справки, шаблоны отчетов и примеры выноси в references/assets/examples. Если SKILL.md раздулся в трактат, вероятность его работы крайне низка

2) description - главный триггер, а не аннотация для красоты

Частая ошибка: красивое тело скилла и бесполезный description. Агент выбирает skill именно по description, поэтому "Helps with code" - мусор. Это как задача в Jira с названием "Сделать нормально"

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

Плохой пример: Helps with project management

Лучше: Checks Jira sprint health, finds blocked issues, stale tasks, missing owners and release risks. Use before daily status update or weekly project report. Do not use for backlog prioritization

Для проектирования смотри skill-creator от Anthropic: https://github.com/anthropics/skills/blob/main/skills/skill-creator/SKILL.md

3) Anti-rationalization надо писать прямо в инструкции

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

Примеры:
- - -
- если есть diff, сначала inspect, потом summary, потом plan
- если действие меняет внешнюю систему, сначала dry-run
- если есть write/delete/update, нужен explicit approval
- если нет данных, верни missing context, а не додумывай
- если scanner не запускался, не пиши что проверка пройдена
- - -

В twinby я бы такие штуки паковал в jira-daily-radar, spec-quality-checker, release-readiness, browser-manual-test и confluence-sync. Не "агент, расскажи статус", а процедура: откуда читать, что считать риском, какой формат отчета, где нужен человек

4) Skill надо тестировать не только на результат, но и на срабатывание

Минимальный набор:
- explicit activation test: вызвался руками
- implicit activation test: вызвался по естественному запросу
- negative test: не вызвался там, где не должен
- golden samples: вход -> ожидаемый выход
- unit tests для scripts/
- trace review: видно какие шаги реально прошли
- with/without skill: есть ли прирост качества, времени или стабильности

По evals полезны OpenAI материалы: https://developers.openai.com/blog/eval-skills и разбор Phil Schmid: https://www.philschmid.de/testing-skills

Хороший skill скучный: он умеет только 1 штуку делать, явно триггерится, явно проверяет, явно падает и явно просит апрув. Всё остальное обычно демка для LinkedIn/X/чата ваших фанатов в телеграм

#рецепт
В чём настоящая ценность Agent Skills. Часть 1

Здравствуй, дорогой читатель. Скиллы до сих почти никто не понял. Я уже писал вводный пост про скиллы и почему менеджерам стоит смотреть на них как на святой грааль: https://t.me/junior_pm/422

После доклада про Agentic Harness хочу докрутить мысль инженернее. Скилл - это не "промпт в папочке", а слой поведения агента. MCP, API и CLI дают агенту руки, а skill объясняет, когда этими руками не стоит случайно уронить запросом БД, переписать ТЗ или сделать ревью уровня "в целом норм"

1) Agent Skill - это workflow package

Если давать адекватное определение, скилл -> самодостаточный пакет процедурного знания, который агент динамически загружает для решения задачи

Если разложить по-честному, то prompt - это разовая инструкция, script - детерминированный код, MCP tool - доступ к действию, subagent - отдельный worker, AGENTS.md/rules - фоновые правила проекта. Skill находится между всем этим: он говорит агенту, когда применять процесс, как идти по шагам, какие артефакты читать, какие проверки делать и где остановиться за апрувом

Реализуется в формате папка с SKILL.md (YAML + Markdown) +
опциональные файлы. Skill.md = metadata + instructions + optional references + usage policy. Открытый формат лежит тут: https://github.com/agentskills/agentskills, реальные примеры от Anthropic тут: https://github.com/anthropics/skills, у OpenAI Codex механика описана тут: https://developers.openai.com/codex/skills

2) Skill хорошо ложится на BPMN-мышление процессников

description - триггер процесса, тело SKILL.md - шаги, When to use / When not - гейты, scripts/ - подпроцессы, references/ - политики и справка, assets/ - шаблоны, examples/ - эталонные входы/выходы, allowed-tools - права. Те это уже не markdown с советами, а почти исполняемая процедура

Менеджерский кайф тут простой: можно перестать пересказывать агенту как у нас принято и начать версионировать это в Git. Не Тимлид Петя знает как делать ревью, а code-review/SKILL.md, пошаренный на всех и прописанный хуком всем перед отправкой MRa

3) Скиллы органично зарождаются и эволюционируют:

0. Замечаешь что пару раз в неделю делаешь одно и то же. Ctrl + c - Ctrl + v инструкция аля в Claude Code
1. Описываешь повторяющееся действие и структурируешь в промпт
2. Переносишь промпт в формат agent skills, чисто враппер
3. Добавляешь в скилл воркфлоу с гейтами что, после чего и как проверять
4. Объясняешь скилл как писать скрипты для решения задачи в моменте
5. Делаешь готовые шаблоны и скрипты и прикладываешь их в скилл, чтобы он их вызывал
6. Выносишь весь дактайпинг, шейрд и прочее из скриптов в общие ассеты, энвы и конфиги
7. Оборачиваешь скрипты в MCP или CLI
7. Переписываешь проект на чистовой бойлерплейт и правильную структуру
8. Распространяешь

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

Практический вывод

Первый skill стоит делать не про агенты, инстаграм инфоцыганщину про Agent OS/Second brain/AI native team, а про маленькую повторяемую проверку: backlog hygiene, PR review precheck, release readiness, spec quality checker, repo safety scan. Чем уже граница, тем проще проверить качество и тем меньше шанс собрать очередной карго-культ в красивой папке, нужный 1 человеку

#мнение
Чем любят грешить менеджеры

Здравствуй, дорогой читатель. Это пост про фундаментальное правило управления изменениями и внедрениями, которое часто игнорируют руководители

В целом проджекты/коучи/продакты и любый IT-менеджеры достаточно часто жалуются что внедрения буксуют, команды сопротивляются чему-то правильному и очевидно нужному. Меня давно раздражает ситуация, когда человек сходил на курс, посмотрел вебинар, словил инсайт, а затем через день несёт его как новый порядок жизни: теперь у нас OKR, переходим на Kanban, ИИ агент для логов и вообще всем курсор! И классика провести через ретро под соусом "tech excellence/улучшения инструментов/команда не знала о таком"

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

Первые пару лет бытности проджектом почти все мои внедрения и улучшения проваливались. Спасибо большое Жене из Яндекс Денег с позицией "ну ты сам научись дашборды делать в повербиай, а потом команде затирай как правильнее". Отсюда выросло огромное количество разных инициатив, которые я предварительно тестировал на себе. Вот несколько примеров

1) Когда я хотел больше прозрачности и нормальной гигиены задач, я сначала несколько месяцев кошмарил самого себя в Notion: цели, инициативы, месячные планы, задачи, статусы, прогресс, декомпозиция и связи задач
2) С OKR было так же: несколько лет связки годовые->квартальные->месячные цели, с полным трекингом и всеми OKR ритуалами
3) С ИИ безопасностью я несколько раз жестко косячил, собрал ai-repo-safety-skill и внедрял сканеры скиллов
4) С быстрым фронтом через ИИ я пошёл в OpenDesign, сделал несколько прототипов, а потом на внутреннем демо Twinby с автономными целями /goal и админкой на Angular знатно облажался. Полезная лужа, после которой я перестал лезть к разработчикам с советами в зоне, где сам ещё не прожил достаточно боли
5) С Text2SQL история такая же. Можно красиво сказать “давайте сделаем агента, чтобы менеджеры и аналитики сами спрашивали базу”, но потом приходят вопросы: как актуализировать метаданные, как объяснить агенту бизнесовый смысл полей, как ограничить доступы, как понять что ответ не бред и тп. Я поковырял VannaAI (царствие ему), сделал семантическую разметку и CLI на Rust. На скрине тот самый "txttsql" : агентик RAG, файловый семантический слой и защищённый read only SQL исполнитель для аналитики. Только после этого у меня появился сильный голос по таким вопросам

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

Я уже писал про то что хороший менеджер должен хотя бы один раз зайти в чужую реальность ногами: хочешь понять разработчиков, сделай маленькую инженерную задачу; хочешь понять аналитиков, сам достань ответ из данных. Я поднимал вопрос вопрос нужны ли менеджеры, аналогичный тому что пишет Аня https://t.me/proproduct/1585 и поднимал вопрос какие менеджеры нужны https://t.me/junior_pm/464. Но тут про другое

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

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

Всем привет!

Напоминаю, в рамках AI Engineers Guild x Bereke Bank делаем сегодня в 18:30 по Алматы состоится Agentic Harness Meetup: что под капотом.

💻 Онлайн: если не успели зарегистрироваться, присоединяйтесь по ссылке
📍 Офлайн: если вы проходили офлайн-регистрацию, ждём вас, адрес вы знаете https://luma.com/48q2s0f5

Сегодня обсудим:
▪️ Павел Королев -> как кастомизировать AI-агентов под реальные инженерные задачи и выстраивать эффективные workflow.
▪️ Родион Мостовой -> как устроены контекстный движок и AI-агент CodeAlive, а также подходы к code exploration и оценке моделей.
▪️ Артем Летюшев -> почему agent skills это не просто промпты, а важный слой для создания гибких и масштабируемых AI-систем.

До встречи вечером! 😉