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

AI Dev Live 2026 И снова выступать. 11 ноября в 14:00 пройдет онлайн конференция конференция по AI в разработке, на которой я выступлю с докладом про внедрение ИИ в легаси проекты (пошаговый план). Конференция идет два дня и на ней мы (спикеры) пройдемся по SDLC со всех сторон. От настройки харнеса до SDD и продуктового мышления. Стоимость билета 10 тысяч, но есть интересная механика. Если подписаться на каналы всех докладчиков (там для этого бот используется), то проход бесплатный. Для меня эта конфа необычна тем, что ее спикеры это инфлюенсеры у которых большие аудитории в телеграме и в основном по теме AI. Я сам мало кого читаю на эту тему в телеге регулярно, поэтому вписался чтобы познакомиться так сказать с коллегами по цеху и посмотреть что там происходит на острие. И даже если вы не планируете идти, хотя бы просто зайдите и жмякните на мое лицо на главной. Очень прикольно сделано :) p.s. мое выступление 12 ноября в 16:15

Эффективная работа с git worktree Если вы уже дошли до точки, когда параллельные агентские сессии как не в себя делают фичи, то вы точно должны были столкнуться с новыми проблемами, среди которых одновременный запуск нескольких копий приложений, быстро забивающийся диск и оперативная память, плюс работа которая встает колом из-за одновременных запусков тестов и линтеров. В этом посте я расскажу про то, как поправить свой сетап, чтобы все стало снова летать. Сначала быстрый рекап. Worktree это фича гита, которая создает под ветки отдельные физические директории в которых можно вести работу. Раньше этой фичей почти не пользовались, так как просто переключались на ветку, сейчас же переключение на ветку будет сбивать параллельные сессии, поэтому все перешли на worktree. Даже если вы этого явно не просите, агенты нередко сами пользуются ими (но не всегда). И так поехали, проблемы и их решения. Отказ от веток Если вы пошли по этому пути, то лучше явно описать агенту, что ветки использовать нельзя, а вместо них нужно создавать worktree. Иначе регулярно будет возникать ситуация, когда один из агентов прыгнет на ветку и помешает другим. Начало и завершение работы По умолчанию создание worktee просто копирует данные, но в таком виде проект врядли заработает и на нем можно будет прогонять тесты. Скорее всего есть какие-то подготовительные шаги от установки зависимостей до создания .env. Вот эту часть нужно сначала автоматизировать, например, с помощью make-команд, а потом уже зафиксировать в доках с агентом, чтобы он вызывал их как при создании рабочего дерева, так и при завершении работы. У себя я считаю завершением это отправку pr, в это время происходит чистка. Независимые базы данных Помните проблему миграций в ветках? Вот здесь будет тоже самое, если не создавать отдельные базы данных под каждое дерево. Сделать это просто, достаточно объяснить агенту задачу и он сам предложит способ формирования динамического имени, связанного с названием worktree. Дальше снова автоматизируем и добавляем в команду создания worktree из предыдущего шага. При этом важно сделать так чтобы это были именно базы данных, а не субд, иначе если на каждое дерево будет подниматься свой postgresql, вы быстрее начнете упираться в производительность Одновременные запуск приложения Кроме баз, такой же трюк надо провернуть с портами (и если используется dns то доменами). Каждое дерево при старте тестов или приложения должно работать со своим набором портов. Опять же, эту задачу сделает сам агент, он без проблем напишет небольшие скрипты, которые находят свободные порты и подсовывают их при старте приложения Параллельный запуск проверок Но даже если сделать все шаги выше, все равно запуск тестов или линтеров из двух worktree, уже может поставить колом всю машину. Здесь есть красивый выход через блокировку. Нужно запускать проверки не напрямую, а через утилиту, которая ставит такие блокировки и упорядочивает запуск (с нужным уровнем параллельности). Пока я этим занимался написал такую утилитку https://github.com/mokevnin/heavy Шаринг данных Ну и последнее, установка зависимостей и кеши. Если вы не хотите чтобы место на диске улетало со скоростью ветра, то нужно использовать инструменты или настраивать существующие так, чтобы они шарили (безопасно) все свои артефакты во внешних директориях. Например лучше работать с pnpm, а не npm, потому что первый хранит зависимости во внешнем сторадже, что очень сокращает потребляемое место. Если все это сделать, то работать с worktree станет реально удобно и быстро. Пользуйтесь 🙂 Telegram | YouTube | ИИ для разработчиков

