Правила передачи PR с кодом, созданным ИИ, в реальных командах разработки

Почему PR, сгенерированные ИИ, создают путаницу

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

Проблема усугубляется, когда PR выглядит как обычная человеческая работа. Если ассистент написал запрос, тест и половину рефактора, но эти части не помечены, ревьюеры не понимают, где им нужно замедлиться. В итоге они проверяют стиль и имена, упуская более важный вопрос: кто на самом деле понимает этот код?

ИИ может сгенерировать код, который выглядит завершённым до того, как кто‑то всё продумал. Он часто достаточно совпадает с локальными паттернами, чтобы пройти быстрый просмотр, даже если добавляет краевые случаи, скрытые предположения или дополнительную сложность. Команда сливает такой PR, потому что «кажется, всё ок», а потом тратит полдня на поиск бага, который никто не может объяснить.

Первое давление чувствуют ревьюеры. Они могут не хотеть блокировать PR только потому, что помог ассистент. Но им не стоит становиться первыми, кто вникает в незнакомую логику построчно. Как только ревью, авторство и верификация смешиваются, процесс становится неряшливым.

Малые команды чувствуют это сильнее. Стартапы движутся быстро, и ИИ делает эту скорость труднопреодолимой соблазнительной. Без ясных правил передачи команда может скатиться от «человек использовал инструмент» к «инструмент сформировал изменение, и никто не отвечает за результат».

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

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

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

Чем должен заниматься ассистент

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

Ему часто полезнее работать вокруг кода, чем внутри него. Локальные правки приемлемы, если они остаются в пределах изменения и не расползаются по несвязанным файлам или большим архитектурным решениям. Хорошие применения включают:

• черновую подготовку unit‑тестов для конкретной функции, хендлера или компонента
• предложения комментариев там, где правило легко пропустить
• аккуратный рефактор небольшой области внутри того же файла или модуля
• написание заметок к PR, объясняющих поведение и краевые случаи

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

Ассистент также должен явно указывать свои предположения в заметках PR. Если он предположил, что поле может быть null, угадал, что старый эндпоинт всё ещё требует обратной совместимости, или решил, что таймаут в 30 секунд приемлем, ревьюер должен увидеть это простым языком. Скрытые догадки делают ревью грязным.

Некоторые вводные остаются под запретом. Ассистент не должен использовать секреты, боевые учётные данные, данные клиентов, приватные тикеты или сырые логи с персональными данными. Работайте с моками, редактированными примерами и тестовыми фикстурами. Он не должен открывать env‑файлы, вставлять токены в инструменты или проверять живые продакшен‑данные, чтобы «разобраться».

Эта линия сохраняет преимущество скорости, не превращая черновик в проблему безопасности.

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

Ассистент может черновать много кода. Но он не должен завершать каждый pull request. Как только изменение может повлиять на деньги, доступ или постоянные данные, человек должен владеть финальной частью работы.

Передавайте изменение человеку, когда PR затрагивает:

• логин, роли, токены, сессии или проверки прав доступа
• биллинг, ценообразование, счета, подписки, возвраты или лимиты использования
• запросы, которые раскрывают приватные записи или данные между аккаунтами
• схему базы данных, миграции, бэкофилы или логику удаления
• общую архитектуру: общие библиотеки, API, контракт очередей или процесс деплоя

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

Тот же передаточный момент нужен, когда сама задача неясна. Если отчёт об ошибке расплывчат, логи указывают в разные стороны или спецификация продукта конфликтует со старым поведением — остановите AI‑only работу рано. Ассистент может резюмировать найденное, перечислить открытые вопросы и предложить несколько безопасных вариантов. Разработчик или технический лидер должен выбрать путь.

Изменения схемы требуют осторожности, потому что их трудно отменить под нагрузкой. Логика удаления имеет ту же проблему. Одна неправильная условная проверка может стереть записи, оставить данные сиротами или сделать след аудита бесполезным. Эти изменения нуждаются в человеке, который понимает историю приложения, а не только файл, который редактируется.

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

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

Простой поток передачи

Этот процесс работает потому, что он короткий.

1. Пометьте задачу по риску до того, как кто‑то откроет ветку. Короткая заметка в тикете — достаточно. Копировочные фиксы и мелкие рефакторы низкого риска. Auth, биллинг, права, миграции и всё, что может испортить данные, начинаются как высокорискованные.
2. Попросите ассистента подготовить черновой PR, патч или идею теста. Не просите финального ответа. Попросите также предположения, чтобы слабые места были видны.
3. Человек должен запустить код локально, протестировать обычные и «грязные» сценарии и завершить те части, которые ассистент обычно пропускает. Обычно это валидация, сообщения об ошибках, уборка, нейминг и мелкие правки, которые облегчают ревью.
4. Ясно пометьте PR. Укажите, в каких файлах помог ИИ, какие переписал человек и где логика изменилась во время уборки.
5. Отправляйте PR на ревью только тогда, когда один человек может объяснить каждое изменение, почему оно сделано и что ещё может сломаться.

Это сохраняет ясность владения. Ассистент добавляет скорость. Человек добавляет суждение.

Стартап может держать процесс лёгким. Если задача — «добавить пропущенную проверку null на внутренней админ‑странице», ассистент может сначала подготовить правку, а инженер доделает её за десять минут. Если задача затрагивает суммы в счётах, инженер должен написать или переписать рискованные части вручную, а затем использовать ИИ для тестов, комментариев или скучного «склеивающего» кода.

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

