Please release conventional commit

Помните я писал, что перешел на коммиты агентом? Это дало сразу несколько плюсов

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

Но это было только начало, буквально сразу же стало понятно, что вот тут то и имеет смысл перейти на подход conventional commit, который очень распространен в опенсорсных продуктах.

<type>[optional scope]: <description>

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

ии про него знает, поэтому достаточно указать в AGENTS.md что ему нужно следовать. Плюс мы поставили линтер, который чекает правильность (вообще вокруг этого подхода довольно богатый тулинг, описание и ссылки есть на сайте) conventionalcommits [.] org.

А дальше я начал думать, а как из этого собирать нормальные ченджлоги и делать релизы прямо на гитхабе. Мне всегда казалось что это довольно муторная работа, поэтому мы ее избегали (да и смотреть особо некому). Как же я был не прав, оказывается существует Please Release это github action сделанный гуглом, который автоматично делает релизы на гитхабе базируясь на conventional commit (с большой долей конфигурации под конкретные правила конкретного проекта).

И вот это прямо бомба. Мало того, что он сам идет по версиям и генерирует нормальные релизы, у нас поменялся сам подход к их формированию. Концепт тут следующий, на каждый коммит создается пулреквест с измененной версией и заполненным ченджлогом, куда попадают все изменения с последнего релиза. Если его не мержить, то после очередного коммита он обновляется. Поэтому в любой момент времени для релиза достаточно сделать мерж (тут можно и cd подрубить если надо). Плюс мы повесили все проверки именно на этот пулреквест, а не на коммит, чтобы блокировать релиз если что-то пойдет не так.

Мы буквально за неделю перевели на эту схему основные проекты и кайфуем (жизнь одна)

Telegram | YouTube | AI Клуб

Конференциям старт (Питер с 22 июня)

Буквально на этих выходных я лечу в Питер чтобы встретить старых друзей и поучаствовать в двух конференциях по приглашению Олега Бунина (фаундер онтико). Значит расписание такое:

Saint HighLoad++ 2026, 22–23 июня, Санкт-Петербург

Saint TeamLead Conf 2026, 25–26 июня, Санкт-Петербург

Помимо стандартной программы по тематикам этих конференций, в каждую из них добавлен отдельный стрим аж на треть программы про AI. Затрагиваются темы от внедрения в SDLC до изменений в менеджменте. Я к этому немного приложил и свою руку, так как теперь вхожу в программный комитет AI ответвления в рамках конференций Олега (и впитываю в себя индустриальный так сказать опыт на примере компаний вокруг).

В стрим на SHL входит 13 докладов и 6 воркшопов/мастер-классов. Один из них буду вести я, по сути, это выжимка самого сока из моего курса про агентную разработку, с лайвкодингом.

А вот примеры докладов, которые там планируются:

• State of AI4SDLC: как AI меняет процессы разработки в крупных компаниях (Александр Поломодов Т-банк)
• Уровни зрелости внедрения AI в процессы разработки (Иван Поддубный)
• Давайте просто развернём свою LLM на 1Т параметров»: как выглядит self-hosted AI после первого миллиона запросов (Сергей Нотевский, Битрикс 24)

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

p.s. И бонус от ребят, по промокоду MokevninAIFriends скидка 15%

Telegram | YouTube | AI Клуб

Уря! Выпуск про .net уже доступен для просмотра. И все равно мы там в середине скатились в обсуждение clean code, solid и потом заели все агентами 🙂 https://www.youtube.com/watch?v=7uj6IxxW13w

Альтернативные ссылки: Аудио | vk

Впечатления от конфы и первого выступления

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

На стендах победил формат когда тебя водят по станциям и ты выполняешь разные задания, а потом участвуешь в общем розыгрыше. Довольно прикольно и везде очереди. Я смог пройти один стенд до конца и выиграл бутылку для воды, которую через 10 минут где-то потерял.

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

На этом хайлоаде впервые запустили стрим по ИИ. Народу туда ломилось так много, что пройти внутрь было невозможно, я в итоге ни одного доклада так и не послушал. Да и в целом не то чтобы я их слушал, потому что без остановки общался в кулуарах. Ребята из ПК, старые друзья, знакомые которых не видел лет по 10-15, бывшие студенты хекслета и мои подписчики тоже были тут.

Во второй день конфы в 10 утра был и мой мастер-класс на два часа, который во многом являлся компиляцией из курса "ии для разработчиков". Честно говоря я довольно сильно переживал из-за того, что до сих пор не умею и не совсем понимаю как показывать людям агентный кодинг так чтобы это было интересно, но вроде кто подходил после, говорили что им понравилось. Кстати когда я спросил, сколько людей в аудитории полностью пишет код агентами, руки подняло процентов 20-30%.

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