Выпуск про состояние ит-рынка, зарплаты, сокращения и поиск работы уже в сети: https://www.youtube.com/watch?v=pnmBEppWjGA

Гардрейлсы всем и пусть никто не уйдет обиженным Помимо обычных линтеров языков, существует тьма дополнительных, которые смотрят все начиная от ошибок в Markdown-файлах и контроля обратной совместимости в openapi до рекомендации лучших практик при использовании github acitons. Мне всегда нравилось улучшать обвязку проекта, поэтому я довольно давно и регулярно обкатывал и внедрял разные чекеры в проекты Хекслета. И сейчас, как будто бы накопилось достаточно много классных штук, которыми уже можно поделиться. В общем я сделал репозиторий, в котором собраны как самые продвинутые линтеры по языкам так и по всему остальному. Готов поспорить что большинство с ними не знакомо. Как с этим работать? Открываете вашего агента, даете ссылку на репу и пишите: Сопоставь инструменты из этого списка с тем что есть проекты. Предложи дополнения и улучшения в проект на базе этого списка с объяснением почему стоит использовать тот или иной инструмент И все, вы махом получаете кучку улучшений и дополнительного контроля для вашего процесса разработки. Пожалуйста 🙂 https://github.com/mokevnin/dev-guardrails Telegram | YouTube | ИИ для разработчиков

Снова в деле Так, тут неожиданно получилось, что я буду преподавать в нашем курсе "ии для программистов". Я когда-то его стартанул и отошел от дел, а тут все таки мир немного ушел вперед и мы его перезапустили. Решили что будет лучше если я сам проведу первый поток, а потом уже передадим его нашим преподавателям. Что поменялось? За последние полгода людей которые вообще пишут без ии почти не осталось, рассказывать о том что такое mcp, как настраивать agents.md и тому подобные вещи нужно только тем, кто учится с нуля. Действующие же разработчики хотят настроить крутой и желательно автоматизированный воркфлоу, который выдает качественный и работающий код. Вот примерный план вебинаров: 1. Эффективность работы с агентами. Как обеспечить агентам полноценный контекст проекта, включая другие репозитории, продакшен, логи и инфраструктуру. Как адаптировать кодовую базу под ии, автоматизировать коммиты и релизы. Отдельно разберу хуки, линтеры, ast-grep и другие guardrails, которые позволяют контролировать архитектурные ограничения и не давать агентам делать что попало. 2. Spec-Driven Development (SDD). Разберу популярные SDD-фреймворки, workflow Мэтта Покока и проблему преждевременной спецификации. Отдельно поговорю про то, как все это применять в существующих проектах (brownfield), где уже есть большая кодовая база, сложившаяся архитектура и куча ограничений. 3. Качество кода. Как правильно организовать дебаг, тестирование и независимое регулярное code review. Как понять какой код действительно нужно смотреть самому, а какой можно вообще не читать. И как сделать так, чтобы качество обеспечивалось процессом, а не необходимостью вручную проверять каждую строчку за агентом. 4. Качество харнеса. Как управлять памятью и контекстом агентов, зачем иногда отключать память и когда нужно очищать окружение. Как проводить ретроспективы работы агентов, находить проблемы в инструкциях и инструментах. Отдельно расскажу про скилы для экономии токенов и способы уменьшить стоимость разработки. Также затрону эвалы, которые позволяют проверять насколько изменения в харнесе действительно улучшают работу агентов. 5. Практика построения агентного воркфлоу. Как объединить все эти подходы в единый процесс разработки, где агенты получают нужный контекст, работают с требованиями, пишут код, тестируют его и проходят независимую проверку. Разберу как связать отдельные инструменты и практики между собой, чтобы получить не набор разрозненных настроек, а работающую систему. Ссылка на курс https://ru.hexlet.io/programs/ai-for-developers (можно оплачивать откуда угодно) Telegram | YouTube | AI Клуб | ИИ для разработчиков