Кто владеет результатом

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

Это снимает много неясностей. ИИ может предложить код. Он не может нести ответственность.

Ревьюеру отведена другая роль. Ревьюер проверяет, ясен ли код, соответствуют ли тесты изменениям и не вышел ли PR за оговоренную область. Расширение области важно с ИИ, потому что небольшой промпт может превратиться в гораздо большее изменение, чем кто‑то просил.

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

Простая политика обычно выглядит так:

• один человек — ответственный автор на каждом PR
• один ревьюер проверяет качество кода, тесты и область изменений
• второй утверждающий необходим для изменений с риском для безопасности или продакшена
• никто не сливает собственный PR без требуемого утверждения

Держите правило коротким и скучным. Если для слияния мелкого фикса нужна блок‑схема, люди пропустят её в момент давления.

Полезный тест: если баг появляется через неделю, может ли команда сказать, кто одобрил дизайн, кто проверил код и кто принял риск? Если нет — ужесточите владение до того, как добавлять больше ИИ в рабочий процесс.

Реалистичный пример

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

Ассистент получает узкую задачу: исправить валидацию, оставить изменение внутри формы и обновить тесты. Он подготавливает PR, который обрезает ввод перед сохранением, блокирует отправку, если поле пусто после обрезки, и показывает короткое сообщение об ошибке под полем.

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

Этот черновик полезен, но не готов к слиянию. Инженер читает патч и сразу замечает шероховатости.

Имя помощника слишком расплывчатое, например checkFieldValue, поэтому инженер переименовывает его в isValidReportEmail. Ассистент также пропустил краевой случай: API может возвращать null для старых аккаунтов, и форма падает, если это значение сразу поставить в input. Инженер исправляет это и проверяет, что форма работает, когда пользователь никогда не редактировал поле.

Затем инженер тестирует поведение в браузере. Он вставляет e‑mail с пробелами, очищает поле, перезагружает страницу на старом аккаунте и убеждается, что сообщение об ошибке исчезает, как только ввод становится валидным. Ручная проверка важна, потому что UI‑баги часто прячутся в разнице между проходящими тестами и реальными кликами.

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

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

Ошибки, которые приводят к проблемам

Команды попадают в беду, когда относятся к помощи ИИ как к незначительному факту, а не как к части записи об изменении. Если pull request использовал ассистента, описание PR должно прямо об этом сказать. Сокрытие этого ослабляет ревью, потому что ревьюеры не знают, где им нужно замедлиться, перепроверить предположения или внимательнее читать сгенерированный код.

Маленькие фиксы часто становятся грязными по другой причине. Кто‑то просит ассистента исправить один баг, а тот переименовывает хелперы, переписывает тесты и трогает файлы, где проблем не было. Такой рефактор может выглядеть аккуратно на зелёном диффе, но усложняет инспекцию реального изменения. Для узкой правки держите область узкой.

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

Владение распадается быстрее, чем команды ожидают. Один человек промптовал ассистента, другой пробежал глазами код, кто‑то слил — и никто не чувствует полной ответственности за результат. Так плохой код доходит до продакшена. Один именованный человек должен взять PR и сказать: «Я прочитал это, я понимаю это и принимаю риск».

Рискованные изменения также требуют плана отката перед слиянием. Это пропускается чаще всего, особенно когда код выглядит простым. Но если PR затрагивает биллинг, auth, миграции, фоновые задания или общую инфраструктуру, команда должна знать, как быстро это откатить. Короткий план отката в PR может сэкономить много времени, когда продакшен начнёт странно вести себя в 16:00 в пятницу.

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

Быстрая проверка перед слиянием

Кнопка merge не должна быть моментом, когда команда догадывается, что делает PR. Если человек не может объяснить, зачем изменён каждый файл, PR не готов.

Используйте короткий чек‑лист:

• человек‑владелец может простыми словами объяснить назначение каждого изменённого файла
• в заметках PR указано, где помог ИИ: черновые тесты, предложение рефактора или начальный патч
• тесты покрывают изменённое поведение, включая хотя бы один провальный случай или краевой случай
• diff соответствует исходной задаче
• утверждающий проверил финальную версию, а не ранний черновик

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

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

Заметки в PR должны быть конкретными. «ИИ помог» почти ничего не говорит. «ИИ подготовил первый файл тестов и предложил изменение инвалидации кеша; разработчик переписал финальный хендлер» — намного полезнее. Это даёт ревьюерам контекст без превращения PR в признание.

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

Начните с малого и корректируйте

Не переписывайте всю инженерную политику за один раз. Начните с одного репозитория или одной команды, которая уже часто использует ИИ. Это даст вам реальные PR для изучения и сохранит ошибки недорогими.

Малый пилот расскажет больше, чем длинные дебаты. Если одна команда пишет бэкенд API каждую неделю — начните там. Если другая команда работает с биллингом или auth, оставьте эту область до тех пор, пока правила не устаканятся.

Ваш первый черновик может быть простым:

• определите, с чем ассистент может действовать самостоятельно
• пометьте виды изменений, которые требуют, чтобы человек довёл работу до конца
• укажите, кто утверждает PR и кто отвечает за баги после слияния
• запишите несколько проверок, которые должен пройти каждый PR перед утверждением

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

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

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

Большинству команд не нужна идеальная политика. Им нужна та, которой можно следовать в рабочий вторник. Чёткие точки передачи, ясное владение и короткая петля ревью — этого достаточно, чтобы начать.

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