ИИ-ассистент повысил производительность 5 172 сотрудников поддержки в среднем на 15%, причём сильнее всего выиграли менее опытные специалисты. Но из этого ещё не следует, что сеньоры стали не нужны: проблема может быть в том, как устроен найм IT-специалистов. По данным Habr / Карьера, многие процессы отбора проверяют именно те навыки, где джун с LLM уже похож на опытного инженера.
Эксперимент с 453 специалистами, выполнявшими профессиональные письменные задачи, показал похожую картину: время работы сократилось на 40%, качество выросло на 18%, а разрыв между участниками уменьшился. Модели хорошо подтягивают результат на знакомых, типовых задачах — написать SQL-запрос, собрать черновик документа, предложить фрагмент кода или структуру дашборда. Для бизнеса это выглядит как повод платить меньше за опыт. Для команд — как потенциально дорогая ошибка классификации.
Ключевое различие между новичком и экспертом не сводится к скорости набора кода или объёму терминов в резюме. Исследования когнитивной психологии связывают экспертизу с накопленными в долговременной памяти схемами: специалист быстро узнаёт тип задачи, видит скрытые зависимости и понимает, с чего начинать. Новичок чаще собирает решение по частям, а LLM помогает ему сделать этот процесс убедительно быстрым. Но она не добавляет человеку способность надёжно проверить собственный ответ.
Именно здесь возникает неприятный для рынка эффект. Модель может предложить рабочий на вид патч, запрос или архитектурную схему, но не предупреждает, что в исходных данных пропущено важное ограничение, нагрузочный сценарий нереалистичен или решение сломает соседний сервис. Эксперт ценен не только тем, что делает работу руками: он замечает, когда работа вообще поставлена неверно. Если роль ограничена повторяемыми задачами в пределах возможностей модели, опыт действительно может стоить дешевле. Однако большая часть инженерных ролей не заканчивается на генерации первого правдоподобного ответа.
Где собеседование теряет экспертизу
Типовой путь кандидата часто начинается с вакансии, составленной по стеку, числу лет опыта и модным ключевым словам. Затем ATS сопоставляет эти слова с текстом резюме. На этом уровне сильный инженер и человек, умеющий адаптировать резюме с помощью ИИ, выглядят почти одинаково. Описание роли, составленное без разбора реальных рабочих задач, повторяет классическую ошибку новичка: оценивать проблему по внешним признакам, а не по её структуре.
На скрининге ситуация редко улучшается. Рекрутер без предметной экспертизы может оценить мотивацию, ожидания и коммуникацию, но ему трудно отличить глубокий технический разбор от гладкого пересказа. Неструктурированные интервью особенно опасны: участники быстро формируют уверенное впечатление о кандидате, даже когда ответы слабо говорят о будущей результативности. Формат STAR способен быть полезным, если интервьюер использует заранее заданные шкалы оценки; в упомянутом метаанализе его валидность достигала 0,63. Без шкал разговор легко превращается в конкурс уверенных историй.
Технические интервью тоже не гарантируют точности. Алгоритмическая задача, live coding или стандартный system design проверяют ограниченный срез навыков и зависят от тревоги кандидата в моменте. Кроме того, это часто именно те типовые задачи, где LLM наиболее полезна. Даже если использование модели на интервью запрещено, рынок уже столкнулся с тем, что готовиться к таким форматам можно с её помощью, а удалённый контроль не всегда работает. В результате найм IT-специалистов измеряет умение пройти знакомый ритуал, а не способность распознать нестандартную проблему и проверить решение.
Что менять компаниям
Практичный старт — анализировать работу до публикации вакансии. Эксперт по роли может описать пять—десять реальных задач, указать типичные сбои, цену ошибки и границу, за которой ответ модели нужно проверять особенно тщательно. Тогда команда ищет не абстрактные «пять лет Python», а человека, который умеет разбираться с конкретными классами проблем. На интервью полезнее давать материалы, похожие на рабочие: неполное ТЗ, противоречивые метрики, фрагмент кода с неочевидным риском, проектное решение с отсутствующим ограничением. Важен не только финальный ответ, но и вопросы кандидата, способ проверки и причины, по которым он отвергает правдоподобный вариант.
Это не аргумент за возвращение многочасовых экзаменов и ловушек на доске. Хорошо спроектированный отбор может быть короче: эксперт быстрее замечает первый содержательный шаг в рассуждении кандидата, чем команда успевает провести несколько раундов разговоров о сильных сторонах. В условиях, когда генеративные инструменты становятся обычной частью работы, разумнее разрешать их там, где ими будут пользоваться после выхода в команду, и оценивать качество постановки задачи, верификации и доработки результата.
Главный риск для отрасли не в том, что ИИ помогает новичкам, а в том, что найм IT-специалистов начинает вознаграждать только умение работать в узкой зоне типовых задач. Эксперты не появляются сами по себе: им нужна практика на сложных случаях, включая ошибки автоматизации. Компании, которые научатся отбирать людей по способности находить границы применимости модели, получат не просто более точный найм, а команду, способную безопасно использовать ИИ, когда шаблонный ответ перестаёт быть ответом.
