TL;DR

В Mail.ru Group я работал директором департамента исследований и образования. В этой роли запускал и руководил тремя совместными с университетами программами: Технопарк с МГТУ им. Баумана, Технотрек с ВМК МГУ и Техносфера с МФТИ. За годы работы через них прошло более 3000 студентов: очно, с отбором, по двухлетним планам, с преподавателями-практиками из индустрии. Сегодня в обсуждении AI часто звучит тезис, что джуны индустрии больше не нужны и учиться программированию бессмысленно. Я с этим тезисом не согласен. Под словом «джун» рынок объединил две разные категории: выпускника инженерной программы и человека, который три месяца смотрел видеолекции и собрал три pet-проекта. AI давит на вторую категорию, первую почти не трогает. Настоящих джунов и так было мало. Они нужны индустрии больше, чем раньше. Ниже: о том, что должен знать настоящий джун, как этому учили мы, и что в этой картине меняет AI.

Подмена понятий

Когда я слышу «AI закрывает рынок джунов», я уточняю, о каких именно джунах речь.

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

Они приходят на одни и те же вакансии. Они называются одинаково. Зарплатные ожидания иногда тоже совпадают. Но это разные по потенциалу люди. Когда сегодня говорят «джунов на рынке слишком много», это означает не то, что фундаментально подготовленных стало много. Их как было мало, так и осталось. Просто вторая категория за десять лет агрессивного маркетинга разрослась до сотен тысяч человек с резюме на джуна и без бэкграунда. AI выбил из-под этой категории тот объем задач, ради которого ее нанимали: типовые формы, верстка по макетам, CRUD-эндпоинты, переписывание модуля под новый фреймворк. Эту работу LLM делает быстрее, точнее, и без онбординга.

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

Кого замещает AI

Если определить профиль человека, по работе которого прошелся AI, получается следующая картина. Без инженерного бэкграунда. Прошел короткую программу из видеолекций по фронтенду или бэкенду, закрыл несколько типовых задач в домашках. Алгоритмы знает на уровне сортировки пузырьком. Базы умеет читать через ORM, SQL руками писал раза четыре. Архитектура для него: структура папок проекта. Чужой код открывает с боязнью. Тесты воспринимает как штраф, не как инструмент. Документации не пишет, дебажит print’ами.

Я провел несколько сотен собеседований с такими кандидатами, когда строил инженерные команды. У них есть конкретные сильные стороны: освоили один фреймворк, написали портфолио, пришли мотивированными. Слабая сторона одна: нет понимания профессии, и они оптимистично надеются добрать его на работе. Иногда добирают, редко, чаще нет.

До 2024 года такой профиль был рынку нужен. На небольших задачах он окупался. Сейчас тот же объем работы аккуратно выполняется парой Cursor и Claude Code, которой управляет один мидл. Аккуратность тут важное слово. LLM в простом случае пишет код, который ближе к лучшим практикам, чем код неподготовленного человека. У LLM нет страха перед чужим репозиторием, нет необходимости разогреться, нет потери контекста за выходные. Для бизнеса задача «нанять трех джунов на типовые задачи» в 2026 году решается уже не наймом трех джунов.

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

Что должен знать настоящий джун

Я перечислю минимум: то, без чего человек не может называть себя инженером, а не пользователем фреймворка. Разумеется, это лично мое мнение. Но так как есть некоторый опыт подготовки джунов, то мнение это достаточно уверенное.

Алгоритмы и структуры данных. Не олимпиадный уровень, индустриальный. Понимание сложности O(), различие между списком, массивом, хеш-таблицей, деревом и графом, умение выбрать структуру под задачу. Курс по алгоритмам в наших программах занимал семестр и шел параллельно с практикой: студенты не зубрили, а решали задачи в коде. На собеседованиях мы давали задание уровня «найти пересечение двух списков» и ждали разбора по сложности, не одного работающего решения, а понимания, почему именно это решение.