Сегодня в выпуске рассказываю про автоматизацию бизнеса за рамками разработки. Как мы в Хекслете сделали общий контекст, перестроили аналитику, автоматизировали сбор и исправление обратной связи, дали команде mcp для управления Хекслетом и сервисами https://www.youtube.com/watch?v=TBYAavvulHg Telegram | Аудио | vk | Системный дизайн

Коварная память кодинговых агентов Быстрый рекап. В современных агентах по дефолту включена память, которая работает конкретно для вас. Поэтому со временем появляется ощущение, что оно работает все лучше и лучше. Иногда это приводит к казусам, когда что-то сильно меняется и агент работает по старинке, но если следить за чистотой и регулярно вызывать что-то типа /doctor в клод коде, то все будет норм. Такая схема хорошо работает для конкретного человека, но работает плохо и даже вредит при работе в команде. У каждого человека начинает копиться свой набор правил, который во многом дублируется, но при этом не распространяется на команду и не меняется синхронно при изменении чего-либо. В итоге мы получаем ситуацию, когда у новых людей все работает не так хорошо, а хорошие практики перестают распространятся или делают это медленно и не равномерно. Я в какой-то момент, когда увидел очередное "я понял, сохраню в память", психанул и запретил ему это делать. Он этот запрет тоже положил в память 🙂 Поэтому пришлось закатать рукава и проработать схему запрета в AGENTS.md. Можно сказать, а почему бы не выключить ее совсем? Есть таки таки вещи, где она нужна и где я не хочу сильно думать. Возможно там есть настройка которая позволяет память менять по проектно (щас пост опубликую и проверю) и тогда вопрос может быть решен кардинально. Какой у вас опыт с памятью? Telegram | YouTube | AI Клуб | Внедрение AI

Когда узнал что бд бекапилась на тот же сервер где хранилась

Выпуск про переход от инженера к предпринимателю, созданию компании express42 и последующему поглощению Флантом уже в сети. Мы встретились с моим старым другом Сашей Титовым, где поговорили про его путь, про девопс и будущее инфраструктуры https://www.youtube.com/watch?v=LUytWE_NShk Telegram | Аудио | vk | Системный дизайн

Улучшаем харнес с помощью ast-grep Утро сегодня началось не с кофе. Пока мы переезжаем (с разной степенью успешности) в другой дц, расскажу про недавнее интересное открытие, связанное с тем как сделать улучшить работу агентов и сделать больше надежных автоматических проверок разных архитектурных правил. Понятно что со временем появляется все больше и больше правил, которые описываются в AGENTS.md (или что лучше в CODING_STANDARDS.md). Но хотелось бы чтобы они чекались автоматом. Клод нам сам постоянно предлагал и в какой-то момент начал писать скрипты допом к линтингу, которые, в основном, регулярками, проверяли что-то. Кушать не просит и ладно, я не сопротивлялся, но видел что это решение на тоненького, хотя и лучше чем ничего. Когда эти скрипты начали копиться, я подумал, хм, а ведь мне ничего не стоит попросить его переписать правила как плагины к линтерам на конкретных языках. Кое что мы так действительно переписали, но в какой-то момент сам клод говорит, а давай заюзаем ast-grep. Я посмотрел и понял что проспал очень логичную штуку. Еще в 22 году, когда полетел treesitter, кто-то замутил инструмент, который грепает не исходники, а AST. Причем что важно, независимо от языка, оно все языки превращает AST и грепает по его нодам. Это резко повышает точность рабатываний, потому что вместо регулярок, которые ловят ненадежно, плюс херово работают с вложенностью, мы имеем по сути универсальный способ представить весь код (и все форматы) в виде единого AST пространства, по которому идет поиск. Ну и естессно переписали все проверки, потому что у этой штуки еще есть sdk для ноды. А все подобные скрипты у нас агент фигачит на TypeScript. Пара примеров: 1. no-unknown-in-generated-types: в сгенерированных фронт-типах (app/javascript/types/serializers/) не должно быть unknown. Typelizer пишет unknown, когда не смог вывести тип поля. Это бывает у атрибута поверх T::Struct или у вычисляемого атрибута без typelize. Тип нужно объявить явно в ресурсе. 2. no-untyped-resource-dsl: в сгенерированных RBI-сигнатурах DSL ресурсов не должно быть T.untyped. Чинить надо в ресурсе или в компиляторе typelizer.rb, а не в RBI. Но это еще оказалось не все. ast-grep в принципе полезен даже вместо обычного грепа, особенно для самих агентов, которые постоянно ищут какие-то символы в исходниках. У ast-grep есть дока с инструкцией, как подключить его к агенту, чтобы агент начал использовать его вместо grep там где это имеет смысл. p.s. Какие еще фишки вы знаете?

