Вайбкодинг не убивает джунов: почему май 2026 года удачен для найма стажёров

Что происходит с рынком: цифры без прикрас

По данным из Татарстана, число IT-вакансий для джунов упало на 49%. Это не региональный кризис. Татарстан просто посчитал первым, остальные регионы движутся в ту же сторону.

После волны сокращений 2025 года российские компании перестроили логику найма. Не «возьмём джуна, вырастим под себя», а «берём готового middle с рабочим стеком, чтобы он вышел на продуктивность за две недели». Это рационально с точки зрения финансового директора. Для начинающего разработчика это означает, что входная дверь физически сузилась.

Гарвард в 2024 году опубликовал исследование по 62 миллионам сотрудников в 285 000 компаниях. Вывод конкретный: junior-позиции сокращаются быстрее любых других категорий. Автоматизация рутинных задач бьёт прежде всего по тем, кто как раз и занимается рутиной. А джун на первом году занимается почти исключительно ею.

В начале 2026 года Microsoft, Google, Meta, Amazon и Salesforce суммарно убрали около 60 000 позиций. Это американский рынок, но сигнал работает глобально. Российские HR-отделы смотрят на эти новости и находят дополнительный аргумент в пользу осторожности при найме.

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

С 2023 года число открытых вакансий для джунов в российских IT-компаниях сократилось примерно втрое.

Откуда взялся страх перед джунами

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

Это не проблема джуна. Это проблема процесса.

Реальная причина, по которой компании перестали нанимать джунов, другая. Сеньоры уже перегружены. У среднестатистической команды сейчас больше кода на ревью, чем год назад: AI-ассистенты вроде Copilot и Cursor генерируют pull request-ы быстрее, чем любой человек их читает. Добавить джуна в эту схему означает ещё один поток ревью. Сеньор и так работает сверхурочно, и менеджер это видит.

Но тут компании перепутали следствие с причиной. Джуны не дорогие. Дорого их учить при отсутствии структуры: когда нет технического онбординга, нет выделенного ментора с временем на менторство, нет задач правильного размера. Уберите эти проблемы, и стоимость джуна резко падает. Оставьте их, и джун действительно обойдётся дороже, чем он стоит.

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

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

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

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

Что такое вайбкодинг и где он реально помогает

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

Работает отлично на изолированных задачах с чёткими границами. CRUD-ручки, утилитные функции, шаблонные React-компоненты, регулярки, базовые валидации. Всё, что можно описать одним абзацем без сносок и "ну ты понимаешь о чём я".

// Промпт: "Напиши функцию валидации email на TypeScript с тестами"
export function validateEmail(email: string): boolean {
  const re = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return re.test(email);
}

// Джун проверяет edge-cases: пустая строка, unicode, субдомены
// Сеньор тратит 0 минут на ревью — если джун обучен читать что получил

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

Ломается подход там, где контекст неявный. Legacy-система с пятью слоями абстракций, накопленными с 2018 года. Бизнес-логика, которую знает только один человек в компании и то по памяти. Требования, которые меняются в процессе разговора. Здесь AI генерирует код, который компилируется, проходит линтер и полностью делает не то. Именно об этом классе проблем, когда AI-разработка разваливается в продакшене при работе со сложным контекстом, говорят подробнее.

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

Вайбкодинг реально ускоряет джунов на рутинных задачах. Джун, который умеет грамотно сформулировать промпт и проверить результат, закрывает задачи быстрее, чем тот, кто пишет всё руками с нуля. Но это не отменяет необходимость понимать, зачем код пишется. AI не знает, что ваш сервис обрабатывает платёжные данные и что вот эта "валидация email" используется ещё и для авторизации через корпоративный SSO. Это знаете вы. Или не знаете, и тогда проблема не в AI.

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

Парадокс: сеньоры заканчиваются, потому что джунов не брали

Senior-разработчик не берётся из воздуха. Путь от первой работы до уверенного senior у большинства занимает несколько лет реальной практики на боевых проектах. Не курсов, не pet-проектов. Именно производственного опыта, где цена ошибки настоящая.

2023-2025 годы прошли под лозунгом "нанимаем только с опытом". Компании срезали расходы, закрывали джуниорские позиции и гордились "оптимизацией найма". Логика понятна: сеньор сразу даёт результат, джун требует 6-12 месяцев вложений до выхода в ноль. Только вот к 2028-2030 годам этот выбор конвертируется в дефицит. Воронка пуста. Новых senior-ов взять неоткуда, потому что мидлов для их роста не вырастили, а мидлов не вырастили, потому что джунов не брали.

Это не прогноз, это арифметика.

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