Языки и системное программирование. Минимум один язык глубоко: модель памяти, GC или ручное управление, многопоточность, стандартная библиотека на уровне «знаю, что из коробки уже подходит». Минимум один язык на уровне «прочитать чужой код и не напугаться», обычно другой парадигмы, чтобы человек видел разницу. Базовым у нас был C++: не потому что он повсеместно используется, а потому что на C++ невозможно обойти стороной модель памяти, указатели, undefined behavior, layout структуры. Кто после двух лет C++ переходил на Java или Go, делал это легко. Обратная траектория, типа сначала Python, потом «наверное и C++ потяну», в реальности почти не работала.

Операционные системы и сети. Уровень «понимаю, что происходит, когда я нажимаю Enter в браузере». Что такое процесс и поток, как ОС распределяет память, чем отличается user space от kernel space, что такое syscall. Что такое TCP, чем он отличается от UDP (и это не шутка), как устроена HTTP-сессия, что такое TLS. Без этих знаний невозможно отлаживать реальные production-проблемы: «пакеты теряются», «соединение висит», «сервис тормозит непонятно почему», это все о сетях и ОС, не о коде.

Базы данных. Не «умею писать SELECT через ORM». Реляционная модель, нормальные формы, индексы и план запроса, транзакции и уровни изоляции, репликация. Понимание, чем отличается строковая блокировка от табличной, что такое deadlock и как от него защищаться. Минимум один опыт работы с raw SQL без ORM. Курс по базам у нас был не про синтаксис, а про устройство: почему индекс ускоряет одни запросы и замедляет другие, как читать EXPLAIN ANALYZE, когда денормализация оправдана.

Тестирование как культура. Не «писать тесты, потому что заставили на ревью». Понимание, что тест: это спецификация. Привычка писать тест до реализации, отделять unit от integration, представлять, какие тесты в проекте дороги в поддержке и почему. У выпускника наших программ тесты были не дополнительной нагрузкой, а способом думать. По меньшей мере мы старались так сделать.

Инженерная культура. Git как инструмент работы, а не «команды, которые я запоминаю». Code review как разговор, а не штамповка LGTM. Документация как часть работы, не «потом напишу». Decision log по архитектурным решениям: то, без чего через полгода никто не помнит, почему был выбран PostgreSQL, а не MongoDB. Чтение чужого кода как навык, который тренируется. Все это мы закладывали через работу в командных проектах с защитой: студенты на втором году обучения в наших проектах делали продукт в команде из четырех-пяти человек, с code review, с минимальным CI, с реальной защитой перед заказчиком.

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

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

Почему этому нельзя научить за три месяца

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

Алгоритмический курс: около 70-80 контактных часов плюс примерно столько же домашней работы. Курс по C++: 90-100 часов плюс самостоятельная практика. Базы данных, сети, ОС: каждый по 40-60 часов. Базовые предметы дают 400-500 часов плотного обучения. Командный проект с защитой: еще 200. Это два года, потому что мозг не усваивает по двадцать часов в день, а нагрузка идет параллельно с другой учебой студента.

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

Отдельный момент: преподаватель. Нужны, очень нужны люди, которые сами в индустрии. Курс по высоконагруженным системам должен проводить человек, который реально проектировал такую систему. Курс по базам: человек, который дежурил по проду. Это не теоретики с готовым сценарием лекции. Это инженеры с опытом, которые могут отвлечься от плана и три занятия разбирать реальный кейс из своей работы. Я всегда так говорил, что идеальный преподаватель, это тот, который кодит днем, а вечером рассказывает, как кодил. Такой опыт нельзя записать в видеолекцию: он передается через диалог, через реакцию на конкретные вопросы студента, через возможность задать вопрос. Даже через неформальное общение. Этого не заменяют видосики и тренажеры.

Что меняет AI

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