Почему нам нужны визионеры Недавно DHH выступил на Rails World и по полной прошелся по привычному программированию. Сказал, что писать код руками становится экономически бессмысленно, что сам почти перестал писать на Ruby, а часть нового HEY они делают на Rust, который он сам не знает и воспринимает как черный ящик для агентов (но уверен что он тут специально нагнетает). Этим он подорвал столько пердаков, что из космоса было видно зарево. Мой твиттер на неделю превратился в бесконечный срач. На Reddit появились треды в духе "уберите DHH из Rails", Aaron Patterson посвятил значительную часть своего закрывающего доклада ответу DHH. Как вообще создатель Rails может выйти на Rails-конференцию и рассказывать людям, что язык, фреймворк и даже понимание собственного кода скоро могут перестать иметь прежнее значение? DHH самый настоящий визионер, не в смысле что он умеет и хорошо предсказывает будущее, такие люди вообще довольно часто ошибаются. Визионерство это способность увидеть большой сдвиг раньше большинства, построить вокруг него цельную картину будущего и начать действовать так, как будто эта картина уже становится реальностью. Поэтому визионеры почти всегда выглядят слишком радикальными. Когда их идеи становятся очевидными, никакого визионерства уже не требуется, тут уже можно строить планы, выделять деньги, нанимать команду и вперед на галеру. Практически любой большой технологический переход требует от кого-то сделать ставку раньше остальных. Apple много раз отказывалась от вещей, которые рынок считал обязательными. Стив Джобс убирал флопи диски, отказывался от физической клавиатуры в смартфоне, воевал с флешом. Каждое отдельное решение можно было критиковать, но за ними стояла цельная картина того, что ПК должен стать ближе к бытовому устройству, чем к набору технологий. Амазон годами инвестировал в инфраструктуру и рост вместо прибыли. AWS поначалу вообще выглядел почти побочным направлением интернет-магазина. Сегодня идея покупать вычисления как электричество кажется естественной, но кто-то должен был вложить в эту модель миллиарды до того, как она стала естественной. Netflix сам начал уничтожать свой успешный dvd-бизнес ради стриминга. Это особенно важный пример, потому что проблема больших компаний обычно не в том, что они не замечают новые технологии. Они часто прекрасно их видят. Проблема в том, что новое направление угрожает существующему бизнесу, который прямо сейчас приносит деньги. И обратных примеров тоже полно. Компании редко погибают потому, что вообще не знали о новой технологии. Kodak одной из первых разработала цифровую камеру. Nokia прекрасно видела развитие смартфонов. Большие корпорации обычно располагают огромным количеством исследований, аналитики и талантливых людей. Знать недостаточно. Нужно быть готовым сделать из знания ставку, которая может навредить сегодняшнему успешному бизнесу. В этом и состоит одна из главных особенностей визионеров. Они не просто придумывают новые продукты. Они способны поставить под сомнение то, благодаря чему сами стали успешными. Причем важно не превращать это в культ великих людей. Визионер вполне может завести компанию не туда. Чем сильнее убеждение, тем опаснее ошибка. Стив Джобс ошибался. Безос ошибался. DHH ошибался и еще много раз ошибется. Большинство людей и организаций хорошо умеют оптимизировать существующую реальность. Улучшать продукт на несколько процентов, уменьшать затраты, отвечать на запросы клиентов, следить за конкурентами. Для работающего бизнеса все это критически важно. Но переход из одной реальности в другую почти никогда не получается как результат такой оптимизации. Для него нужен кто-то, кто в какой-то момент скажет: то, что сегодня составляет основу нашего бизнеса, завтра может вообще перестать иметь значение. И начать действовать исходя из этого раньше, чем это станет очевидно всем остальным.

