Организованное программирование | Кирилл Мокевнин

Выпуск в сети! В этот раз я лайвкожу с агентами. Пока закрывал тикеты фиганул пару пулреквестов в mantine, которые уже приняли https://youtu.be/Eplxom-e1C4?is=3HME8iWRITMJxhe2

Зачем ускорять разработку? Просто через раз вижу этот вопрос, во всех постах про агентов и новую эру автоматического кодинга. Переубедить конечно никого не получится, но написать надо, чтобы получилось структурировано. Погнали. Нет такого количества задач Если вы поговорите не с менеджерами, а владельцами бизнесов, то окажется, что количество идей у них такое, что за всю жизнь не сделать. То что из этого не всегда доходит до низов, проблема размера и процессов, которые тоже пытаются решать, поэтому так много разговоров про sdd и аналогичные истории. Если разработка стала в два раза дешевле/быстрее, становятся экономически оправданными задачи, которые раньше вообще не попадали в backlog. Это никому не нужно В конкурентном мире невозможно сделать продукт до конца и сидеть сложа руки. А конкуренция приводит еще к тому, что кто первый встал, того и тапки. Сегодня вы на высоте, завтра ваш бизнес угрохали потому что вы не успели адаптироваться. Ну если вы работаете у монополиста/госа/стратегического игрока, то можете игнорировать этот пункт 🙂 Фичи не принесут деньги Может принесут, а может и нет, это невозможно обобщать не зная конкретных обстоятельства конкретных ситуаций. Например мы годами не могли сделать b2b кабинет таким как хотели наши клиенты, потому что у нас никогда не хватало ресурсов на эту часть. С помощью агентов мы это сделали и смогли получить хорошие контракты, которые от нас раньше уплывали. Ускорение разработки меняет не только скорость выполнения уже выбранных задач, но и сам набор задач, которые становится рационально делать. Покажите как это сократило фот? По правде говоря у многих сократило. Но последовательность другая. Последние годы у многих были сокращения по экономическим причинам, а потом заморозка найма при одновременном росте производительности за счет ИИ. Поэтому ии больше повлиял не на сокращение как таковое, а на отсутствие найма Покажите как это увеличило прибыль? В экономике есть только два способа растить маржинальность: рост производительности и повышение цены. Когда то массовое внедрение компьютеров и экселя привело к такому же эффекту. Итого Ускорение разработки само по себе не цель. Реальная цель это снизить стоимость изменения продукта, поэтому помимо разработки одновременно ускоряется еще много всего, но об том просто говорят в других местах, куда разработчики не ходят, поэтому у них часто складывается такое одностороннее представление о происходящем Telegram | YouTube | AI Клуб

Вперед к монорепам Практика показывает, что эффективнее всего с агентами работать тогда, когда весь контекст есть по рукой и можно просто погрепать, причем речь идет не про один какой-то конкретный сервис/проект, а когда все репозитории проекта, лежат в одной папке, а возможно даже в одном репозитории. В таком случае и дока общая (это важно для спек) и все просвечивается насквозь и пулреквесты можно сразу бахнуть везде. Но многое зависит от размеров. Понятно что вообще все сервисы в одно место может быть перебором, скорее это правило применимо к командам и тому что у них там внутри. Но это не мешает теоретически заливать и чужие сервисы рядышком, чтобы по ним можно было погрепать если это имеет смысл. Объединения можно добиться двумя способами. Один это тупо все свалить в одну репу (что не заставляет нас собирать все как единый проект) и работать всегда из корня. Более того, в некоторых языках системы сборки поддерживают прямо такой режим работы, поэтому в какой-нибудь Java, получается двойной выигрыш. Второй, это сделать единую высокоуровневую репу, в которой хранятся спеки и любые другие общие доки, а дальше с помощью настроенных команд все клонируется внутрь по подпапочкам. Делать это кстати не обязательно ручками/скриптами, для этого уже есть готовая утилита ghorg. Ну а дальше, эта репа постепенно обрастает артефактами: доками и скриптами, которые помогают работать на всем объеме репозиториев. Если еще на это насадить openspec так вообще красота. Кстати у последнего появилась такая штука как Store, это как раз подобный репозиторий, но без необходимости все складывать внутрь одной папки. Там идея такая что репа со спеками (Store) кладется в домашнюю директорию, а в репах проекта на нее дается ссылка. Дальше команды openspec все это знают учитывают и работают со Store отдельно. И расскажу про наш кейс. На хекслете много практик и проектов. Каждая сущность это своя репа (потому что свой релизный цикл) и даже каждый курс (тексты) это тоже своя репа. Суммарно это под 8000 репозиторев. Плюс для них есть набор базовых образов и разных проверочных скриптов. Так вот у нас всегда существовал подход, когда есть одна базовая репа с общими штуками и туда с помощью make clone добавлялись все эти репы. Но правилось это ручками. А сейчас мало того, что ии может менять все пачками (например связано обновить версию react в курсе + практиках + проекте), так мы еще добавили туда редактор (на него завязана часть логики) и сотни наших реп с гитхаба, куда мы выкладываем разного рода библиотеки и базы данных для курсов. То есть теперь в одном месте практически 100 процентный контекст (осталось еще mcp на хекслете завести, чтобы еще фидбек по курсам и вопросы в ассистента связать). У нас бывают дни, когда мы можем за раз поправить 500-1000 реп.

