Ассистенты ИИ для младших разработчиков: сохраняйте менторство живым

Почему это кажется рискованным

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

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

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

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

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

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

Люди ощущают этот риск, потому что уже видели похожие вещи раньше. Копирование кода с форумов создавал тот же эффект, но в меньших масштабах. Ассистент делает этот паттерн быстрее, плавнее и сложнее для обнаружения, если сеньоры не смотрят дальше diff'а и не обращают внимания на путь, которым младший пришёл к решению.

Что проверять кроме diff'а

Diff показывает, что изменилось. Он редко показывает, как младший думал над задачей, а именно там происходит основное менторство.

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

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

Затем спросите, почему они выбрали этот подход. Не нужно устраивать лекцию. Вы слушаете простые причины вроде: «Я следовал тому же паттерну, что и в billing flow» или «Я попробовал сначала меньшее изменение, но оно не покрывало retries». Это показывает, сделал ли он осознанный выбор или просто принял первое, что предложил ассистент.

Ручная проверка тоже важна. Младшие часто говорят «я протестировал», имея в виду, что они лишь один раз прошли happy path. Спросите, что именно они проверяли вручную. Пытались ли они отправить пустое поле, эмулировать медленную сеть, кликнуть дважды, войти под другой ролью? Конкретные проверки показывают, что они думали о поведении, а не только о стиле кода.

Неуверенность — ещё один полезный сигнал. Спросите, где они всё ещё сомневаются. Многие скрывают это, потому что хотят выглядеть готовыми. Вам нужно обратное. Если младший говорит: «Я не уверен, что это корректно обработает concurrent updates» или «Не знаю, останется ли этот запрос быстрым при большем объёме данных», — у вас появляется реальная тема для обучения.

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

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

Задайте правила до первого промпта

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

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

Дайте каждой задаче одну учебную цель. Делайте её узкой: безопасная миграция базы, прослеживание состояния в React-форме, объяснение, почему тест падает. Эта цель меняет ревью: сеньор проверяет не только работает ли код, но и понимает ли младший выбор за ним.

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

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

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

Простая политика помещается на один экран:

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

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

Используйте простой цикл ревью

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

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

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

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

Небольшой цикл достаточен:

1. Младший пишет план из 3–5 предложений.
2. Ассистент черновикит код или тесты.
3. Младший сверяет черновик с планом и отмечает пробелы.
4. Сеньор сначала проверяет заметки, затем код.
5. Младший завершает одной фразой о том, чему научился.

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

Здесь рабочий поток с ИИ помогает, а не мешает. Ассистент остаётся в роли поддержки. Младший всё ещё должен думать, объяснять и защищать изменения. Именно здесь происходит развитие навыков.

Делайте рассуждения видимыми

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

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

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

Хорошая заметка также показывает два варианта. Один — быстрый патч, другой — более долгий, но более поддерживаемый. Младшим не нужен длинный дизайн-док; двух кратких вариантов с одной фразой о компромиссах обычно достаточно.

Лёгкий формат заметки

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

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

Тесты должны быть в той же заметке. Зафиксируйте точные проверки: unit-тесты, один ручной happy-path, один путь с ошибкой и то, что не проверялось. «Все тесты прошли» говорит ревьюеру почти ничего. «Прогнал unit-тесты signup, проверил дубликат email, не тестировал rate limit» — гораздо полезнее.

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

Небольшой пример фичи

Младшему дают задачу по регистрации: добавить валидацию для имени, email и пароля. Это задача, где ассистенты могут сэкономить время, не превращая работу в слепое копирование. Младший просит помощи, и инструмент предлагает несколько изменений: inline-ошибки в форме, валидацию на бэкенде и проверку на дубликат перед созданием аккаунта.

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

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

Что они тестируют вместе

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

Каждый результат даёт короткое обсуждение. Кто ловит это первым? Какое сообщение видит пользователь? Можно ли обойти проверку и попасть на API? Эти вопросы делают рассуждения видимыми.

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

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

Ошибки, которые тормозят рост

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

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

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

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

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

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

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

Короткий чеклист для каждого ревью

Ревью работает лучше, когда сеньор проверяет, как младший думал, а не только что попало в Git. Если ассистент написал половину патча — норм. Младший всё равно должен владеть изменением.

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

• Попросите младшего вслух объяснить изменение простыми словами. Он должен сказать, что делает фича, где изменился код и почему выбран этот подход. Если он не может объяснить без чтения с экрана, он ещё не понимает.
• Попросите назвать допущения и риски. Может быть, поле никогда не пустое, таймаут будет коротким или helper уже обрабатывает ошибки. Слушайте слабые места, а не идеальную формулировку.
• Проверьте, что он прогнал автоматические тесты и быстрый ручной проход. Прохождение тестов недостаточно, если, например, неверна подпись кнопки, состояние загрузки сломано или один крайний кейс падает в браузере.
• Спросите, сэкономил ли ассистент время или скрыл путаницу. Это не одно и то же. Если младший вставлял промпты, пока что-то не сработало, замедлитесь и вместе разберите рассуждение.
• Найдите один урок, который можно перенести в следующую задачу. Может быть, это как прослеживать изменения состояния, разбивать функцию на части или замечать рискованные допущения до начала кода.

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

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

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

Держите пилот коротким. Двух недель достаточно, чтобы понять, экономят ли ассистенты время или просто перекладывают работу на сеньоров. В этот период просите сеньоров ревьюить рассуждения младшего, а не только diff, и фиксировать, где ассистент помог, а где скрыл путаницу.

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

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

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

Некоторые команды могут настроить это самостоятельно. Другим нужна внешняя структура, обычно потому что сеньоры заняты и никто не владеет правилами. В таком случае внешняя помощь помогает. Oleg Sotnikov на oleg.is работает в роли fractional CTO и стартап-советника; он помогает командам выстроить правила ревью, менторские привычки и AI-first рабочие процессы, которые сохраняют скорость доставки без потери обучения.

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