Ассистенты для программирования в senior-команде: правила, которые защищают качество

Что ломается, когда правила расплывчаты

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

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

Ревьюеры чувствуют это первыми. Один коммит выглядит как безобидный рефакторинг. Следующий меняет обработку ошибок на пути, который падает в продакшене раз в месяц. Поскольку риск распределён неравномерно, люди читают больше, а не меньше.

Настоящее расхождение во мнениях часто всплывает слишком поздно. Один инженер считает, что ассистент может трогать только тесты и документацию. Другой думает, что он может рефакторить продакшн-код, если тесты остаются зелёными. Этот спор должен происходить до промпта, а не после открытия pull request.

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

Такая неопределённость меняет и поведение людей. Одни авторы скрывают использование ассистента, потому что ожидают сопротивления. Другие вставляют большие diff’ы и надеются, что тесты поймают риск. Оба подхода ухудшают ревью, потому что команда теряет общее понимание того, что считается нормой.

Доверие тихо падает. Ревьюеры перестают доверять размеру коммита. Авторы перестают доверять обратной связи. Менеджеры перестают верить обещанной экономии времени. Проблема не в инструменте. Проблема в отсутствии границы.

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

Сначала задайте scope файлов, потом пишите промпт

Команда теряет контроль, когда в промпте написано «обнови onboarding», а какие именно файлы менять — никто не назвал. Ассистент заполняет пробелы догадками, а догадки быстро расползаются по репозиторию. Scope файлов должен быть задан до первого промпта, а не после того, как diff стал грязным.

Начните там, где ошибки стоят дёшево. Документация, тесты и небольшие модули с малым числом зависимостей — хорошие места для старта. Обычно они затрагивают меньшую часть системы, а проверить и откатить их проще.

Потом проведите жёсткую границу вокруг кода, где всегда нужен человеческий здравый смысл. Auth, billing, data deletion и database migrations должны оставаться под запретом, если только инженер не одобрил очень узкую задачу. Одна неверная догадка там может заблокировать пользователей, списать деньги не с того счёта или удалить данные, которые уже не вернуть.

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

Политика может быть простой: разрешить раннее использование в документации, тестах и модулях с низкой зависимостью; защищать auth, billing, потоки удаления и migrations; требовать, чтобы инженеры называли точные файлы перед каждым промптом; отклонять размытые запросы вроде «почини весь flow» или «обнови всё, что связано с этим».

Последнее правило важнее, чем кажется. Change price_rules.go and pricing_test.go ставит модели забор. Update the pricing system зовёт её блуждать.

Одна продуктовая команда использовала это при исправлении бага в checkout. Инженер ограничил ассистента одним файлом валидатора и одним тестовым файлом, устранил проблему и оставил платёжный поток в покое. Для небольшого бага это казалось жёстким, но зато сократило время ревью и помогло избежать более крупной чистки позже.

Требуйте доказательства для изменений поведения

Когда изменение влияет на поведение, в pull request нужны доказательства из тестов, а не заметка «теперь должно работать».

Попросите две вещи: доказательство, которое падало до исправления, и доказательство, которое проходит после него. Это может быть падающий тест, понятный failing output или короткая reproduction. Смысл в том, чтобы дать ревьюерам что-то конкретное для проверки.

Доказательство должно совпадать с заявлением. Если ассистент говорит, что исправил баг с часовым поясом в расписании, ревьюеры должны увидеть тест именно для этого часового пояса. Зелёная сборка по не связанным тестам почти ничего не доказывает. Если ассистент утверждает, что улучшил retry logic, показывайте тесты на повторы, а не просто скрин того, что приложение загрузилось.

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

Это правило должно оставаться строгим. Отклоняйте pull request’ы, которые опираются на комментарии вроде «fixed», «works on my machine» или «модель проверила логику». Они экономят минуту сейчас и стоят часов потом.

Возьмём простой пример с checkout. Если ассистент меняет округление цены, в pull request нужно показать падающий тест для старого случая округления и тот же тест, который проходит после исправления. Полностью зелёный тестовый набор всё равно не говорит ревьюеру, изменился ли этот баг вообще.

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

Помечайте рискованные типы изменений простыми словами

Senior-команда не должна спорить о риске после того, как код уже написан. Перед началом работы назначайте простой ярлык каждой задаче или pull request, если там используется ассистент.

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

Изменения схемы всегда относятся к самой высокой категории. Новая колонка или индекс в diff’е могут выглядеть мелочью, но они способны сломать старый код, замедлить запросы или оставить выкладку незавершённой. Если ассистент меняет форму базы данных, команде нужно спросить про план миграции, план отката и доказательство того, что старый и новый код могут работать вместе во время релиза.

