Что будет с джунами в эпоху ИИ-кодинга?

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

Если вы хотите узнать ещё больше об организации процессов ML-разработки, подписывайтесь на наш Телеграм-канал Варим ML

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

• В школе/универе учишь какую-то базу по программированию/математике/ML

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

• Постепенно через эти задачи обретаешь практические навыки программирования, дебаггинга, доменные знания, базовое архитектурное понимание

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

Сейчас первые три этапа становятся под большой знак вопроса. Окей, фундаментальное образование ещё можно заставить себя получить, а вот что дальше? Как овладеть практическими навыками разработки, если руками прогать не надо? Можно ли стать хорошим архитектором или лидом, если не копался руками в коде легаси-проектов? Я вот сам именно как программист никогда особо силён не был, но всё равно сотни часов кодинга однозначно помогли разобраться во внутренностях ML-систем и нюа��сах их работы. А главное, это сыграло немаленькую роль в наработке интуции – что лучше попробовать сейчас, что не сработает, каким путём лучше пойти.

В общем, беспокойство по поводу будущего джунов растёт от года к году – например, в 2025 году 54% респондентов опроса LeadDev обозначили это как проблему внедрения ИИ-агентов, это второе место после качества кода.

Антропик в конце января разродился очередным исследованием (здесь полная версия). Они сделали классический эксперимент с treatment/control-группами джунов, одной из групп выдавали ИИ-инструмент для решения задач, связанных с незнакомой им питоновской библиотекой. Основные выводы:

• Группа с ИИ заканчивала задание в среднем чуточку быстрее (статистически незначимо, но и выборка не очень большая)

• Группа с ИИ сильно хуже проходила тест по пониманию библиотеки после выполнения задания

• При этом по качественному анализу (для количественного опять же участников недостаточно) результаты отличались в зависимости от стиля использования ИИ. Полное делегирование давало самое быстрое выполнение задания, но худшие результаты на тесте. Гибридные паттерны использования и использование ИИ только для ответов на вопросы давали лучшие результаты тестов

Эксперимент маленький, но показательный. Что же делать джунам и студентам и нам в целом как индустрии? Использовать ИИ по полной, писать руками или что-то третье? Давайте подумаем, какие у нас есть варианты решения этой проблемы.

Что делать компаниям и руководителям?

Забить

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

Безусловно, доля ручного кодинга будет падать и дальше. Я сейчас код руками не пишу вообще, а опрос в нашем чатике (нынешние и бывшие сотрудники ML-отдела Цельса) “Сколько кода пишешь руками?” показал такие результаты:

• Весь – 0%

• Почти весь – 18%

• 40-60% – 18%

• 10-40% – 32%

• Не пишу или почти не пишу – 32%

Но само написание кода – далеко не единственная наша зона ответственности, и пока сложно представить, что в ближайшие 5-10 лет ИИ полностью заберёт у нас все эти задачи (какие-то может):

• коммуникация с бизнесом, превращение их хотелок в технические стратегии и конкретные планы

• постановка задачи ИИ-агенту с учётом контекста компании, домена и текущей ситуации (сейчас часто используется термин “tacit knowledge” – неявные знания, существующие только “в головах”)

• проверка корректности результата с точки зрения бизнеса

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

• принятие верхнеуровневых архитектурных и продуктовых решений

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

А зачем нам тратить на это силы?

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

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

• Джуны сильно дешевле, а несложные задачи, которые пока нельзя полностью переложить на ИИ, всё ещё существуют

• Джунов легче адаптировать под свой домен, команду, стиль коммуникации

• Отказ от джунов замыкает все знания на несколько старших разработчиков, снижает бас-фактор

• Джуны – часто молодые, очень амбициозные ребята с горящими глазами, они сами могут стать источником новых знаний и bleeding edge практик работы с ИИ. Кто-то вообще считает, что в современных реалиях, “если не знаешь что делать – спроси джуна”

По этой теме мне откликнулся текст Кента Бека, джун – это инвестиция, а не просто дешёвая рабочая сила, и это не меняется в эпоху ИИ. Более того, ИИ может ускорять окупаемость найма джунов, ведь при правильном использовании он ускоряет обучение – сужает пространство поиска (не ищем три часа API-фреймворки, а оцениваем предложенные ИИ), отвечает на вопросы, помогает разобраться в старых кодовых базах.

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

Моя оценка способа – 2/10, можем столкнуться с очень неприятными последствиями.

Перейти на модель средневековых подмастерьев

На OpenTalks.AI Лёша Могильников, которого я знаю по LeanDS, закинул прикольную аналогию. Он предположил, что мы можем вернуться к модели подмастерьев. Каждый новый джун (подмастерье) в обязательном порядке прикрепляется к синьору (мастер) на длительное время, выполняет для него всякую черновую работу и учится на живом примере. Соответственно, через несколько лет он получает возможность сам стать мастером. Понятно, что фактический процесс будет выглядеть чуть посовременнее, что-то типа очень глубокого парного программирование (или парного DS). Какие минусы?

• Дорого, тратится много времени синьора

• Плохо масштабируется под массовый найм – хотя он, может быть, будет и не нужен

