Младшие разработчики после ИИ: когда роль стоит сохранять

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

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

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

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

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

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

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

Где младшие разработчики всё ещё полезны

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

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

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

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

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

Воспроизведение багов — ещё один сильный сценарий. Сообщение вроде «не прошёл checkout» почти ничего не говорит. Кто-то должен повторить то же действие с тем же состоянием аккаунта, браузером и последовательностью кликов, а потом записать, что именно произошло. Хорошая заметка по багу обычно простая: что сделал пользователь, чего он ожидал, что случилось вместо этого, повторяется ли проблема и какой скриншот или лог помогает. Такая запись может сэкономить старшему разработчику 20 минут на маленьком баге и гораздо больше — на запутанном.

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

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

Чего ИИ не замечает в ежедневной поставке

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

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

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

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

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

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

Есть и тихая зона между тикетом и настоящим продуктом. Тикет может говорить: «добавьте статусный бейдж на дашборд». ИИ это сделает. Но должен ли бейдж также появляться в экспортируемых данных, фильтрах, уведомлениях и журналах аудита? Если команда не задаёт такие вопросы, работа уходит в продакшен полусделанной.

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

Как разделить работу после внедрения ИИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ошибки, которые совершают команды, когда сокращают роль слишком рано

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

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

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

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

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

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

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

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

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

Быстрые проверки перед тем, как убрать роль

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

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

Посмотрите на последние три релиза

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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