Причем важно не превращать это в культ великих людей. Визионер вполне может завести компанию не туда. Чем сильнее убеждение, тем опаснее ошибка. Стив Джобс ошибался. Безос ошибался. DHH ошибался и еще много раз ошибется. Но есть фундаментальная асимметрия. Большинство людей и организаций хорошо умеют оптимизировать существующую реальность. Улучшать продукт на несколько процентов, уменьшать затраты, отвечать на запросы клиентов, следить за конкурентами. Для работающего бизнеса все это критически важно. Но переход из одной реальности в другую почти никогда не получается как результат такой оптимизации. Для него нужен кто-то, кто в какой-то момент скажет: то, что сегодня составляет основу нашего бизнеса, завтра может вообще перестать иметь значение. И начать действовать исходя из этого раньше, чем это станет очевидно всем остальным. p.s. Ход конем, Хекслет запланировал переписывание бека на go в 27 году 🙂

Почему нам нужны визионеры Недавно DHH выступил на Rails World и по полной прошелся по привычному программированию. Сказал, что писать код руками становится экономически бессмысленно, что сам почти перестал писать на Ruby, а часть нового HEY они делают на Rust, который он сам не знает и воспринимает как черный ящик для агентов (но уверен что он тут специально нагнетает). Этим он подорвал столько пердаков, что из космоса было видно зарево. Мой твиттер на неделю превратился в бесконечный срач. На Reddit появились треды в духе "уберите DHH из Rails", Aaron Patterson посвятил значительную часть своего закрывающего доклада ответу DHH. Как вообще создатель Rails может выйти на Rails-конференцию и рассказывать людям, что язык, фреймворк и даже понимание собственного кода скоро могут перестать иметь прежнее значение? Но я зайду в эту историю со стороны технического прогресса и предпринимательства. DHH самый настоящий визионер, не в смысле что он умеет и хорошо предсказывает будущее, такие люди вообще довольно часто ошибаются. Визионерство это способность увидеть большой сдвиг раньше большинства, построить вокруг него цельную картину будущего и начать действовать так, как будто эта картина уже становится реальностью. Поэтому визионеры почти всегда выглядят слишком радикальными. Когда их идеи становятся очевидными, никакого визионерства уже не требуется, тут уже можно строить планы, выделять деньги, нанимать команду и вперед на галеру. Но до этого момента все выглядит совсем по другому в глазах большинства людей. Доказательств недостаточно, огромные риски, да и текущий бизнес работает неплохо. Клиенты просят совсем другое, а профессиональное сообщество может считать новую идею откровенной чушью. Или как в данном случае, считает что человек предал конкретно их и все человечество. Практически любой большой технологический переход требует от кого-то сделать ставку раньше остальных. Apple много раз отказывалась от вещей, которые рынок считал обязательными. Стив Джобс убирал флопи диски, отказывался от физической клавиатуры в смартфоне, воевал с флешом. Каждое отдельное решение можно было критиковать, но за ними стояла цельная картина того, что ПК должен стать ближе к бытовому устройству, чем к набору технологий. Амазон годами инвестировал в инфраструктуру и рост вместо прибыли. AWS поначалу вообще выглядел почти побочным направлением интернет-магазина. Сегодня идея покупать вычисления как электричество кажется естественной, но кто-то должен был вложить в эту модель миллиарды до того, как она стала естественной. Netflix сам начал уничтожать свой успешный dvd-бизнес ради стриминга. Это особенно важный пример, потому что проблема больших компаний обычно не в том, что они не замечают новые технологии. Они часто прекрасно их видят. Проблема в том, что новое направление угрожает существующему бизнесу, который прямо сейчас приносит деньги. NVIDIA десятилетиями инвестировала в программируемые GPU и CUDA задолго до нынешнего бума генеративного AI. Дженсен Хуанг не мог знать, какой именно вид примет сегодняшний рынок. Но у него была достаточно сильная картина будущего вычислений, чтобы продолжать ставить на нее, когда рынок видел прежде всего видеокарты для игр. И обратных примеров тоже полно. Компании редко погибают потому, что вообще не знали о новой технологии. Kodak одной из первых разработала цифровую камеру. Nokia прекрасно видела развитие смартфонов. Большие корпорации обычно располагают огромным количеством исследований, аналитики и талантливых людей. Знать недостаточно. Нужно быть готовым сделать из знания ставку, которая может навредить сегодняшнему успешному бизнесу. В этом и состоит одна из главных особенностей визионеров. Они не просто придумывают новые продукты. Они способны поставить под сомнение то, благодаря чему сами стали успешными.