Выпуск про spec driven development с Иваном Поддубным на практике https://youtu.be/oDxODi3X2Mg?is=SVMdRrndaqgbxmIe

Открытие дня. Все же знают dependabot, который обновляет зависимости всего и вся на гитхабе? Причем речь не только про пакетные менеджеры всех языков, но и например github actions и даже версии образов в Dockerfile. Так вот есть такое же решение, не привязанное к вендору. Небольшая предыстория. Помимо гитхаба у нас есть свой гитлаб с большим количеством реп, в котором так же находится инфраструктура запуска практик Хекслета. В нее входит репа с кучей Dockerfile под разные экосистемы, которые мы используем как базовые образы для практик запускающихся в браузере. В этой репе есть просто все что только можно себе представить: версии образов, версии дев тулов, версии зависимостей, причем часто указываемые напрямую в Dockerfile. Обновлять все это добро раньше было отдельным приключением. С иишкой стало проще, но один фиг это процедура, которой надо заниматься. А на днях делая очередное обновление, я подумал какого хрена, по-любому должно же что-то быть. Попросил клод найти и он нашел. Оказалось что есть такая штука как Rennovate, которая очень похожа на dependabot, но работает еще круче. Мало того, что она может обновлять все версии в стандартных случаях, так эта фигня умеет обновлять версии, которые заданы числами в разных местах за счет спец разметки:

# renovate: datasource=maven packageName=org.apache.maven:maven
ARG MAVEN_VERSION=4.0.0-rc-6
# renovate: datasource=java-version packageName=java-jdk
ARG JAVA_VERSION=25

Все это расставил сам клод и написал мне такую таску:

make deps-check 
images/base/Dockerfile            setuptools       83.0.0  -> 84.0.0
images/java-base/Dockerfile       java-jdk       25      -> 25.0.4+7.0.LTS
images/multi-language/Dockerfile  java-jdk   25      -> 25.0.4+7.0.LTS

Ну и все это добро отлично подключается к ci и шлет пулреквесты с обновками. Пользуйтесь

