Иногда запрос на слияние (merge request) даже не стоит отправлять на код-ревью, так как при его составлении кто-то злоупотреблял искусственным интеллектом, и это повредило как проекту, так и команде. Например:

1. Удалив часть кода, можно значительно улучшить запрос на слияние

2. Вы не знаете основ языка, на котором подавали запрос

3. Спам в документации

4. Вопиющая несогласованность материала

5. Чрезмерно подробно рассмотрены пограничные случаи

6. Вы добавили бессмысленные или нежелательные зависимости и сами не понимаете, зачем.

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

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

Определимся с терминами

• Запрос на слияние (MR): когда программист в структурированном виде подаёт те изменения, которые предлагает внести в проект. Благодаря такой информации, каждому легко увидеть разницу «было-стало» и изучить внесённые изменения. Также называется "пул-реквест", этот термин пришёл с GitHub.

• Код-ревью (CR): когда другой программист проверяет MR, даёт обратную связь или предлагает улучшения, либо принимает или отклоняет изменения.

Почему я решил об этом написать?

Я считаю себя вправе об этом написать, так как:

1. Я старший исследователь-информатик, специализируюсь на ИИ и облаке. Я был техническим наставником, подготовил примерно 20 студентов и джунов.

2. У меня есть учёные степени и опыт работы как в информатике, так и в преподавании.

3. Я разбираюсь в коде и ИИ. Мой проект с ИИ установлен на миллионах машин и приносит мне ежемесячный доход.

4. Я уделяю массу личного времени и с удовольствием исследую и обсуждаю связанные с ИИ новости и прорывы.

5. Я не ищу работу и ничего не продаю. Я не инвестор и не CEO, впаривающий ИИ-шлак, а также мне никто не платит за порицание ИИ.

Зачем делать код-ревью?

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

1. Авторы учатся и растут над собой

2. Рецензенты учатся и растут над собой

3. Проверяется, насколько корректны все важные изменения

4. Минимизируется когнитивная нагрузка человека и объём работы для ИИ

5. Получается самосогласованный и простой код

6. Каждый принятый запрос на слияние идёт на пользу проекту

7. Авторы отвечают за свой код и могут его обосновать

Разбор причин, по которым я отклоняю запросы на слияние

1) Удалив часть кода, можно значительно улучшить запрос на слияние

Легко ли удалить часть кода без последствий?

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

2) Вы не знаете основ языка, на котором подавали запрос

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

3) Спам в документации

Однажды мне попались две практически идентичные копии документации, только в разных форматах.

Так нарушаются принципы «рецензент учится» и «на пользу проекту».

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

4) Вопиющая несогласованность материала

Распространённые примеры такого рода, которые мне попадаются, связаны с использованием новых стилей и фреймворков при логировании и модульном тестировании.

Так нарушаются принципы, связанные с «самосогласованностью» и «когнитивной нагрузкой». Чтобы понять софтверный проект, и человеку, и ИИ требуется одновременно оперировать десятками (скажем, 50) концепций, «держа их в уме». Мы хотим довести это количество до 200? Если не умеешь управлять сложностью и согласовывать материал, то проект парализуется, поскольку ни человеку, ни нейронке «не хватает ума», чтобы его развивать.

5) Чрезмерно подробно рассмотрены пограничные случаи

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

Если мы реализуем фичу ценой двадцати новых багов и непротестированных пограничных случаев, проект от этого лучше не становится. Всё равно, что вы сделали шаг вперёд (прогресс), но упали в глубокую грязную лужу.

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

6) Вы добавили бессмысленные или нежелательные зависимости и сами не понимаете, зачем

Так нарушаются принципы «рецензент учится» и «ответственность за свой код». Рецензент может задать вопрос: «А зачем здесь вот эта новая штука»? И автор не вправе отвечать: «Не знаю, так нейронка подсказала». Так вы можете приучить команду пользоваться нежелательным инструментом или инструментом, который не подходит для решения поставленной задачи.

Может и так нормально

Ни одно из этих правил не абсолютно. Я скорее склонен одобрить сгенерированный нейронкой запрос на слияние или отрецензировать его при одной из следующих оговорок:

• Передо мной временный код или экспресс-анализ, и этот код не рассчитан на длительную поддержку. Работает – и хорошо!

• В запросе на слияние объяснено, почему использовался искусственный интеллект, в какой степени, зачем, и какие дополнительные шаги автор проделал, чтобы проверить работу нейронки.

• Это второстепенная фича, а не базовый компонент.

Времена сейчас непростые

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

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

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