Код пишется быстро, а што с ревью

Я как-то уже бухтел на тему код-ревью. Но мир так быстро меняется, что хочется поднять её снова.

Код теперь генерируют агенты. Увидеть пиар на +4623 −200 – да запросто. А дальше у всех по-разному.

Вижу проекты, где код всё так же по старинке дотошно и вдумчиво смотрят люди. Ревью становится бутылочным горлышком: код пишется быстро, пиары висят днями.

Где-то к просмотру глазами подключают агента: «Сделай ревью и смотри, чтобы там всё хорошо было» – тоже вариант.

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

Мы решили сделать накопленный опыт ревью доступным агентам ещё до создания пиара. Для этого:

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

Так агент может ещё во время написания кода учесть, как у нас всё устроено.

Дальше, уже в CI, добавили дополнительные валидации и ревью агентом.

В итоге обычно смотрим пиары глазами по минимуму: многие замечания уже учтены по умолчанию. А иногда и не смотрим вовсе :)

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

Расскажите, как у вас устроено код-ревью? Что хорошо работает?

Остаётся, конечно, ещё один вопрос: кто в этой схеме отвечает за все эти тонны кода? Но это уже совсем другая история.

ММММолния!

В последнем обновлении Claude Code добавили поддержку AGENTS.md! Это настоящий биг факин диал.

По умолчанию Claude Code читает AGENTS.md, если в проекте нет CLAUDE.md. Выбор можно изменить в /config → Project instructions.

Ждем, когда еще начнет учитывать .agents в своей работе.

Попробуйте Herdr

По долгу службы я использую самые разные инструменты и какое-то время экспериментировал с herdr.

Очень рекомендую присмотреться тем, кто погоняет агентов в консоли.

Что в нём удобно:

- поддерживает много харнессов – можно рядом гонять клоды, кодексы, OpenCode и другие
- хорошо кастомизируется: если чего-то не хватает, можно накрутить свою интеграцию через плагины. Например, подключить внутреннюю систему контроля версий, чтобы показывать статус пиара рядом с сессией агента, или связать сессии с тикетами – любой каприз
- позволяет подключать удалённые тачки по SSH и менеджить локальные и удалённые сессии из одного окна
- запоминает раскладку: если засплитили экран под несколько сессий, после перезапуска восстановит вкладки, панели и рабочие директории
- показывает статусы агентов в боковой панели: кто работает, кто закончил, а кто ждёт вашего ответа. Удобно, когда сессий много
- позволяет отключиться и вернуться позже: пока сервер herdr работает, агенты продолжают выполнять задачи. Если оборвалось SSH-соединение с удалённой машинкой, работа на ней идёт дальше

Используете что-то подобное поверх ванильных харнессов? Или, может, знаете классные фичи в herdr?

Кстати, вступайте в чатик – там бывают интересные обсуждения.

Багфикс по расписанию

AI врывается в разные этапы SDLC. Сейчас экспериментирую с автоматизацией maintenance-части – сопровождения продукта.

Сделал cron-таску, которая периодически смотрит логи системы и анализирует частоту ошибок. Если она превышает заданный порог, в дело вступает агент.

Он локально дебажит и пытается воспроизвести ошибку, создаёт тикет с диагностикой, затем берётся за исправление. По результатам приносит PR.

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

Агент воспроизвёл сбой и исправил обработку отсутствующего файла: теперь в этом случае процесс сам освобождает ресурсы и завершает работу. Закрепил сценарий регрессионным тестом.

Человеку остаётся посмотреть исходную проблему, диагностику и правки. И если всё ок – нажать МЕРДЖ)

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

В общем, красота нечеловеческая!

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

#devfm

Когда агенту нужен браузер

Словил удивительное поведение в Codex: при работе с браузером получил ошибку, мол, ресурс запрещён. 0_0

Я его и так, и так уговаривал, просил подиагностировать – ни в какую. Говорит, просто запрещено, и всё.

Ну и в целом бывает, что настраиваешь какую-то машинерию и нужен браузер.

На этот случай рекомендую классный скилл agent-browser от Vercel.

#ai

А вы стали пилить больше фичей?

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

А всё ли из того, что пилится, реально нужно?

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

Задачи, до которых никогда не доходили руки
Это задачи, которые годами пылились в бэклоге. Опытный проджект раз за разом откладывал их со словами: «Скоро обязательно доберёмся».

И вот кладбище таких задач вероломно вскрыли. Задачи пошли в ход, и этим очень гордятся: «Видали, что мы сделали! Столько лет откладывали, а теперь взяли и сделали!»

Меня, честно говоря, такое пугает. Если задача месяцами или годами откладывалась, то, может, она и не нужна?

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

Теперь на такие скучные вещи просто нет времени. Нужно бежать, разработка стынет :)

И вот тут вопрос: а нужно ли это? Есть ли от этого реальный профит?

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

А сейчас: так-так-так, система сложная, встроиться в существующее решение непросто, да и агент не очень держит всё это в контексте… Что же делать? А давайте-ка просто рядом бабахнем нашлёпку, и всё будет супер.

Сама нашлёпка выглядит логичной и продуманной. А когда смотришь на систему и архитектуру в целом – ну херня же какая-то!