Как я провел лето Ну все, прилетел, два с половиной месяца в рф пролетели как один день. Документы привел в порядок, кого надо прописал, кому надо сделал паспорт, оформил гражданство мелкому. В процессе оформление многодетства, но это уже можно закончить онлайн. Выступил на 6 конфах, провел пару мастерклассов и один двухдневный воркшоп, даже был фасилитатором на одном мероприятии, где разбирался вопрос внедрения ии в бигтехах. Развиртуализировался с кучей ребят включая моих читателей и познакомился с еще большим числом новых интересных людей. Так как прилетел с сыном, то его надо было постоянно где-то оставлять. Поэтому он у меня проводил все время в дневных лагерях. Начиная от батутов и роликов до плавания. Подтянул язык, офигел от тополей, метро и количества разного рода насекомых. У нас такого нет как будто (в майами комары почти отсутствуют например). На всех мероприятиях были кальяны, плюс народ любит встречаться в таких местах. Я так то не курю, но накальянился на всю оставшуюся жизнь. В целом так встречи проходят интереснее 🙂 Наконец-то вхожу в нормальный ритм, со следующей недели уже пойдут регулярные выпуски и посты. Хочу попробовать немного заработать и со временем включу интеграции и немного рекламных постов. Обещаю что спамить не буду, но мне интересно посмотреть на то, как быть по ту сторону экрана. Как рекламодатель я работаю уже давно (от лица Хекслета), а вот как блогер только учусь. Значит что я заметил. Платить и проходить в метро по лицу, это конечно мощь, прямо сильная штука, я даже когда вернулся, почувствовал что уже привык и не хватает. Из негативного, цены выросли сильнее чем выросли в штатах. Местами так дорого, что аж жуть. С другой стороны, Москва и Питер как всегда красиво и масштабно. В сокольниках забахали такой парк, мама мия. Чтобы вы понимали, в штатах нет таких парков (как и культуры парков в нашем понимании). В целом было ощущение, что очень улучшилась логистика. Как будто лучше распределяются потоки + сильно выросла транспортная сеть. Я ни разу не торчал в жутких столпотворениях, как это было лет 15 назад на выхино (кто помнит тот знает). Взять те же кассы в метро, которые тупо закрыты. Да, китайских машин в штатах нет, их сюда не пускают. Я пару лет назад в Казахстане видел все это, но до сих пор не сильно разбираюсь в моделях и названиях, хотя покатался почти на всем что было. Уровень машин впечатляет. Кстати моей тачки вообще в рф нет как будто, да и люди не знают про существование lexus tx (трехрядный), так как он появился в 2024 году. Примерно считали, что в штатах в три раза дешевле + лизинг. Так что если кто-то едет на x5 в штатах и в рф это сильно разные ценовые категории и уровень дохода. Пару раз летал в питер победой. Чот я столько слышал негатива, а оказалось очень кайфово. Я еще купил спец рюкзак для вещей и ноутбука и летел на легке (первый раз в жизни). Офигел от кайфа, когда просто берешь рюкзак и идешь куда хочешь не ожидая чемоданов и колясок с самокатами. Вообще все мои путешествия в жизни, это дети, поэтому я испытал много новых ощущений 🙂 И еще, стало реально заметно потепление. В Ульяновске тусил на даче, а там тебе и цикады и геконы (!!!). Даже дожди становятся тропическими. Вроде есть кондиционеры, но до штатовского +16 в помещении еще далеко 🙂 Все боятся что их продует. За это время ни разу не купался. После чистого океана, любой пресный водоем кажется живым. Тупо страшно туда заходить. Сын постоянно спрашивал про аллигаторов, настолько привык что в обычные водоемы соваться нельзя. Аллигаторов то нет, но комары по страшнее будут. Ну и любимый вопрос, как граница? Единственное место где мне задали пару вопросов, это в аэропорту майами по прилету. Кстати, вы знаете что у меня есть личная инста (для orgprog тоже есть)? Единственное место где не про работу, а про жизнь https://www.instagram.com/mokevnin

Программирование с явно выделенным состоянием Одна из моих любимых тем, про которую не устаю говорить. В модели данных часто бывает ситуация, когда состояние выражено не прямым образом, а косвенно. Буквально вчера я реализовывал кастомные тарифы под конкретных пользователей. Отличие такого тарифа от обычного сводится к тому, заполнено ли поле user_id в тарифе или нет. Если не заполнено, то значит это общий тариф, если заполнено, значит под конкретного пользователя и другие его не могут видеть. Это вполне рабочая схема и она встречается повсеместно, особенно в связке с датами типа deleted_at, но она обладает одним очень важным недостатком. Понимание того, что эта запись находится в особом состояние вычисляется через косвенный признак или, что хуже, через набор признаков. Об этом надо думать и каждый раз вспоминать и выуживать эту информацию. Сейчас, в эру агентного программирования, это стало еще важнее. Агент может догадаться до правила, но ему нужно на это время и отдельный анализ. Можно конечно написать об этом в правилах, но зачем, когда можно просто поправить модель данных? Все что требуется, это введение текстового поля со статусом, которое явным образом скажет о происходящем с этой записью. В общем не полагайтесь на то как заполнены поля, вводите нужные статусы, которые явно будут говорить о том что происходит. Заодно это дает более удобную аналитику и выборки Telegram | YouTube | AI Клуб

Новый выпуск подкаста про Agile, Scrum и ИИ трансформацию уже доступен https://youtu.be/FhthTCoR3uw?is=X5GCG6XrrFds65ws В этот раз с Асхатом Уразбаевым мы вспоминаем как это было и куда пришло. Взлеты и падения, культы карго и трансформации в компаниях. А что в конце? Дейли не нужен, вот такие пироги

