Как сохранять качество кода, когда джуниоры используют ИИ

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

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

Как выглядит проблема

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

Не спешите делать вывод о причине. Одинаковые симптомы могут означать разное:

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

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

Что известно об обучении с ИИ

Одно близкое к этой ситуации рандомизированное исследование опубликовано в январе 2026 года. В нем участвовали 52 преимущественно начинающих разработчика, которые не меньше года еженедельно писали на Python, имели опыт работы с ИИ-ассистентами, но не знали библиотеку Trio для асинхронного программирования. Каждый должен был реализовать две функции на Trio, а затем пройти тест на понимание: чтение кода, отладка, написание кода и вопросы по концепциям. Одна группа работала с ИИ-ассистентом в боковой панели чата, который по запросу мог выдать правильный код, другая писала вручную.

Средний результат теста составил 50% в группе с ИИ и 67% в группе без него. Разница между средними — 17 процентных пунктов; относительно результата группы без ИИ это примерно на четверть ниже. Наибольший разрыв был в заданиях по отладке. Группа с ИИ справилась примерно на две минуты быстрее, но разница не была статистически значимой — исследование не доказало ускорение.

Результаты сильно различались и внутри группы с ИИ. Участники, задававшие концептуальные вопросы, просившие код вместе с объяснением или уточнявшие после генерации, как работает решение, в среднем набирали не менее 65%. Те, кто полностью делегировал задачу или отладку, в среднем набирали меньше 40%. Но эти подгруппы были очень маленькими — от двух до семи человек, а анализ не устанавливает причинной связи между стилем работы и результатом.

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

Два более ранних контролируемых исследования дают дополнительный контекст. В одном исследовании 2022 года участники с доступом к тогдашнему ИИ-помощнику писали менее безопасный код и чаще считали его безопасным; участники, которые меньше доверяли помощнику и активнее уточняли запросы, допускали меньше уязвимостей. Это аргумент в пользу обязательной проверки, но не оценка современных моделей. В отдельном эксперименте 2023 года участники, использовавшие ИИ-помощника, реализовали HTTP-сервер на JavaScript на 55,8% быстрее контрольной группы. Это одна ограниченная задача; скорость выполнения ничего не говорит об освоении навыков или последующей поддержке кода.

Правила работы с помощником

Правила должны быть короткими, чтобы их соблюдали. Этот набор можно адаптировать:

1. Сначала сформулировать задачу своими словами. До обращения к ИИ разработчик записывает, что нужно сделать, какие есть ограничения и какой подход он предлагает. Достаточно двух-трех предложений.
2. В режиме обучения просить подсказку, а не готовое решение. Например: «Какой подход здесь уместен и почему?», «Что я упускаю?», «Объясни эту ошибку». Не начинать с «напиши функцию».
3. Проверять реализацию. Запускать каждую сгенерированную часть, покрывать ее тестом и перечитывать. Неизвестные функции библиотек проверять по документации.
4. Составлять список неизвестного. Перед ревью автор честно указывает, что в решении пока не до конца понимает. Это материал для наставника, а не повод для наказания.

Разницу между режимами видно по примерам:

Запрос в режиме доставки не «плохой». Он сам по себе не показывает, произошло ли обучение; для новой темы лучше отложить его, пока человек не поймет основу. Режим обучения часто дает и более точный ответ: разработчик уже описал свой план, то есть предоставил модели больше контекста.

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

Что изменить в ревью

Ревью — удобное место, чтобы увидеть, понимает ли автор свой код. Вопрос «это сгенерировано?» бесполезен: надежно отличить текст модели от человеческого нельзя, и это не главное. Важен смысл.

В описании pull request или на короткой встрече автор объясняет:

• инварианты: что всегда должно быть верно, например «сумма списания не превышает сумму заказа»;
• граничные случаи: пустой список, нулевая сумма, повторный запрос, таймаут внешнего сервиса;
• причину выбора: почему выбран этот подход, а не очевидная альтернатива.

Рецензент проверяет не стиль, а эти объяснения: выполняется ли инвариант в коде, есть ли тест на крайний случай, рассматривалась ли альтернатива. Если объяснения нет, верните PR не с просьбой «переписать», а с конкретным вопросом: «Что произойдет, если платежный сервис ответит дважды?»

Практика самостоятельности

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

Короткие задачи без подсказок. Раз в неделю — небольшая задача на 30–60 минут без ИИ: исправить дефект, добавить тест, реализовать простую функцию. Цель — не контроль, а тренировка самостоятельного мышления.

Разбор дефектов. Когда в коде джуниора находят ошибку, он сам ее воспроизводит, объясняет причину и предлагает исправление. Наставник помогает вопросами, а не готовым ответом.

Повторная реализация. После объяснения от ИИ или наставника разработчик закрывает подсказку и реализует решение заново самостоятельно.

Учебное упражнение: обработчик платежа

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

1. Объяснить повторную доставку. Платежный сервис может отправить одно событие дважды. Что сделает код? Не спишет ли товар дважды?
2. Объяснить проверку суммы. Где код сверяет сумму платежа с суммой заказа? Что произойдет при частичной оплате?
3. Объяснить границу транзакции. Если статус заказа изменился, а списание со склада завершилось ошибкой, в каком состоянии окажется система?
4. Написать тест на повторное событие: одно событие приходит дважды, товар списывается один раз.
5. Показать поведение при таймауте: база не ответила вовремя; что увидит платежный сервис и отправит ли событие повторно?

Наставник ведет простую таблицу прогресса:

Как оценить результат

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

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

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

Итог и первые шаги

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

Что можно сделать в следующем спринте:

1. Ввести два режима — обучение и доставка — и явно выбирать режим для каждой задачи джуниора.
2. Добавить в шаблон pull request три поля: инварианты, граничные случаи и причина выбора решения.
3. Раз в неделю давать короткую задачу без ИИ и разбирать ее вместе.
4. После найденного дефекта просить автора воспроизвести его тестом и объяснить причину.
5. Вести таблицу наставника «понял — воспроизвел — исправил — объяснил компромисс».
6. Через несколько недель сравнить дефекты после ревью, повторяющиеся ошибки и способность объяснять с исходным уровнем; затем решить, что изменить.

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

Частые вопросы