Одинаков ли риск увольнения из-за ИИ для джунов и сеньоров?

ИИ не уничтожит профессию инженера, но уже сокращает объем рутинной разработки, за который компании готовы платить людям. Это важное различие. Число рабочих мест в профессии может расти, хотя попасть в нее становится намного сложнее. Звание сеньора тоже может обесцениться, если за ним стоят лишь годы работы с предсказуемыми задачами из трекера.

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

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

Данные одновременно говорят о росте и вытеснении

Общий объем разработки растет, но состав задач и специалистов внутри профессии меняется. Бюро трудовой статистики США прогнозирует рост занятости разработчиков ПО на 15,8% с 2024 по 2034 год, что означает около 267 700 новых рабочих мест. В той же таблице число рабочих мест для программистов должно сократиться на 6%. Ведомство разделяет эти профессии не случайно: у проектирования ПО и ответственности за него перспективы лучше, чем у перевода готовых спецификаций в код.

Глобальный опрос работодателей в отчете Всемирного экономического форума Future of Jobs Report 2025 показывает ту же картину. Разработчики ПО и приложений входят в число профессий с ожидаемым значительным чистым ростом к 2030 году. В отчете также сказано, что технологии ИИ и обработки информации создадут 11 миллионов рабочих мест и вытеснят 9 миллионов по всей экономике. Это прогнозы на основе опросов, а не обещание конкретному инженеру. Зато они объясняют, почему общая фраза «рабочие места исчезают» не описывает происходящее.

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

Часто смешивают три разных показателя:

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

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

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

Изменения будут идти с разной скоростью в разных странах и компаниях. Регулируемый банк, производитель оборудования и стартап на ранней стадии не могут в одинаковом темпе передавать ИИ одни и те же задачи. На наем независимо от ИИ влияют местный рынок специалистов, доступность финансирования и аутсорсинг. Сравнивайте позиции на рынке, где вы действительно можете работать. Не переносите прогноз для США на любую страну и не считайте кадровый план одного стартапа прогнозом для всего мира. Направление общее, сроки зависят от места.

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

Первым страдает спрос на джунов

Давление на начинающих инженеров сильнее, потому что ИИ пересекается с задачами, на которых компании традиционно учили и оценивали новых сотрудников. Типовые конечные точки API, заготовки тестов, простые преобразования данных, черновики документации и небольшие исправления ошибок никогда не составляли всю работу джуна. Это были безопасные задачи, с помощью которых новичок изучал кодовую базу и завоевывал доверие.

Исследователи Stanford Digital Economy Lab Эрик Бриньолфссон, Бхарат Чандар и Жуюй Чэнь изучили зарплатные ведомости ADP в работе «Canaries in the Coal Mine?». В версии за ноябрь 2025 года они обнаружили относительное снижение занятости на 16% среди работников 22-25 лет в профессиях, сильнее всего подверженных влиянию ИИ, после учета изменений на уровне компаний. Занятость более опытных работников в тех же профессиях оставалась стабильной или росла. В примере с разработчиками ПО к сентябрю 2025 года занятость людей 22-25 лет упала почти на 20% относительно пика конца 2022 года.

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

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

Возникает проблема обучения, которую работодатели часто игнорируют. Удалив все безопасные стартовые задачи, компания уничтожает путь к пониманию рабочих систем. Если команда три года не берет джунов, на четвертый год опытные кандидаты из воздуха не появятся. Сильные технические руководители сохранят стажировки и наставничество, изменив содержание начальной работы. Остальные оптимизируют ближайший бюджет и переложат дефицит кадров на кого-то еще.

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

Сеньора защищает контекст, а не должность

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

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

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

Рандомизированное исследование METR с инструментами начала 2025 года полезно отрезвляет тех, кто обещает мгновенное ускорение каждому опытному разработчику. Шестнадцать опытных участников проектов с открытым исходным кодом выполнили 246 реальных задач в хорошо знакомых репозиториях. С ИИ они в среднем тратили на 19% больше времени, хотя считали, что ускорились. Выборка была узкой, инструменты конкретными, а средняя задача занимала около двух часов. Поэтому вывод «ИИ замедляет всех сеньоров» неверен. Но исследование показывает, что знание проекта, стоимость проверки и неочевидные ограничения репозитория могут съесть всю видимую экономию от генерации.

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

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

ИИ сначала забирает задачи, а потом меняет профессии

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

В рамках Anthropic Economic Index исследователи проанализировали 500 000 диалогов о программировании. При использовании агента для программирования люди чаще автоматизировали работу, тогда как в обычных чатах автоматизация сочеталась с совместной работой. Источник опирается на данные собственного продукта поставщика, поэтому он не описывает всех инженеров и все инструменты. Но он показывает, как люди используют способных агентов: поручают им законченные части реализации, а не ограничиваются просьбой подобрать имя переменной.

Подверженность задачи влиянию ИИ зависит от четырех свойств:

• Входные данные можно записать без большого объема закрытого контекста.
• Результат легко быстро проверить тестами или статическими правилами.
• Ошибка обходится недорого, а изменение можно отменить.
• Задача похожа на шаблоны из кода и документации.

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

Поэтому вопрос «какой процент программирования может выполнить ИИ?» плохо подходит для планирования карьеры. Объем кода не равен экономической ценности. Модель может создать 90% строк в изменении, а человек добавит ограничение, которое предотвратит потерю данных. Другой инженер вручную напишет каждую строку малозначимой внутренней страницы. Число строк почти ничего не говорит о том, без чьей работы компания сможет обойтись.

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

Рутинная реализация стала опасной серединой

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

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

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

Инженер, который останется нужен после такой перестройки, задает другие вопросы до генерации кода. Насколько большим бывает импорт? Может ли пользователь безопасно повторить попытку? Какие побочные эффекты должны случиться один раз? Что увидит поддержка при ошибке в строке 8 412? Можно ли остановить и продолжить процесс? Какая метрика покажет, что очередь отстает? Эти вопросы превращают задачу реализации в ответственность за поведение.

Я не советую всем подряд «становиться ИИ-инженерами». Совет популярен, потому что обещает понятный переход в растущую специальность. Некоторым действительно стоит изучать оценку моделей, поиск по данным, системы инференса или проектирование агентов. Для остальных попытка выдать обычные вызовы API за экспертизу в ИИ создает поверхностное резюме на переполненном рынке. Каждой отрасли по-прежнему нужны инженеры, понимающие ее данные, сбои, экономику и клиентов.

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

Меняйте позицию через ответственность и доказательства

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

Используйте такую запись ответственности для проекта или заметного изменения:

Outcome:
Constraint I discovered:
Decision I made and alternatives rejected:
Work delegated to AI:
Checks I ran myself:
Failure found before release:
Production signal after release:
Business result or cost avoided:

Заполните каждую строку фактами, которые можно обсуждать без раскрытия закрытой информации. В строке «Checks I ran» назовите нагрузочный тест, репетицию миграции, матрицу разрешений, проверку отката или сравнение с известными случаями. В «Production signal» укажите метрику, событие журнала, трассировку или обращение поддержки, которые подтвердили поведение. Если строки заполнить нечем, проект может доказывать активность, а не ответственность.

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

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

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

Сдвиг в карьере виден по глаголам. «Реализовал» и «помогал» описывают участие. «Определил», «ограничил», «проверил», «эксплуатировал» и «сократил» описывают ответственность. Не усиливайте глаголы в резюме, пока за ними нет доказательств. Сначала измените саму работу.

Портфолио должно показывать работу с ИИ под контролем

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

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

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

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

$ ./replay-fixture duplicate-payment.json
event payment_104: accepted
event payment_104: ignored_duplicate
charges_created=1

Такая форма вывода скажет интервьюеру больше, чем значок о владении моделью. Она показывает понимание идемпотентности, наблюдаемости и бизнес-последствий. Репозиторию не нужно обращаться к настоящему платежному провайдеру. Детерминированный пример проще проверить.

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

Если работодатель запрещает публиковать код, напишите обезличенную запись решения. Опишите масштаб общими словами без выдуманной точности, сформулируйте ограничение и покажите метод проверки. На собеседовании руководитель сможет проверить ваше рассуждение вопросами. Из пункта резюме «использовал ИИ для повышения производительности» он ничего не узнает.

Выбирайте работодателя по модели работы

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

Попросите привести недавний пример изменения, которое с помощью ИИ дошло до рабочей среды. Кто написал критерии приемки? Как его проверяли? Какой рабочий сигнал имел значение? Инструмент сократил время реализации, проверки или весь путь до выпуска? Зрелый ответ содержит упоминание сложностей. Расплывчатое заявление «все стали в десять раз быстрее» обычно означает, что компания не измеряла всю систему.

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

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

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

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

Изменитесь раньше, чем вашу роль изменят без вас

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

За следующие 30 дней создайте одно доказательство:

1. Две недели учитывайте задачи по объему нужного контекста, цене проверки, обратимости и последствиям для бизнеса.
2. Выберите одну повторяемую задачу с низким риском и проверьте ИИ по полному времени выполнения, включая постановку, проверку, исправление и выпуск.
3. Возьмите одну соседнюю обязанность, которую ИИ не может вывести из входных данных: критерии приемки, план запуска, расчет стоимости или наблюдение за рабочей системой.
4. Составьте запись ответственности и попросите уважаемого инженера найти слабые места в допущениях.
5. После исправлений превратите запись в пример для портфолио или внутреннее предложение о более широкой области ответственности.

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

Если вы руководите компанией, оцените должности на уровне задач до заморозки найма или введения произвольной нормы использования ИИ. В рамках Team & AI Audit я за пять рабочих дней составляю карту работы, затрат и эксплуатационных ограничений, а затем нахожу экономию не менее $50 000 в год, иначе аудит бесплатен. Систему нужно перестраивать на основе доказательств, потому что грубые сокращения часто уничтожают контекст, который оставшаяся команда уже не восстановит.

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