Можно разок похохмить? :)

Иммутабельная денормализация Изучение баз данных всегда сопровождается понятием нормализации, а конкретно первыми тремя формами, которые задают нам ограничения, помогающие правильно разложить все по таблицам. И это действительно база, без которой нормально работать не получится. Но есть, как обычно, нюансы. В реальных проектах выясняется, что нормализованные данные сложно соединять и выбирать. При глубоком уровне зависимостей, чтобы добраться до внешней сущности, нужно либо соединять 5 таблиц, либо делать 5 запросов. Пример из Хекслета. У нас есть программа обучения, которая состоит из модулей, в которые входят темы которые состоят из уроков, которые состоят из юнитов (теория, практика, тесты). На это все накручено много логики по прогрессу и отображению. В такой структуре, вопросы типа "какой урок следующий по порядку?" заставляют поломать голову. В таких ситуациях мы начинаем денормализацию данных. В основном она сводится к добавлению внешних ключей на косвенно связанные сущности, например, урок связан с программой обучения через модуль. Здесь мы добавляем ключ на программу прямо из урока, что позволяет выполнять запросы на уроки одной программы без необходимости соединять таблицы. В принципе это довольно базовая концепция с которой знакомы большинство разработчиков, но дальше начинается самое интересное. Как только мы делаем денормализацию, то сразу упираемся в необходимость синхронизировать данные. Если поменялось в одном месте, надо не забыть поменять и в другом месте. Это цена денормализации и ее надо платить. > Кстати есть такой концепт как синхронизирующие триггеры, которые вешают только для того, чтобы синхронизировать подобные данные. Когда-то я его активно использовал, но сейчас не стал бы Но есть и альтернативный подход, который иногда работает лучше. Вместо того, чтобы синхронизировать денормализованные данные, мы можем пересмотреть саму систему и сделать данные иммутабельными (неизменяемыми), чтобы их не нужно было синхронизировать. Например в том же примере с уроками, мы сделали так, что урок принадлежит одной программе и не может перемещаться между программами. А это значит, что мы можем записать в урок все внешние ключи, которые никогда не поменяются. В таком случае цена денормализации это занятое место ключами, чем обычно можно пренебречь. А что касается бизнес-логики? Да, такой подход работает не всегда, но, как показала практика, его можно использовать намного чаще чем кажется. Например в нашем случае это даже наоборот хорошо, иначе получается ситуация, что при переносе урока нужно переносить прогресс, что значительно усложняет логику и создает странное впечатление, когда в середине программы вдруг появляются пройденные уроки. При этом сама процедура довольно редкая, поэтому если кому-то придется пройти два раза один и тот же урок (перенос в нашем случае это копирование), то ничего страшного не случается. Но есть места где без синхронизации данных не обойтись никак. В основном это касается статусов, они могут меняться и за ними нужно следить. Telegram | YouTube | AI Клуб

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

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