С тем же вниманием нужно относиться к безопасности, денежным потокам и concurrency. Одно маленькое правило доступа может открыть не те данные. Одно изменение в платеже может списать деньги дважды или пропустить возврат. Один пропущенный lock, retry-правило или проверка очереди может породить баги, которые проявляются только под нагрузкой, а значит их трудно найти и дорого исправлять.

Командам также нужна чёткая граница между чисткой и изменениями поведения. Переименование переменных, переписывание комментариев и переформатирование файлов — в одну корзину. Если ассистент меняет то, что код делает, даже немного, переносите это в другую категорию и проверяйте тщательнее.

Количество файлов тоже важно. Безопасное на вид изменение в одном файле легко понять. Та же схема, размноженная на 15 файлов, — это уже другой уровень риска, даже если каждая правка по отдельности выглядит безобидно. Общие типы, shared helpers и кросс-сервисные изменения заслуживают более строгого ревью, потому что одна неверная догадка может разойтись далеко.

Если две метки подходят, выбирайте более высокую. Так ревью остаётся понятным, и «маленьким» AI-изменениям сложнее проскользнуть в продакшн с большими последствиями.

Внедряйте это маленькими шагами

Медленный запуск лучше широкого релиза. Начните с одной команды и одной части репозитория, где ошибки легко заметить и легко откатить. Внутренние инструменты, тестовые помощники или простая UI-работа подходят лучше, чем auth, billing, data migrations или всё, что может быстро сломать продакшн.

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

Вам не нужна длинная политика. Ограничьте правки ассистента одной названной папкой или сервисом. Требуйте тесты и lint для любого нетривиального изменения. Блокируйте большие diff’ы в CI, если их не одобрил ревьюер. Помечайте изменения схемы, auth-кода, платёжной логики и потоков удаления как рискованные. Просите ревьюеров подтверждать, что изменение осталось в рамках scope.

Сразу добавьте проверки в CI. Озвученные правила исчезают, когда команда занята. Проверка тестов, lint-проверка и контроль размера diff ловят простые ошибки ещё до начала ревью. Тогда у ревьюеров остаётся только то, что действительно требует суждения: понятно ли изменение, верно ли оно и стоит ли его оставлять.

Каждую неделю проверяйте пилот, но держите этот обзор коротким и фактическим. Смотрите на переделки, упавшие тесты, откаты и комментарии к ревью. Если одна и та же проблема появляется дважды, меняйте правило. Обычно слабое место видно сразу: scope файлов был слишком широким, доказательство слишком тонким или ассистент тронул код, который пока не должен был трогать.

Это совпадает с тем, как Oleg Sotnikov описывает AI first operations: сначала сужайте возможный ущерб, измеряйте результат, потом расширяйте. Порядок важен.

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

Простой пример из продуктовой команды

Продуктовой команде нужен небольшой change в signup. Маркетинг хочет более понятные сообщения об ошибках, а support — ещё одно правило для длины пароля. Это разумный случай для ассистента, потому что работа узкая и её легко проверить.

Инженер сначала задаёт scope файлов. Ассистент может обновить validation tests, test fixtures и небольшой helper, который влияет только на эту форму. Ему нельзя трогать платёжный код, таблицы базы данных, файлы схемы или что-либо, связанное с billing аккаунта.

Это ограничение важнее, чем сам промпт. Команда держит рискованные зоны вне игры, поэтому никому не нужно гадать, не зашёл ли быстрый AI-редакт в часть продукта, которая может сломать billing или сохранённые данные.

Pull request остаётся простым: точный промпт, diff ассистента и прогон тестов, который доказывает, что изменение работает.

Ревью остаётся строгим. Один senior-инженер читает промпт, чтобы понять, что именно просили у ассистента. Другой проверяет diff и вывод тестов. Если тесты покрывают только простой путь, они просят больше.

Во время ревью они замечают одну рискованную функцию. Ассистент изменил общий валидатор так, что это могло повлиять на другие формы. Человек переписывает эту функцию вручную до merge и оставляет AI-сгенерированные обновления тестов.

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

Результат скромный, и это обычно хороший знак. Инженер экономит около 30 минут на повторяющихся правках тестов. Качество ревью не падает. Никто не снижает стандарт доказательств, и никто не считает код, написанный с помощью AI, чем-то особенным.

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

Ошибки, которые быстро снижают стандарты

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

Одна частая ошибка — дать ассистенту слишком широкую область для правок одним промптом. Если он может тронуть целый сервис или несколько папок, ревьюеры перестают видеть настоящий риск. Изменение, начавшееся как «исправить баг валидации», может незаметно одновременно поменять логирование, кэширование, конфигурацию и обработку ошибок.

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

