AI Dev Podcast #8 / Дуализм Клода: как не пере-делегировать права Claude/Codex

Андрей задаёт рамку выпуска: с одной стороны, хочется, чтобы агент делал всё подряд — читал почту, писал код, тестировал функциональность, писал постановки, — с другой, это очень рьяный, но не вполне компетентный сотрудник, которого приходится ограничивать. Александр добавляет стадийность: этап подсказок в IDE, где инженер явно принимал или отвергал каждую подсказку, пройден, и в России, по крайней мере, к 2026 году агенты заработали вовсю; но без переделки инженерной системы агент быстро выдаёт много кода, слабо связанного с функциональными и нефункциональными требованиями и с дальнейшим развитием системы. Владимир начинал как все: разработчики втихаря, без всякого одобрения, ставили себе бесплатный Qwen, потом Codex, который, по его словам, в феврале-марте раздавал большие бесплатные лимиты, потом ушли на Claude. Восторг длился до момента, когда через две недели возвращаешься дописать функцию и видишь, что модель зацепила кучу вещей сбоку.

На рабочих проектах повторилось то же самое: как только моделям начали отдавать не автодополнение, а осмысленный функционал, они стали править не то, о чём просили, и заодно «чинить» то, что им показалось неудачным. Самый яркий случай — авторизация во внутреннем сервисе: в ходе итерации агент предложил просто удалить таблицу со всеми пользователями, ведь нет авторизации — нет проблемы. В студии замечают, что это не так масштабно, как «давайте пересоздадим Terraform», но нервирует другим: если этот случай ты поймал случайно, что осталось незамеченным. Глобальных потерь не было — агентам в принципе не дают доступ в продакшен, только чтение метрик. Дальше команда пошла искать методологию, которая ограничит свободу, и из существовавших тогда больше всего понравилась AIDLC от Amazon: подробный препринт и отдельная лаборатория, которая её развивает. Её взяли за основу, выпилили набор инструментов Amazon и привязку к их облаку, добавили свои ограничения и проверки код-стайла.

Вторая перемена — документация. Гонять модель в Confluence на каждый запрос дорого по токенам и ненадёжно, а выдавать ей права на правку вики чревато последующими разбирательствами, куда что пропало. Поэтому user story, архитектурные решения и объяснения, почему сделали именно так, перенесли в Git рядом с кодом, а в Confluence оставили внешние взаимодействия: диаграммы развёртывания и описания API, которыми делятся с соседними командами. Сам процесс собран не как инструмент, а как набор скилов — так контекст не перегружается. Базовые подгружаются везде: код-стайл (у команды это Python), setup проекта, который создаёт структуру папок и кладёт в корень файл для текущей модели, и общий скил AIDLC common с правилами, шаблонами безопасности и указанием, когда нужно отдельное архитектурное решение.

В Inception намерение превращается в user story с обязательным форматом — кто, как, когда и какой результат хочет получить, с позитивными и негативными примерами — и разбивается на юниты. Спринтов нет, есть болты длиной в одну-две сессии кодинга, но с законченным результатом; юниты Владимир сравнивает с эпиками в Jira. Он хочет, чтобы обе фазы проходил продукт: нагрузка почти нулевая — сформулировать намерение и подтвердить сгенерированные формулировки, риски и нефункциональные требования, — но продукты отлынивают, и чаще идёт аналитика. Construction — это доменная модель, архитектурные решения, генерация кода, инфраструктура как код и внешние клиенты; protobuf-клиент пробовали, ложится почти нативно, только скилы всё время сносят в сторону REST. В Operation деплой и эксплуатацию сопровождает SRE-агент: смотрит графики в Grafana, собирает метрики в Prometheus и спамит предупреждениями — разрешить ему сразу чинить было бы здорово, но пока боятся.

Четыре governance-скила запускаются на переходах между фазами, обязательно на релизе и по явной просьбе проверить, что ничего не нарушено. Проверка ADR смотрит, что у нового юнита вообще есть архитектурное решение, что оно не нарушает внутренние правила из папки с референсами и не конфликтует со старыми решениями; отдельный шаг перечитывает прошлые ADR и сильно раздувает контекст — на Qwen эта проверка умирала, её вынесли в подагентов и запускают в чистой сессии. При сильном конфликте выбор возвращают человеку, а в устаревшее решение дописывают комментарий. Traceability строит MD и CSV: номер story, путь через болты и ADR, где смотреть результат; матрицу смотрят глазами редко, удобной аналитики по ней ещё не придумали. Health check следит не за живостью приложения, а за целостностью процесса: форму с календариком попросили переключать по месяцам и кварталам — проверка укажет на конфликт поведения. Security review основан на наборе правил Microsoft, название которого Владимир не вспомнил, и работает как SAST с уклоном в безопасность.

Отдельная дискуссия — ADR против спеки. Александр, который сейчас читает книгу про AI-assisted engineering и обещал автору фидбэк, считает ADR застывшим во времени, а спеку — живой вместе с фичей, и в своих пет-проектах ходил смотреть именно спеки. Владимир начинал так же, с пяти-шести крупных ADR уровня «взяли Kafka, а не кролика», но в итоге сделал ADR любое заметное решение проекта, и спеки у него слились с ADR. По числам: два проекта полностью в проде, один близок, к концу квартала ждут ещё около шести, с отзывами приходило человек пятнадцать. Показательный кейс — админка, которую писали два года: один инженер две недели переписывал её с Java на Python в одиночку, показал первый результат, потом к нему добавили ещё двоих, и втроём закончили меньше чем за два месяца. Их фидбэк укоротил ADR и вернул в процесс трассировку. Впереди браунфилд с двумя десятками разработчиков; Александр напоминает, что такие процессы держатся на энтузиазме инициатора. В скилы много добавили после вопросов новичков «а как этим вообще пользоваться», чтобы они сами вели пользователя по шагам.