• Качество обучения будет очень сильно зависеть от способностей наставника

• Сможет ли быть эффективным наставником синьор, который сам давно не писал ни строчки кода?

• Люди должны быть очень совместимы, чтоб проводить столько времени вместе

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

Моя оценка способа – 5/10, интересная идея, но, наверное, не массовая, можно пробовать для очень талантливых джунов при наличии достаточно терпеливых синьоров.

Заставлять джунов писать код самим через силу

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

• Сложно что-то полностью запретить. Даже в компаниях, где запрещён ИИ, люди втихую им пользуются

• Джуны будут уходить в компании, которые придумали более эффективную схему

• В реальной работе джун потом столкнётся с продвинутыми ИИ-инструментами, с которыми у него не будет опыта работы

• Как выставить эту границу, когда уже можно? По времени? Экзамен?

Моя оценка способа – 3/10, я против запретов, они не работают и бесят.

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

Придумать новую систему обучения и мотивации для джунов

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

Сделать это сложно, нужны обучающие программы, которые будут в рамках рабочего процесса учить джунов:

• Паттернам использования ИИ – написание спецификаций, декомпозиция задач, ревью изменений

• Использованию при работе с ИИ-агентами специальных фишек типа output styles, которые помогут лучше разобраться в коде и в причинах выбора того или иного решения

• Какой режим работы с ИИ сейчас использовать и когда лучше не доверяться вслепую решениям ИИ. В этом посте описываются разные “персоны” при работе с ИИ (вайб-кодер, джун, опытный инженер) и когда и как их использовать – например, для рисёчерских задач, где аутпут можно будет выбросить, вполне окей использовать YOLO вайб-кодинг

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

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

Моя оценка способа – 7/10, самый реалистичный, но сложный и дорогой, плюс пока нет почти никаких лучших практик. Да и как они могут появиться, когда каждое новое поколение LLM перечёркивает половину нара��отанных практик? Главным навыком и руководителей, и инженеров становится быстрая адаптация.

Что делать джунам?

А что делать самим джунам? Учить ли программирование, учить ли ML? Честно – естественно, я не знаю ответа, но дам от себя несколько советов, которые вряд ли навредят:

• Учитесь читать и любить читать. LLM точно никуда не денутся, а их основной способ передачи информации – это текст. Spec-driven development, похоже, плотно в нашей жизни – а это десятки маркдаун-файлов

• Расширяйте кругозор, читайте статьи и книги из разных сфер. Можно, конечно, упороться в какую-нибудь супер-узкую крутую область типа написания эффективных кернелов на CUDA, но в большинстве случаев более профитно и безопасно будет быть шаристым генералистом. Хотя здесь уверенности у меня нет – можно и рискнуть и углубиться в тему, в которой LLM плохо шарят в силу их сложности и отстутствия обучающих данных. Ориентируйтесь на свой характер и сильные стороны. И как всегда – занимайтесь только тем, что вам нравится

• ML и опыт в обучении и построении ML-систем – всё ещё ценный навык. Например, если натравить текущих ИИ-агентов на результаты 10-20-30 экспериментов в ClearML и попросить сформулировать какие-то выводы и предложить топ-5 лучших новых гипотез на пробу, результаты обычно удручающие. На мой взгляд, хорошей ML-интуиции у современных ИИ-агентов пока нет, советы обычно очень общие

• Обязательно учитесь использовать ИИ-инструменты! Но используйте те возможности, которые дают современные ИИ-агенты, для обучения – например, Explanatory и Learning стили отве��ов в Claude Code. Разбирайтесь с помощью ИИ в опенсорс-проектах, старайтесь понять, почему были приняты те или иные архитектурные решения

• Опять же, по Саймону Виллисону умение верифицировать результаты работы ИИ остаётся ключевым навыком, как для джунов, так и для синьоров. Учитесь формулировать гипотезы и критерии их успешности, сами попишите тесты, поработайте с ИИ по TDD, учитесь дебажить вместе с ИИ. ИИ невероятно хорош в быстром создании MVP, но даже современные модели подвержены проблеме 70%, и джунам может быть сложнее понимать, что финальные 10-30% ещё не пройдены

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

Заключение

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

Некоторые считают, что компании не будут тратить свои ресурсы на воспитание джунов, и это плохо закончится. Но дилемма “нанимать джунов vs брать готовых” стояла всегда. И я уверен, что останутся компании, которые будут сохранять и развивать свои программы стажировок и найма младших сотрудников. Ну и никуда не исчезнут кибербомжи (как Цельс в 2019), которые только джунов и могут на начальных этапах себе позволить.

Короче, думаю, работа найдётся, но перестроиться и следить за трендами в найме придётся. Реалистичный сценарий на ближайшие годы – не исчезновение джунов, а сокращение их количества и повышение входных требований. Приток кадров в IT и так затруднил поиск работы для джунов, а LLM, кажется, ещё сильнее повысят нижнюю планку. Скорее всего, нас ждут изменения – и в определении самого грейда “джун”, и в системе образования и подготовки специалистов.

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

Если вы хотите узнать ещё больше об организации процессов ML-разработки, подписывайтесь на наш Телеграм-канал Варим ML