Что точно меняет. Простой код стало писать быстрее. Любое типовое задание: формы, CRUD, парсинг конкретного формата, миграция между фреймворками, теперь делается LLM в разы быстрее, чем человеком. Подготовленный джун с AI делает за день столько, сколько раньше джун без AI делал за пару недель. Это огромное усиление: я наблюдаю это в собственной работе. Но без подготовки эта пара не работает. AI пишет код, его кто-то должен прочитать и понять. Если читать некому, через несколько недель система превращается в кладбище решений, в котором никто не разбирается. Об этом я подробно писал в предыдущей статье.

Что AI меняет меньше, чем громко заявляется. Сложные задачи. Архитектура распределенных систем, отладка performance-проблем, разбор неочевидных багов в чужом коде, проектирование схем данных под рост в десять раз: LLM здесь ускоряет работу инженера, но ничего не делает за него. Здесь по-прежнему нужен человек, который понимает фундамент. И этот человек когда-то был джуном. Без потока джунов, выходящих с реальной подготовкой, через десять лет некому будет поддерживать корпоративные системы, которые сейчас развиваются.

Что AI пока не делает и, вероятно, не будет делать в обозримой перспективе. Здесь полезно отделять временные ограничения от устойчивых. Временные: длина контекста, размер модели, тонкость промпт-инжиниринга, цена токена. Они уменьшаются с каждым релизом, и нет оснований думать, что эта динамика остановится. Устойчивые: это то, что от размера модели почти не зависит. Архитектурные инварианты крупного проекта живут не в коде, а в головах людей, которые этот код пишут. Они нигде не записаны полностью, ни в документации, ни в комментариях. Их обсуждают на ревью, проговаривают на проектировании, держат в виде неявных договоренностей между инженерами. LLM, которая видит только репозиторий, эти инварианты периодически нарушает: не потому что плохо обучена, а потому что у нее нет доступа к источнику. Решение этой проблемы лежит не в более крупной модели. Оно лежит в людях, которые держат картину целиком и валидируют все, что модель сгенерировала. Утверждать, что следующее поколение закроет проектирование сложных систем, это очень и очень оптимистичная экстраполяция. Я бы на это не поставил и десяти рублей.

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

Что AI меняет в подготовке. Если раньше джун первого года писал заведомо тривиальный код, теперь часть этого этапа можно сжать: AI пишет шаблон, джун его читает, объясняет себе и коллеге, переделывает, разбирается, почему так. Это может быть лучшей задачей, чем «напиши свой первый CRUD». Но при условии, что джун уже умеет читать код и знает, на что смотреть. Если не умеет, LLM становится ловушкой: он копирует и не учится.

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

Зачем учиться

Через пять лет миддлом станет тот, кто сегодня джун. Через десять: сеньером. Это математика индустрии. Если завтра прекратить готовить настоящих джунов, не дутых, которые три месяца для «войти в ИТ», а с фундаментом, через десять лет некому будет поддерживать ничего сложнее лендинга. AI этот разрыв не закроет, потому что AI не заменяет инженера, который умеет думать. AI ускоряет такого инженера в несколько раз. Это разные истории.

Профессии разработчика не угрожает AI. Ей угрожает деградация системы подготовки: когда массовый сегмент учит «вкатиться за квартал», а инженерные программы стоят дороже, набираются сложнее, и работодатели десять лет относились к их выпускникам как к взаимозаменяемой массе с теми, кто прошел курс на лендинге. Сейчас, когда AI убирает с рынка второй сегмент, индустрия имеет шанс снова начать разговаривать про инженеров, а не про «вход в IT». Как по мне, это хорошие новости. Учиться все еще имеет смысл. Только учиться чему-то реальному.

Дмитрий Волошин, сооснователь и генеральный директор OTUS, основатель Клуба менторов, основатель школы бизнеса Ninox. Заметки про управление, найм и фаундерский опыт: t.me/coffee_notes