Команда AI for Devs подготовила перевод статьи о будущем джунов в эпоху ИИ. Автор утверждает: полностью заменить начинающих разработчиков невозможно и опасно — именно они со временем становятся тимлидами. Но чтобы оставаться востребованными, джуны должны освоить «версию 2.0» своей роли и научиться работать бок о бок с ИИ.

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

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

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

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

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

Неопределённое будущее с меньшим количеством джунов

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

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

Я не думаю, что мы сейчас — или когда-либо — окажемся в точке, где джунов можно полностью исключить из уравнения. Попытки уже были, например, с инструментами вроде Devin AI. И если судить по рассказам, это не сработало: многие команды внедряли «ИИ-разработчика», а через несколько месяцев отказывались от него. И речь даже не конкретно про Devin — а в целом про ценность роли джуна.

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

Джун 2.0: как помочь начинающим разработчикам расти вместе с ИИ

Зачем вообще нужны джуны?

Если коротко — они берут на себя мелкие задачи, чтобы синьоры могли сосредоточить силы на более серьёзных.

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

Как этого добиться? Вот несколько идей:

Первый шаг: знать «противника» в лицо

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

Хорошо ли это? Аргументы есть по обе стороны. Но я могу с уверенностью сказать: когда LLM попадает в свою «зону комфорта», они становятся мощным ускорителем разработки.

И именно это должны понимать джуны: когда LLM «в своей тарелке»?

Ведь они отлично умеют воспроизводить то, на чём были обучены (пусть и с вариациями). А обучались они в основном на фронтенд- и фуллстек-коде на разных языках и платформах. Особенно это касается веб-разработки: JavaScript/TypeScript, React, Next.js, PHP, Rails и так далее. Если это open source или лежит на GitHub — значит, модель это видела.

Поэтому джуну, пишущему CRUD для Next.js, может быть непросто — LLM умеет делать это быстро и надёжно.

Их задача — понимать, что у ИИ получается хорошо, а что нет. Этому можно научиться, если «подружиться» с ИИ в IDE. Пусть он поможет быстро набросать заготовки, а автодополнение использовать точечно — там, где нужно довести до ума уникальный код, который модель не понимает.

Так ИИ используют синьоры: они доверяют ему рутину — создание API-эндпоинтов, вызовы к базе, формы, валидации полей — а сами работают над уникальными частями приложения. Теми самыми «клёвыми штуками».

Поэтому если вы джун и ещё не пробовали «агентную» IDE — скачайте VS Code, войдите под учёткой, чтобы получить бесплатный доступ к Copilot, и попробуйте. Посмотрите, как работает автодополнение. Дайте агенту реализовать фичу.

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

Быть больше, чем «просто разработчиком»

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

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

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

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

Допустим, вы бьётесь над тем, как вытащить потоковый ответ от ИИ через API в своём пет-проекте. Поработали с LLM, покодили, и наконец всё заработало. Может быть, вы даже вели заметки в Markdown по ходу дела. Отлично! Возьмите эти заметки, добавьте немного текста (пусть даже с помощью LLM) — и вот у вас уже статья. Опубликуйте её на Medium или Dev.to, или на обеих платформах. И теперь, когда кто-то будет искать, как стримить ответы, он найдёт вашу статью и ваше имя. И вы станете «тем самым экспертом по AI streaming».

Серьёзно: если вынести из этой статьи только один совет, то вот он — пишите статьи. Это открыло двери для многих. Спросите вокруг.

Принятие будущего

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

Появятся новые модели взаимодействия. Будут изобретены новые стандарты. Спроектированы, построены, задокументированы и внедрены новые фреймворки. Одно можно сказать точно: нас ждут серьёзные перемены.

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

Что такое MCP? Не знаете? Загуглите и разберитесь. Попробуйте пару экспериментов. Подключите это к приложению. Напишите и опубликуйте статью об этом. Если ошиблись — всегда можно снять публикацию. Если оказались правы — вы уже впереди остальных.

Перемены как константа: меняющаяся роль джунов

Сейчас непростое время для всех, кто работает в разработке. Нет никаких гарантий. Но, честно говоря, их никогда и не было.

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

Да, работа меняется, и вместе с ней меняется понимание ролей вроде «junior-разработчик». Ещё несколько лет назад от джунов ждали, что он сможет добавить поля в форму и поправить пару API-эндпоинтов.

Сегодня ожидания другие, но они всё ещё вполне достижимы. А может, даже проще — благодаря бесплатным инструментам ИИ, которые у вас под рукой. Джуны должны принять эту версию 2.0. Лиды разработки тоже должны осознавать свою роль: полная замена джунов ИИ может поставить под угрозу будущее всей профессии.

В повседневной работе джуна в 2035 году вряд ли будет что-то кардинально отличаться от 2025-го. Задача та же: разгружать синьоров от мелких дел, чтобы они могли сосредоточиться на крупных задачах — новых фичах, рефакторинге, архитектурных изменениях. А успех джуна по-прежнему в том, чтобы помогать своим синьорам быть максимально продуктивными и самому расти в лиды.

Русскоязычное сообщество про AI в разработке

Друзья! Эту статью перевела команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-ассистентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!

Заключение

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

Так было, когда я начинал, так обстоят дела сегодня и так будет, когда я уйду на пенсию из этой безумной профессии — и задолго после.

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