Сегодня в подкасте про принятие решений в компаниях. Насколько менеджеры понимают что делают и почему от этого страдает разработка: https://youtu.be/-XAWWoxHfpo?is=gMrfxTH_PzpnFVxN

Статистика по коду Хекслета Раз пошла такая пьянка, давайте я вам выдам еще кучку разной инфы. Про деньги и бизнесовую часть поговорим потом, а щас про коммиты и код. И так погнали. Хекслет не такой маленький проект, как может показаться тем, кто не погружен в нашу кухню. Это по сути lms (learning management system), где много разных биллинговых историй (покупки подписки), управление студентами, кабинет для b2b клиентов, маркетинговые инструменты, управление контентом и большая подсистема запуска и подготовки практик. И это не считая отдельного редактора (по сути ide) и множества других систем делающихся в отдельных репах. В базе порядка 300 таблиц, а про код поговорим ниже. Задач тут много от всех команд, поэтому и изменений тоже много. Активно писать через ИИ мы начали в конце 24 года, но там был долгий этап подготовки, мы типизировали проект, переходили на sdd, делали рефакторинги и всячески адаптировали проект под удобство ии. И вот когда это закончилось (плюс минус), мы рванули фигачить фичи. Поэтому я взял данные за последний год. Учитывайте что это не показывает как было до ии и после ии. Это показывает разгон на фоне улучшения харнеса и перехода в sdd. Итоги года по кодовой базе Hexlet, с октября 2025 по октябрь 2026 Автогенерацию я не считал, только реальный код. В цифрах «было» нет легаси, которое мы за год удалили. Объём кода вырос со 180 до 322 тысяч строк, в 1,8 раза. TypeScript вырос втрое. Ruby полгода стоял на месте, а с весны пошёл вверх. За год мы сделали 5 268 коммитов. Добавили 633 тысячи строк, удалили 460 тысяч. Самым активным месяцем стал сентябрь: 713 коммитов. Сейчас две трети кодовой базы написаны на языках программирования: 114 тысяч строк на Ruby и 103 тысячи на TypeScript. Ещё четверть составляют данные и конфиги: фикстуры, локали, YAML и JSON. По rails stats бэкенд вырос с 20 до 78 тысяч строк кода, а тесты к нему — с 6 до 25 тысяч. Контроллеров было 118, стало 310. Моделей было 122, стало 205. Живых таблиц в базе данных было 149, стало 228. Тестов стало вдвое больше: 1 948 против 918 год назад. Из них 1 536 интеграционных (79%) и 401 юнит-тест (21%), ещё 11 проверяют архитектурные правила. Тестовый код растёт вровень с приложением: на каждые 100 строк кода приходится около 35 строк тестов. Покрытие сейчас 92,4%. Около 60% текущей кодовой базы написано с помощью ИИ. Точно это известно для кода с середины мая: тогда мы начали коммитить через Claude, и с тех пор на ИИ приходится 83% новых строк. Если считать, что до этого доля была такой же, выходит около 60%. По коммитам с явной пометкой получается минимум 38%.

