Анализ почти 50 тысяч вакансий показал, что новые роли в IT появляются не в виде армии одинаковых «AI-инженеров», а на стыке привычных специальностей. Для русскоязычных разработчиков и руководителей это плохая новость для тех, кто рассчитывал спрятаться за универсальным резюме, и хорошая — для специалистов с глубокой базой, готовых освоить соседний участок работы.
Исследование провела Andela — компания, работающая с глобальным рынком технических специалистов. Руководитель исследований Corey Hymel рассказал, что команда сопоставила вакансии со своей детальной таксономией навыков, чтобы увидеть изменения раньше, чем рекрутеры успеют придумать им устойчивые названия, сообщает Stack Overflow Blog. Главный вывод: заголовок вакансии всё хуже объясняет реальную работу, а внутри старых ролей формируются устойчивые наборы новых компетенций.
На рынке много разговоров о том, что генеративный ИИ превратит разработчиков в тотальных универсалов: один человек будет одновременно писать код, проектировать интерфейсы, общаться с пользователями, настраивать инфраструктуру и тестировать результат. Данные Andela такой картины не подтверждают. Компании не столько ищут абстрактного сотрудника «на всё», сколько смешивают навыки в соседних звеньях процесса разработки: продукта и фронтенда, бэкенда и эксплуатации, документации и инженерии ИИ.
Это объясняет и популярность расплывчатого названия AI engineer. Оно удобно работодателю: можно не разбираться в десятках комбинаций навыков и положить все требования в один мешок. Но для кандидата такая вакансия может означать что угодно — от интеграции API языковых моделей до построения систем оценки агентов, контроля расходов на токены и настройки ограничений для корпоративных данных. Название одно, а профессиональные профили совсем разные.
Один из обнаруженных Andela профилей — инженер LLM-приложений. Это не просто бэкенд-разработчик, который умеет вызвать API модели. Такому специалисту нужны навыки создания приложений поверх LLM и открытых моделей, проектирования обвязки вокруг них, построения evals — проверок качества ответов и поведения агентов, а также настройки governance и guardrails. Иными словами, модель надо не только подключить к продукту, но и научиться измерять её полезность, ограничивать ошибки и поддерживать систему после запуска.
Второй профиль связан с экономикой ИИ. Hymel называет его FinOps reliability engineer: инженер должен учитывать стоимость разработки и эксплуатации наряду с производительностью и надёжностью. Речь идёт не только о привычных счетах за облако. В ИИ-ориентированной разработке расходы возникают при использовании моделей, инструментов для разработчиков и сервисов с оплатой по потреблению. Выбор между быстрой дешёвой моделью для простого шага и более мощной для сложной задачи становится архитектурным решением с финансовыми последствиями. Для CTO это повод перестать обсуждать токены исключительно как заботу команды платформы.
Третий пример — docs-as-code engineer. На фоне интереса к разработке по спецификациям и агентному программированию растёт ценность людей, которые умеют создавать точный контекст для моделей и команд. Классические технические писатели здесь получают неожиданное преимущество: хороший документатор умеет формулировать требования, фиксировать ограничения и поддерживать знания о кодовой базе. Когда агенту нужно дать задачу в большом проекте, плохо оформленная документация превращается из раздражающего долга в прямую причину лишних итераций и ошибок.
Изменения заметны и в привычных инженерных ролях. Фронтенд-разработчик может сильнее включаться в продуктовую работу: разговаривать с пользователями, собирать обратную связь, участвовать в приоритизации функций. Бэкенд-разработчик — уходить в сторону развёртывания моделей, масштабирования и эксплуатации. Hymel описывает это как расширение от основной специализации в одну сторону, а не отмену специализации. По его оценке, рынок скорее движется к T-образному профилю: широкое понимание смежных задач дополняет глубокую экспертизу, а не заменяет её.
Для компаний новые роли в IT означают, что шаблоны вакансий и матрицы компетенций придётся пересматривать быстрее обычного. Нанимать «AI-инженера» без описания конкретной зоны ответственности — почти гарантированный способ получить поток нерелевантных откликов и разочарование после выхода сотрудника. Для специалистов практичнее выбирать соседнюю область к уже сильной базе: бэкендеру — оценку и эксплуатацию LLM-систем, фронтендеру — продуктовую аналитику и исследование пользователей, техписателю — спецификации и контекст для агентов.
Самый интересный вопрос теперь не в том, исчезнут ли старые названия должностей. Они, вероятно, ещё долго останутся в HR-системах и на визитках. Важнее, какие из нынешних гибридных наборов навыков закрепятся как отдельные профессии, а какие окажутся временной надстройкой над привычной разработкой. Пока рынок явно голосует не за «мастера на все руки», а за специалиста, который хорошо знает свою область и понимает, где начинается следующая.