Есть ещё проблема, которую плохо измеряют в цифрах. Когда уходит сеньор, а обучать некого, уходит не человек. Уходят архитектурные решения, неписаные соглашения, понимание того, почему система сделана именно так. Документация это не фиксирует. Junior бы за два года впитал это через парное программирование и code review. Но джуна не было.

Компании, которые брали джунов в 2022-2024 годах вопреки тренду, сейчас в другой ситуации. Их "рисковые" найм-решения дали результат: к 2026 году эти люди выросли в мидлов с контекстом конкретно этого продукта и стека. По зарплате ниже рыночного мидла, с лояльностью выше рыночной. Тихая выгода для тех, кто не поддался панике.

Без регулярного притока джунов воронка роста внутри компании перестаёт работать уже через 2-3 года.

Почему май 2026 года, удачный момент для найма стажёров

Рынок сделал за тебя половину работы по отсеву. Большинство компаний в 2025-2026 году резали бюджеты именно на джунов: слишком долгий онбординг, слишком много ментор-времени, слишком неочевидный ROI. Это значит, что сейчас в пуле кандидатов сидят люди, которые год назад просто бы уже работали где-то.

Зарплатные ожидания у начинающих тоже пришли в чувство. Волна 2023-2024 годов, когда часть выпускников коротких курсов приходила с завышенными ожиданиями относительно своего реального уровня, схлынула. Рынок объяснил всё сам, без HR-разговоров. Сейчас человек без опыта приходит с реалистичной цифрой и готовностью её обосновывать через результат.

Но главное изменение не в деньгах. Инструменты изменили что умеет стажёр.

Кандидат, который учился параллельно с появлением Cursor и нормальных AI-агентов, работает с ними нативно. Не "использует как поисковик", а строит рабочий процесс вокруг них. Такой человек с Cursor и нормальным ТЗ закрывает задачи, на которые год назад требовался мидл с двухлетним опытом в проекте. Я видел это конкретно: стажёр за три дня написал интеграцию с внешним API там, где мидл потратил бы день только на изучение документации.

И ещё один фактор, который обычно не называют открыто. По данным hh.ru за начало 2026 года, около 57% российских компаний уже встроили AI в HR-процессы, включая онбординг и оценку новых сотрудников. Это снижает стоимость ввода джуна в должность. Автоматизированные чек-листы, AI-код-ревью на базовых задачах, структурированный фидбек без нагрузки на тимлида. То, что раньше отнимало у сеньора значительную часть времени в первый месяц, теперь частично покрывается инструментами.

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

Как джун с Cursor делает работу мидла: конкретная механика

Возьмём конкретный сценарий. Джун получает задачу: "добавить эндпоинт для выплат контрагентам". Без Cursor это недели размазанного кода, три итерации ревью и нервный сеньор в Slack. С Cursor и нормальной декомпозицией картина другая.

Сначала тимлид садится с джуном на 30 минут и режет фичу на куски по 2-4 часа каждый. Не "сделай выплаты", а: написать Zod-схему для тела запроса, написать Prisma-транзакцию, написать обработку ошибок, написать тесты. Каждый кусок изолирован. Джун не держит в голове всю систему, он держит одну подзадачу.

Дальше в дело идёт .cursorrules. Это файл в корне проекта, который Cursor читает при каждой генерации. Джун не объясняет в промпте "используй Prisma" или "ошибки в RFC 7807" каждый раз. Контекст уже зашит:

// .cursorrules — пример контекста проекта для джуна
// Cursor читает этот файл и учитывает при генерации

You are working on a fintech API (Node.js + TypeScript + Prisma).
Rules:
- No raw SQL, always use Prisma ORM
- All endpoints must have Zod validation
- Error responses follow RFC 7807 format
- Write tests with Vitest, coverage > 80%

// Джун с этим файлом генерирует код в нужном стиле сразу

С таким файлом джун пишет промпт в духе "создай POST /payouts, тело: amount, recipientId, currency" и получает код, который уже соответствует соглашениям команды. Не потому что джун знает все архитектурные решения компании, а потому что они записаны в одном месте.

После генерации джун не нажимает "принять" и не идёт пить кофе. Он запускает тесты, читает diff построчно и пишет в PR-описании что именно сделано и почему именно так. Это уже не работа вслепую. Это осмысленная верификация, пусть и с опорой на инструмент. Разница примерно как между тем, кто решает задачу по учебнику, и тем, кто переписывает с доски не понимая зачем.

Сеньор приходит на ревью и видит: маленький PR, изолированное изменение, тесты зелёные, описание есть. Ревью занимает 15-20 минут. До этого та же задача размазывалась на 2 часа разбора, потому что джун делал всё сразу, код был связан по всему файлу, и непонятно что именно проверять.

