Не потому что AI заменил опытных инженеров. А потому что рынок перестаёт выращивать новых

Последние несколько лет в IT повторяли почти успокаивающую фразу: AI не заменит разработчиков, он станет их помощником.

В 2026 году эта формулировка всё хуже описывает реальность.

AI‑инструменты уже не просто дописывают строки в IDE. Codex, Claude Code и другие агентные среды всё чаще берут на себя полный цикл реализации: читают кодовую базу, редактируют файлы, запускают команды, пишут тесты и готовят изменения к ревью. Человек остаётся в процессе, но его роль смещается от автора каждой строки к контролёру результата.

Я бы сформулировал это так:

Участие человека в разработке становится критическим, но минимальным.

Критическим — потому что кто‑то должен понять задачу, принять архитектурное решение, проверить результат и отвечать за продакшен.

Минимальным — потому что всё больший объём непосредственного производства кода уходит модели.

Google на Cloud Next 2026, главном ивенте Google Cloud для разработчиков, компаний и партнёров, публично заявил, что 75% нового кода внутри компании уже генерируется AI и утверждается инженерами. Важна не только сама цифра, а формулировка: код генерируется AI, а человек его утверждает.

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

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

AI забирает не всю профессию сразу. Он забирает нижний слой

Когда говорят «AI заменит разработчиков», спор часто уходит в крайности.

Одни представляют полное исчезновение профессии. Другие отвечают, что сложные системы всё равно требуют людей, и поэтому ничего принципиально не изменится.

Но реальный сдвиг происходит между этими крайностями.

AI не должен заменить всю профессию сразу, чтобы радикально изменить рынок. Ему достаточно автоматизировать нижний слой задач:

• типовые CRUD‑сценарии;

• простые компоненты;

• миграции;

• базовые интеграции;

• тесты;

• документацию;

• простые багфиксы;

• первичный рефакторинг;

• объяснение чужого кода;

• быстрые прототипы.

Именно на этих задачах раньше учились начинающие разработчики.

Стажёр приходил в команду. Ему давали небольшую задачу. Он делал её медленно, ошибался, получал ревью, переписывал, спрашивал, ломал локальное окружение, снова чинил, постепенно понимал кодовую базу и учился видеть последствия своих решений.

Это был не самый эффективный способ закрывать задачи здесь и сейчас. Но это был способ выращивать инженеров.

Теперь компания смотрит на ту же задачу иначе: зачем отдавать её джуну на несколько дней, если мидл или сеньор с Codex, Claude Code, Copilot или другим агентом закроет её быстрее, дешевле и с меньшими организационными рисками?

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

Производство кода отделяется от профессии разработчика

В отчёте Sonar State of Code Developer Survey 2026 разработчики оценивают, что 42% их текущего кода уже является ИИ‑сгенерированным или существенно ИИ‑дополненным. К 2027 году они ожидают рост до 65%. Среди тех, кто пробовал ИИ‑инструменты для разработки, 72% используют их каждый день.

Можно спорить о точности каждой отдельной цифры. Можно говорить, что «AI‑assisted» — это не то же самое, что полностью сгенерированный код. Можно справедливо замечать, что автодополнение, чат, агент в IDE и автономная работа с PR — разные уровни участия модели.

Но направление очевидно: производство кода становится всё менее ручным процессом.

Anthropic в отчёте Agentic Coding Trends 2026 описывает похожий сдвиг: разработчики всё чаще не пишут каждую строку сами, а управляют агентами, которые берут на себя реализацию, тесты, документацию и работу с кодовой базой. При этом важная оговорка: по внутренним исследованиям Anthropic, разработчики используют AI примерно в 60% своей работы, но полностью делегировать могут только небольшую долю задач — обычно 0–20%.

Подробнее этот отчёт Anthropic я разобрал в своём Telegram‑канале.

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

Контур ответственности

Здесь появляется первый важный термин.

Контур ответственности — это всё, что остаётся за человеком, даже если код пишет машина:

• понять задачу;

• уточнить требования;

• выбрать архитектурный подход;

• определить ограничения системы;

• оценить безопасность;

• проверить производительность;

• предусмотреть крайние случаи;

• организовать тестирование;

• провести ревью;

• принять риск;

• отвечать за продакшен.

AI может сгенерировать код.

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

Поэтому новая роль сильного разработчика — не просто писать код быстрее.

Новая роль — удерживать контур ответственности.

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

Старый процесс:

разработчик получил задачу
→ написал код
→ написал тесты
→ открыл PR
→ получил ревью
→ поправил
→ смерджил

Новый процесс:

