Владение кодом ИИ: правила ревью, очистки и ответственность

Почему ИИ размывает владение

Разработчик может попросить модель сделать рефакторинг, отправить пару дополнительных подсказок и получить в итоге 800 изменённых строк, прежде чем кто‑то задастся вопросом — имеет ли предложенный подход смысл. Дифф выглядит насыщенным, поэтому кажется, что работа идёт быстро. Иногда это так. Иногда скорость скрывает слабые решения.

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

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

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

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

Быстрая генерация полезна. Размытая ответственность — нет. Если команде важно, чтобы владение чем‑то значило нечто большее, кто‑то должен владеть решением, а не просто диффом.

Назначьте одного владельца до первой подсказки

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

Хорошее владение начинается до того, как кто‑то попросит инструмент написать код. Укажите имя одного инженера в тикете, ветке или pull request. Этот человек принимает окончательное решение о слиянии, даже если ИИ написал половину диффа и три коллеги предложили правки.

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

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

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

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

Такая ясность лучше группового обвинения и лучше молчания. Одно имя на изменении сохраняет скорость, но и прикрепляет ответственность к работе.

Соотнесите глубину ревью с риском

Время на ревью должно соответствовать риску, а не размеру diff. Маленькое изменение в логике сброса пароля может навредить сильнее, чем большой UI‑ремонт. Здесь владение часто теряет чёткость: люди доверяют маленькому диффу, быстро мёржат, а позже выясняется, что изменение затронуло что‑то критичное.

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

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

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

Большие смешанные диффы создают ещё одну проблему. ИИ может быстро сгенерировать много аккуратно выглядящего кода, и это делает огромные pull request'ы нормой. Это не так. Если один дифф смешивает изменения схемы, бизнес‑правила, рефакторинг и UI‑обновления, ревьюеры начнут просматривать их бегло. Как только начинается поверхностное чтение, владение начинает исчезать.

Тесты также должны соответствовать риску. Новая логика, пограничные случаи, ретраи, проверки прав и расчёты денег заслуживают тестов до мёржа. Копирайт‑изменения или правки форматирования обычно такого не требуют. Цель простая: сохранить высокую скорость, но не позволять кому‑то сказать «ИИ написал — значит, я решил, что всё ок».

Планируйте очистку до мерджа

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

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

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

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

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

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

Сохраняйте ответственность после мерджа

Владение распадается, когда дифф попадает в main, проходит ревью, а потом никто не отвечает за первую неделю в продакшне. Мёрдж не должен завершать работу. Тот же человек, кто вел изменение, должен сопровождать его во время релиза и ранней поддержки.

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

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

Эта привычка ловит распространённую ошибку ИИ: код выглядел чистым в ревью, но ведёт себя странно под реальной нагрузкой. Модель может сгенерировать код, который проходит тесты и всё равно пропускает предположение про ретраи, null‑данные или права. Человек, близкий к изменению, увидит это быстрее, чем тот, кто читает код холодным взглядом.

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

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

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

Короткая заметка для диффов с участием ИИ

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

Держите заметку простой. Без длинных рассказов и общей воды. Если владелец не может объяснить изменение в пару строк, вероятно, не стоит мёржить.

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

Простой формат заметки

One short block is enough. For example:

AI drafted the first version of the billing retry worker and two test files.
Nina rewrote the retry limits, error handling, and database query.
Checked by hand: failed payment flow, duplicate retry guard, unit tests, and logs.
Still unsure: timeout behavior under heavy queue load.
Cleanup: simplify worker naming by May 14 - Nina. Add load test by May 16 - Sam.

Эта заметка делает две полезные вещи. Во‑первых, она показывает ревьюерам, где смотреть внимательнее. Во‑вторых, она предотвращает призрачное владение, где все предполагают, что кто‑то другой понимает рискованные части.

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

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

Продуктовая команда хочет добавить форму импорта CSV, чтобы клиенты могли загрузить контакты одним шагом. Один разработчик просит ИИ набросать первый вариант. Дифф быстро растёт. В нём форма, парсер CSV, валидация полей, состояния ошибок для битых файлов и небольшой набор тестов.

Здесь владение перестаёт быть абстрактным. Разработчик, который открыл задачу, держит своё имя на ней, даже если ИИ написал половину строк. Никто не говорит «модель добавила эту часть», как будто это снимает ответственность.

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

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

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

Фича уходит в прод. На следующий день клиент загружает CSV с неожиданным форматом даты, и импорт падает. Тот же владелец берёт продакшен‑инцидент, даже если другой инженер в тот день сидит на ротации поддержки. Это замыкает петлю между подсказкой, ревью, мерджем и влиянием на пользователя.

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

Ошибки, которые создают призрачное владение

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

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

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

Очистка часто умирает так же. Кто‑то говорит «потайчи́м это в следующем спринте», но тикета нет, даты нет, и владелец не назначен. Это не план.

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

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

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

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

Быстрая проверка перед мёрджем

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

1. Назначьте владельца. Укажите одного человека на дифф, даже если ИИ написал часть и несколько людей формировали подсказку.
2. Соотнесите глубину ревью с риском. Изменения копирайта и мелкие рефакторы можно быстро просмотреть. Аутентификация, биллинг, удаление данных, миграции или инфраструктурные правки требуют более медленного ревью и убедительных тестов.
3. Протестируйте изменённое поведение. Скриншоты счастливых путей недостаточны. Проверьте плохие входные данные, ретраи, пустые состояния, таймауты и ошибки прав доступа.
4. Запишите работу по очистке. Если дифф уходит с грубыми краями, создайте задачи‑поддержки с датами и именами.
5. Проверьте независимость от инструмента. Ревьюер должен объяснить, что поменялось, не открывая заново чат ИИ и не перезапуская подсказку.

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

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

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

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

Короткая стартовая политика обычно достаточна. Назначайте одного владельца до первой подсказки ИИ. Устанавливайте глубину ревью по риску, а не только по длине diff. Открывайте задачи по очистке до мёрджа, если код требует доработки. Держите одного человека ответственным после релиза. Добавляйте короткую заметку, когда ИИ написал часть изменения.

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

Некоторым командам нужен внешний взгляд, чтобы заметить паттерны, которые они перестали видеть. Oleg Sotnikov на oleg.is работает внештатным CTO и советником стартапов, и как раз с такими проблемами процесса он помогает командам: чётче правила ревью, яснее владение кодом и меньше путаницы после релиза.

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