Статистика по задачам. Как повлиял ии? Заметил интересный эффект. По мере внедрения агентов, мы стали очень сильно ускорятся в скорости закрытия тасок, в какой-то момент мне почудилось что еще чуть-чуть то текучка пропадет и мы займемся, новыми большими фичами почти без отвлечения. Но как я был не прав :) Задач было столько не потому что их было столько, а потому что где-то мы не все видели и ИИ подсветил, где-то просто перестали добавлять даже в беклог, понимая что за эти задачи мы в ближайшее десятилетие не возьмемся. Когда задачки стали закрываться, а у продактов и других ребят появились коннекторы ко всем системам, мы получили такой рост количества тикетов, что уже пришлось просить притормозить. У нас бывают дни когда за раз открывается новых несколько десятков и закрывается несколько десятков. То что раньше делалось недели, проскакивает за часы. В итоге прямо сейчас задач висит столько, сколько не висело никогда. А между тем 5 агентов (только у меня) херачат сутками. У меня кстати накопилось уже материала по изменениям, буду про это писать скоро. И переписывания на го и снижение цены лида и улучшение аналитики. Ух сколько всего. Цифры Посчитал все тикеты разработки, фидбека и контента в Трекере с октября 2025 по сентябрь 2026. За год создано 1340 тикетов, закрыто 1032. Точка отсчёта — 14 мая: в этот день в репозитории появился первый коммит, написанный вместе с Claude. Сколько создаём и закрываем в месяц • Октябрь–апрель: создавали около 70, закрывали около 50. • Июнь–август: создаём около 105, закрываем около 105. • Сентябрь: создали 422, закрыли 222. Как быстро закрываем • До мая тикет жил до закрытия в среднем от 3 недель до 2 месяцев. Начиная с мая — 5–6 дней. • Доля тикетов, закрытых за неделю, выросла примерно с 20% до 35–48%. Исключения — июнь и сентябрь. Коммиты • До мая было около 400 в месяц, в сентябре — 713. У 87% сентябрьских коммитов соавтор — Claude. Выводы 1. Тикеты закрываются примерно в 6–10 раз быстрее, чем до мая. 2. Летом мы впервые закрывали не меньше, чем создавали. До этого очередь только росла. Аппетиты растут во время еды :)

Плановое обслуживание кода Даже если вы настроили у себя процесс разработки, в котором все делают агенты, есть задачи которые они не могут выполнить качественно в моменте. В основном это связано с тем, что они фокусируются вокруг тех изменений с которыми работают прямо сейчас. Причем каждое конкретное изменение может выглядеть допустимо, но если посмотреть на дистанции, то будет видна деградация, постепенное расползание плохих практик, дублирование, отсутствие обобщения там где оно напрашивается. Поэтому в процесс нужно включать задачи по расписанию, которые имеет смысл запускать раз в неделю или месяц. Ниже расскажу что я делаю сам с помощью каких команд или скилов. Эффективность агента /doctor (Claude Code) — раз в месяц проверяю здоровье агентского окружения: конфигурацию, неиспользуемые скилы и MCP, медленные хуки, проблемы с permissions и другие накопившиеся проблемы. Заодно помогает освобождать память от устаревшего и лишнего. /fewer-permission-prompts (Claude Code) — анализирует историю работы и предлагает, какие часто используемые безопасные команды стоит добавить в allowlist, чтобы агент меньше отвлекал подтверждениями. /run-skill-generator (Claude Code) — периодически пересобирает знания агента о том, как поднять и проверить проект, чтобы /run и /verify не опирались на давно устаревшие команды. /retro (Matt Pocock Skills) — формально не плановая задача. Запускаю после сессии, где агент заметно буксовал, делал лишние шаги или его приходилось несколько раз исправлять. Скил анализирует, что можно поменять в инструкциях, автоматических проверках и окружении, чтобы эта проблема больше не повторялась. Качество кода /simplify (Claude Code) — прохожусь по активно меняющимся частям проекта. Ищет дублирование, лишние абстракции, возможность переиспользовать уже существующий код и просто слишком сложные решения. Удобно запускать раз в неделю по нескольким наиболее активно меняющимся каталогам. /code-review (Claude Code; у Matt Pocock также есть одноимённый skill) — отдельный проход по изменениям за неделю на корректность, качество кода и возможные упрощения. Обычный review конкретного изменения такую накопительную деградацию часто не замечает. /improve-codebase-architecture (Matt Pocock Skills) — ищет места, где архитектура постепенно поплыла: слишком мелкие модули, неудачные границы, сложные интерфейсы, размазанное по нескольким местам поведение. Можно натравливать прямо на конкретные слои, типа посмотри сервисы Чтобы не потерять это добро, я включил в его книгу паттернов агентной разработки Кстати есть неочевидный нюанс. По идее все это надо стартовать автономно, но автономный запуск где-нибудь на github actions подразумевает работу не от подписки конкретного пользователя, а по апи. А хорошие модели чертовски дороги в таком варианте использования, поэтому пока по старине, стартуем все это ручками. p.s. Поделитесь своими фишками, что запускаете вы? Telegram | YouTube | AI Клуб | Внедрение AI