разработчик сформулировал задачу для агента
→ агент написал код→ агент открыл PR
→ разработчик проверил diff
→ нашёл неверную абстракцию
→ усилил тесты
→ проверил безопасность
→ принял ответственность за merge

В первом процессе человек производит большую часть кода.

Во втором процессе человек может написать меньшую часть кода, но всё равно отвечает за 100% последствий.

Это и есть новая асимметрия разработки: операционного участия меньше, ответственности больше.

Человек может написать 5% кода, но отвечать за 100% результата.

Что это меняет в работе команды

Представим обычную задачу: добавить новый endpoint, сохранить данные, отдать ответ, покрыть тестами.

Раньше это могла быть нормальная задача для джуна. Не слишком сложная, но полезная: разобраться в роутинге, DTO, валидации, слое доступа к данным, тестах, локальном окружении и правилах команды.

Теперь ту же задачу можно отдать агенту.

Через некоторое время агент откроет PR. Там будет endpoint, миграция, тесты, возможно, обновлённая документация.

Бизнес доволен: задача закрыта быстрее.

Сеньор доволен: меньше рутины.

Но у этого выигрыша есть скрытая цена: никто не прошёл учебный цикл.

• Не было вдумчивого чтения чужого кода;

• Не было ошибки в миграции;

• Не было вопроса на ревью: «почему ты положил эту логику сюда?»;

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

• Не было понимания, где в этой системе границы ответственности.

Задача закрыта. Инженер не вырос.

Если такое происходит один раз — ничего страшного.

Если так устроена вся воронка входа в профессию — рынок начинает сам себя обеднять.

Разрыв воспроизводства инженеров

Сеньор‑разработчик — это не человек, который просто дольше писал код.

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

Сеньорство нельзя полностью прочитать в документации. Его нельзя получить только через pet‑проекты. Его нельзя выучить только через промпты. Оно формируется через практику. Но если нижний слой практики автоматизируется, возникает разрыв воспроизводства инженеров.

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

Компании хотят мидлов, сеньоров, тимлидов, архитекторов.

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

Stanford AI Index 2026 фиксирует тревожный сигнал: занятость software developers в возрасте 22–25 лет упала почти на 20% с 2024 года. При этом эффекты AI на рынок труда проявляются неравномерно и сильнее концентрируются в найме и в самых молодых работниках в профессиях, подверженных AI.

Это не доказывает, что AI единолично «убил джунов». На рынок влияют ставки, постковидная коррекция, сокращения, насыщение bootcamp‑рынка, география найма и общая осторожность компаний.

Но AI усиливает уже существующий сдвиг.

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

AI‑потолок джуна

Так появляется второй термин — AI‑потолок джуна.

AI‑потолок джуна — это барьер между входом в профессию и реальной инженерной практикой.

Новичок больше не конкурирует только с другим новичком.

Он конкурирует с комбинацией:

опытный разработчик + AI‑инструменты + готовая инфраструктура + накопленный контекст команды.

И это нечестная конкуренция. Джун не проигрывает потому, что он ленивый или плохо учился.

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

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

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

Когнитивный потолок: джун не успевает сформировать базу

У AI‑потолка есть не только рыночная, но и когнитивная сторона.

Джун сегодня входит не просто в профессию разработки. Он входит в профессию, которая сама перестраивается быстрее, чем он успевает сформировать фундамент.

Ему нужно одновременно учить язык, фреймворки, Git, базы данных, тестирование, архитектуру, безопасность, работу с устаревшим кодом — и поверх этого ещё слой AI‑инструментов: Cursor, Claude Code, Copilot, Codex, агентные сценарии, контекст, промпты, правила ревью AI‑кода, новые режимы проверки и новые риски.

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

Для новичка тот же слой инструментов часто превращается в перегруз. Когда задача непонятна, делегирование модели выглядит рационально. Модель быстрее объяснит ошибку, напишет функцию, предложит тесты, соберёт прототип.

Но здесь появляется цикл когнитивной уступки:

непонятная задача:
→ перегруз
→ делегирование AI
→ быстрый результат
→ слабое внутреннее понимание
→ следующая задача кажется ещё сложнее
→ ещё больше делегирования.

Человек выигрывает задачу, но проигрывает навык.

Anthropic в недавнем исследовании о влиянии AI‑помощи на формирование навыков программирования показал похожий риск. В рандомизированном эксперименте участники с AI справились немного быстрее, но затем показали более слабое понимание: средний результат группы с AI на проверочном тесте был 50% против 67% у группы, которая писала код вручную. Исследователи отдельно отмечают, что агрессивное внедрение AI в рабочую среду может дать выигрыш в продуктивности, но навредить развитию навыков, необходимых для проверки AI‑кода.