Собственно, 4-5 июля в Москве будет аж двухдневный воркшоп с утра до вечера, где участники под моим присмотром и с моими рекомендациями будут создавать проект через агентов, прокачивая себя в том как это делать максимально эффективно. Билеты на это добро в открытом доступе с возможностью платить от компании. Если что заходите на огонек.

p.s. придется еще недельку потерпеть, пока все это не закончится 🙂

Telegram | YouTube | AI Клуб

T-shaped снова в моде?

Подняли тут вопрос, о том что мы снова движемся от специализации в T-shaped специалистов. Компании планируют сокращать персонал и одновременно с тем надеятся на усиление текущих специалистов за счет ИИ. В некоторых случаях это потребует замены текущих команд или как минимум отдельных людей, на агентно-ориентированных.

В обиход входит слово tiny teams. По представлениям сбера (это их инициатива), это компактные команды в несколько человек с большой степенью автономности находящиеся внутри ai sdlc, где все процессы изменены, где все знания доступны агентам и так далее. В общем ai native организации, вместо (зачеркни ненужное) бирюзовых, agile и других слов.

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

Сейчас же ИИ действительно позволяет увеличить производительность, что само по себе приводит к укрупнению зон ответственности, но это явление временное. Когда агенты станут такой же обыденностью как персональные компьютеры (представьте разницу между теми у кого они были и у кого их не было в 80 годы), то для увеличения производительности труда снова придется дробить ответственности и брать больше людей.

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

Через 5 лет мы будем оглядываться назад и говорить о том, как все было очевидно, вот это работает, а вот это бы не заработало никогда. Как говорится, знал бы прикуп жил бы в Омске

Telegram | YouTube | AI Клуб

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

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

Telegram | YouTube | AI Клуб

Архитектурные практики

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

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

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

Наверное главное, за чем я слежу и что прорабатываю глубоко это онтология проекта: сущности, свяжи между ними и границы ответственности. Причем речь не идет о том, чтобы попытаться полностью повторить реальный мир, наоборот, идет попытка создать систему, с одной стороны, простой, с другой нужно учесть все необходимые требования от нормализации до поддержки историчности при изменениях (там где это надо). Связь m2m сложнее o2m, это будет проявляться и в запросах и в коде. Можно ли не усложнять? А если мы работаем с иерархией сущностей, надо ли делать одну таблицу с полями сразу для всего, но чтобы каждый тип использовал свое подмножество или нам надо создавать разные таблицы? А как потом их объединять? Денормализация или внешний поиск? И обязательно инварианты. Какие состояния в системе вообще допустимы? Что не должно происходить никогда? Какие связи обязательны, какие опциональны.

Здесь мы имеем дело и со смыслами и с технической имплементацией на уровне хранилища и, в моем случае, ORM. Можно ли в этом случае довериться ии? Обсуждать, спрашивать совет и просить рассказать плюсы и минусы разных вариантов это прямо хорошо, но принимать решение точно надо самому, потому что слишком дорого потом придется платить за неудачно принятые решения. А они точно будут.

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

Между первым (моделями) и вторым (api) собственно и лежит большая часть кода в типовых веб-приложениях. Да ее пишет ИИ, но на базе заложенной архитектуры. Причем она достаточно стандартна. У нас есть слой сервисов, где выполняются бизнес-операции и проверяются инварианты. Рядом находится слой авторизации и события. К этому примыкает инфраструктурный слой с асинхронными джобами, очередями, мидлварами и тому подобным.

Я отдельно выношу обработчики http, dto и валидациями данных запроса и ответа. Все это вообще не надо писать самостоятельно, сейчас, когда легко доступен design-first, лучше пользоваться генераторами типа openapi-generator, которые создают все автоматом на базе openapi. Все что остается, это вписать в нужные места вызовы своих сервисов и правильно сформировать ответ. Даже если обходиться без генерации, ии отлично справится опираясь на существующий код, если он написан нормально.

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

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

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

Что еще упустил?

Telegram | YouTube | AI Клуб

Фух, смог в промежутках между поездками и выступлениями записать видео: youtube.com/watch?v=6w6NstwWb1Y Я знаю вы уже соскучились 🙂 Забирайте и наслаждайтесь

Альтернативные ссылки: Аудио | vk

Отставить гусары! Я тестирую кнопку "direct messages" (чтобы туда писали по коммерческим предложениям). В телеге вообще столько всего надобавляли, надо посмотреть и потыкать (а вы блин палите и страшно что то нажимать)