Архитектурные практики Прошло чуть больше полугода, как я перестал писать код руками, за редкими исключениями. Но несмотря на это, я просматриваю его глазами. Где-то внимательнее, где то по диагонали, в зависимости от степени влияния на структуру кода и логику. И каждый раз спрашиваю себя, а какими принципами я руководствуюсь? Пишу этот пост, чтобы порефлексировать с одной стороны и заложить на будущее темы, которые буду разбирать. ИИ это хорошо для кодинга, но инженерия никуда не девается. Все происходит над подсознательном уровне, я работаю в давно знакомом мне проекте и хотя бы примерно понимаю что и где происходит, задачи которые я делаю тоже понятны, все таки и в разработке давно и сам проект не гугл. Но он достаточно большой и сложный, чтобы можно было просто забить на архитектуру и делать как придется. Наверное главное, за чем я слежу и что прорабатываю глубоко это онтология проекта: сущности, свяжи между ними и границы ответственности. Причем речь не идет о том, чтобы попытаться полностью повторить реальный мир, наоборот, идет попытка создать систему, с одной стороны, простой, с другой нужно учесть все необходимые требования от нормализации до поддержки историчности при изменениях (там где это надо). Связь m2m сложнее o2m, это будет проявляться и в запросах и в коде. Можно ли не усложнять? А если мы работаем с иерархией сущностей, надо ли делать одну таблицу с полями сразу для всего, но чтобы каждый тип использовал свое подмножество или нам надо создавать разные таблицы? А как потом их объединять? Денормализация или внешний поиск? И обязательно инварианты. Какие состояния в системе вообще допустимы? Что не должно происходить никогда? Какие связи обязательны, какие опциональны. Здесь мы имеем дело и со смыслами и с технической имплементацией на уровне хранилища и, в моем случае, ORM. Можно ли в этом случае довериться ии? Обсуждать, спрашивать совет и просить рассказать плюсы и минусы разных вариантов это прямо хорошо, но принимать решение точно надо самому, потому что слишком дорого потом придется платить за неудачно принятые решения. А они точно будут. Примерно такая же история с api. Если внешние ручки спроектированы плохо, потом мы обалдеем тащить это легаси через года и пространство. Между первым (моделями) и вторым (api) собственно и лежит большая часть кода в типовых веб-приложениях. Да ее пишет ИИ, но на базе заложенной архитектуры. Причем она достаточно стандартна. У нас есть слой сервисов, где выполняются бизнес-операции и проверяются инварианты. Рядом находится слой авторизации и события. К этому примыкает инфраструктурный слой с асинхронными джобами, очередями, мидлварами и тому подобным. Я отдельно выношу обработчики http, dto и валидациями данных запроса и ответа. Все это вообще не надо писать самостоятельно, сейчас, когда легко доступен design-first, лучше пользоваться генераторами типа openapi-generator, которые создают все автоматом на базе openapi. Все что остается, это вписать в нужные места вызовы своих сервисов и правильно сформировать ответ. Даже если обходиться без генерации, ии отлично справится опираясь на существующий код, если он написан нормально. Отдельный большой блок связан с микросервисной архитектурой, но я пишу про нее редко, потому что живу в монолите (хотя и с кучей сервисов, асинхронных джоб и обвязок вокруг). Оставляю эту тему другим блогерам 🙂 Ну и фронтенд, с ним ситуация явно проще, особенно если использовать готовые библиотеки компонентов и сгенерированные sdk для api (если у нас есть openapi). Да, во фронте есть свои заморочки связанные с безопасностью, отсутствием коннекта, локальным стейтом, ошибками, идемпотентностью и другими интересными темами. И конечно без понимания базы, сделать что-то серьезное будет сложно. Все? Нет конечно, самое интересное начинается когда надо думать об обратной совместимости, следить за транзакционными границами, идемпотентностью и конкурентностью. И тесты, которые ии по дефолту пишет плохо. Вот это все не будет происходить само по себе и хорошо бы знать, как оно устроено под капотом. Что еще упустил?

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

T-shaped снова в моде? Подняли тут вопрос, о том что мы снова движемся от специализации в T-shaped специалистов. Компании планируют сокращать персонал и одновременно с тем надеятся на усиление текущих специалистов за счет ИИ. В некоторых случаях это потребует замены текущих команд или как минимум отдельных людей, на агентно-ориентированных. В обиход входит слово tiny teams. По представлениям сбера (это их инициатива), это компактные команды в несколько человек с большой степенью автономности находящиеся внутри ai sdlc, где все процессы изменены, где все знания доступны агентам и так далее. В общем ai native организации, вместо (зачеркни ненужное) бирюзовых, agile и других слов. Пару мыслей про это от меня и других ребят, с которыми мы кулуарно общались. Во-первых сама тенденция возврата к фулстек режиму, во многом определяется не тем что у нас появился ИИ, а тем что идет общий экономический спад и компании сжимаются. А в таких случаях обязанности перераспределяются среди оставшихся. И наоборот, когда все активно развивается, происходит дробление. Сейчас же ИИ действительно позволяет увеличить производительность, что само по себе приводит к укрупнению зон ответственности, но это явление временное. Когда агенты станут такой же обыденностью как персональные компьютеры (представьте разницу между теми у кого они были и у кого их не было в 80 годы), то для увеличения производительности труда снова придется дробить ответственности и брать больше людей. Во-вторых, есть серьезные опасения, что сильных спецов в принципе всегда было мало, а тут мы как будто бы хотим лучших их лучших. Откуда их брать? И насколько людей действительно хватит? Мы не можем бесконечно масштабироваться, ИИ очень быстро уперся в ограничения кожанных. А комфотная работа для многих превратилась в изматывающий марафон на скорости стометровки.