Это не значит, что новичкам нельзя использовать AI. Наоборот, им придётся его использовать. Но способ использования становится критичным.

Есть большая разница между:

«сделай за меня»

и

«объясни принцип, покажи варианты, помоги найти ошибку, но я сам должен понять решение».

В первом случае AI закрывает пробел понимания.

Во втором — помогает его заполнить.

Поэтому главный вопрос для джуна в 2026 году звучит не так:

«умею ли я пользоваться AI?»

А так:

«становлюсь ли я сильнее после использования AI?»

Если после каждой задачи человек получает результат, но не получает понимания, он не растёт как инженер. Он просто учится управлять чужим мышлением.

В этом смысле AI‑потолок джуна — это не только проблема найма. Это проблема обучения.

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

Рынок уже показывает первые симптомы

Отдельно стоит сказать про рынок труда.

В России это уже ощущается не только как абстрактный разговор про будущее. Для начинающих специалистов рынок стал заметно жёстче.

Да, вакансии всё ещё есть и их много. На hh.ru, Хабр Карьере и других площадках можно найти объявления для junior и стажёров. Но наличие вакансии на сайте уже не всегда означает реальный живой спрос.

Часть объявлений висит месяцами. Часть собирает резюме «на будущее». Часть закрывается внутренними кандидатами. Часть зависает из‑за замороженного найма или долгого согласования.

Для джуна разница небольшая. Он видит вакансию, откликается, проходит тестовое, ждёт ответ — и сталкивается с тишиной.

Феномен «призрачных вакансий» уже обсуждается в HR‑среде: так называют объявления, которые создают видимость роста или собирают базу кандидатов, но не обязательно ведут к реальному найму прямо сейчас.

Параллельно публичные разборы российского IT‑рынка в 2026 году показывают другую проблему: в некоторых стеках и направлениях дисбаланс между вакансиями и активными резюме стал настолько сильным, что на небольшое число вакансий может приходиться огромный поток откликов. Один из разборов на Хабре прямо формулирует это как «2 вакансии, 1 000 откликов в сутки». Это не академическое исследование всего рынка, но хороший симптом того, как рынок ощущается изнутри. На своём личном опыте сталкивался с огромными волнами откликов на джун/интерн позиции при публикации вакансий 5–6 месяцев назад, ситуация сейчас ещё острее.

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

Поэтому фраза «рынку нужны IT‑специалисты» стала слишком общей.

Какие специалисты нужны?

Сильные — да.
Опытные — да.
Редкие — да.
Люди, которые могут быстро взять ответственность за систему, — да.

А вот нужно ли рынку такое же количество начинающих специалистов, как в эпоху роста 2020–2021 годов, — уже большой вопрос.

Именно здесь AI усиливает болезненный сдвиг. И в этой новой экономике джун оказывается в самой уязвимой позиции.

• Он ещё не приносит скорость как сеньор;

• Ещё не держит контур ответственности;

• Ещё требует онбординга;

• Ещё ошибается;

• Ещё нуждается в ревью;

• А задачи, на которых он мог бы учиться, уже всё чаще автоматизируются.

Главный вопрос теперь не в том, заменит ли AI разработчиков

AI не отменяет разработку.

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

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

Сеньоры не исчезают сейчас. Наоборот, сильные инженеры становятся ещё ценнее.

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

И здесь перед IT‑компаниями возникает новый вызов: что делать с начинающими специалистами?

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

Куда они пойдут, если бизнесу они всё меньше нужны?

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

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

• Кода станет больше

• ИИ‑агентов станет больше

• Автоматических PR станет больше

• Скорость поставки фич станет выше.

Но людей, которые понимают, как всё это работает, может стать меньше.

Поэтому главный вопрос ближайших лет звучит не так:

«Заменит ли AI разработчиков?»

И даже не так:

«Нужны ли будут джуны?»

Главный вопрос жёстче:

«Кто будет выращивать инженеров, если простые задачи больше не требуют людей?»

Если IT‑компании не построят новый карьерный лифт, рынок получит странную конструкцию: наверху — дорогие сеньоры и AI‑агенты, внизу — толпа людей, которые хотят войти в профессию, а между ними — всё меньше живых ступеней.

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

И, возможно, именно это станет одной из главных кадровых проблем IT в эпоху AI.

Если вам интересны такие разборы про AI, рынок разработки, продуктовые сдвиги и то, как меняется работа IT‑команд, я продолжаю писать об этом в личном Telegram‑канале