Выпуск опубликован, можно смотреть и слушать. Сегодня в подкасте создатель Вастрик Клуба Василий Зубарев с которым мы обсуждаем сообщества, контент и конечно же программирование https://youtu.be/VwNYYIFlahY?is=he5vbWEAqJ3OxrgL

Костные наушники Под каждым видео коммент, что за наушники ты носишь? Это костные наушники компании shokz, которые, насколько я знаю, сделали по технологии изначально созданной для слуховых аппаратов. Они не вставляются в уши, а прижимаются снаружи передавая звук через вибрацию. Зачем это надо? Мелкие наушники-вставки это всегда проблема для меня. Я постоянно их теряю, батарейки не хватает на весь день если активно разговаривать, их надо вынимать/вставлять, от них устают уши и они мешают слышать что происходит снаружи когда это важно (например на велике катаешься). С костными в этом смысле приятнее. Их можно в принципе никогда не убирать, а если надо убрать они легко оказываются на шее. У них намного дольше работает батарейка, а я много говорю по телефону и air pods мне тупо не хватало на день. Из минусов ниже качество звука из-за самой природы передачи. А если снаружи шумно или ветер, то в них очень плохо слышно. Иногда приходится прямо затыкать ухо, чтобы услышать. Тоже самое касается микрофона, если ветер, то тебя уже не слышат нормально, поэтому для себя я купил версию с выносным микрофоном. Ее вы видите в видео :) Плюс у меня есть отдельный вариант (на картинке) для плавания. А еще у каждого в семье по такому наушнику. Кстати, они очень популярны у нас тут p.s. Вы пробовали?

Статистика участия в опенсорсе Активно разрабатывая я регулярно наыткаюсь на баги и не доработки в используемых либах. Мне всегда было интересно помогать авторам улучшать их либы, но не всегда была возможность это делать, хотя я так или иначе это делал. А тут иишка конечно развязала руки. После очередной сессии дебага и понимании, что бага в либе, я взял за правило помимо локального фикса отправлять пулреквест в саму либу. И вот какая у меня накопилась статистика за 30 дней: За последние 30 дней отправил в чужие проекты 31 пулреквест. Из них 17 влиты (55%), 12 ещё ждут ревью, 2 закрыты без мержа. Куда влиты (17): - stathis-alexander/boba: 9 (из 10, один закрыт без мержа) - Shopify/rbi-central: 5 (из 6, один ещё открыт) - Shopify/tapioca: 1 - ElMassimo/vite_ruby: 1 - lostisland/faraday: 1 Ещё открыты (12): - hougesen/mdsf: 2 - jedrzejboczar/devcontainers.nvim: 2 - Shopify/rbi-central: 1 - brianhuster/live-preview.nvim: 1 - RubyMoney/money-rails: 1 - WeAreFarmGeek/diplomat: 1 - bkeepers/dotenv: 1 - kjvarga/sitemap_generator: 1 - rudderlabs/rudder-sdk-ruby: 1 Как видите тут все подряд от типизации (очень много про тулинг для типов в ruby) и http либы до работы с докером вимом и генератором сайтмапов. Причем не всегда я слал сразу пулреквест, если это фича, то обычно сначала спрашивал в ишьюсе как на это смотрит автор. Ну и везде очень позитивная реакция. Иногда, кстати, пулреквест уже есть от другого человека и я просто докидывал туда контекст. Был один кейс, где мое предложенное решение в комменте понравилась ментейнеру больше и он попросил автора пулреквеста поправить его код (inertia.js). А какая стата у вас? Telegram | YouTube | AI Клуб | Внедрение AI