Хочу фичу, а то…
Может, видели эти горящие глаза? Приходит пользователь с запросом. Ты ему аккуратно говоришь, что это пока не приоритет, что не ложится в общую стратегию продукта. А тебе в ответ: «А давайте я сам пиар вам принесу».

И тут глаз начинает дёргаться, а в голове – пиар на +100500 -3. Пожалуйста, не нааада! Кто это будет поддерживать? Но это мало кого интересует.

Или вообще смотришь, а рядом уже растёт свой костыльный проект, который пытается решить какие-то локальные проблемы.

Поделитесь в чатике, как у вас с этим обстоят дела. А мне пора заканчивать писать, а то там сварился ещё один пиар в соседний сервис. Нужно занести коллегам :)

#devfm

Удивительная стойкость и профессионализм

Все мы знаем слова SLA, отказоустойчивость, высоконадёжные системы и Кабанчика тоже читали. И обычно, когда говорим об этом, представляем неприятности типо: нагрузка выросла, реплика не успевает, сервак потух.

А тут случилось невероятное: серьёзно повреждены несколько крупных дата-центров Яндекса.

Я пытаюсь представить масштаб проблемы — и не получается.

И я, конечно, искренне восхищаюсь людьми, которые всё это проектировали. Теми, кто заранее думал, что может пойти не так, закладывал резервирование и продумывал восстановление.

Теми, кто из раза в раз проводил учения с отключением дата-центров, проверяя надёжность сервисов. Несмотря на недовольство: «Ну всё же и так работает, всё ок».

И теми, кто прямо сейчас всё это чинит и поднимает упавшее. Когда одна решённая проблема открывает следующую, мощности ограничены, а любое действие приходится продумывать на несколько шагов вперёд. И при этом ещё как-то находить время поспать.

В общем, это невероятно сложная ситуация. Но мы справимся, и всё будет работать. Потому что у инфры есть такой девиз: «Работаем, чтобы работало».

А вы храните .md в проекте?

Частая тема для обсуждения: вот мы написали план для агента – стоит ли коммитить его в проект? Нужен ли он там после того, как задача сделана?

Кажется, единого подхода пока нет. Даже если решили хранить, остаётся вопрос: что конкретно и зачем?

Я обычно не хранил такие документы в репе и до сих пор не храню. Зачем агенту какие-то дизайн-доки из прошлого? В процессе реализации мы могли что-то поменять, и в итоге документ рассказывает одно, а код делает другое (часто видел неактуальное говнище в репах). Чтобы рассинхрона не было, нужно поддерживать документы в актуальном состоянии и городить вокруг этого какую-то машинерию. В общем, волевое решение «теперь храним планы в репе» требует дополнительных приседаний.

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

Он предлагает относиться к маркдауну как к исходникам и хранить часть таких файлов в /src/md, рядом с кодом. В них фиксировать, как должна работать система, почему приняты те или иные решения и какие есть ограничения. Вплоть до деталей реализации, моделей данных и API.

По сути, разработчик не пишет разовые промпты на разработку, а готовит и обновляет артефакты в маркдауне. Затем передаёт их агенту, который на их основе пишет код и тесты. Тесты проверяют поведение автоматически, а маркдаун объясняет замысел в форме, удобной и человеку, и агенту.

Аргумент – весь этот контекст остаётся рядом с реализацией. Его можно искать, смотреть в diff и ревьюить в PR. Он не теряется в истории промптов, и за объяснением конкретного модуля не нужно каждый раз идти в вики или переписку.

Но мой вопрос всё ещё остаётся: как надёжно поддерживать синхрон между этими файлами и кодом?

А вы что сохраняете после работы с агентом? И как поддерживаете актуальность?

#ai

Ну это просто что-то замечательное. Пятничное развлекательное:)

Как использовать мессенджеры для повышения ярости в команде

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

• Пользоваться функцией меншена отдельных людей недостаточно. Активно используй everyone и here, чтобы показать, что твой вопрос важен.
• Голосухи. Ну это классика. Но ты можешь пойти дальше: ставь задачи на разработку голосухами, так ты шокируешь даже тимлидов, которые думали, что повидали все в своей жизни.
• Напиши «у нас серьезная проблема» и пропади. Это создаст ощущение драматичности момента, чтобы подчеркнуть что проблема реально серьезная.
• Кидай ссылки на статьи и посты без своих комментариев. Кто не понял к чему это - его проблема. В идеале, чтобы статья была недельной давности.
• Если решил отправить скриншот, то только фоткой экрана монитора дрожащей рукой. Камера телефона гораздо лучше передает цвета да и это тупо удобнее.
• Обращайся «коллеги», потому что ты же коллегам пишешь.
• Капс. Невозможно довести команду, если ты не пользуешься капсом. Каждый дополнительный восклицательный знак к капсу - плюс 1 пункт к ярости команды. СРОЧНО удваивает накопленную ярость.
• Если одно сообщение можно разбить на 10 (например, в сообщении 10 слов) - сделай это.
• Если потенциал групповых чатов исчерпан, переходи на личку. Используй треды в личных сообщениях, чтобы дезориентировать собеседника.
• Пиши «У НАС ЛЕЖИТ САЙТ!!!!!!!!!!!».

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