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

Эффективная работа с git worktree

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

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

Отказ от веток

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

Начало и завершение работы

По умолчанию создание worktee просто копирует данные, но в таком виде проект врядли заработает и на нем можно будет прогонять тесты. Скорее всего есть какие-то подготовительные шаги от установки зависимостей до создания .env. Вот эту часть нужно сначала автоматизировать, например, с помощью make-команд, а потом уже зафиксировать в доках с агентом, чтобы он вызывал их как при создании рабочего дерева, так и при завершении работы. У себя я считаю завершением это отправку pr, в это время происходит чистка.

Независимые базы данных

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

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

Одновременные запуск приложения

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

Параллельный запуск проверок

Но даже если сделать все шаги выше, все равно запуск тестов или линтеров из двух worktree, уже может поставить колом всю машину. Здесь есть красивый выход через блокировку. Нужно запускать проверки не напрямую, а через утилиту, которая ставит такие блокировки и упорядочивает запуск (с нужным уровнем параллельности). Пока я этим занимался написал такую утилитку https://github.com/mokevnin/heavy

Шаринг данных

Ну и последнее, установка зависимостей и кеши. Если вы не хотите чтобы место на диске улетало со скоростью ветра, то нужно использовать инструменты или настраивать существующие так, чтобы они шарили (безопасно) все свои артефакты во внешних директориях. Например лучше работать с pnpm, а не npm, потому что первый хранит зависимости во внешнем сторадже, что очень сокращает потребляемое место.

Если все это сделать, то работать с worktree станет реально удобно и быстро. Пользуйтесь

Коварная память кодинговых агентов

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

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

Я в какой-то момент, когда увидел очередное "я понял, сохраню в память", психанул и запретил ему это делать. Он этот запрет тоже положил в память :) Поэтому пришлось закатать рукава и проработать схему запрета в AGENTS.md. Можно сказать, а почему бы не выключить ее совсем? Есть таки таки вещи, где она нужна и где я не хочу сильно думать. Возможно там есть настройка которая позволяет память менять по проектно (щас пост опубликую и проверю) и тогда вопрос может быть решен кардинально.

Какой у вас опыт с памятью?

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

Улучшаем харнес

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

Понятно что со временем появляется все больше и больше правил, которые описываются в 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. Какие еще фишки вы знаете?

Статистика по задачам. Как повлиял ии?

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

Задач было столько не потому что их было столько, а потому что где-то мы не все видели и ИИ подсветил, где-то просто перестали добавлять даже в беклог, понимая что за эти задачи мы в ближайшее десятилетие не возьмемся. Когда задачки стали закрываться, а у продактов и других ребят появились коннекторы ко всем системам, мы получили такой рост количества тикетов, что уже пришлось просить притормозить. У нас бывают дни когда за раз открывается новых несколько десятков и закрывается несколько десятков. То что раньше делалось недели, проскакивает за часы. В итоге прямо сейчас задач висит столько, сколько не висело никогда.

А между тем 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) — ищет места, где архитектура постепенно поплыла: слишком мелкие модули, неудачные границы, сложные интерфейсы, размазанное по нескольким местам поведение. Можно натравливать прямо на конкретные слои, типа посмотри сервисы

Чтобы не потерять это добро, я включил в его книгу паттернов агентной разработки https://mokevnin.github.io/agentic-coding-design-patterns/ru/scheduled-maintenance.html

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

p.s. Поделитесь своими фишками, что запускаете вы?