В 2025 году несколько команд публично описали эту схему. Outreach от Engineering Manager Factorial, пост в блоге Vercel о внутренних процессах, несколько тредов на HN про "junior leverage". Общий вывод везде одинаковый: пропускная способность команды растёт без найма новых людей. Не потому что джуны вдруг стали писать код как сеньоры. А потому что сеньоры перестали тратить время на базовые правки и начали тратить его на архитектурные решения, которые инструмент не принимает. Как выглядит этот процесс изнутри, с конкретными цифрами закоммиченного и выброшенного кода, разобрано в двухнедельном опыте вайбкодинга на Cursor.

С AI-инструментами джун справляется с декомпозицией и черновым кодом за часы, а не дни.

Риски, которые реально существуют, и как их закрыть

Я видел, как это разваливается. Берёшь джуна, даёшь ему Cursor или Copilot, через две недели он шипит код с уверенностью мидла, а через два месяца выясняется, что он не понимает, почему код работает. Просто доверял модели.

Это первый и самый опасный риск. ИИ не ошибается очевидно, он ошибается правдоподобно. Джун не знает, что именно проверять, потому что у него нет референса. Лечится одним способом: каждый PR разбирается голосом. Не комментарием в GitHub, а разговором. "Объясни мне эту функцию своими словами. Что произойдёт, если сюда придёт null?" Пять минут, но они дают больше, чем неделя самостоятельного чтения.

Второй риск вытекает из первого. Вайбкодинг генерирует технический долг с такой скоростью, что джун физически не успевает его осознать. Решение здесь жёсткое и неудобное: никаких задач без тестов, никакого мержа без зелёного CI. Совсем. Это убивает скорость на первые два месяца и спасает архитектуру на два года. Хрестоматийный пример того, что бывает, когда AI-код идёт в прод без должного контроля, с детальным разбором последствий: как Claude дописал SQL-миграцию и удалил прод-таблицу.

Третий риск про сеньоров. Онбординг реально съедает время, и команда это чувствует. Структурированный план на 90 дней с чёткими чекпоинтами помогает снизить нагрузку, потому что джун перестаёт спрашивать всё подряд, у него есть маршрут. Часть материалов можно сделать асинхронными: записанные разборы, документация с примерами, Notion с FAQ. Сеньор нужен на вопросы, которые нельзя решить без него, а не на "как настроить линтер".

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

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

Каких джунов брать в 2026 году: критерии отбора

Я перестал спрашивать на собеседованиях, как работает quicksort. Вместо этого прошу объяснить, какой инструмент выбрать для конкретной задачи и почему. Этот сдвиг многое меняет в том, кто проходит отбор.

Первое, на что смотрю сейчас: умеет ли человек сформулировать промпт и потом объяснить, что получилось. Синтаксис Python можно не знать наизусть в 2026 году, это реально. Но если кандидат скопировал код из Copilot и не может рассказать, что он делает и почему так, а не иначе, это красный флаг. Инструменты усиливают понимание, а не заменяют его.

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

Реальный проект с деплоем весит больше, чем сертификат курса. Учебный проект тоже принимаю, но пет-проект, который крутится на каком-нибудь Railway или Fly.io, говорит о человеке больше, чем диплом. Там видно, как принимались решения, где спотыкались, что переделывали.

Тип вопросов на собеседовании многое показывает. Кандидат спрашивает "как это работает" или "почему именно так, а не вот так"? Второй тип вопросов говорит о том, что через полтора года передо мной будет мид. Первый тип вопросов говорит о том, что человеку нужен постоянный надзор.

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

Что получит компания через 18 месяцев

Стажёр, которого вы берёте в 2026 году, к середине 2027-го становится мидлом. Не абстрактным мидлом с рынка, которому нужно три месяца объяснять, почему у вас именно такая архитектура и откуда взялся вот этот странный сервис. А человеком, который был рядом, когда это решение принималось. Такой контекст не купишь на HeadHunter.

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

Отдельный момент, который часто недооценивают. Человек, который начал работать с AI-инструментами с первого дня, не переучивается. У него нет старых привычек "пишу руками, потому что всегда так делал". Он изначально строит свой workflow так, как это работает в 2026 году, с Cursor, с Copilot, с автоматизацией рутины. Сеньоры в среднем тратят на переход от старых паттернов больше времени. Джуны этот этап просто пропускают.

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

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

Выращенный джун выходит на окупаемость к 18-му месяцу, тогда как нанятый мид с рынка обходится дороже с первого дня.