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

Мы в Beeline Cloud решили разобраться в теме.

Где-то мы это уже видели

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

Цифровизация в целом. В 1970-е годы в США начали появляться первые банкоматы, и банковские операционисты всерьез опасались, что останутся без работы — ведь новенькие аппараты сами могли выдавать наличные, а позже научились принимать деньги. В каком-то смысле распространение банкоматов действительно привело к сокращению персонала в отделениях. Однако парадокс в том, что за тот же период занятость в данной отрасли выросла — с 300 тыс. работников в 1970 году до 600 тыс. в 2010-м. Как поясняет экономист Джеймс Бессен из Бостонского университета, в то время количество банковских филиалов росло, поскольку финансовые организации боролись за рынок, в том числе за счет новых технологий.

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

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

Подобная ситуация в каком-то смысле сложилась еще вокруг COBOL, представленного в конце 1950-х — начале 1960-х годов. Его продвигали как универсальное решение: предполагалось, что он настолько прост, что писать бизнес-приложения смогут не программисты, а менеджеры и бухгалтеры. И COBOL действительно обрел аудиторию, заняв значительную долю рынка. Им пользовался бизнес, банки, госкомпании; язык до сих пор лежит в основе многих критических legacy-систем. Но заменить разработчиков он не смог, ведь чтобы писать эффективный и поддерживаемый код на COBOL, по-прежнему требовались логическое мышление, навыки отладки и понимание ограничений систем.

История повторилась в начале 1990-х, когда на сцену вышли языки и среды разработки четвертого поколения (4GL). Они были ориентированы на узкие прикладные области и были ближе к естественному языку с точки зрения синтаксиса. Многие тогда тоже посчитали, что благодаря 4GL чуть ли не любой желающий сможет написать собственное приложение, а труд профессиональных программистов обесценится. Любопытно, что среди радикальных прогнозов фигурировала даже «смерть языков третьего поколения» — в том числе COBOL. Пользователь одного из форумов рассказал, что еще его дед писал статью про кончину этого ЯП. Он отмечал, что миграция на 4GL неизбежна, но займет какое-то время, а «COBOL мертв, но не похоронен» лишь потому, что нем уже написано огромное количество приложений. 

Спустя тридцать лет мы видим, что не только разработчики на COBOL по-прежнему существуют (хотя, очевидно, что язык теперь является крайне нишевым), но и развитие 4GL не привело к массовой безработице среди программистов. Наоборот, новые технологии поспособствовали росту спроса на специалистов с соответствующими навыками, ведь некоторые идеи 4GL мигрировали в языки SQL и R. При этом SQL сегодня занимает третье место по популярности и используется почти 61% профессиональных разработчиков.

Хайп по no-code и low-code. Буквально в начале десятилетия апологеты no-code и low-code-программирования настаивали, что уже в ближайшем будущем сотрудники без знаний языков и опыта в программировании вполне смогут заменить разработчиков на ряде направлений. Подобные заявления также вызвали тревогу в профессиональной среде, однако обещанной революции так и не случилось. Low-code-платформы заняли свою нишу и превратились во вспомогательный инструмент, но о замене разработчиков речи не идет — почему так получилось, мы подробнее обсуждали в одном из наших прошлых материалов на Хабре. 

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

Пока (почти) все на месте

Заметные фигуры в индустрии не раз заявляли, что вот-вот появятся системы ИИ, способные писать «идеальный» код — и тогда, мол, профессии разработчика придет конец. В той же Microsoft машинные алгоритмы уже пишут порядка 20–30% кода, при этом компания ожидает, что к 2030 году эта цифра вырастет до 95%. Но параллельно звучит и другое мнение: индустрия в очередной раз страдает краткосрочной амнезией и повторяет знакомый сценарий. Идея массовой замены разработчиков системами ИИ — это очередной виток цикла, в котором новая технология не уничтожает профессию, а меняет характер работы: например, когда вместо простого написания кода инженеры постепенно берут на себя роль системных архитекторов. 

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

А минимизировать ошибки приходится: в феврале 2025 года исследователи из Швейцарской высшей школы Цюриха и Калифорнийского университета представили бенчмарк BaxBench, предназначенный для оценки качества кода, который генерируют LLM-модели. В него вошли 392 задачи по разработке backend-приложений, а также набор функциональных и security-тестов: в ходе проверки в систему отправлялись вредоносные API-запросы, чтобы выявить уязвимости. Результаты оказались показательными: более чем в 60% случаев «ИИ-код» либо не работал, либо содержал критические уязвимости. Даже флагманские ИИ-системы пока не способны стабильно выдавать решения, которые можно использовать без доработок.

При этом стоит отметить, что нейросети не всегда ускоряют решение проблем. В прошлом году ИТ-сообщество активно обсуждало исследование организации METR — в том числе здесь на Хабре. Его авторы пришли к выводу, что использование интеллектуальных инструментов замедляет работу опытных разработчиков. Участники эксперимента закрывали рабочие задачи как с использованием ИИ, так и без помощи ассистентов. Выяснилось, что в первом случае инженеры выполняли задания в среднем на 19% медленнее, хотя сами были уверены, что скорость работы возросла.

Более того, некоторые отмечают, что нейросети пока не способны заменить даже джуниоров, не говоря уже о мидлах и сеньорах. Недавно генеральный директор AWS Мэтт Гарман прямо заявил, что идея подменить младших разработчиков LLM-моделями лишена смысла. По его словам, отказ от найма джунов разрушает кадровый конвейер и препятствует потоку свежих идей. При этом он подчеркнул, что, в отличие от программистов старой школы, начинающие разработчики лучше обращаются с нейросетями и «способны извлечь из них наибольшую пользу». Этот тезис подтверждает и свежий опрос Stack Overflow, согласно которому 55,5% «молодых» программистов ежедневно пишут код в паре с нейросетью

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

Учитывая текущую ситуацию и настроения среди специалистов и руководителей компаний, говорить о замене разработчиков пока рано. Возможно, история будет развиваться по сценарию с банкоматами. Распространение интеллектуальных систем уже создает новые рабочие места, причем зачастую более высокооплачиваемые. Разработчики переходят на стратегические позиции и курируют работу систем ИИ: отвечают за контроль, интеграцию и принятие решений. Свежие прогнозы от Morgan Stanley подтверждают этот тренд: рынок труда в ИТ продолжит расти — число разработчиков будет увеличиваться в среднем на 1,6% в год вплоть до 2033 года, а совокупные расходы на разработку ПО вырастут почти на 4%.

Уже сейчас в индустрии рассуждают о следующей потенциальной «угрозе». Один из вариантов — так называемые созвездия автономных агентов. По сути, это несколько специализированных LLM-систем, объединенных в команду для планирования, делегирования и выполнения задач — от написания кода и проведения ревью до развертки инфраструктуры. В первой половине прошлого года сразу 68% руководителей ИТ-компаний планировали профинансировать создание подобных «созвездий». Что интересно, такие инструменты уже развиваются, в том числе на базе open source-технологий — и существуют не только в сфере ИТ, но и в других областях. Хотя специалистам все еще предстоит решить вопросы с интеграцией, риск-менеджментом и качеством данных для обучения подобных систем. 

Beeline Cloud — secure cloud provider. Разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.

О чем еще мы рассказываем в нашем блоге:

• «У меня есть новость для вашего безопасника» — или зачем нужен security.txt

• Экспериментальные дата-центры списывают, а классическое ЦОДы снова в моде?

• С толикой «крипоты» — откуда пришло понятие feature creep