ИТ-индустрия активно движется в сторону так называемой "ассистированной разработки". Это свершившийся факт. В этом случае искусственный интеллект подключен на каждом шагу: когда задачу придумывают, когда пишут код, когда его проверяют и выпускают для пользователей. Инженер работает с ИИ-инструментами, которые встроены в работу команды, подчинены ее правилам. Продакт-инженер выступает в роли ИИ-разработчика с продуктовым видением. Инструменты забрали часть повторяющихся операций, освободившееся время ушло на задачи, которые раньше в его зону ответственности не входили, и именно поэтому требования к специалисту выросли.
Чем новая роль отличается от фуллстека
При этом границы между специальностями в разработке размываются сильнее с каждым годом. Сначала появился фуллстек-разработчик, который закрывает и бэкенд, и фронтенд. Потом разработку соединили с эксплуатацией в профессии DevOps. Потом распространилась модель T-shaped, где человек глубоко знает свою область и уверенно ориентируется в соседних. Каждое изменение добавляло специалисту зоны ответственности и требовало от него больше знаний, поэтому такие люди оставались редкостью и стоили дорого.
"Нынешний виток отличается снижением цены входа в смежную зону. Раньше, чтобы взять на себя тестирование, инфраструктуру или продуктовую часть, приходилось изучать их всерьез и годами. Сейчас достаточно понимать, как соседняя область устроена, и уметь самостоятельно углубиться в конкретный вопрос, когда он возникает. ИИ-инструменты закрывают ту часть работы, которая раньше требовала отдельного специалиста, - рассказывает директор по персоналу Битрикс24 Олеся Сагалакова. - Классификация "джун, мидл, сеньор" (начинающий, опытный, ведущие разработчики. - Прим. "РГ") также устаревает. Инструменты дают наибольший прирост тем, у кого уже есть накопленный опыт, потому что усиливают имеющуюся экспертизу и не создают ее с нуля. Быстрее всего стирается граница между мидлом и сеньором. Раньше до этого уровня можно было дорасти проактивностью и объемом работы, дальше начинался долгий этап, где значение имел накопленный опыт: проектный, архитектурный, продуктовый. Но сейчас мидлу с инструментами открываются задачи, которые еще недавно уходили только сеньорам, и разрыв сокращается до месяцев вместо нескольких лет".
Эксперт отмечает, что сегодня граница между джуном и мидлом при этом тоже меняется. Это связано с тем, что усиливать у начинающего специалиста пока нечего, при этом от него ждут того, что год назад спрашивали с мидла, то есть умения работать с инструментами, разбираться в задаче целиком и проверять то, что получилось. Он может, используя ИИ-модель, собрать работающий сервис и написать к нему тесты, при этом не заметит, что через полгода выбранное решение упрется в рост нагрузки и потребует полной переделки. Поэтому джуновские позиции в привычном виде постепенно исчезают из ленты вакансий.
Нежелание нанимать джунов обсуждают как один из главных рисков текущей трансформации, так как это может привести к снижению числа мидл- и сеньор-специалистов через 5-10 лет.
"Мои наблюдения за самыми талантливыми ребятами говорят, что в 17-19 лет они становятся джунами на пет-проектах еще в вузе или колледже. Откуда возьмутся опытные специалисты? Из профессиональной среды гиков с адекватным образованием (и иногда даже без него), но из всего "моря людей" в ИТ сеньорами могут стать лишь проценты, поэтому таких джунов больше никто и не хочет брать", - считает заместитель директора управления продуктов и технологий "Е-Флопс" Филипп Моднов.
А руководитель продуктового направления компании "НЕКСТБИ" Евгений Сурков уверен, что необходимо заботиться о наличии в штате специалистов уровня сеньор, так только они могут адекватно контролировать весь поток "ИИ-артефактов", достающийся от коллег с меньшим уровнем опыта: "Крупные компании решат вопрос более ранним и более долгим целевым обучением, сотрудничая с вузами и открывая свои. Опытные специалисты также могут по-прежнему появляться в малых успешных командах и стартапах, которые, возможно, будут некоторое время более конкурентны на меняющемся рынке".
Почему схлопывание ролей идет медленно
Роли в командах объединяются постепенно. В публичном поле тема обсуждается активно, на практике компании действуют осторожно по двум причинам. Часть работодателей пока не решается перестраивать команды, потому что цена ошибки высокая: неудачный эксперимент означает потерю сильных людей и просадку по срокам. Другая часть уже пробует новые форматы внутри, но публично результаты не озвучивает.
Несмотря на то, что открытых успешных кейсов смены формата разработки пока нет, рынок определенно движется в эту сторону. Перераспределяют бюджеты между специальностями и наращивают спрос на инженеров, которые закрывают несколько зон сразу. В России количество ИТ-вакансий сократилось на 22% с начала 2025 года, а доля позиций, где от кандидата ждут работы с ИИ-инструментами, постоянно растет.
Направление изменений понятно. Предметом спора остается лишь скорость. Разработчик, который начал перестраиваться сейчас, входит в новую конфигурацию раньше, чем она станет обязательным требованием. Скорее всего, через несколько лет такой профиль перестанет считаться редким и превратится в норму найма. Открытым остается вопрос, где у этой роли предел. Объединять задачи можно до определенной черты, дальше человек перестает справляться с объемом ответственности, и сейчас никто не знает, где эта черта проходит.
Производительность, предела которой никто не знает
Работать больше при таком подходе не требуется, потому что специалист переходит на уровень выше и становится редактором вместо автора, а значит, проверяет логику, ловит ошибки и отвечает за итог, тогда как саму работу ведет параллельно в нескольких потоках. За тот же рабочий день специалист, управляющий ИИ-ассистентами, выдает заметно больше, чем полгода назад. Написание кода делится на параллельные потоки, и выигрыш по производительности заметен именно в этой зоне.
Общих ориентиров у рынка пока нет, и внутри одной команды одни сотрудники успевают в разы больше других. Причины у этого разные: у кого-то лучше получается ставить задачи модели и проверять результат, а кому-то просто достались задачи, которые хорошо распараллеливаются. Осваивают новые инструменты все с разной скоростью, и это нормальная ситуация для любого перехода.
Требовать одинаковой отдачи от разных людей в такой ситуации нельзя, поэтому руководителю приходится ориентироваться на среднюю производительность по команде и определять новые нормы эффективной работы. Пока непонятно, по каким меркам оценивать сотрудника через полгода, особенно если за это время условия изменятся сильнее, чем за предыдущие шесть месяцев. Выше всего сейчас ценится умение учиться быстрее, чем меняются требования.
Что делать разработчику
Переход в новую роль, по мнению Сагалаковой, складывается из трех решений, и ни одно из них не связано с выбором инструмента. Инструменты осваиваются быстро, курсов по внедрению ИИ в рабочие процессы на рынке слишком много, а базовым навыкам работы с моделью можно научиться за вечер у самой модели.
Сложность лежит в несколько другой плоскости, считает эксперт.
- Начать с цели. Нужно понимать, что именно ты создаешь, кому это нужно и как связано с деньгами компании. Разбираться в предметной области продукта, над которым работаешь, стало таким же профессиональным требованием, каким было раньше знание языка программирования.
- Встроить обучение в работу. Технические навыки устаревают быстрее, чем раньше, и ценность сместилась со знания наизусть на скорость освоения нового. Учеба перестала быть нагрузкой поверх основных задач и стала их частью, а компании, которые вкладываются в системное обучение сотрудников, получают более эффективную команду.
- Принять, что правила меняются каждый месяц. Специалист, который остается только разработчиком и не берется за продуктовую часть, продолжает работать в прежнем режиме, а его доход по мере изменения рынка постепенно отстает от вилок тех, кто закрывает полный цикл.
Какой может быть разработка ПО через несколько лет
"Нас может ожидать больше интересных продуктов, созданных одиночками, тогда такие одиночки и станут будущей элитой ИТ. Однако обязательным условием успешного и неординарного продукта будет являться технический лидер, который использует ИИ для самообучения и развития, а не для того, чтобы "отойти от дел" и все передоверить роботам, - считает Сурков. - Важен уровень контроля за новой технологией и степень его концентрации в руках крупных игроков. Можно представить сценарий, когда производители наиболее распространенных моделей и ассистентов опосредованно монополизируют рынок разработки, будут получать регулярные "лицензионные" платежи за поддержание на плаву всего разработанного с помощью их инструментов. Это возможно, если разработчики массово откажутся от глубокого понимания используемых технологий в пользу быстрой сборки из готовых "микро" компонентов, предоставляемых ИИ-ассистентами".