Впечатления от конфы и первого выступления Хайлоад прошел, я сижу в коворкинге и восстанавливаю силы для завтрашнего старта на тимлиде. Поделюсь наблюдениями и расскажу про ближайшие планы. За пять лет, что я не был на конфах, много чего поменялось. Например если тогда везде был фудтех, то сейчас сплошной финтех и экосистемы. На стендах победил формат когда тебя водят по станциям и ты выполняешь разные задания, а потом участвуешь в общем розыгрыше. Довольно прикольно и везде очереди. Я смог пройти один стенд до конца и выиграл бутылку для воды, которую через 10 минут где-то потерял. Что касается людей, то какое то эпическое количество технических директоров и технических руководителей. Из удивительного для меня, все какие-то очень высокие. Я привык быть одним из самых высоких в округе, а тут как-то аж не по себе было среди великанов. На этом хайлоаде впервые запустили стрим по ИИ. Народу туда ломилось так много, что пройти внутрь было невозможно, я в итоге ни одного доклада так и не послушал. Да и в целом не то чтобы я их слушал, потому что без остановки общался в кулуарах. Ребята из ПК, старые друзья, знакомые которых не видел лет по 10-15, бывшие студенты хекслета и мои подписчики тоже были тут. Во второй день конфы в 10 утра был и мой мастер-класс на два часа, который во многом являлся компиляцией из курса "ии для разработчиков". Честно говоря я довольно сильно переживал из-за того, что до сих пор не умею и не совсем понимаю как показывать людям агентный кодинг так чтобы это было интересно, но вроде кто подходил после, говорили что им понравилось. Кстати когда я спросил, сколько людей в аудитории полностью пишет код агентами, руки подняло процентов 20-30%. Сейчас я весь наполнен знаниями о том кто чем живет, как внедряется ии в компаниях, что по людя, что по бизнесу, куда мы все идем и как с этим жить. Про это пока писать не буду, впереди еще пару конференций плюс большой воркшоп. Собственно, 4-5 июля в Москве будет аж двухдневный воркшоп с утра до вечера, где участники под моим присмотром и с моими рекомендациями будут создавать проект через агентов, прокачивая себя в том как это делать максимально эффективно. Билеты на это добро в открытом доступе с возможностью платить от компании. Если что заходите на огонек. p.s. придется еще недельку потерпеть, пока все это не закончится 🙂

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

Конференциям старт (Питер с 23 июня) Буквально на этих выходных я лечу в Питер чтобы встретить старых друзей и поучаствовать в двух конференциях по приглашению Олега Бунина (фаундер онтико). Значит расписание такое: 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) Не знаю как, но надо будет успеть везде сходить. В общем предлагаю там встречаться. И бонус от ребят, по промокоду MokevninAIFriends скидка 15% Telegram | YouTube | AI Клуб

Please release conventional commit Помните я писал, что перешел на коммиты агентом? Это дало сразу несколько плюсов Дисциплинирует, стараешься вести сессию через прогрузку тикета и не уходить в сторону, когда подмывает что-нибудь еще зацепить Спустя несколько дней, агент стал заметно чаще обращаться к истории и использовать описание коммитов, которые сам же и написал. Они довольно подробные и реально помогают Но это было только начало, буквально сразу же стало понятно, что вот тут то и имеет смысл перейти на подход 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 подрубить если надо). Плюс мы повесили все проверки именно на этот пулреквест, а не на коммит, чтобы блокировать релиз если что-то пойдет не так. Мы буквально за неделю перевели на эту схему основные проекты и кайфуем (жизнь одна)

В сегодняшнем выпуске подкаста у меня в гостях Антон Плешивцев (он уже был в самых первых выпусках), который поделился тремя историями: запуск и автоматизация ИИ бизнеса (подготовка фоток под документы). Тут и ядро бизнеса все на ml и вокруг обвязка для обслуживиания клиентов на OpenClaw. Вторая история про текущий американский проект, в котором Антон руководит разработкой. Как случилось так, что команда довела проект до ручки следуя советам агентов и почему с частью ребят пришло расстаться. И третья история это то как можно делать найм в эпоху ИИ, так чтобы проверять реальные скилы без насилия разрабов. https://www.youtube.com/watch?v=kQAWgM_b0XI Наслаждаемся и машем 🙂 p.s. А между тем совсем скоро старт курса llm-разработчик где за 4 месяцы мы научим создавать бизнес решения с использованием ИИ: ai studio, hermes, локальные модели и многое другое