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

Давайте обозначим проблему. ChatGPT от OpenAI был запущен 30 ноября 2022 года и привлёк большое внимание пользователей своими широкими возможностями: написание кода, создание текстов, возможности перевода и т.д. и т.п. Через год уже стало понятно, что классический карьерный рост IT-инженера становится поставлен под удар.

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

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

Некоторые из вас скажут: «Ха-ха-ха, это то же самое что и было!». А вот и нет, это совсем не то же самое. Есть одно очень важное качество, которое мешает джуну быть синьорным джуном, я называю это качество «наивный оптимизм». Избавившись от этого качества джун получит необходимую ему синьорность, и войдёт в IT.

Избавившись от «наивного оптимизма» вы получите необходимую вам синьорность и войдёте в IT.

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

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

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

Анатомия проблемы: почему джуны игнорируют ошибки?

1. Образовательный разрыв

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

2. Когнитивное искажение

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

3. Отсутствие боевого опыта

Джуны просто не сталкивались с ситуациями, когда:

• База данных не отвечает в самый неподходящий момент

• Внешний API возвращает неожиданный формат данных

• Пользователь вводит "Абырвалг"

• Система потребляет всю доступную память из-за незакрытого соединения

• Пролетевшее нейтрино «выбивает» кусок памяти

4. Давление сроков

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

5. Вайбкодинг

Красивый, «вайбовый» код без обработки ошибок становится образцом для подражания. Молодые разработчики копируют этот стиль, не понимая, что видят лишь вершину айсберга, в то время как под водой скрывается 90% кода, обеспечивающего надежность.

// Красиво, лаконично, работает (в идеальных условиях)
const fetchUserData = async (id) => {
  const response = await fetch(`/api/users/${id}`);
  const data = await response.json();
  return data;
};

Суровая математика бизнеса

Представьте себя на месте технического лидера. Раньше он брал джуна с потенциалом, зная, что через 6-12 месяцев вложений в обучение получится полноценный мидл. Сейчас картина изменилась:

1. Синьоры с Copilot/Claude повысили свою эффективность на 30-50%. Они закрывают задачи, которые раньше требовали помощника.

2. LLM действительно пишут неплохой шаблонный код для стандартных задач: CRUD-операции, простые API, базовые компоненты.

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

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

Станьте «инженером по надежности» своего кода

Для каждого куска кода задавайте вопросы не только «работает ли», но и:

• Как мы будем мониторить это в проде?

• Что произойдет при пиковой нагрузке?

• Как откатить это изменение, если что-то пойдет не так?

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

Раньше джун был «руками» — реализовывал простые задачи под руководством синьора. Теперь ИИ стал «руками» синьора.

Работодатель будет платить вам не за написание строчек кода, а за то за что он платит синьору:

• Способность принимать архитектурные решения

• Умение предвидеть проблемы до их появления

• Глубокое понимание, которое невозможно выучить за неделю с помощью ИИ

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

Об образовании

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

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

Вывод

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