Автор: Анна Жибулёва, HR OSMI IT

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

 

По данным hh.ru, доля вакансий, где требуются навыки работы с искусственным интеллектом, за три года выросла в 2–3 раза — особенно в аналитике, разработке, маркетинге и дизайне. CNews со ссылкой на исследование hh.ru и PR DEV также писал, что в I квартале 2026 года российские работодатели разместили более 16,5 тыс. вакансий, где одним из требований было умение работать с ИИ-инструментами или готовность их осваивать. По сравнению с аналогичным периодом 2025 года упоминаемость таких навыков выросла в 2,7 раза. Для IT это уже не модная надстройка, а новая профессиональная норма.

Что изменилось в найме разработчиков

Еще несколько лет назад на собеседовании было достаточно проверить стек, опыт коммерческой разработки, качество кода, понимание архитектуры и умение работать в команде. Сейчас к этому добавился еще один обязательный блок: как кандидат использует ИИ в работе.

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

ИИ не отменяет разработчика. Но он забирает значительную часть типовой рутины: генерацию шаблонного кода, первичную проверку гипотез, написание тестов, подготовку документации, анализ ошибок, работу с повторяющимися сценариями. Раньше такие задачи могли занимать много времени у junior- и middle-специалистов. Теперь они всё чаще закрываются быстрее — при условии, что человек умеет правильно поставить задачу модели и проверить результат.

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

Вайбкодинг — не про «написать как-нибудь»

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

Сильный специалист не просто просит модель написать код. Он умеет:

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

Это важный момент для заказной разработки и enterprise-проектов. Ведь у компании должна быть политика работы с данными, кодом и клиентской информацией. Если проект связан с персональными данными, закрытым контуром или требованиями информационной безопасности, использование ИИ должно быть управляемым, а не стихийным.

Кейс OSMI IT: кандидат, который управляет тремя ИИ-агентами

На одном из собеседований мы общались с backend-разработчиком из заказной разработки. Он сказал: «Я уже год не пишу код руками в прежнем объеме». У кандидата был выстроен собственный рабочий контур из трех ИИ-агентов: один помогал писать код, второй — тестировать, третий — готовил аналитику и отчетность. Сам разработчик администрировал этот процесс, проверял результат и отвечал за качество.

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

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

Какие вопросы я задаю на собеседовании

Один из обязательных вопросов на интервью сейчас звучит так: «Какими ИИ-инструментами вы пользуетесь и как именно вы с ними работаете?»

Дальше важно не просто услышать название сервиса. Мне важно понять механику:

Что спрашиваем	Что хотим понять
Какие ИИ-инструменты используете?	Следит ли кандидат за рынком и пробует ли новые решения
Для каких задач используете ИИ?	Есть ли реальный рабочий опыт, а не только интерес
Как проверяете результат модели?	Понимает ли кандидат риски ошибок, галлюцинаций и некачественного кода
Какие задачи не делегируете ИИ?	Есть ли профессиональные границы и ответственность
Использовали ли несколько моделей под разные задачи?	Умеет ли кандидат сравнивать инструменты, а не зависеть от одного сервиса
Как соблюдаете безопасность данных?	Понимает ли ограничения enterprise-проектов, NDA и работы с клиентским кодом
Собирали ли своих агентов или автоматизации?	Есть ли навык оптимизации собственных процессов

Показательный ответ — не «я иногда прошу ChatGPT что-то подсказать». Сильный ответ — это конкретный рабочий сценарий: что было до ИИ, что изменилось после, какие инструменты использовались, как проверялось качество и какой эффект получила команда.

Если компания запрещала ИИ — это не всегда минус

Часть кандидатов говорит: «Я не работал с ИИ-инструментами, потому что политика компании, в которой работал(а) запрещала их использовать». Это нормальная ситуация, особенно если речь идет о крупном бизнесе, закрытых контурах, персональных данных или чувствительной разработке.

Но здесь важна позиция самого кандидата. Если человек не мог использовать ИИ на рабочем проекте, он всё равно мог изучать инструменты вне работы: тестировать модели на учебных задачах, собирать личные автоматизации, писать pet-проекты, пробовать ИИ-агентов для своей сферы. В IT сейчас важно оптимизировать не только бизнес-процессы компании, но и собственную работу.

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

Кейс OSMI IT: Cursor как рабочий инструмент команды

В OSMI IT мы внедрили Cursor с оплачиваемыми токенами для сотрудников, чтобы ускорить работу над проектами и снять часть рутины с команды, оставляя за ней ответственность. 

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

Кого лучше нанять: senior без ИИ-опыта или middle с ИИ-опытом

Здесь нет универсального ответа. Я бы не выбирала только по грейду. Важнее смотреть на проекты, с которыми работал кандидат, его способность быстро входить в сложный контекст, уровень ответственности, понимание бизнеса и то, как он использует ИИ в работе.

Но если речь идет об ИИ-продуктах или сложной заказной разработке для крупного бизнеса, я скорее выберу middle+ со смежным опытом и реальными ИИ-навыками, чем сильного senior, который принципиально не работает с ИИ и не готов менять подход.

Почему? Потому что ИИ-продукты сложны в онбординге. Нужно понимать не только разработку, но и бизнес-процессы, данные, интеграции, ограничения клиента, безопасность, логику агентов и работу с моделями. Если специалист уже умеет использовать ИИ как часть своего рабочего процесса, он быстрее адаптируется к такой среде.

При этом senior без ИИ-опыта не становится автоматически слабым кандидатом. Но для него важен другой критерий: готовность быстро перестроиться. 

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

Если позиция звучит как «я всегда писал руками и буду писать только так», — это другая.

Что происходит с PM и менеджерами проектов

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

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

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

Что ИИ может забрать у PM	Что остается за PM
Саммари встреч	Управление ожиданиями клиента
Черновики отчетов	Приоритизация задач и решений
Первичную аналитику задач	Коммуникация между бизнесом и командой
Подготовку статусов	Управление рисками
Структурирование backlog	Ответственность за сроки, бюджет и результат
Шаблонные письма и документы	Понимание клиента, контекста и возможностей для развития проекта

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

 

Как создать в компании устойчивую среду, в которой сотрудники могут быстро проверять идеи и запускать эксперименты, приносящие бизнес-результат   

 

Нужны ли ещё рынку junior- и middle-специалисты?

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

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

Полностью отказываться от junior опасно: без них рынок не получит будущих middle и senior. Но роль их меняется. Это уже не сотрудники, которым можно отдать всю рутину. Это кандидаты, которые должны быстро наращивать самостоятельность и учиться работать в новой технологической среде.

Мини-чек-лист для кандидата, который хочет быть в рынке

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

Мини-чек-лист для работодателя

1. Добавить в интервью блок про ИИ-инструменты и реальные сценарии их использования.
2. Проверять не только факт использования ИИ, но и качество контроля результата.
3. Разделить разрешенные и запрещенные сценарии работы с ИИ внутри компании.
4. Дать сотрудникам легальные и безопасные инструменты, а не ждать, что они будут использовать случайные сервисы.
5. Обучать не только разработчиков, но и PM, аналитиков, HR, маркетинг и другие функции.
6. Оценивать производительность не по количеству ручных действий, а по качеству результата.
7. Не заменять экспертизу ИИ-инструментами, а усиливать экспертов за счет ИИ.

Вывод

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

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

 

 

Экономика экспертности в России: что интересует россиян, чему учатся и за что платят