Джуны не вымрут. Но требования к ним изменятся.
73% — на столько упал найм на junior-позиции в IT за последний год. Не «стало чуть сложнее» — три четверти позиций просто исчезли.
54% инженерных руководителей говорят, что будут нанимать ещё меньше джунов — AI позволяет сеньорам закрывать больше работы. Джуниорских вакансий на 34% меньше, чем пять лет назад, а на каждую оставшуюся приходят сотни откликов.
Что делать? Ситуация действительно не из простых, и в этой статье мы осветим ситуацию и дадим практические советы.
Что на самом деле изменилось
AI не заменил джунов. Он обесценил то, за что джунов раньше держали: простые CRUD-эндпоинты, вёрстка «по макету». Раньше под это нанимали нескольких джунов. Сейчас один мидл с Claude Code/Codex закрывает ту же работу быстрее.
Но компании по-прежнему нанимают джунов — им нужны люди, которых можно вырастить внутри. Просто ожидания сместились. Не «быстро печатает код», а:
- может выполнить несложную задачу и не сломать то, что работает
- разберётся в незнакомом куске кодовой базы сам или с помощью AI-агента
- задаст правильный вопрос заказчику, а не сделает ерунду «как в ТЗ»
И подлянка: стандартный путь обучения (курсы, туториалы) готовит к работе, которую AI уже автоматизировал. Вы учитесь писать код с нуля. А на первой работе вам придётся читать, дебажить и аккуратно менять чужой.
Фильтр, который теперь проходят не все
Раньше барьер входа был техническим: выучи язык, пойми HTTP, напиши что-нибудь работающее. Сейчас «что-нибудь работающее» можно получить за вечер с Claude Code или Cursor. Барьер сместился.
Новый фильтр — способность работать с тем, что уже есть. Не с пустым файлом, а с 200 000 строк legacy-кода, с чужими архитектурными решениями, с багом, который воспроизводится только в production. Это другой навык, и его почти невозможно прокачать «по роликам».
На собеседованиях это видно сразу. Всё чаще дают не «напиши функцию», а:
- «вот реальный PR с багом, найди его»
- «вот микросервис, объясни, что он делает и где может упасть»
Если вы к этому не готовы, вас обойдут кандидаты, которые готовы.
Что делать: без мотивационных плакатов
Стройте с нуля — от идеи до деплоя
Лучшее, что может сделать джун — реализовать собственный проект целиком. Не «todo app по туториалу», а что-то, что решает реальную задачу лично для вас. Выбрать стек, продумать архитектуру, задеплоить на сервер или хотя бы на GitHub Pages.
Процесс важнее результата. Когда вы сами решаете, как организовать код, как хранить данные, как настроить CI — вы сталкиваетесь с теми же вопросами, что и на реальной работе. AI-агент поможет с реализацией, но решения о структуре проекта принимаете вы.
Если хотите — загляните в open-source проект, которым пользуетесь, посмотрите, как он устроен внутри. Но не нужно заставлять себя контрибьютить ради строчки в резюме.
Берите на себя больше ответственности
Сейчас важно расти вширь. На собеседовании разница между «я написал бэкенд» и «я сделал веб-приложение с кэшированием, PostgreSQL, развернул на GCP через Terraform, добавил аудит-логи и аналитику, повесил на домен» — огромная. Даже если на сайте пока нет пользователей.
GCP даёт $300 бесплатных кредитов после регистрации (или арендуйте дешевый VPS и разверните всё через Docker). У cloud.ru есть бесплатный тариф, которого хватит для размещения сайта. Домен можно взять бесплатный. Terraform, мониторинг, CI/CD — всё это можно настроить за выходные с помощью AI-агента. И вот что важно: на выходе у вас не учебный проект в папке, а живой сервис, доступный по URL. Это уже другой разговор на собеседовании.
Со всеми этими пунктами — кэширование, база, деплой, логи — вам поможет AI-агент. Но результат будет ваш: работающий проект, который можно открыть и потрогать.
Будьте проактивными
Джун, который ждёт задачу в Jira — норма. Джун, который сам замечает проблему и приходит с предложением — редкость. Увидели, что в проекте нет тестов — предложите начать покрывать. Заметили, что документация устарела — обновите. Нашли баг, который не в вашем тикете — заведите issue.
Проактивность — это не «делать чужую работу». Это показывать, что вам не всё равно. Руководители запоминают таких людей, потому что им не нужно за ними следить. А на собеседовании история «я сам заметил проблему и предложил решение» звучит сильнее любого pet project.
Насмотренность
Чем больше чужих решений вы видели, тем лучше ваши собственные. Читайте технические блоги компаний — как Яндекс проектирует высоконагруженные системы, как Stripe строит API, как маленькие стартапы выбирают между монолитом и микросервисами. Смотрите, как устроены популярные open-source проекты: структура папок, как пишут тесты, как оформляют PR, какие там CI/CD.
Именно так развивается насмотренность вкупе с интуицией. Эту интуицию не заменит ни один AI-агент — он может предложить решение, но оценить его адекватность можете только вы.
Выберите домен, а не стек
React, Python, Go (вставьте любое другое название технологии) сами по себе уже не преимущество. AI уже пишет код на популярных языках достаточно хорошо. Преимущество теперь в другом: понимать, что вы автоматизируете.
Понимание, как устроены платежи в e-commerce, почему медицинские данные нельзя хранить как обычные, или что значит settlement в банковском контексте — это знание, которое не лежит на поверхности и требует понимания домена.
Джун, который понимает домен, часто полезнее мидла, который не понимает. Потому что джун задаёт правильные вопросы, замечает нестыковки в требованиях и не реализует бездумно то, что не имеет смысла.
Не обязательно выбирать прямо сейчас. Но если вы уже работаете в финтехе, здравоохранении, логистике — копайте в предметную область параллельно с техническими навыками. Через два года это будет ваше главное отличие.
Публичный след
Компании всё чаще нанимают людей, которых заметили в X (Twitter), на Хабре, в GitHub. Build in public тоже работает — когда вы делитесь процессом. Можно проявить креативность и если ваша публикация залетит в тренды, то можно получить предложения о работе. Навык самопрезентации никогда не будет лишним.
Что реально помогает:
- Пост на Хабре, где вы разбираете конкретную техническую проблему, с которой столкнулись
- Сайт-визитка на Astro или аналоге, выложенный на GitHub Pages — и сам по себе артефакт, и место для портфолио
- Активность в соц.сетях: делитесь тем, что строите, что сломали, что поняли. Не нужна аудитория — нужен след, который можно найти
С коммитами в чужие репозитории осторожнее. После волны AI-спама в open-source (бессмысленные PR от ботов) мейнтейнеры стали подозрительнее. Контрибьютить можно, но осмысленно, с реальным пониманием кода, а не ради зелёных квадратиков на GitHub.
Это про артефакты, которые рекрутер или тимлид может открыть и увидеть, как вы думаете.
AI ускоряет обучение, но не заменяет его
Раньше, чтобы разобраться в незнакомой библиотеке, нужно было часами читать документацию, ковырять примеры и ждать ответа на Stack Overflow. Сейчас можно спросить у агента «объясни, как работает middleware в этом проекте» и получить разбор за минуту. Попросить пройтись по коду с комментариями, объяснить незнакомый паттерн, показать, как связаны модули. В 3 часа ночи, без осуждения за глупые вопросы, на вашем уровне.
Это реально ускоряет рост. Джун в 2026 году может за месяц освоить то, на что раньше уходило полгода.
Понимание — уже половина дела. Раньше, чтобы разобраться в асинхронном программировании, BFS или прочих алгоритмах сложнее легких, нужно было неделю читать документацию и набивать шишки вслепую. Сейчас агент объяснит за пять минут, с примерами на вашем коде. Но чтобы понимание стало навыком, нужен следующий шаг: попробовать самому. Спросил — попробовал — уткнулся в проблему — вернулся к агенту с конкретным вопросом. Этот цикл работает быстрее, чем что угодно до него.
Практикуйтесь в безопасной среде: локальный проект, отдельная ветка, тестовая база. Не на проде. Для джуна это особенно важно — цена ошибки на учебном проекте нулевая, а на production совсем другая.
Профессиональный workflow: то, чему не учат на курсах
Есть разница между «я написал скрипт на 200 строк» и «я работаю в команде над продуктом». Курсы часто дают первое. На работе нужно второе. И вот навыки, которые реально влияют на испытательный срок, но почти не попадают в программу курсов.
Git — достаточно понимать основы
Git — это то, чем вы будете пользоваться каждый день. Хорошая новость: вам не нужно заучивать десятки команд. Достаточно понимать концепции, а с командами помогут AI-агенты.
Что стоит знать хотя бы в теории:
- Ветки — зачем работать в отдельной ветке, а не прямо в
main. Как создать feature-ветку и смержить обратно - Коммиты — что это снимок изменений, и почему «fix race condition in token refresh» полезнее, чем просто «fix». Много где используются конвенциальные коммиты (названия веток начинаются с feat/fix/docs), где-то есть semver. Узнайте, что это.
- Pull request — как выглядит процесс: вы создаёте PR, описываете изменения, коллеги смотрят код и оставляют комментарии
- Мердж-конфликты — что
<<<<<<< HEADне означает катастрофу, а просто два человека изменили одно и то же место
На практике Claude Code и Codex умеют работать с git напрямую: создавать ветки, коммитить с осмысленными сообщениями, помогать с разрешением конфликтов. Но чтобы понимать, что агент делает, и не принять случайный force push, базовое понимание git workflow нужно всё равно.
Тесты — ваш способ контролировать AI
На курсах тесты часто идут «в конце, если останется время». В реальной разработке тесты — это то, что позволяет вам менять код и не бояться всё сломать. А когда код пишет AI-агент, тесты становятся вашим главным инструментом контроля: агент сгенерировал — тесты проверили, что он не наломал дров.
Какие тесты бывают:
- Unit-тесты — проверяют одну функцию или модуль изолированно. Быстрые, простые, пишутся первыми
- Интеграционные — проверяют, что несколько компонентов работают вместе (API + база данных, например)
- E2E (end-to-end) — имитируют действия пользователя от начала до конца. Медленные, но ловят баги на стыках
Что стоит освоить:
- Написать unit-тест на свою функцию до или после реализации
- Понять, почему тест упал, и отличить баг в коде от бага в тесте
- Настроить pre-commit hook, который запускает тесты и линтер автоматически перед каждым коммитом — так сломанный код не попадёт в репозиторий
- Знать, что такое CI/CD хотя бы на уровне «мой PR не смержат, пока pipeline зелёный»
Вам не нужно быть экспертом в TDD. Нужна привычка: написал код (или агент написал за вас) — проверил тестами, что всё работает.
Claude Code и Codex — от экспериментов до рабочих задач
Экспериментировать с AI через веб-интерфейс — нормально, с этого все начинают. Но для серьёзной работы есть инструменты, которые встраиваются прямо в ваш проект.
Claude Code (Anthropic) и Codex CLI (OpenAI) — терминальные AI-агенты, которые работают прямо в вашем проекте. Разные компании, разный путь к одной идее, но суть одна: агент видит вашу кодовую базу целиком, понимает структуру и предлагает изменения в контексте реального кода. Вы подтверждаете или отклоняете каждое действие.
Разница с веб-чатом примерно такая: ChatGPT — как спрашивать совет у прохожего. Терминальный агент — как работать с коллегой, который сидит рядом и видит ваш экран и весь репозиторий.
Конкретный пример. Вам нужно добавить endpoint для экспорта данных в CSV. Вместо копирования кусков из веб-чата:
> Добавь GET /api/export/csv, который возвращает все заказы
> текущего пользователя в формате CSV. Используй существующую
> модель Order и middleware авторизации из этого проекта.
Агент сам найдёт модель Order, посмотрит, как устроены остальные эндпоинты, повторит паттерн авторизации и создаст файлы в нужных местах. Вы ревьюите diff, а не собираете пазл из фрагментов. И Claude Code, и Codex работают по этому принципу — отличается обёртка, не суть.
Субагенты: как масштабируется AI-разработка
Субагенты (sub-agents) — это когда вы параллелите работу не людьми, а агентами. И Claude Code, и Codex умеют запускать «дочерних» агентов: один быстро пробежится по кодовой базе и найдёт нужные места, другой напишет тесты, третий проверит безопасность. Каждый работает в своей рамке и со своим контекстом.
Зачем это знать джуну? Потому что это отражает реальный процесс в команде: задачи декомпозируются и делаются параллельно. Умение разбить большую задачу на независимые куски, собрать результат и не потерять качество в стыках ускоряет рост сильнее, чем ещё один фреймворк в резюме.
Подробнее об архитектуре мульти-агентных систем: обзор инструментов оркестрации.
Как на самом деле выглядит реализация фичи
На курсах часто учат так: открыл файл → написал код → запустил → работает. В реальности (в нормальной команде) процесс выглядит примерно так:
1. Понять задачу. Прочитать тикет. Задать уточняющие вопросы. Понять, зачем это нужно пользователю, а не только что нужно реализовать.
2. Изучить контекст. Как устроены похожие фичи в проекте? Какие паттерны используются? Есть ли существующий код, который можно переиспользовать? AI-агенты помогают здесь отлично — claude "как устроена авторизация в этом проекте?" даёт ответ за секунды.
3. Создать ветку. git checkout -b feat/csv-export. Не работать в main.
4. Реализовать. Писать код — руками или с помощью AI-агента. Ключевое: вы должны понимать каждую строку. Если агент сгенерировал что-то непонятное — разберитесь, прежде чем коммитить.
Понять, что текущая реализация не работает, поэтому этот пункт может повториться…
5. Написать тесты. Не «потом», а сейчас. Хотя бы один тест на основной сценарий и один на граничный случай.
6. Проверить локально. Запустить тесты, проверить линтер, убедиться, что ничего не сломалось.
7. Сделать PR. Написать описание: что сделано, зачем, как проверить. Попросить ревью.
8. Отреагировать на ревью. Не обижаться на комментарии, а учиться.
Этот цикл выглядит «долго» только на бумаге. На практике он экономит время: меньше откатов, меньше ночных фиксов, меньше стресса. Если вы освоите его до первой работы, вы будете выглядеть как профессионал, с которым можно успешно сотрудничать.
CLAUDE.md и AGENTS.md — контекст для AI
У проектов, в которых активно используют AI-агенты, есть файлы CLAUDE.md (для Claude Code) и AGENTS.md (для Codex). Они описывают структуру проекта, стек, правила кода и важные контексты — чтобы агент не переизобретал архитектуру с нуля при каждом запросе.
Писать с нуля необязательно — можно попросить самого агента сгенерировать первую версию по вашему проекту, а потом подправить. Главное — держать файл актуальным и компактным. Раздутый CLAUDE.md на 500 строк забивает контекстное окно агента и снижает качество его работы. Не забывайте проверять, что забивает ваш контекст через команду /context в Claude Code.
О чём молчат «карьерные» статьи
T-shaped, П-shaped и прочая геометрия — ретроспективное описание, а не стратегия. Никто не стал успешным, потому что целенаправленно «строил T-shape». Люди решали интересные задачи и со временем обнаруживали, что их опыт складывается в паттерн.
Отдельно про софт скиллы. Да, коммуникация важна. Нет, она не заменяет техническую компетентность. Джун, который отлично презентует, но не понимает архитектуру и принципы хотя бы верхнеуровнево, бесполезен на практике. Сначала научитесь быть полезным технически.
И самый вредный совет: «просто научись промптить». Промпт-инженерия в вакууме бесполезна. Хороший промпт для AI-агента требует понимания: что такое endpoint, как работает ORM, зачем нужен middleware, что будет при конкурентном доступе. Без технической базы вы не сможете даже оценить, правильный ли код сгенерировал агент. Промпт — это интерфейс, а не замена знаний. Конечно можно положиться на сайты вроде Lovable, но с мало-мальско сложным продуктом - без понимания основных компонентов будет тяжело.
Итог
AI не убивает позицию джуна. AI убивает конкретный способ быть джуном: сидеть тихо, писать что скажут, не задавать вопросов, не лезть в чужой код, не знать git, не писать тесты, использовать ChatGPT вместо профессиональных инструментов.
Новый джун — это человек, который разбирается в незнакомом быстрее, чем другие, замечает то, что пропустил AI, понимает контекст за пределами кода и владеет рабочим циклом: от ветки до code review. Этому не учат «по туториалам». Этому учатся в реальных репозиториях, на реальных багах, в реальных командах.
Хорошая новость: большинство ваших конкурентов этого не делают.
Через Omni Router вы можете подключить Claude Code и Codex через свою подписку или API-ключ — и начать практиковаться с профессиональными инструментами уже сегодня.