Есть несколько повторяющихся паттернов. Один промпт редактирует файлы, которые должны были остаться вне scope. Тесты проходят, но они покрывают только простой путь и не видят реальный сценарий отказа. Большой diff мерджат только потому, что большая его часть выглядит как безобидная чистка. Ревьюеры расслабляются, потому что код выглядит обычным, а ассистент написал его быстро. Потом команда винит инструмент вместо того, чтобы исправить правило, которое пропустило ошибку.

Зелёные тесты всё ещё могут скрывать плохое изменение. Допустим, ассистент обновил API handler, и все unit tests прошли. Если никто не проверил правила авторизации, поведение повторных попыток или странный входной случай из продакшена, эти тесты доказали очень мало. Пройденные проверки — не доказательство, если они пропускают ту часть, которая может навредить пользователям.

Большие diff’ы — ещё одна ловушка. Именно в чистке удобно прятать переименованные поля, изменённые значения по умолчанию и переставленные условия. Если ревьюеру нужно десять минут только чтобы понять, что вообще поменялось, diff слишком большой.

Пропуск ревью ещё хуже. Senior-команды должны проверять результат ассистента тщательнее, а не слабее. Код может компилироваться, совпадать с локальным стилем и всё равно содержать плохую догадку.

Если это происходит, чините процесс, а не спорьте об инструменте. Сужайте scope файлов. Просите доказательства, связанные с риском. Делите большие diff’ы. Если одна и та же ошибка случается дважды, значит правило было слишком мягким.

Быстрые проверки перед merge

Для проверки перед merge нужны пять прямых вопросов. Они занимают около минуты и ловят большую часть ущерба, спрятанного в аккуратных на вид diff’ах.

Сначала проверьте список файлов. Автор должен назвать ожидаемые файлы до начала ревью. Если diff затронул лишние файлы, спросите почему. Неожиданные правки — это место, где прячутся плохие догадки.

Просите доказательства, а не намерения. Комментария «это должно работать» недостаточно. В ветке должны быть тесты, логи, скриншоты или короткий repro, показывающий заявленное поведение.

Сразу смотрите на рискованные зоны. Если изменение затрагивает auth, billing, permissions, data deletion, imports, exports или что-то, что пользователь не может отменить, замедляйтесь и проверяйте вручную.

Читать diff нужно так, как будто вы новый участник команды. Если причина изменения расплывчата, код ещё не готов. Короткая заметка в pull request должна объяснять, что изменилось, почему это изменилось и что не изменилось.

Сделайте откат простым. Один небольшой коммит лучше, чем смешанный набор из рефакторинга, вывода ассистента и правок конфигурации. Если релиз пойдёт не так, нужен один чистый revert.

Именно здесь доказательства становятся настоящими. Пройденный unit test всё ещё может не попасть в точку, если он проверяет только замоканный путь. Если пользователь может потерять доступ, получить двойное списание или удалить данные, попросите один тест или демо, которое показывает полное поведение end to end.

Небольшой пример показывает, почему размер может ввести в заблуждение. Ассистент обновляет checkout flow, и diff всего 40 строк. Звучит безопасно. Но если эти 40 строк меняют retry logic вокруг списания платежа, проверка уже не про размер. Она про цену ошибки.

Когда один ответ слабый, не начинайте десять комментариев подряд. Верните изменение с узкой просьбой: сузить scope, добавить доказательства или разделить коммит. Хорошие команды держат стандарт высоким, потому что делают следующий шаг очевидным.

Что делать дальше

Начните с одного безопасного сценария в следующем спринте. Выберите работу, которую легко проверить и легко откатить, например обновление тестов, небольшой рефакторинг внутри одного модуля или повторяющиеся правки типов. Не начинайте с auth, billing, permissions, migrations или чего-то, что может повредить данные.

Этот первый выбор определяет, как команда воспримет эксперимент. Узкий пилот даёт ревьюерам честный шанс нормально проверить код. Если ассистент ошибётся, ущерб останется небольшим.

Запишите три запретные зоны и разместите их там, куда команда уже смотрит каждый день, а не в забытом документе: никаких changes схемы или data migrations, никаких правил auth, payment или permissions, и никаких изменений поведения, написанных AI, без тестового доказательства.

Затем добавьте короткий шаблон ревью в каждый pull request, где использовался AI. Хватит трёх вопросов: какие файлы были в scope, какая метка риска применяется и какое доказательство подтверждает изменение. Это занимает около минуты и отсекает размытые одобрения вроде «всё ок».

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

Если хотите внешний взгляд, Oleg Sotnikov на oleg.is работает Fractional CTO и помогает стартапам и небольшим командам выстраивать практичные ограничения вокруг разработки с AI, инфраструктурой и автоматизацией. Если команда всё ещё ищет границы, короткий разбор процесса может сэкономить много споров позже.

К следующему планированию спринта сделайте три вещи: выберите безопасный сценарий, опубликуйте запретные зоны и добавьте шаблон ревью. Этого достаточно, чтобы начать учиться, не снижая планку.