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

Мы в Codenrock делаем инструменты для оценки и развития сотрудников и по работе много разговариваем с HR-директорами. Этот вопрос в разных формулировках звучит все чаще. Аналитики Gartner отмечают, что финансовые директора уже оценивают, можно ли за счет ИИ сократить численность HR. В Shopify его записали в правила: прежде чем просить людей и бюджет, команда должна показать, почему задачу нельзя решить с помощью ИИ.

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

Оценка, когда ИИ есть у обеих сторон

Рекрутер открывает вакансию в понедельник, к среде на нее триста откликов. Сопроводительные письма написаны одинаково гладко, резюме повторяют текст вакансии почти слово в слово. Раньше аккуратный отклик что-то говорил о человеке. Теперь он говорит о том, что у человека есть нейросеть.

Это видно и по большим числам. На LinkedIn, по данным The New York Times, подается около 11 000 откликов в минуту, на 45% больше, чем годом раньше.

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

Компании пробуют два выхода. У каждого своя цена.

Первый выход: вернуть очную встречу. Так поступили Google и Cisco, а агентство по подбору ИТ-специалистов рассказало The Wall Street Journal, что очных собеседований просит уже каждый третий его клиент. Годом раньше таких было около 5%. Способ надежный. Но для растущей компании он дорогой: людей приходится искать в других городах, руководители тратят на встречи часы. И проверяется на такой встрече в основном то, что человек знает без подсказки. На работе подсказка у него будет каждый день.

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

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

Есть третья сторона, о которой легко забыть. Это сами кандидаты. Разработчик системы для найма Greenhouse в мае 2026 года опубликовал опрос соискателей. В его американской части (1 200 человек) 63% уже проходили собеседование с ИИ, а 38% из-за такого собеседования бросили процесс найма. 70% никто заранее не предупредил, что оценивать будет машина.

В обсуждении на Reddit, которое пересказала Business Today, один из участников сформулировал претензию коротко: лицемерно, что компании используют ИИ на интервью, а кандидатам это запрещают. Автор той ветки, к слову, уже работал и новое место выбирал спокойно. Логично, что первыми уходят те, кому есть из чего выбирать.

На месте HR-директора мы бы начали с трех вещей:

• Пересмотреть задания. Оставить те, по которым видно понимание: человек объясняет свое решение и находит ошибку в чужом.
• Написать для кандидата правила про ИИ: на каких этапах им можно пользоваться и на каких нельзя.
• Сказать кандидату, где ИИ использует сама компания и на каком шаге решение принимает человек.

Потенциал, когда опыта нет ни у кого

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

О найме по навыкам вместо формальных признаков говорят давно, но приживается он плохо. Гарвардская школа бизнеса и Burning Glass Institute проверили, что изменилось после того, как крупные работодатели начали убирать из вакансий требование диплома. Реальный наем изменился меньше чем в одном случае из 700. Около 45% компаний поменяли только текст вакансии.

Наше объяснение такое. Строчка в резюме работает как страховка для того, кто нанимает. Если не справился человек с десятью годами опыта, виноват человек. Если не справился человек без опыта, виноват тот, кто его взял. Пока у руководителя нет другой страховки, он будет возвращаться к стажу и диплому, что бы ни было написано в вакансии.

Отсюда задача HR-директора: дать руководителю другое основание для решения. Мы видим три рабочих варианта.

Задание, похожее на настоящую работу. Canva вместо классической алгоритмической задачи просит спроектировать систему управления взлетами и посадками в загруженном аэропорту и смотрит, как кандидат принимает решения. Готового ответа у такой задачи нет, поэтому виден ход мысли.

Обучение внутри оценки. Человеку дают материал, которого он заведомо не знает, и через час проверяют, как он его применил. Так проверяется скорость, с которой он осваивает новое. Для задач, где опыта нет ни у кого, это, на наш взгляд, самое близкое к прогнозу, что можно получить за один день.

Свои сотрудники. О них компания знает больше, чем о любом внешнем кандидате: результаты оценок, отзывы руководителей, то, как человек уже осваивал новое. Здесь мы регулярно слышим одну и ту же фразу: «Все ведем в Excel». Пока оценки лежат в файлах у разных людей, на вопрос «кого из своих можно перевести на новую задачу» отвечают по памяти. Когда данные собраны в одном месте, на него отвечают по ним.

Команда прежнего размера, компания больше

Теперь к вопросу финансового директора. Прогнозы на этот счет резкие. Gartner ожидает, что к 2030 году половину нынешних задач HR будут выполнять ИИ и ИИ-агенты. Josh Bersin Company считает, что HR-службы за это время станут меньше на 30–50%. Это расчетные модели, и читать их стоит как направление.

Измеренный пример тоже есть. В IBM внутренний агент AskHR закрывает без участия человека 94% типовых вопросов сотрудников. Операционные расходы HR за четыре года снизились на 40%, агенты взяли на себя работу нескольких сотен человек. Глава компании говорил, что общая численность IBM выросла: высвободившиеся деньги пошли в другие направления, наем сместился к разработке и продажам.

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

Здесь есть подвох, и его хорошо показала Klarna. В 2024 году компания сообщала, что ИИ-помощник в поддержке клиентов делает работу 700 операторов. Через год ее глава признал, что ставка на экономию зашла слишком далеко и качество упало. Компания снова стала нанимать людей. В HR цена такой ошибки, на наш взгляд, выше. Недовольный клиент уходит, а недовольный сотрудник остается и рассказывает об этом коллегам.

И еще одно, про слова. В июле 2024 года разработчик HR-систем Lattice объявил, что ИИ-агенты получат в его продукте карточки сотрудников и место в оргструктуре. Через три дня, после волны критики в соцсетях, компания отказалась от этой идеи. Мы вспоминаем эту историю, когда слышим от HR-директоров: «ИИ должен помогать, а не заменять». За фразой стоит понятный расчет. Люди в HR-команде читают те же новости о сокращениях. От того, как руководитель назовет происходящее, зависит, станут они помогать или будут тихо тормозить.

Один человек ведет цикл, который раньше вел отдел

Теперь о том, куда это, по нашему мнению, придет.

Сегодня HR-система устроена как набор разделов: подбор, адаптация, оценка, обучение. В каждом свои настройки, и в команде часто есть один человек, который знает, где что нажимать. Когда он в отпуске, запуск оценки ждет его возвращения.

Следующий шаг уже виден по отдельным продуктам. В России hh.ru в ноябре 2025 года запустил «ИИ-помощника», которому можно поручить текст вакансии, приглашения, разбор откликов и первый разговор с кандидатом. У LinkedIn есть похожий агент для рекрутеров. Пока это части одного процесса, подбора. Мы думаем, что через два-три года так будет устроен весь цикл работы с людьми: специалист пишет задачу обычными словами, система раскладывает ее на шаги и выполняет.

Как это может выглядеть:

• «Нужны два менеджера по продажам к ноябрю». Система собирает профиль роли и задание под него, рассылает кандидатам, проверяет ответы и показывает короткий список.
• «В понедельник выходит новый сотрудник». Заводит профиль, назначает стартовую оценку, собирает план на первые недели.
• «Проведи оценку отдела продаж». Готовит вопросы по компетенциям, запускает цикл, напоминает тем, кто не ответил, собирает отчет и черновики планов развития.
• «Кого из команды можно повышать?» Сводит результаты оценок и показывает, кто к чему готов и чего кому не хватает.

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

Для HR-директора это означает, что один человек сможет вести цикл, который раньше вел отдел. Мы понимаем, как это звучит для руководителя, у которого в команде пять человек. Но в растущих компаниях, с которыми мы разговариваем, выбор обычно выглядит иначе. Штат HR не увеличивают вместе с компанией. Тогда либо часть работы откладывается (оценку переносят на следующий год, на адаптацию не хватает рук), либо ее ведет система под присмотром человека.

Что остается у человека:

• Решения о людях. Взять, отказать, повысить, расстаться.
• Правила, по которым работает система. Кого считать сильным кандидатом, какие компетенции важны для роли, какие вопросы допустимы. Это методика. Когда HR-директора говорят нам «важно сохранить контроль и методику», они говорят об этом.
• Исключения и конфликты. Все, что не укладывается в правило.
• Проверка. «Кто проверит ИИ, когда сотрудников тысяча?» Тот же человек, только проверка устроена иначе. Он смотрит выборку и все случаи, где система сомневается или где решение затрагивает конкретного человека.

Об ограничениях стоит знать заранее.

Агент ошибается. Первые месяцы его работу проверяют плотно, и это время нужно закладывать в план.

Агенту нужны данные в одном месте. Если половина сведений о людях лежит в таблицах, он будет работать с половиной.

Есть закон. Статья 16 закона о персональных данных запрещает решения, которые затрагивают права человека и приняты исключительно автоматически. Исключений два: письменное согласие человека или прямое указание федерального закона. Отказ кандидату без участия человека на такое решение очень похож. По статье 64 Трудового кодекса причину отказа по требованию кандидата нужно сообщить письменно за семь рабочих дней, и шаблонное письмо от системы эту обязанность не закрывает. Рабочее правило простое: агент готовит, решает человек. Свою схему отбора стоит показать юристу.

Насколько это близко. В опросе Talantix и hh.ru осенью 2025 года использовать ИИ в подборе собирались 46% российских работодателей, среди крупных 61%. Намерение есть почти у половины. Целиком такой способ работы, по нашим наблюдениям, пока мало у кого собран, и время разобраться спокойно еще есть.

С чего начать

Пять шагов для компании от ста до тысячи человек, где HR состоит из нескольких специалистов.

1. Расписать один процесс по шагам. Например, адаптацию. В каждом шаге отметить, где принимается решение, а где идет пересылка, напоминание и сверка. Вторая группа и есть работа для агента.
2. Собрать данные о людях в одном месте. От этого шага зависят все остальные, и он полезен сам по себе: история перестает зависеть от одного сотрудника.
3. Пересобрать оценку. Задания, близкие к работе. Правила про ИИ для кандидата. Понятное предупреждение о том, где ИИ использует компания.
4. Записать, какие решения остаются за людьми, и рассказать об этом своей команде. Лучше сделать это до запуска, чтобы команда узнала о планах от вас.
5. Запустить один цикл и мерить. Часы команды, сроки, число ошибок агента, оценку от самих сотрудников. Через квартал будет видно, что переносить дальше.

По этой схеме мы строим Vibe: оценка при найме, компетенции, обратная связь 360 и планы развития лежат в одной системе, а запуск этих циклов из чата сейчас в разработке.

Что ответить финансовому директору

Вернемся на защиту бюджета. Нам кажется честным такой ответ: «Да, часть работы закроет ИИ, и вот какая». Дальше идет список. Что отдаем агентам в этом году. Что остается людям и почему. Как через квартал проверим, что получилось. После такого ответа обсуждают устройство работы, и ведет этот разговор HR-директор.

Кто-то в компании все равно будет решать, что агентам можно поручать про людей. Глава Nvidia Дженсен Хуанг считает, что отделом кадров для ИИ-агентов станет ИТ. Moderna объединила HR и ИТ в одну службу и отдала ее своему HR-директору. Нам ближе второй вариант. Правила для агентов собираются из того, что HR и так ведет: профили ролей, модели компетенций, критерии оценки, порядок проверки качества. ИТ может подключить агента и выдать ему доступы. Что считать хорошей работой с людьми, в компании определяет HR.

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

HR в вашей компании уже есть, и это вы

По данным «Авито Работы», в 58% компаний со штатом до 15 человек поиском и наймом занимаются руководитель или главы отделов. В компаниях на 16–100 человек в половине случаев наем лежит на руководителях компании и отделов либо на других сотрудниках. Это данные 2024 года. Директор по маркетингу сервиса Никита Макаров тогда говорил, что руководителям малого и среднего бизнеса зачастую приходится самим быть HR-специалистами и организовывать наем и адаптацию.

Компания платит за это трижды.

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

Второй раз скоростью. По оценке той же «Авито Работы», малый и средний бизнес закрывает вакансию за 3–5 недель, крупный за 1–2. Месяц без менеджера по продажам означает месяц без его продаж. Ошибку найма сервис оценивает в два-три оклада.

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

И все это дорожает. В исследовании «Экопси» «HR-метр 2026», о котором со ссылкой на «Ведомости» писала «Точка», стоимость привлечения одного сотрудника за год почти удвоилась. Доля компаний, которые собираются урезать расходы на HR, выросла с 7% до 33%. Нанимать стало дороже, а тратить на это хотят меньше.

Три привычных выхода и цена каждого

Делать самому. На бумаге бесплатно. По факту оплачивается вашим вниманием, а качество зависит от того, сколько сил осталось к вечеру. До тридцати-сорока человек это терпимо, дальше руководитель перестает успевать. В выборке из 973 британских стартапов первого специалиста по персоналу нанимали в среднем на 40–50 сотрудниках.

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

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

В разговорах с небольшими компаниями мы часто слышим одну фразу: «Этим некому заниматься». Она точно описывает положение дел. Работа есть, владельца у нее нет.

Четвертый выход: функция целиком как услуга

С бухгалтерией руководители небольших компаний эту задачу уже решили. Мало кто строит отдел. Берут сервис, в котором есть программа и есть бухгалтер, который в ней работает. NeoAnalytics оценивает рост рынка бухгалтерского аутсорсинга в 38% за 2024 год и в 10,4% за 2025-й. Там же описано, куда он движется: от модели «передать бухгалтерию на аутсорсинг» к модели «купить цифровую финансовую функцию как сервис».

С людьми можно так же. Вы ставите задачу, сервис ее ведет, результат и история остаются у вас.

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

В США внешняя кадровая служба для небольших компаний давно обычное дело. По данным отраслевой ассоциации NAPEO на октябрь 2025 года, с такими организациями работают больше 230 000 компаний. Это около 15% всех работодателей со штатом от 10 до 499 человек. В основном они берут на себя административную часть: зарплату, льготы, соответствие трудовому законодательству. Есть и сервисы следующего шага. Bambee продает небольшим компаниям закрепленного HR-менеджера по подписке вместе с программой.

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

Почему это становится доступно небольшим компаниям

Услуга с живым специалистом всегда упиралась в его часы. Внешний HR мог вести всего несколько компаний, и цена получалась такой, что ее тянули средние и крупные.

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

У специалиста остается то, что требует суждения. Уточнить у вас задачу, посмотреть короткий список, поговорить с финалистами, заметить странное. Один человек с такой системой ведет заметно больше компаний, и услуга становится посильной для штата в пятьдесят человек.

Как это может выглядеть для руководителя

Дальше описание того, как такая услуга может работать. Вы пишете задачу словами, как написали бы толковому помощнику.

• «Нужны два менеджера по продажам к ноябрю». Вам задают несколько уточняющих вопросов о роли. Дальше сервис сам готовит описание и практическое задание, рассылает его откликнувшимся и проверяет ответы. Вы получаете короткий список с результатами и пояснением по каждому и проводите финальные встречи.
• «В понедельник выходит новый сотрудник». Он получает план на первые недели и стартовую оценку, его руководитель получает напоминания о контрольных точках. Через месяц вам приходит короткая справка: что человек освоил и где ему нужна помощь.
• «Проведи оценку отдела продаж перед пересмотром зарплат». Сервис собирает вопросы под ваши роли, запускает оценку, напоминает тем, кто не ответил, и приносит сводку по каждому.
• «Кого из команды можно ставить руководителем нового направления?» Ответ собирается из накопленных оценок и отзывов.

Здесь часто спрашивают, чем это лучше обычного чата с ИИ, в котором можно попросить составить вакансию или вопросы для собеседования. Чат отдает текст. Разослать, напомнить, собрать и сохранить после него должен кто-то из ваших людей, то есть снова вы. Услуга доводит дело до результата, и история остается в системе, которая принадлежит компании.

Вариантов исполнения два. В первом задачи пишет кто-то из ваших сотрудников, и система ведет их сама. Во втором за компанией закреплен менеджер сервиса, как бухгалтер в бухгалтерском сервисе. Для компании, где «этим некому заниматься», естественнее второй.

Сразу оговорка о зрелости рынка. Подбор по подписке в России уже продают. Услугу, которая закрывает весь цикл от найма до оценки и развития и которой можно управлять из одного окна, мы целиком пока не встречали. Рынок идет к ней с двух сторон: агентства добавляют технологии, разработчики систем добавляют сервис. Мы в Codenrock идем со стороны продукта. В Vibe оценка при найме, компетенции, обратная связь 360 и планы развития уже лежат в одной системе, а управление ими из чата сейчас в разработке.

Что остается у вас

Три вещи услуга с руководителя не снимает.

Решения. Кого взять, с кем расстаться, кого повысить. Сервис готовит материалы и варианты, решаете вы. Того же требует закон. Статья 16 закона о персональных данных запрещает решения, которые затрагивают права человека и приняты исключительно автоматически, без его письменного согласия.

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

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

Есть и честное возражение: внешний человек не знает нашу команду. В первый месяц это правда. Дальше знание о команде накапливается в системе и остается в ней, кто бы ни вел работу.

Если в компании уже есть HR

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

Руководителю полезно задать своему HR один вопрос: какая часть недели уходит на напоминания, таблицы и пересылку. Ответ покажет, сколько времени можно вернуть на работу с людьми.

Как понять, что пора

Несколько признаков. Если совпадают два или три, тему стоит поднять:

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

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

Вернемся к вечеру четверга

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

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

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

Представим собирательную сцену. Сорок минут обсуждения на тему «тянет ли он на сеньора». В комнате пять человек, у каждого своё определение сеньора, но вслух его никто не произносит. Решает тот, кто говорит увереннее. Через месяц инженер получает в другой компании оффер на позицию мидла — не разучившись за месяц ничему.

Напрашивается решение: нужна объективная система грейдов. Появляется матрица на сто двадцать пунктов, баллы, пороги. Но если ожидания так и не согласовали, следующий спор будет уже о том, ставить человеку 3,5 или 4 по «системному мышлению».

Моя позиция: измерения могут быть входом в решение о грейде. Но выбор критериев, их веса и границы уровней остаются договорённостью компании. Формула может последовательно применять эти правила; она не делает их единственно правильными.

«Договорённость» не значит «произвол». Хорошее решение опирается на проверяемые наблюдения и позволяет понять, как из них получили вывод. Плохое прячет спорные предпосылки за итоговой цифрой.

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

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

Что именно мы называем грейдом

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

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

Поэтому смена компании может изменить присвоенный уровень при тех же навыках. Это говорит о различиях требований и доступных свидетельств, а не обязательно об ошибке одной из сторон. Грейд из резюме полезен как отправная точка; дальше всё равно нужно выяснять, что человек делал и за что отвечал.

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

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

Измерение: наблюдаемое поведение вместо прилагательных

«Глубокое понимание баз данных» оставляет слишком много пространства для толкования. Полезнее описать, что человек должен уметь показать:

• читает план запроса и объясняет, почему индекс не применился;
• различает гипотезы о блокировке и неудачном плане выполнения, предлагает способ проверки;
• перед изменением оценивает риски и готовит способ проверить результат и откатиться.

Даже здесь мало отметить «делает / не делает». Нужно учитывать сложность задачи, помощь коллег и качество объяснения. Сам факт, что человек открыл план запроса, ещё не подтверждает компетенцию. Но теперь есть предмет разговора: конкретная работа и основания для вывода.

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

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

Учебный пример для одной роли. Это основа обсуждения, а не универсальный чек-лист сеньора.

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

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

С баллами нужна такая же осторожность. Без оценки надёжности шкалы мы не знаем, значима ли разница между 3,6 и 3,8. Десятичный знак сам по себе точности не добавляет.

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

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

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

Откуда брать наблюдения

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

В нашей системе названия 180/270/360 обозначают наборы участников: сотрудник и руководитель; они же плюс коллеги либо подчинённые; все перечисленные группы. Для процесса важнее явно назвать отвечающих, чем опираться только на привычный ярлык.

Анкету полезно собирать из индикаторов текущего или следующего уровня. Вопрос «оцените лидерство от 1 до 5» вернёт нас к спору о прилагательных. Вопрос о том, как человек выявлял зависимости и согласовывал действия, позволяет попросить пример. Нужен и ответ «не наблюдал»: отсутствие свидетельства нельзя автоматически превращать в низкую оценку.

У Ирины стоит спросить коллег из обоих проектов. Если выбрать только участников удачного, картина будет неполной. Состав респондентов должен быть понятен сотруднику и руководителю; приглашать стоит тех, кто действительно видел нужную работу.

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

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

В интерфейсе выбирают процесс оценки. Состав участников и правила сбора обратной связи нужно определить до запуска цикла.

Суждение: как перейти от наблюдений к уровню

Допустим, наблюдения собраны. Теперь возникает соблазн: «средний балл 4,5 и выше — сеньор».

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

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

Мы разделяем три значения:

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

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

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

Вернёмся к Ирине. Расчётная рекомендация может указывать на следующий уровень, а руководитель — сомневаться из-за проекта со смежниками. Полезный вопрос: что именно ожидалось от неё в этом проекте? Были ли у неё полномочия, доступ к нужным людям и информация о зависимости?

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

Решение: что именно компания фиксирует

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

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

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

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

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

В списке команды уровень показан рядом с должностью. Сам экран не показывает основания назначения: для них нужна отдельная история решений.

Пример правила: действующее назначение имеет приоритет; справочное название используется с пометкой об источнике; неоднозначность требует уточнения.

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

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

Что с этим делать в понедельник

1. Разделите оценку, обсуждение и назначение. У каждого этапа должны быть понятный результат и ответственный. Это не обязательно три отдельные встречи.
2. Опишите требования через работу. Для каждого критерия укажите, какие примеры помогут его оценить и как учитывать помощь коллег.
3. Оставьте посильную матрицу. Число пунктов должно позволять разбирать свидетельства, а не только проставлять баллы.
4. Собирайте наблюдения независимо. Включайте людей из разных релевантных проектов и разрешайте ответ «не наблюдал».
5. Разбирайте расхождения. Проверяйте формулировки, условия работы и доступные оценивающим сведения.
6. Сохраняйте версии и основания. Требования, расчётная рекомендация и объяснение итогового решения должны оставаться доступны для пересмотра.
7. Разведите компетенции и бюджет. Если повышение задерживается, называйте действительную причину. Договоритесь, кто и когда вернётся к решению.
8. Обеспечьте возможность роста. Следующий уровень требует подходящих задач, полномочий и понятной процедуры оспаривания ошибок оценки.

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

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

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

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

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

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

Что такое адаптивное тестирование

Идея не новая. Классический подход — CAT (Computerized Adaptive Testing) на базе IRT (Item Response Theory, теория ответов на задания) — используется, например, в американском экзамене для медсестёр NCLEX с 1994 года и в сертификациях ISC2. Схема такая: у каждого вопроса есть статистически откалиброванные параметры (сложность, способность различать сильных и слабых, вероятность угадывания), способность кандидата описывается одним числом, а следующий вопрос выбирается по математическому критерию — какой вопрос даст максимум информации об уровне именно этого человека. Тест останавливается, когда погрешность оценки становится достаточно малой. Результат: сокращение теста примерно вдвое при той же точности.

У классики есть цена. Чтобы откалибровать один вопрос, нужно 200–500 реальных ответов на него — то есть новые вопросы нельзя вводить без длительного пилотирования. Банк должен быть большим: от 300+ вопросов для полноценного CAT. Оценка одномерна — если компетенций несколько, модель заметно усложняется. И главное для HR: решение «почему задан именно этот вопрос» объясняется только формулой.

В Codenrock Vibe используется другой подход: решение о следующем вопросе принимает языковая модель (LLM), которая видит полный контекст сессии — покрытие каждой компетенции, сложность уже пройденных вопросов, последние ответы, выбранную стратегию и глубину теста. Формула подхода из нашего практического гайда:

Адаптивное тестирование = банк проверенных вопросов + выбранная стратегия + анализ ответов кандидата + контролируемый AI-выбор следующего вопроса.

Ключевое слово — «контролируемый». LLM работает в жёстких рамках, которые обеспечивает обычный детерминированный код: выбор только из заранее подготовленного банка, никаких сочинённых на ходу вопросов, никаких повторов, обязательные минимум и максимум длины теста. AI не принимает кадровых решений — он только строит маршрут по банку.

Чем это отличается от классического CAT на практике:

• Работает «с нуля». Не нужна статистическая калибровка на сотнях ответов — сложность задаётся при создании вопроса и проверяется на этапе генерации. Банк можно собрать и запустить за дни, а не за месяцы пилотирования.
• Многомерность. Система оценивает не один общий балл, а профиль по каждой компетенции — и решает сразу, какую компетенцию проверить следующей и вопросом какой сложности.
• Объяснимость. По каждому шагу сохраняется словесное обоснование: почему выбран этот вопрос, почему тест продолжен или завершён. HR и технический эксперт видят логику маршрута, а не только итоговую цифру.

Честная оговорка: на больших, годами откалиброванных банках классический CAT статистически строже — у него есть математические гарантии сходимости оценки. LLM-подход выигрывает там, где банк новый или часто меняется, компетенций много, а интерпретируемость маршрута важна для людей, принимающих решение.

Как работает цикл: от ответа к ответу

После каждого ответа кандидата происходит следующее.

1. Оценка ответа. Вопросы с выбором вариантов проверяются автоматически. Открытые ответы и код оценивает AI: фиксируется вердикт «верно/неверно» и балл от 0 до 100.

2. Обновление картины. Пересчитывается статистика по всем компетенциям: сколько вопросов задано по каждой, какая доля правильных, какая средняя сложность. Ответы, которые ещё не успели пройти оценку, честно исключаются из статистики целиком — они не считаются ни правильными, ни неправильными.

3. Жёсткие проверки до всякого AI. Если достигнут максимум вопросов — тест завершается, LLM даже не вызывается. Если в банке не осталось незаданных вопросов — тоже.

4. Решение LLM. Модель получает: выбранную стратегию и её текущую фазу, прогресс, сводку по компетенциям (включая предупреждение о перекосе покрытия), последние ответы кандидата и весь банк с пометками «задан/не задан». Она возвращает решение — продолжить или остановиться, — выбранный вопрос и словесное обоснование.

5. Проверка решения кодом. Здесь начинаются гарантии:

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

6. Логирование. По каждому вопросу фиксируется: фаза теста, состояние кандидата до вопроса, причина выбора именно этого вопроса, причина продолжения. Это основа «прозрачного» отчёта — маршрут можно разобрать постфактум.

Движок сам прекращает выдачу вопросов тремя путями: достигнут максимум вопросов (гарантируется кодом — LLM не может продлить тест сверх лимита); исчерпан банк; либо LLM решила остановиться — и это решение принимается только после минимума. Кроме того, как и в любом тесте, действует общий лимит времени, а после набора минимума кандидат может завершить тест и сам. Ориентиры для остановки со стороны модели: достигнуто целевое число вопросов и по каждой компетенции есть хотя бы 2 вопроса; последние ответы не выявляют новых слабых мест; уровень стабильно подтверждён.

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

Четыре стратегии адаптации

Стратегия отвечает на вопрос «что оптимизирует система»: баланс, слабые зоны, скорость или точность определения уровня. Каждая проходит три фазы; границы фаз считаются как доля от целевого числа вопросов.

Сбалансированная (стратегия по умолчанию)

Цель — ровный профиль по всем компетенциям без перекосов.

• Первичное покрытие (0–50% теста): минимум 2 вопроса на каждую компетенцию.
• Адаптивное заполнение (50–85%): добираются компетенции с меньшим числом вопросов, сложность подстраивается под ответы.
• Финальное выравнивание (85%+): покрытие всех компетенций выравнивается, чтобы подтвердить итоговую оценку.

Когда выбирать: первичный отбор, сравнение нескольких кандидатов на одну роль, любой типовой найм, где нужен полный профиль. Если сомневаетесь — начинайте с неё.

Углубленная проверка

Цель — достоверно локализовать слабые места.

• Сканирование (0–35%): быстрая оценка всех компетенций, поиск проблемных зон.
• Погружение (35–85%): интенсивная проверка 2–3 самых слабых компетенций — больше вопросов, вариация сложности; минимальное покрытие остальных сохраняется.
• Верификация (85%+): повторная проверка изначально провальных зон — случайность или закономерность?

Обратите внимание: фаза погружения начинается уже с 35% теста — раньше, чем основная фаза у Сбалансированной (50%) и Быстрой оценки (40%), — и занимает половину теста: стратегия быстро переходит от сканирования к работе со слабыми зонами. Когда выбирать: оценка перед повышением, перевод на другую роль, построение индивидуального плана развития. Здесь нужен не общий балл, а ответ «где именно нужно развитие».

Быстрая оценка

Цель — максимум информации за минимум вопросов.

• Экспресс-скан (0–40%): обычно 1–2 вопроса средней сложности на компетенцию.
• Фокус (40–80%): прицельная проверка только тех зон, где осталась неопределённость; на очевидно сильные зоны вопросы не тратятся.
• Завершение (80%+): финальная верификация ключевых компетенций.

Когда выбирать: массовый скрининг, экспресс-оценка перед интервью. Обычно сочетается с глубиной «Быстрая». Меньшая длительность не означает более лёгкую оценку — просто уровень становится понятен быстрее.

Адаптивная сложность

Цель — точно определить уровень кандидата через управление сложностью.

• Калибровка (0–30%): установка базового уровня со средней сложности.
• Адаптация (30–70%): сложность растёт после уверенных ответов и снижается после ошибок; фокус на пограничных компетенциях.
• Подтверждение (70%+): прицельные вопросы для стабильного подтверждения уровня.

У этой стратегии самая длинная финальная фаза — треть теста уходит на подтверждение, чтобы вывод «это middle» опирался не на пару удачных ответов. Когда выбирать: грейдирование junior/middle/senior, роли с широким ожидаемым разбросом навыков.

Как выбрать: задача → стратегия

Глубина теста и банк вопросов

Стратегия определяет, что оптимизирует система; глубина — сколько данных она должна собрать. Три пресета:

Есть и произвольный режим со своими min/target/max. Семантика: раньше минимума тест завершить нельзя (кнопка «Завершить тест» до минимума просто выдаёт следующий вопрос); целевое число — ориентир для остановки; максимум — жёсткий потолок. Фактическая длина плавает внутри диапазона: если картина ясна, тест закончится ближе к целевому числу, при неопределённости — дотянется к максимуму.

Сколько вопросов должно быть в банке

Это самый частый практический вопрос, и здесь важно понимать поведение системы: при недостаточном банке она не блокирует запуск, а молча укорачивает тест. Если банк меньше максимума пресета, потолок сжимается до размера банка; если банк меньше даже минимума — тест сожмётся до 50–100% от того, что есть. То есть формально «Углубленная» глубина с банком в 40 вопросов запустится — но по факту это будет короткий тест, и заявленной глубины вы не получите.

Отсюда правило номер один: чтобы пресет отработал в полную силу, банк профессии должен быть не меньше максимума пресета — 30 вопросов для Быстрой, 50 для Стандартной, 100 для Углубленной.

Дальше — рекомендации из практики (это уже не жёсткие пороги системы, а гигиена банка):

• Запас в 1,5–2 раза сверх максимума. Адаптивный выбор — это выбор из ещё не заданных вопросов. Если банк равен максимуму впритык, к концу теста «выбор» вырождается в «берём что осталось». Для Стандартной глубины это означает банк ~50–100 вопросов, для Углубленной — ~100–200.
• 5–7 компетенций на профессию. Больше — тест размазывается, на каждую компетенцию не хватает вопросов для уверенного вывода. При 5–7 компетенциях и Стандартной глубине получается ~10–15 вопросов на компетенцию в банке, при Углубленной — ~20–30.
• Равномерность по компетенциям. Все стратегии в первой фазе обходят все компетенции — банку нужен сопоставимый объём в каждой, а не 90% вопросов в одной. Компетенция, важная для роли, но представленная двумя вопросами, — типичная ошибка.

• Покрытие всех уровней сложности. Шкала сложности — от 1 (базовый) до 4 (экспертный), и в каждой компетенции должны физически существовать и лёгкие, и сложные вопросы. Стратегия «Адаптивная сложность» без этого просто не сможет повышать и понижать планку. Важно: перед запуском система это не проверяет — распределение по сложности целиком на совести автора банка.
• Разнообразие типов. Доступны четыре типа: один правильный вариант, несколько правильных вариантов, открытый ответ, задача с кодом. Вопросы с выбором дешевле проверять и быстрее проходить; открытые и код дают глубину. Разумная смесь работает лучше, чем 100% «угадаек».

Пример. Скрининг 500 откликов на Junior Python: стратегия «Быстрая оценка» + глубина «Быстрая» (20–30 вопросов, ~30–45 минут). Банк — минимум 30 вопросов, комфортно 45–60, преимущественно вопросы с выбором вариантов плюс несколько коротких задач с кодом.

Другой пример. Ежегодная оценка команды из 20 инженеров под планы развития: «Углубленная проверка» + глубина «Углубленная» (50–100 вопросов). Банк от 100 вопросов, лучше 150–200, с полным покрытием сложностей 1–4 в каждой компетенции — иначе фаза погружения не сможет варьировать сложность в слабых зонах.

Что система проверяет перед запуском

Перед запуском система подсказывает о проблемах готовности банка:

• Блокер: пустой банк или роль, у которой суммарно меньше 5 вопросов по всем компетенциям.
• Блокер: шаблон оценки без вопросов (для адаптивного шаблона считается весь банк профессии).
• Предупреждение (не блокер): компетенции, у которых 0 вопросов.

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

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

Откуда берутся вопросы

Банк можно собрать тремя путями: написать вопросы вручную через интерфейс, импортировать свои готовые, либо сгенерировать встроенной AI-системой — по описанию компетенций она раскладывает каждую на подтемы и создаёт вопросы нужных типов и сложностей (до 50 вопросов на компетенцию за один запуск).

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

Подробный разбор пайплайна генерации выйдет отдельной статьёй — «Как устроена AI-генерация вопросов в Codenrock Vibe»; ссылку добавим сюда после её публикации.

Чек-лист внедрения

Перед запуском адаптивного теста пройдитесь по списку:

1. Компетенции. 5–7 на профессию, согласованы с техническим экспертом или нанимающим менеджером. Веса и приоритеты зафиксированы.
2. Стратегия. Выбрана по таблице «задача → стратегия». По умолчанию — Сбалансированная.
3. Глубина. Быстрая — скрининг, Стандартная — большинство сценариев, Углубленная — развитие и критичные роли.
4. Объём банка. Не меньше максимума пресета (30 / 50 / 100), с запасом — в 1,5–2 раза больше.
5. Равномерность. У каждой важной компетенции сопоставимое число вопросов; нет компетенций с 0–2 вопросами.
6. Сложность. В каждой компетенции есть вопросы всех уровней от 1 до 4 — система это за вас не проверит.
7. Типы вопросов. Смесь выбора вариантов, открытых ответов и кода — под специфику роли и бюджет времени кандидата.
8. Проверка готовности. Система не показывает блокеров; предупреждения о непокрытых компетенциях разобраны.
9. Пилот. Прогоните тест на 2–3 своих сотрудниках известного уровня и посмотрите отчёты с маршрутами: логика выбора вопросов должна быть объяснима, а итоговые профили — соответствовать вашим ожиданиям об этих людях.
10. Интерпретация. Договоритесь, как используется результат: итоговый отчёт — вход для интервью и решения человека, а не замена им.

Заключение

Адаптивное тестирование — это не «AI вместо HR», а способ тратить вопросы туда, где они дают информацию. Кандидат отвечает на 30–40 вопросов вместо 60–100, получает задачи своего уровня и реже бросает тест; вы получаете профиль по компетенциям и объяснимый маршрут вместо одной цифры. LLM-подход снимает главный барьер классического CAT — необходимость месяцами калибровать банк — и при этом остаётся в жёстких рамках: только подготовленный банк, только в пределах лимитов, с проверкой каждого решения кодом.

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

Разбор пайплайна Codenrock Vibe: планировщик покрытия, факт-чекер, слепой калибратор сложности, симулятор кандидата — и грабли, на которых всё это выросло.

Мы делаем платформу оценки кандидатов и сотрудников. Тестовый вопрос для нас — не контент, а измерительный инструмент: если он кривой, компания наняла не того человека. Проблема в том, что наивная генерация — «вставил компетенцию в ChatGPT, скопировал десять вопросов» — даёт результат, который выглядит прилично и не работает.

Вот типичный вопрос из той эпохи (пример стилизованный, но дефект настоящий):

Как называется паттерн, при котором объект создаётся единственный раз, а все обращения идут к одному общему экземпляру?

A) Singleton B) Factory Method C) Observer D) Builder

Вы только что ответили правильно, даже если никогда не программировали: «единственный раз», «один экземпляр» — Singleton. Это утечка ответа в формулировку: вопрос измеряет не знание паттернов, а умение читать. Таких дефектов у наивной генерации — системный набор, и мы прошли через него сами. Ниже — аудит, который нас отрезвил, и конвейер, который из него вырос: до десятка ролей на один вопрос — причём не все роли нейросетевые, ключевые решения принимает детерминированный код — и два источника знаний: фронтирные модели и документы самой компании-клиента.

Точка отсчёта: аудит, который нас отрезвил

Первая версия была ровно тем, что мы теперь критикуем: один вызов LLM, один промпт, ноль проверок. Потом эксперт вручную разобрал сгенерированный банк из 59 вопросов — и нашёл 12 системных типов брака. 14 из 19 вопросов по Python оказались про одну и ту же подтему (генераторы и ленивая обработка файлов), включая шесть открытых вопросов с одинаковым описанием подряд. Верные варианты были помечены неверными. В коде «с багом» бага не существовало. Тривиальные задачи гордо носили метку «сложно». Запреты из описания компетенции игнорировались. Отклонений — ноль, потому что проверки не существовало.

Отдельного упоминания заслуживает reasoning-режим, на котором всё это работало: генератор запускался с минимальным reasoning-усилием — модель буквально не думала. Одно только включение полноценного reasoning подняло долю прохождения валидации с 52% до 68%.

Главный вывод аудита мы зафиксировали во внутренней документации почти дословно: LLM не может надёжно проверить сама себя, а инструкции в промпте деградируют при масштабной генерации. Каждый из 12 найденных дефектов позже стал машинным кодом проблемы и отдельной проверкой в пайплайне.

Главный принцип: генератор никогда не проверяет сам себя

Ключевое архитектурное решение — adversarial-разделение. Один AI пишет вопрос, независимые reasoning-модели других вендоров его атакуют, а финальное решение «принять / отклонить / переделать» принимает вообще не модель, а детерминированный код. У разных семейств моделей разные слепые зоны, и модель склонна прощать собственные ошибки — поэтому кросс-вендорная проверка зафиксирована в коде как инвариант, а не как пожелание.

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

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

До генерации: чистим вход и планируем покрытие

Препроцессор компетенции. Описание компетенции — свободный текст, и пользователи пишут туда далеко не только суть навыка (самый дорогой инцидент на эту тему — в «Музее граблей» ниже). Показательный случай: почти все вопросы Python-разработчику оказались про телеметрию роботов — в описание компетенции был вшит контекст компании, и генератор исправно тащил его в каждый вопрос.

Теперь описание предварительно разделяется на «что тестируем» (уходит генератору) и «инструкции и запреты» (уходят проверяющему на контроль соблюдения). Заодно это защита от prompt-injection: эвристики ловят и русские, и английские паттерны инъекций.

Планировщик покрытия. Разнообразие не оставляется на волю случая. До генерации компетенция декомпозируется на аспекты в два прохода: сначала генерация аспектов «по граням», затем отдельный LLM-критик разнообразия находит близнецов — один навык разными словами — и заменяет их аспектами из непокрытых граней. Любопытная деталь: от эмбеддингов здесь мы отказались — классические метрики близости на наших данных разделяли соседние аспекты хуже, чем LLM-критик. Единица разнообразия — пара «аспект × тип вопроса»: один аспект другим типом — это глубина, а не дубль. Если различимых граней меньше плана, система возвращает меньше, а не выдумывает натянутые темы. И отдельный дешёвый вызов решает, уместен ли вообще код: для «коммуникации» и «лидерства» кодовые слоты автоматически конвертируются в открытые вопросы — кодовых задач про переговоры не рождается.

Генерация: не «напиши вопрос», а техзадание с обвесом

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

• «вопрос-ЗАДАЧА, а не вопрос-ОПРЕДЕЛЕНИЕ»: если на вопрос можно ответить, перечитав его и не зная предмета, — это утечка;
• психометрическая деталь: дистрактор не должен повторять редкое слово из формулировки — это статистическая подсказка;
• компетенция-зависимые правила: для «Тестирования» кодовые задания обязаны требовать написания тестов, для «ООП» — классы, плюс «антименеджерский фильтр» для технических компетенций — не спрашивать про спринты там, где надо писать код;
• детерминизм кода: запрет timing-зависимого asyncio и random без seed.

Параллельные генераторы «видят собратьев»: назначения перемешаны round-robin по компетенциям, и каждому подкладываются краткие описания уже созданных в батче вопросов — иначе «слепой залп» рожает близнецов. У блоков правил есть бюджет по символам, контролируемый тестами, — промпт не разбухает. Всего в системе около 58 runtime-промптов, каталогизированных с метаданными и уровнем риска редактирования; JSON-контракт ответа не может изменить даже владелец проекта.

Снаружи вся эта машинерия выглядит как один аккуратный диалог:

ОТК: панель валидаторов

Нулевой этаж — структурный валидатор, ноль LLM-вызовов. Детерминированный ранний гейт: полнота вариантов и правильного ответа, длина вариантов, «вопрос спрятан в комментариях кода», «консольный вывод склеен в одну строку», блок-лист нерелевантной доменной терминологии — тот самый кейс с телеметрией роботов из раздела про препроцессор, закреплённый теперь ещё и детерминированной проверкой. Сработал — дорогие агенты даже не запускаются.

Факт-чекер — до шести независимых осей проверки; набор зависит от типа вопроса: от трассировки кода — существует ли заявленный баг вообще — до корректности каждого варианта по отдельности («дистрактор тоже верен» — тоже брак).

Слепой калибратор сложности. Ему намеренно не показывают заявленную сложность — он независимо оценивает уровень и прогнозирует поведение кандидатов на вопросе. Существенное расхождение с заявкой — отклонение с конкретной подсказкой «сделай значительно сложнее/проще». Ловит классику: тривиальный вопрос с меткой «сложный».

Симулятор кандидата (максимальный режим качества) — самый наглядный агент. Модель проходит вопрос как сильный кандидат, не видя разметки. Если она уверенно выбирает вариант, помеченный неверным, и внятно это обосновывает — вопрос неоднозначен, брак. Для задач «найди баг» симулятор иногда отвечает: «код и так корректен» — значит, баг фейковый. Стилизованный пример вердикта:

Задание: «Найдите баг в функции пагинации». Симулятор: «Функция корректна для всех граничных случаев, включая пустой список и последнюю неполную страницу. Заявленного бага не существует». → код проблемы FAKE_BUG, реджект.

Агрегатор вердиктов — принципиально без LLM. Решение принимает детерминированный код: воспроизводимость важнее «интеллектуальности». Схематично — без реальных кодов, порогов и весов, они часть продукта:

problems = collect_all(validators)          # один проход, все проблемы сразу
problems -= { p | p.code == TOOL_FAILURE }  # сбой инструмента не влияет на вердикт
if exists p: p.fatal and p.confident   -> REJECT(reasons = problems)
if exists p: not p.confident           -> RETRY(hints = problems)   # сомнение — второй шанс, а не расстрел
-> PASS

Строка про TOOL_FAILURE — выстраданный инвариант: сбой самого инструмента проверки не может забраковать вопрос — поломка линейки не делает деталь бракованной.

Выборка кодов проблем (из более чем двух десятков): ANSWER_LEAKED, FAKE_BUG, QUESTION_IN_CODE, NON_DETERMINISTIC_CODE, SEMANTIC_DUPLICATE, WRONG_ANSWER_MARKED.

Что происходит с браком: ретраи с памятью и ремонт утечки

Отклонённый вопрос не выбрасывается молча. Подсказки всех валидаторов («найдено два верных варианта вместо одного», «вопрос проще заявленного») вклеиваются в следующую попытку как обязательные исправления. На последней попытке система меняет сам аспект на резервный из пула планировщика — возможно, тема неудачна в принципе.

Самая частая причина брака — утечка ответа — лечится отдельным механизмом. Если утечка — единственная причина реджекта, вопрос не перегенерируется с нуля: полная регенерация обычно «течёт» снова. Вместо этого дешёвый агент точечно ремонтирует формулировку под жёсткими инвариантами неизменности, после чего вопрос проходит укороченную ре-валидацию. Результат: выход банка вырос с ~72% до ~86%, при этом принятый вопрос не стал дороже.

И контринтуитивный A/B-эксперимент: глубина рассуждений утечку НЕ вылечила — pass rate 0.27 против 0.26, на нашей выборке разница не выходит за пределы шума. Утечка лечится правилами формулировки, а не «думанием». Полезный тезис против карго-культа reasoning.

Дубликаты и умение остановиться

Дедупликация — семантическая, двухуровневая: быстрый фильтр на эмбеддингах отбирает подозрительные пары, затем LLM подтверждает «тот же навык, другой словесный камуфляж» (при недоступности эмбеддингов — fallback на Jaccard). Ключевая идея — таксономия когнитивных уровней: два вопроса про одну тему НЕ дубликаты, если тестируют разные уровни — знание, понимание, применение, анализ. Дубль — совпадение и темы, и уровня.

Поверх работает механизм «насыщения»: если доля дублей по компетенции превысила порог, генерация останавливается с явным статусом — «создано N из M, тема исчерпана» — вместо оплаты заведомого брака. В старой версии был анти-паттерн: при переполненном банке система сама просила модель «сделать вариацию того же навыка» — и сама же удаляла результат как дубликат. Мы платили за мусор, который сами и заказали.

Режим второй: вопросы по вашим регламентам, а не по «интернету вообще»

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

Ингест. Загружаются PDF, DOCX, XLSX, TXT и веб-страницы (версионирование по SHA-256, защита от SSRF); обработка — асинхронный конвейер из пяти стадий: скачивание → парсинг → чанкинг → эмбеддинги → сохранение. Парсер восстанавливает структуру даже из плоского текста четырьмя эвристиками заголовков, включая кириллический капс; таблицы выделяются в отдельные «ассеты». Чанкинг структурно-осознанный, с перехлёстом между соседними чанками — мысль не рвётся на границе.

Grounding. Поиск двухступенчатый: сначала по документам, явно привязанным к компетенции (с приоритетом и флагом «обязательный источник»). Если привязанных источников нет — fallback на все базы проекта. А вот если источники привязаны, но поиск по ним ничего не нашёл, — генерация идёт без grounding’а, с зафиксированным режимом и предупреждением, а не притворяется обоснованной.

Каждый найденный фрагмент попадает в промпт с атрибуцией, а ключевая инструкция генератору — опираться на факты компании, но не копировать дословно: вопрос проверяет понимание, а не запоминание. У готового вопроса сохраняется provenance до конкретных чанков — можно показать, из какого абзаца регламента он «вырос». Разница на стилизованном примере:

Без базы знаний: «В какой срок по закону потребитель может вернуть товар надлежащего качества?» — вопрос про интернет вообще.

С базой знаний: «Клиент требует возврат на 20-й день, ссылаясь на акцию. Как по внутреннему регламенту возвратов обрабатывается такой кейс и кто согласует исключение?» — источник: «Регламент возвратов, раздел 4».

Деградация без падения. Если векторное расширение БД недоступно — молчаливый пересчёт косинусов на Node.js; если упали эмбеддинги — чанки остаются доступными текстовому поиску. Пайплайн нигде не падает целиком из-за отказа одной подсистемы.

Человек в контуре

AI-проверки — не замена эксперту, а фильтр перед ним. Эксперт ставит APPROVE/REJECT с одной из 13 категорий («Ответ виден в коде», «Спорный правильный ответ»…) и комментарием. Дальше фидбэк замыкается в обучающий контур: топ категорий отклонений по компетенции автоматически подмешивается в промпты всех будущих генераций — «ранее отклонено экспертом, не повторяй эти ошибки». Перегенерация идёт через тот же конвейер проверок — без планировщика, тема уже задана старым вопросом, — с контекстом старого («НЕ ПОВТОРЯЙ, сделай другой на ту же тему»); новый вопрос связывается со старым — у вопросов есть родословная. State machine статусов плюс единый фильтр выдачи, вшитый во все пути показа и подсчёта готовности, гарантируют, что забракованный вопрос никогда не попадёт кандидату.

Качество тестируется как код: 12 регрессионных фикстур — по одной на каждую реальную проблему, найденную экспертом; 20 вручную размеченных фикстур утечки (10 «текущих», 10 чистых) — детектор утечек проверяется как модель, по precision/recall. Даже у промпта ремонта есть юнит-тест на бюджет длины: промпт — артефакт с контрактом.

Музей граблей

1. «Промпт в описании профессии». Поле описания компетенции изначально никак не валидировалось — и пользователи закономерно стали писать туда собственные ТЗ: «Ты — senior разработчик…», «сгенерируй 5 вопросов», требования к количеству и типам вопросов прямо в тексте. Генератор послушно исполнял чужие инструкции, а проверяющие так же послушно браковали результат: на «грязных» описаниях доля прохождения факт-чекера падала до 3,1%, и система сжигала до 100 LLM-вызовов на один принятый вопрос. Из этого инцидента вырос препроцессор из раздела про подготовку входа; заодно эвристики выучили английские паттерны инъекций — до инцидента ловили только русские.
2. «Хвост банка без валидации». При исчерпании бюджета деградация управляемая: отключается только дорогой симулятор кандидата — ниже уровня STANDARD, то есть факт-чекера, калибратора и структурных проверок, система не опускается никогда.
3. «Дешёвая модель дешёвой модели рознь». Разброс pass rate валидации между economy-моделями — 0.71–0.84 против 0.28–0.29. Выбор дешёвой модели под валидацию — отдельное исследование, а не «возьмём что подешевле». Конкретные модели мы сознательно не называем — карта «модель → задача» часть ноу-хау, об этом в конце, — но сам факт четырёхкратного разброса переносим на любой стек. Бонус из той же серии: 83% completion-токенов одной дешёвой модели уходило в невидимый reasoning из-за унаследованной настройки.
4. «Почти-JSON». Модели возвращают markdown-фенсы, reasoning-преамбулы, неэкранированные бэкслеши (привет, PHP-неймспейсы) и сырые переводы строк внутри строковых литералов. Наш парсер применяет пять стратегий по нарастающей плюс авторемонт, и покрыт примерно сорока юнит-тестами на реальные форматы. У разных вендоров свои сюрпризы: где-то нет structured output, где-то фиксированная температура, где-то служебные reasoning-токены незаметно съедают лимит ответа — без спец-обработки приходит пустой ответ.

Экономика качества и честные статусы

Качество стоит денег, и мы это не прячем: порядка десятка LLM-вызовов на принятый вопрос, банк собирается десятки минут (около получаса на банк из двух десятков вопросов), примерно половина первых генераций отклоняется факт-чекером и перегенерируется. Эта цифра не противоречит ~86% из раздела про ремонт утечки: половина — брак первого прохода, а ~86% — итоговый выход банка после ретраев и точечного ремонта. Есть три уровня качества — FAST (структурные проверки и дедуп), STANDARD (плюс факт-чекер и калибратор), FULL (плюс симулятор кандидата). Квота вопросов тарифа при этом списывается только за вопросы, прошедшие все проверки, — черновики и ретраи в неё не попадают.

Прогресс стримится в UI по стадиям — «Проверка корректности…», «Ремонт утечки…», «Попытка 2 из 3: причина…» — вместо вечного спиннера, а по завершении приходит отчёт с раскладкой недостачи: не прошли проверку качества, дубликаты, темы исчерпаны, технические ошибки.

Статусы готовности не прячутся: если по компетенции пробел — это видно фильтром, а не выясняется на оценке. Сравнение на идентичных описаниях компетенций: старый пайплайн — 59 вопросов и ноль проверок, почти все — с утёкшим в тест доменом компании, а 14 из 19 Python-вопросов — про одну подтему; новый — 5–7 уникальных подтем на компетенцию и ноль дубликатов.

Что мы вам не рассказали

Честно: тексты промптов, численные пороги, формулы агрегации и карту «модель → задача» мы сознательно не публикуем. Это и есть продукт, а публикация точных эвристик упрощает их обход. Зато принципы переносимы:

1. Покрытие планируется заранее и защищается критиком разнообразия, а не надеется на случайность.
2. Генератор никогда не проверяет сам себя: независимые модели других вендоров, до шести осей проверки, включая адверсариальные.
3. Сложность оценивается вслепую.
4. Дубликаты ловятся семантически, с учётом когнитивных уровней.
5. Брак не выбрасывается втупую: точечный ремонт, ретраи с памятью, смена темы.
6. Система умеет остановиться и явно сообщить о неудаче.
7. Каждый инцидент закреплён в коде инвариантом и регрессионной фикстурой.
8. Вопросы могут расти из ваших собственных регламентов — с provenance до конкретного абзаца.

Если хотите потрогать — генерация банков вопросов по компетенциям и по вашим документам доступна на vibe.codenrock.com. Если хотите поспорить об архитектуре — велком в комментарии. Нам особенно интересно: а как бы вы валидировали сам валидатор? Мы пришли к размеченным фикстурам и precision/recall для детектора утечек — но подозреваем, что это не единственный путь. И если тема зайдёт, отдельных статей просят парсер «почти-JSON», регрессионное тестирование промптов и RAG-ингест документов.

Через месяц после запуска тестирования в компании обычно происходит один и тот же разговор. HR приходит к руководителю и говорит: «Тест работает, но что-то не то». Кандидаты на стажировку жалуются, что не успели, — а на самом деле половина просто открыла ссылку в последний вечер. Сильный синьор бросил тест на середине, потому что решил, что раз времени в обрез, то и позиция несерьёзная. Джуниор набрал больше мидла — и все понимают, что дело не в знаниях, а в том, что вопросы гуглились.

Дело почти никогда не в самих вопросах. Дело в том, что тест собран одинаково для всех задач, а задачи разные. Отсев трёхсот откликов на стажировку и финальная проверка человека, который получит доступ к продовой базе, — это два разных инструмента, даже если внутри лежит один и тот же банк вопросов.

Ниже — пять сценариев, которые закрывают большую часть реальных задач найма и оценки. Для каждого: как ситуация выглядит изнутри, какие настройки её решают, что при этом увидит кандидат и на какие грабли обычно наступают. Мы разбираем всё на примере Codenrock Vibe, но логика применима к любой платформе оценки — вопрос лишь в том, есть ли в ней нужные ручки.

Сначала — из чего вообще собирается тест

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

Время. Лимитов три, и они живут на разных уровнях. Общий — на весь тест, в минутах. На секцию — это блок вопросов со своим таймером, от 5 секунд до 24 часов. И на отдельный вопрос — здесь интерфейс предлагает готовые значения от 15 секунд до 60 минут. Можно включить любой один, можно все три сразу.

Порядок. Вопросы и варианты ответов можно перемешивать — у каждого кандидата свой порядок. Навигацию назад можно разрешить или запретить. Вопросы можно показывать все сразу или выдавать по одному.

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

Внешний вид. Логотип, фирменный цвет, favicon — на странице регистрации, внутри теста и в письмах.

Результаты. Отдельная настройка решает, что кандидат увидит после теста: от «ничего» до подробного разбора по компетенциям с рекомендациями.

Антифрод. Поведенческий мониторинг: переключения вкладок, потеря фокуса, работа с буфером обмена. Плюс превентивные меры вроде запрета копирования и водяного знака.

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

Сценарий 1. Поток откликов: 300 человек на стажировку

Это состояние знакомо каждому, кто хоть раз открывал набор на стажировку. Вакансия провисела неделю, откликов больше двухсот, и они продолжают капать. Резюме у всех похожие: один и тот же курс, один и тот же пет-проект, одна и та же формулировка «быстро учусь». Отсматривать глазами бессмысленно — вы всё равно не отличите по резюме того, кто действительно писал код, от того, кто повторил за ментором. А назначать всем скрининг-звонок по 20 минут — это 100 часов разговоров.

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

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

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

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

Отдельная приятная мелочь — сообщение над формой. Одна фраза, которая снимает половину будущих вопросов в почту: сколько времени займёт тест, что попытка одна и когда ждать ответа. Кандидат читает её до того, как нажмёт «Начать», а не после.

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

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

Вторая — точечные таймеры на вопросы, где ответ ищется в поиске за минуту. Не на весь тест, а именно на такие вопросы: 30–60 секунд на фактологию вроде «чем отличается WHERE от HAVING». Тот, кто знает, отвечает сразу. Тому, кто идёт в поисковик, времени не хватит. При этом задачу на рассуждение вы оставляете без ограничения — пусть человек думает столько, сколько нужно.

Как только у одного вопроса появился таймер, тест сам переключается в режим выдачи по одному: платформа показывает вопросы последовательно, а отсчёт привязан к моменту, когда вопрос впервые открылся. Вернуться и получить время заново не выйдет.

И последнее для этого сценария — результаты. На массовом отсеве не показывайте баллы. Не из вредности: как только кандидат видит «64%», у вас появляется переписка на тему «а почему не 70, я же правильно ответил». Для потока хватает статуса «пройден / не пройден» без точного балла — такая комбинация собирается переключателями видимости. А развёрнутую обратную связь вы дадите тем, кто пойдёт дальше.

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

Сценарий 2. Мидл и синьор: теория и практика в одном тесте

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

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

Лечится это секциями. Тест разбивается на блоки, у каждого — собственный таймер: «Теория» на 15 минут, «Практика» на 45. Когда время блока заканчивается, платформа сама закрывает его и переводит человека дальше. Пересидеть в практике за счёт теории не получится — и это ограничение проверяет сервер, а не кнопка в интерфейсе, которую можно обойти.

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

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

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

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

Сценарий 3. Несколько вакансий сразу и бренд работодателя

Ситуация третья. Компания растёт, открыто пять ролей, кандидаты приходят с разных сторон: часть с job-борды, часть из телеграм-канала, часть — с ярмарки вакансий, где вы раздавали визитки с QR-кодом. И начинается ручная работа: этому отправить ссылку на бэкенд, той — на аналитику, третьему — «подождите, сейчас найду».

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

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

Работает это аккуратно: в каталог попадают только активные тесты с включённым публичным доступом, а сама страница видна кандидатам только после того, как вы её опубликуете. Черновик можно спокойно готовить неделю.

Второе лечится брендированием, и настраивать его стоит один раз на уровне проекта. Логотип (рекомендуемый размер — 400×80 пикселей, отдельно можно загрузить версию для тёмной темы), favicon для вкладки браузера, фирменный цвет и скругление углов. После этого каждый новый тест выходит уже в ваших цветах — не нужно вспоминать про оформление каждый раз, когда открывается новая вакансия.

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

Грабли этого сценария. Дефолтный брендинг проекта подставляется в новые тесты, но не переписывает задним числом те, что уже созданы. Если вы настроили оформление после того, как завели десяток тестов, по ним придётся пройтись руками.

Сценарий 4. Оценочная кампания или конкурс: баллы потом, обратная связь — всем

Четвёртая ситуация выглядит иначе, и HR тут скорее организатор, чем рекрутер. Это может быть оценка студентов образовательной программы, внутренний конкурс, отбор в кадровый резерв или диагностика перед стартом обучения. Общего с наймом мало, а особенностей две.

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

Первое решается окном доступности. Вместо срока «ссылка живёт 72 часа» вы задаёте прямые даты: тест открывается 10 августа в 9:00 и закрывается 24 августа в 23:59, часовой пояс указывается явно. До открытия человек видит «тест ещё не доступен», после закрытия — «срок истёк». Не нужно ничего включать и выключать руками в полночь.

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

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

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

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

Грабли этого сценария. Открывать результаты задним числом — приятная возможность, но она работает только вперёд по времени: участник увидит новую версию, когда зайдёт на страницу результата. Поэтому день, когда вы меняете политику, лучше сопроводить рассылкой — иначе половина участников просто не узнает, что там что-то появилось.

Сценарий 5. Строгий отбор: когда цена ошибки высокая

Последний сценарий — про случаи, где ошибка стоит дорого. Финальный этап отбора, сертификация, роль с доступом к деньгам, персональным данным или инфраструктуре. Здесь важно не только «кто набрал больше», но и «сам ли человек это решал».

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

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

Юридический контур на этом этапе — не формальность. Кандидат принимает согласие на обработку персональных данных до старта теста: либо одним общим чекбоксом, либо отдельной галочкой на каждый документ. К платформенным документам можно добавить свои — в формате PDF или DOC, до 50 МБ. Что именно человек принял, в какой версии документа и когда — фиксируется на сессии. Если через полгода возникнет спор, у вас будет не «мы точно показывали», а конкретная запись.

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

Грабли этого сценария. Соблазн включить всё сразу — самый сильный именно здесь. Но тест с максимальной строгостью на входе воспринимается как недоверие, и на финальном этапе, где вы уже боретесь за кандидата с другими работодателями, это может стоить дороже, чем гипотетическое списывание. Разумная рамка: мониторинг собирает данные, тест даёт фактуру, а решение принимается по связке «результат + живой разговор».

Сводная шпаргалка

С чего начать, если вы настраиваете это впервые

1. Заполните реквизиты организации — юрлицо, ИНН, email для отзыва согласия. Без них публичная ссылка не включится, и лучше узнать об этом сейчас, а не за час до запуска вакансии.
2. Настройте брендирование и документы согласий на уровне проекта: всё, что вы создадите дальше, унаследует эти настройки автоматически.
3. Выберите сценарий из таблицы выше и соберите его комбинацию. Не пытайтесь собрать «универсальный тест на все случаи» — его не существует.
4. Отдельно решите, что кандидат увидит после теста. Для многих компаний это единственная точка контакта с человеком, которого не взяли, и она хорошо запоминается.
5. Пройдите тест сами, по своей же публичной ссылке, с личного адреса и до самого конца. Один такой прогон находит больше проблем, чем любой чек-лист: и опечатку в вопросе, и таймер, который оказался слишком жёстким, и письмо, которое ушло в спам.

Что в итоге

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

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

Честные границы тоже стоит знать заранее. Попытки не настраиваются: одна регистрация — одна сессия, вторую попытку может дать только организатор вручную. Антифрод поведенческий, а не видео. Часть палитры брендирования пока доступна только через API — интерфейс даёт менять основной цвет.

Две большие темы остались за кадром: адаптивный режим, где тест сам подбирает следующий вопрос под уровень кандидата, — про него выйдет отдельная статья, ссылку добавим после публикации; и генерация банка вопросов по компетенциям — тоже выйдет отдельной статьёй, ссылку добавим после публикации.

А большинство описанного можно проверить за вечер на бесплатном тарифе: собрать тест, включить публичную ссылку и пройти его самому — как это сделает ваш кандидат.

Зарегистрироваться можно на странице соревнования до 30 августа включительно. Основной этап продлится с 31 августа по 11 октября 2026 года.

Что такое Кубок СЭРПАС

СЭРПАС — сообщество энтузиастов российских программных и аппаратных средств, которое сложилось в 2025 году вокруг простой идеи: на отечественном железе можно и нужно не только работать, но и соревноваться. Двигатель проекта — программист-энтузиаст Кирилл Ерохин: он собрал сообщество, лично нашёл и убедил первых участников, купил собственный сервер на «Эльбрусе» — что в то время было совсем непросто — и профинансировал первый кубок из своих средств.

Первый Кубок СЭРПАС прошёл осенью 2025 года и собрал более 30 участников — студентов и выпускников технических вузов. Тогда каждый получал прямой SSH-доступ к серверам с «Эльбрусами» и работал в консоли. О соревновании писали на Хабре, его обсуждали в подкасте C++ Russia, а анонс кубка 2026 года вышел на «Сделано у нас». Отдельный бонус для победителя от МЦСТ — разработчика процессоров «Эльбрус»: освобождение от конкурсного отбора на стажировку в компании (останется пройти устное собеседование).

Формат и призы 2026 года

• Участники — граждане РФ в возрасте от 18 до 24 лет включительно;
• Регистрация — открыта до 30 августа 2026 года на codenrock.com/contests/sc26;
• Основной этап — с 31 августа по 11 октября 2026 года, онлайн;
• Формат — одиночный, задачи алгоритмические, решения на C/C++;
• Призовой фонд — 400 000 рублей, плюс для победителя — стажировка в МЦСТ без конкурсного отбора, по итогам собеседования;
• Сайт кубка — cup.serpas.ru.

Почему «Эльбрус» — это интересно

«Эльбрус» — семейство российских процессоров, которые разрабатывает МЦСТ. В основе — одноимённая архитектура (у программистов прижилась аббревиатура E2K) с явным параллелизмом на уровне команд (VLIW): порядок выполнения инструкций планирует не процессор, а компилятор. Для спортивного программиста это отдельный вызов — привычные интуиции о том, «что быстрее», на e2k работают иначе, и оптимизация решений превращается в самостоятельную дисциплину. Соревнование идёт на серверах с восьмиядерными процессорами «Эльбрус-8СВ» с пятым поколением архитектуры «Эльбрус», а код собирается штатным компилятором lcc, который поддерживает стандарты от C++03 до C++20 и C11/C18.

Как мы научили платформу запускать код на «Эльбрусе»

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

• задачи, помеченные как «эльбрусовские», платформа направляет не в общий пул проверяющих серверов, а в выделенную шину сообщений — отдельный кластер Apache Kafka с шифрованием и аутентификацией (TLS + SASL);
• на сервере «Эльбрус-8СВ» работает наш проверяющий сервис, собранный нативно под e2k, — он забирает решения из очереди и запускает их в изолированных Docker-контейнерах (используется нативная e2k-сборка Docker);
• решения проверяются строго по одному — так тайминги остаются воспроизводимыми, и участники соревнуются в равных условиях;
• если язык задачи не поддерживается на «Эльбрусе», отправка автоматически уходит на обычный раннер — для участника всё прозрачно.

Кроме C/C++ для e2k уже собраны окружения Python, JavaScript, Java, Go, PHP и C#, а также образы с PostgreSQL и MySQL — то есть на «Эльбрусах» можно проводить соревнования практически любого стека, от олимпиад до SQL-контестов.

Как это выглядит для участника

Участник открывает задачу, выбирает язык — например, «C++11 (Эльбрус)» — и пишет решение в редакторе кода прямо в браузере. Рядом с лимитами задачи виден бейдж «Работает на платформе „Эльбрус“ (e2k)»: он означает, что код будет собран и прогнан именно на отечественном процессоре.

Интеграцию мы прогнали на адаптированной задаче отборочного этапа прошлогоднего кубка — решении системы линейных уравнений методом Гаусса. Эталонное решение проходит все 32 теста, в том числе 29 скрытых, — каждый тест укладывается в 12 миллисекунд при лимите 5000 мс. Участник видит вердикт, время и память по каждому тесту через несколько секунд после отправки.

Что это значит для организаторов соревнований

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

Как принять участие

Регистрация открыта до 30 августа 2026 года на странице Кубка СЭРПАС 2026. Участвовать могут граждане РФ в возрасте от 18 до 24 лет включительно. Участие бесплатное, формат онлайн — нужен только браузер и уверенный C/C++. Приходите померяться силами с «Эльбрусом»: такой опыт в спортивном программировании пока есть у единиц.

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

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

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

Зачем вообще формализовать оценку

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

Грейды и пересмотр зарплат. Без модели грейдов повышение — это переговорный навык сотрудника, а не его квалификация. Рабочая схема: для каждой пары «грейд — компетенция» задаётся минимальный балл и вес. Тогда разговор о повышении превращается из «мне кажется, я готов» в «по компетенции X тебе не хватает до порога — вот план». В Vibe грейды привязываются к профессии, а шаблон теста — к конкретному грейду, так что «тест на мидла» и «тест на сеньора» — это разные наборы требований, а не одна планка для всех.

Планирование обучения. Бюджет на курсы обычно расходуется по принципу «кто попросил». Оценка даёт gap-анализ: разрыв между текущим баллом по компетенции и требуемым. Индивидуальный план развития (ИПР) в этом случае строится не «из головы», а на фактических результатах — и обучение закрывает реальные пробелы, а не интересные сотруднику темы.

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

Bus-фактор и матрица навыков. Кто, кроме одного человека, разберётся в платёжном сервисе? Матрица «люди × компетенции» отвечает на этот вопрос, но заполнять её вручную — сизифов труд. Если у каждого сотрудника есть свежий результат оценки, матрица собирается из отчётов: в Vibe есть экспорт сессий в Excel, где компетенции разложены по колонкам, — фактически готовая матрица навыков по команде.

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

Как устроена оценка: профессия → компетенции → вопросы

В основе — трёхуровневая модель.

Профессия — это роль плюс уровень. Уровней пять: стажёр, джуниор, мидл, сеньор, лид. «Backend-разработчик (middle)» и «Backend-разработчик (senior)» — разные профессии с разными наборами требований.

Компетенции принадлежат профессии. У каждой — важность по шкале от 1 до 4 (Низкий / Средний / Высокий / Критический) и список разрешённых типов вопросов. Важность влияет на то, как адаптивный алгоритм распределяет внимание между компетенциями.

Вопросы принадлежат компетенции. У каждого — сложность от 1 до 4: Лёгкий, Средний, Сложный, Экспертный.

Типы вопросов и как каждый проверяется

Типов ровно четыре, и у каждого свой механизм проверки.

«Один ответ» — выбор одного варианта. Проверяется автоматически: совпало с правильным — 100 баллов, нет — 0.

«Несколько ответов» — выбор нескольких вариантов. Тоже автоматика, но с частичным зачётом: доля выбранных правильных минус доля выбранных неправильных (не ниже нуля), умноженная на 100. Наугад отметить всё подряд не получится — штраф съест балл.

«Открытый ответ» — свободный текст до 5000 символов, опционально с файлами-вложениями. Здесь четыре режима проверки:

• точное совпадение — автоматическое сравнение с эталоном без участия AI (подходит для коротких фактических ответов);
• строгая сверка — AI-модель сопоставляет ответ с эталоном по ключевым терминам;
• оценка по критериям (режим по умолчанию) — к вопросу задаются критерии с баллами, сумма которых равна 100, и AI-модель оценивает ответ по каждому критерию отдельно;
• сравнительная оценка — нестрогое сравнение с эталонным ответом: кандидат может выразить те же идеи другими словами.

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

«Код» — два принципиально разных вида. Алгоритмические задачи проверяются автоматически прогоном тест-кейсов: балл равен проценту пройденных тестов, а кандидат может запускать проверку до отправки ответа. Задачи формата код-ревью (найти баг, оптимизировать, отрефакторить, реализовать, объяснить или конвертировать код, провести ревью) оценивает AI-модель по критериям задания — тоже с баллом, уверенностью и текстовым обоснованием.

Пороги «правильности» различаются: у закрытых вопросов порог засчитывания строже, чем у открытых и кода, — угадывание в закрытых не должно сходить за знание. Итог сессии — среднее по всем вопросам; тест пройден, если итог не ниже проходного балла шаблона (по умолчанию 70%).

Адаптивное тестирование — коротко

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

Стратегий четыре: «Сбалансированная» (ровное покрытие всех компетенций — дефолт для первичной оценки), «Углубленная проверка» (копает слабые зоны — для решений о повышении), «Быстрая оценка» (массовый скрининг) и «Адаптивная сложность» (определение уровня джуниор/мидл/сеньор). Глубина настраивается: быстрая — 20–30 вопросов (примерно 30–45 минут), стандартная — 30–50 (45–75 минут), глубокая — 50–100 (75–150 минут).

Принципиально: модель не придумывает вопросы на лету — только выбирает из заранее подготовленного банка, и каждое её решение логируется с объяснением. Подробный разбор адаптивного режима выйдет отдельной статьёй, ссылку добавим после публикации.

Нюансы для разных специальностей

Дальше — рекомендации из нашей практики; универсального рецепта нет, но закономерности устойчивые.

Backend. Лучшая комбинация — алгоритмические задачи с автопроверкой плюс открытые вопросы об архитектуре, базах данных и отказоустойчивости с оценкой по критериям. Закрытых вопросов хватает для проверки знания фреймворка и стандартной библиотеки, но сеньорские компетенции («спроектируйте», «что сломается при росте нагрузки») закрытыми не проверяются в принципе.

Frontend. Хорошо работают код-ревью форматы: найти баг в компоненте, отрефакторить, объяснить, что делает код. Основы (браузерные API, специфика языка) закрываются вопросами «Один ответ» и «Несколько ответов», производительность и доступность — открытыми.

QA. Тест-дизайн — это мышление, а не факты, поэтому ядро — открытые вопросы с критериями: «составьте набор проверок для этой формы». Тип «Несколько ответов» здесь полезнее, чем где-либо: «выберите все подходящие виды тестирования для сценария» с частичным зачётом честно отражает неполные знания. Для автоматизаторов добавляйте задачи на код.

DevOps. Самое ценное — открытые сценарии инцидентов («прод отвечает 502 после деплоя — ваши действия») со сравнительной оценкой: правильных путей несколько, и жёсткий эталон только мешает. Знание инструментов проверяется закрытыми вопросами, скрипты — задачами на код.

Аналитики. Почти всё — открытые вопросы по критериям: постановка задачи, проверка гипотез, интерпретация метрик. SQL удобно проверять закрытыми вопросами по готовому запросу или задачами на код.

Общий принцип: чем ближе компетенция к «принимать решения в неоднозначной ситуации», тем нужнее открытые вопросы и AI-проверка с обоснованием. Чем ближе к «знать факты и синтаксис» — тем дешевле и надёжнее закрытые.

Как настроить у себя: пять шагов

Шаг 1. Профессия и компетенции

Создайте профессию в разделе «Профессии»: роль, уровень, описание. Компетенции можно завести вручную или сгенерировать AI по описанию роли. По нашему опыту, оставляйте 5–7 компетенций на профессию: генератор может предложить десятки, но каждую компетенцию придётся покрыть вопросами, а в отчёте различать между собой — при 15+ компетенциях радар превращается в кашу. Расставьте важность: «Критический» — для ядра роли, «Низкий» — для желательного.

Шаг 2. Банк вопросов и покрытие

Вопросы добавляются вручную или генерируются AI: от 5 до 30 вопросов на компетенцию за запуск (по умолчанию 12). Распределение типов настраивается поштучно; по умолчанию для 12 вопросов — 4 «Один ответ», 2 «Несколько ответов», 4 открытых и 2 с кодом. Для алгоритмических задач есть встроенная база из 3000+ задач. Про то, как устроена AI-генерация и контроль качества вопросов, выйдет отдельной статьёй, ссылку добавим после публикации.

Сгенерированное обязательно вычитывайте: AI-генерация экономит часы, но финальная ответственность за формулировки — на вас. Перед запуском платформа проверяет готовность: на роль нужно минимум 5 вопросов, а компетенции без единого вопроса блокируют осмысленный запуск — они попадут в отчёт с нулём данных.

Шаг 3. Шаблон теста

В разделе «Шаблоны тестов» собирается сам тест. Ключевые настройки:

• режим: обычный (фиксированный список вопросов) или адаптивный (весь пул профессии + «Стратегия адаптации» и «Глубина тестирования»);
• «Проходной балл (%)» — по умолчанию 70;
• «Ограничение времени (минуты)» — по умолчанию не задано; отдельно можно включить таймеры на секции и на отдельные вопросы (от 15 секунд) — с вопросными таймерами тест автоматически выдаётся по одному вопросу;
• перемешивание вопросов и вариантов ответа — от списывания «по номерам»;
• переключатель «AI Оценка» — без него открытые вопросы и код-ревью потребуют ручной экспертной проверки;
• «Допускать краткие ответы» — снимает штраф за краткость при жёстком тайминге (но не за бессодержательность);
• политика показа результатов кандидату — 6 режимов, от полностью скрытых результатов до подробных; по умолчанию сотрудник не видит ничего. Для внутренней оценки рекомендуем показывать хотя бы разбивку по компетенциям: оценка «в один конец» демотивирует. Правильные ответы кандидату не показываются ни в одном режиме — так банк вопросов гораздо сложнее растащить по команде.

Шаг 4. Запуск сессий

Сессии создаются именными приглашениями (срок действия по умолчанию — 72 часа) или публичной ссылкой с лимитом числа прохождений. Одна сессия — одна попытка; повторная оценка — это новая сессия, что и нужно для честного сравнения срезов. Администратор может продлить время, сдвинуть срок действия или принудительно завершить сессию.

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

Шаг 5. Чтение отчётов

Отчёт по сессии — это итоговый балл и разбор каждого вопроса: ответ сотрудника, балл, обоснование AI-оценки, экспертная оценка (если была) — отдельными блоками. Главный инструмент — разбивка по компетенциям: число вопросов, доля правильных, средний балл; при трёх и более компетенциях она отображается радаром.

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

Прокторинг фиксирует браузерные события (переключения вкладок, потерю фокуса, буфер обмена) и поведенческие метрики печати, сводя их в scoring честности 0–100%. Две честные оговорки: видеонаблюдения через веб-камеру нет — это именно браузерный мониторинг; и высокий риск-балл — повод для разговора, а не автоматический вердикт. Отчёты выгружаются в Excel (сводно по сессиям, с компетенциями в колонках) и PDF.

Чек-лист внедрения

• Сформулирована цель оценки (грейды / обучение / аудит) и озвучена команде
• Создана профессия с уровнем; компетенций 5–7, важность расставлена
• Банк вопросов покрывает все компетенции, все типы и уровни сложности представлены
• Сгенерированные вопросы вычитаны техническим экспертом
• Шаблон настроен: проходной балл, время, AI-оценка, перемешивание
• Выбрана политика показа результатов сотрудникам
• Пилот на 2–3 лояльных сотрудниках, формулировки поправлены по итогам
• Запущены сессии, назначен ревьюер для спорных AI-оценок
• Результаты разобраны по компетенциям, по пробелам построены планы развития
• Назначена дата повторного среза

Вместо заключения

Оценка компетенций не заменит ни один разговор один на один и не примет за вас кадровое решение — и не должна. Её роль скромнее и полезнее: превратить «мне кажется» в данные, на которые можно опереться при пересмотре грейдов, планировании обучения и разборе bus-фактора.

Настроенная один раз, она работает циклом: срез → gap-анализ → план развития → повторный срез. Разница между двумя срезами — это и есть измеримый эффект вашего бюджета на обучение.

Начать проще с малого: одна профессия, 5–7 компетенций, пилот на нескольких людях — для этого достаточно стартового тарифа, актуальные условия и лимиты смотрите на странице тарифов. Общий обзор платформы — в статье «Обзор Codenrock Vibe».

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

Четыре процесса, четыре инструмента, четыре бюджета. И ни один инструмент не знает о существовании соседнего. Человек провалил вопрос о регламенте возвратов — LMS не назначит ему курс; предложил лучшую идею года — в кадровом резерве он не значится. Данные о людях есть везде и не работают нигде.

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

Codenrock Vibe построен вокруг другой идеи: ИИ работает внутри каждого шага цикла «оценить → развить → переоценить».

— Михаил Трофимов, ИТ-предприниматель, эксперт по разработке ПО и агентным системам

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

Что за продукт: весь цикл одной схемой

Codenrock Vibe — платформа оценки и развития персонала на одном контуре данных: профессия и компетенции → банк вопросов → тест → результаты → фидбек → индивидуальный план развития → обучение → переоценка. От того же контура питаются грейды и повышения, ревью 360/180 и программа идей.

Важная оговорка о слове «платформа»: внедрять всё сразу не нужно. Коммерчески продукт устроен просто:

• Vibe Hire закрывает один сценарий — оценку внешних кандидатов.
• Vibe Talent открывает все модули работы с сотрудниками сразу, без «вилок функциональности» между тарифами.

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

Боль 1: банк вопросов делается квартал

Знакомая сцена. HR-директор просит запустить оценку под новую роль. Методолог берёт три недели на матрицу компетенций, ещё три на банк вопросов, потом два круга согласований с техническим экспертом, у которого «нет времени, посмотрю в пятницу». К моменту готовности теста роль уже дважды поменяла требования, а половина кандидатов ушла туда, где отвечают быстрее. Бюджет — недели работы двух дорогих специалистов на каждую роль. Поэтому оценку и проводят раз в год: чаще — просто не успеть.

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

Совет: мы рекомендуем выбрать 5–7 компетенций — система умеет и больше, но тест размазывается.

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

Отдельный режим — вопросы по вашим регламентам, а не по «интернету вообще». В базу знаний загружаются внутренние документы (PDF, DOCX, XLSX), и вопрос вырастает из конкретного абзаца регламента — с сохранённым источником. Для банков, ритейла, производств это главный сценарий: публичная нейросеть не знает ваш процесс согласования исключений, а тест — знает.

Запуск при этом не требует операционного подвига: кампанию можно открыть публичной ссылкой — кандидаты регистрируются и проходят тест сами, без ручных приглашений; для закрытых кампаний есть пакетные email-приглашения. Рекрутер перестаёт быть диспетчером рассылок.

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

Боль 2: все проходят один и тот же тест

Простая арифметика. 200 кандидатов проходят линейный тест из 60 вопросов — это 12 000 ответов. Сильному кандидату первые сорок вопросов очевидны, слабый после десятого угадывает: информации в большинстве этих ответов — ноль, а рабочее время и терпение людей они сжигают исправно. Сколько сильных кандидатов бросили ваш тест на середине в прошлом году — вы знаете?

Адаптивный тест строит маршрут под человека: следующий вопрос выбирается по уже данным ответам. Четыре стратегии определяют, что оптимизирует система — ровный профиль, слабые зоны, скорость или точность грейда. На стандартной глубине кандидат отвечает на 30–40 вопросов вместо 60–100 в линейном тесте, получает задачи своего уровня и реже бросает, а вы видите не «прошёл/не прошёл», а профиль по компетенциям и различимый грейд. Каждый шаг маршрута логируется со словесным обоснованием — отчёт можно разобрать постфактум, что для защиты решений важнее красивой цифры.

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

Мини-кейс. Набор стажёров: несколько сотен откликов, два техлида на проверку. Раньше — либо примитивный тест «на отсев», либо две недели вечеров техлидов. Теперь — короткий адаптивный скрининг с задачами по коду: техлиды смотрят не все работы, а профили финалистов и спорные AI-оценки. Их время уходит на решения.

Что это меняет: оценивается рассуждение, а не умение выбирать из четырёх вариантов; узкое место массовой оценки — ручная проверка — исчезает; эксперт тратит на спорные случаи часы вместо дней.

Боль 3: ChatGPT проходит ваши тесты лучше кандидатов

Проведите эксперимент. Возьмите три вопроса из теста, которым вы сейчас отсеиваете кандидатов, и вставьте их в любой публичный чат-бот. Если он ответил правильно за несколько секунд — у вас нет теста. У вас есть проверка умения пользоваться чат-ботом.

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

У Vibe три слоя защиты, и первые два вообще не про наблюдение.

1. Утечка перестала быть катастрофой. Банк вопросов регенерируется за минуты: пересоздать его дешевле, чем кандидату — найти слитый. Экономика списывания ломается — красть нечего надолго, а «протухший» банк из главной статьи расходов превращается в расходный материал.
2. Траектория у каждого своя. Адаптивный маршрут строится по ответам конкретного человека, и кандидату отдаётся только его вопрос: правильные ответы и критерии оценки вырезаются из выдачи. Заготовленная шпаргалка с «правильной последовательностью» бесполезна: маршрут складывается по ходу теста из ответов самого кандидата, а не по фиксированному списку.
3. Скоринг достоверности — встроен, без доплаты. Во время теста, с согласия участника, фиксируются события сессии — смена вкладки, потеря фокуса, копирование и вставка, открытые DevTools — и поведенческие метрики набора текста. На выходе — риск-скоринг 0–100% по каждой сессии: HR видит, каким результатам можно доверять, и получает список событий, который можно разобрать с кандидатом.

Подчеркнём формулировку, за которую отвечаем: это скоринг достоверности, а не слежка и не видеонаблюдение. Система не выносит вердикт «списал» — она даёт взвешенную оценку риска, а решение остаётся за человеком. Для комплаенса в банках и госсекторе эта разница принципиальна.

Боль 4: оценка прошла — и ничего не изменилось

В понедельник выходит новый аналитик. В привычном мире его ждут два PDF, доступ к вики и обещание наставника «на неделе созвонимся»; через три месяца выясняется, что пробел в SQL так и остался пробелом. В Vibe создание профиля сотрудника само запускает цепочку: должность → входная оценка по профессии → карта пробелов → черновик плана развития. К среде руководитель видит не ощущения, а профиль.

Боль 5: карьерные решения не защищаемы

— Почему повысили его, а не меня?

Если ответ руководителя начинается с «ну, понимаешь…» — у вас проблема, и она дороже, чем кажется: демотивированный сильный сотрудник, письмо в комплаенс, а в регулируемых отраслях — спор, в котором компании нечего предъявить, кроме ощущений.

В Vibe карьерный контур формализован от и до. Грейды описаны требованиями к компетенциям — «senior» превращается из вкусовщины в чек-лист. Грейды присваивает калибровочная сессия: люди собираются, сверяют оценки между командами и принимают решения; система применяет результат целиком и записывает его в журнал аудита — незаметно «подправить» грейд задним числом не получится. Повышение проходит workflow с этапами — номинация, ревью, запрос информации, утверждение — и каждый шаг остаётся в журнале аудита.

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

Рядом — инструменты объёмной картины. Ревью 360/180 собирает обратную связь от руководителя, коллег и подчинённых с защитой анонимности: оценки малочисленных групп подавляются, чтобы «анонимный» отзыв единственного подчинённого не оказался анонимным только на словах. Опросники DISC и Big Five добавляют к hard skills поведенческий профиль, а AI-отчёт о командной динамике превращает профили в разбор сочетаемости, рисков и рекомендации руководителю — то, что раньше заказывали у внешнего оргпсихолога за отдельный счёт. Оргструктура, профили сотрудников и дашборд руководителя — фундамент, на котором всё это стоит; о них одной строкой: они просто есть.

Боль 6: идеи сотрудников умирают в почте

У директора по инновациям самая несчастная воронка в компании: сто идей в год, десять доходят до рассмотрения, одна внедряется, и никто не может сказать, где потерялись остальные восемьдесят девять. Не потому, что идеи плохие, — потому что у процесса нет механизма, только почта и энтузиазм.

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

Аналитика инноваций отвечает на вопросы квартального отчёта — воронка статусов, тренды по месяцам и категориям, лидерборды авторов — без единой выгрузки в Excel, а геймификация связывает оценку, обучение и идеи в один контур вовлечения. Когда же программу нужно разогнать внешним событием, хакатоны и инженерные соревнования остаются смежной услугой команды Codenrock — отдельным бизнесом, из которого мы, собственно, и выросли.

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

Принцип под капотом: LLM предлагает — код решает

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

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

Сам AI-контур — управляемый: фронтирные модели нескольких провайдеров с автоматическим fallback (отказ одного вендора не останавливает ваш процесс), каталог промптов с контролируемыми изменениями, журнал использования. Это контур управления, как в промышленной автоматике, а не «чат-бот, которому виднее». Если ваш техдиректор на этом абзаце поднял бровь — он правильно делает: именно для него написаны оба инженерных разбора серии, ссылки — в конце статьи.

Скучная (и обязательная) часть: что спросят ваши ИБ и юристы

Мы знаем, что после HRD статью читает служба безопасности. Отвечаем сразу — сэкономим вам один круг согласований.

Здесь нет ничего захватывающего — и это лучшее, что можно сказать о разделе про комплаенс.

Сколько стоит и как покупается

Две линейки под две разные задачи — и правила, которые мы считаем частью продукта.

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

Что мы честно пока не умеем

Фирменный раздел серии.

• Детекция ответов, написанных нейросетью, — в разработке. В риск-скоринге уже предусмотрен вклад такой детекции, но заявлять её готовой функцией мы не будем, пока она не работает на реальных данных. Сегодняшняя защита от списывания — регенерация банка, индивидуальная адаптивная траектория и поведенческий скоринг: этого много, но называть это «детекцией ChatGPT» было бы враньём.
• Единого BI-дашборда по всей платформе нет — аналитика помодульная (проекты, сессии, ИПР, идеи, дашборд руководителя) с экспортом в Excel и PDF. Сквозной BI — в roadmap.
• Из HRIS-адаптеров рабочий — 1С:ЗУП. Каркас синхронизации готов, остальные системы подключаются как проект, а не галочкой в настройках.
• Психометрическая оговорка. Классический адаптивный алгоритм (CAT) на больших, годами откалиброванных банках статистически строже нашего LLM-подхода — у него есть математические гарантии сходимости оценки. Наш подход выигрывает там, где банк новый или часто меняется, компетенций много и важна объяснимость маршрута. Где проходит эта граница и почему мы выбрали свою сторону осознанно — в честной оговорке статьи об адаптивном тестировании, которая выйдет следом.

С чего начать

Не с презентации — руками. При регистрации на vibe.codenrock.com разворачивается демо-проект с готовым контентом и результатами: платформу можно пощупать до любой настройки, а Launch Center проведёт по чек-листу запуска. Дальше — маршрут на одну неделю.

1. Возьмите одну реальную роль, по которой сейчас нанимаете или оцениваете.
2. Соберите профиль из 5–7 компетенций: AI предложит, вы вычеркнете лишнее.
3. Сгенерируйте банк вопросов — лучше на своих регламентах, загрузив их в базу знаний.
4. Прогоните тест на двух-трёх сотрудниках, чей уровень знаете, и сравните профили со своим мнением об этих людях.
5. Положите рядом две цифры: часы вашего эксперта на валидацию — и недели методолога или счёт провайдера, как это устроено сейчас.

Первые кандидаты — на бесплатном Hire, внутренний контур — на 14-дневном trial Talent; привязывать карту не нужно ни там, ни там.

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

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

Если вы строите агентную систему, вы проектируете точки подключения: к каким частям инфраструктуры агент может обращаться, какие действия выполнять, в каких границах и с какими ограничениями. MCP (Model Context Protocol) — это контракт между инструментом и агентами, через который они читают данные, запускают проверки, анализируют артефакты и возвращают результат в понятной форме.В этой статье мы разберём, как спроектировать собственный MCP-сервер: определить его ответственность, обеспечить воспроизводимость и полноценно встроить его в цикл разработки. 

По теме: как агентный пайплайн Codenrock Vibe проверяет код разработчиков — реальный кейс

Как устроен MCP в инженерной архитектуре

MCP добавляет в агентную систему отдельный инфраструктурный слой для формализованного доступа к инструментам. Архитектурно в нём три роли:

• MCP-сервер — реализует конкретные инструменты и экспонирует контракт: что агенту разрешено делать, с какими параметрами и в каких границах.
• MCP-клиент — агент или среда (IDE, CLI, Dev Tools), которая вызывает инструменты.
• Транспорт — механизм обмена сообщениями между ними.

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

• анализируют CI-лог и выделяют вероятную причину падения;
• собирают release notes из git-истории;
• проверяют Dockerfile на анти-паттерны;
• ищут техдолг в репозитории.

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

Сущности MCP-сервера, которые важно спроектировать

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

Resources — данные, к которым агент получает доступ. Инженер должен определить разрешённые источники, допустимые пути и ограничения по объёму и типу данных.

Prompts — шаблоны или инструкции, встроенные в сервер. В контексте Dev-to-Dev они полезны для стандартизации операций: например, анализа логов или генерации отчётов.

Пример: автоматизация повседневной рутины 

Представим типичную ситуацию: CI-пайплайн упал. Лог содержит тысячи строк, и нужно быстро понять, где именно произошёл сбой и что стало причиной. Эту задачу можно поручить агенту. Но прежде чем он сможет помочь, инженер должен формализовать операцию — вынести её в MCP-сервер. Именно отсюда начинаются архитектурные решения.

При проектировании такого сервера нужно учесть 5 основных моментов. 

Границы ответственности

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

Хороший подход начинается с декомпозиции задачи:

1. Определить конкретный вход — например, файл CI-лога.
2. Зафиксировать операцию — извлечение структурированных сведений о сбое.
3. Ограничить область анализа — только содержимое переданного лога, без обхода всего репозитория.

В этом случае сервер не заменяет модель, а подготавливает для неё данные.

Формат результата

Агент работает лучше, когда получает не свободный текст, а формализованный ответ. Допустим, сервер проанализировал лог. Если сервер возвращает что-то в духе «похоже, ошибка связана с зависимостями», агенту сложно принимать дальнейшие решения. Это субъективная интерпретация. 

Инженер должен задать структуру результата. Для этого потребуется определить, какие поля реально нужны агенту, зафиксировать их формат, обеспечить стабильность структуры ответа. После этого агент сможет сопоставить ошибку с последним коммитом, проверить, менялись ли зависимости и сформировать объяснение.

Пример удачной структуры ответа, который поможет правильно интерпретировать результат: 

• этап пайплайна;
• команда, завершившаяся с ошибкой;
• код возврата;
• фрагмент сообщения об ошибке;
• предполагаемая категория (если она выводится по формальным правилам).

Проектируя MCP-сервер, важно думать о том, как с его результатом будет работать другой агент, а не человек. 

Детерминированность

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

Проектируя сервер, инженер должен:

1. Использовать формальные правила анализа.
2. Исключить случайность.
3. Зафиксировать версии библиотек.
4. Ограничить объём входного файла.
5. Учитывать лимиты контейнера (CPU, RAM).

Это особенно важно в Dev-to-Dev, где сервер тестируют другие участники. Такой подход поможет избегать скрытой случайности, ограничивать объём входных данных и учитывать лимиты по CPU и памяти.

Ограничения доступа

CI-лог — лишь один файл. Но сервер может быть запущен внутри контейнера проекта. Инженер должен решить:

• может ли инструмент читать любые файлы?
• может ли он выполнять системные команды?
• допустим ли доступ к сети?

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

Грамотный подход:

1. Ограничить директорию, в которой сервер может работать.
2. Запретить произвольное выполнение shell-команд.
3. Ввести ограничения по размеру входных данных.
4. Установить таймаут выполнения.

Такой сервер будет безопасен, воспроизводим и понятен для ревью.

Тестируемость без модели

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

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

• Берём конкретный файл CI-лога с известной ошибкой.
• Передаём его серверу.
• Проверяем, что сервер возвращает корректно определённый этап, правильный код, фрагмент ошибки и ожидаемую классификацию, если она предусмотрена.

Таким образом мы проверим, что инструмент корректно анализирует лог, правильно выделяет ошибку и стабильно формирует структуру ответа.

Агент — вероятностный компонент. MCP-сервер — детерминированный. Если его можно протестировать независимо от модели, значит, инструмент можно безопасно включать в цепочку автоматических действий. 

Мини-чеклист: как спроектировать MCP-сервер за вечер

1. Сформулировать одну операцию в формате «глагол + объект», например: «извлечь причину падения из CI-лога».
2. Зафиксировать входной артефакт: файл, путь или ресурс.
3. Описать схему ответа и минимально необходимые поля.
4. Установить границы доступа: директория, сеть, команды.
5. Добавить лимиты: размер входа, таймаут, CPU/RAM.
6. Сделать детерминированную обработку без LLM внутри инструмента.
7. Подготовить 2–3 эталонных лога для тестов.
8. Добавить smoke-проверку: один запуск → ожидаемая структура ответа.
9. Документировать контракт: что делает инструмент, что не делает, какие ошибки возвращает.

Когда MCP-сервер начинает ломать систему

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

Агент компенсирует архитектуру. Если сервер возвращает неструктурированный результат или работает слишком широко, агент вынужден компенсировать архитектурные пробелы. Он повторно интерпретирует текст, угадывает структуру и усложняет промпты. Система начинает зависеть от поведения конкретной модели: небольшое изменение контекста или версии может нарушить логику всей цепочки.

Что делать:

• Сузить ответственность инструмента до одной операции.
• Возвращать структурированные данные вместо текста.
• Явно фиксировать схему входа и выхода.
• Убрать из сервера логику, которую должна выполнять модель.

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

Что делать:

• Ограничить область доступа к данным.
• Исключить скрытые побочные действия.
• Логировать входные параметры и ключевые этапы обработки.
• Документировать контракт инструмента.

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

Что делать:

• Зафиксировать версии зависимостей.
• Ограничить влияние внешней среды.
• Проверять инструмент на одинаковых входных данных.
• Добавить отдельный сценарий smoke-проверки.

Модель становится «клеем». Когда архитектура сервера продумана слабо, модель начинает компенсировать её недостатки: нормализует данные, исправляет формат, сглаживает ошибки, пытаясь удержать систему. Но поскольку модель — вероятностный компонент, устойчивость всей конструкции снижается.

Что делать:

• Чётко разделить зоны ответственности сервера и агента.
• Убрать из сервера вероятностную логику.
• Делать формат ответа строгим и предсказуемым.
• Проектировать инструменты так, чтобы модель использовала их, а не исправляла.

Ограничения MCP-сервера: что ему не стоит поручать

MCP-сервер — инфраструктурный компонент. Он необходим, чтобы формализовать операции и обеспечить предсказуемый доступ к инструментам. Главный принцип:

• MCP-сервер отвечает за операции.
• Агент отвечает за интерпретацию.
• Оркестрация отвечает за стратегию.

Если эти роли смешиваются, система становится сложнее, а не умнее. Есть классы задач, которые лучше оставить на уровне агента или оркестрации:

1. Стратегические решения. Сервер не должен принимать решения о том, что делать дальше. Например, инструмент может вернуть сведения о сбое в CI, но решение — откатить релиз, создать задачу или инициировать повторную сборку — принимает агент или человек.
2. Вероятностный анализ и интерпретация. MCP-серверу не следует поручать задачи, требующие гибкой интерпретации контекста. Инструмент может подготовить данные, но не должен подменять собой LLM.
3. Комплексная оркестрация. Сервер не управляет цепочками инструментов и не координирует работу нескольких агентов. Если инструмент вызывает другие инструменты и запускает последовательности действий, он превращается в скрытый оркестратор.

Как настроить MCP-сервер: шпаргалка по SDK

Независимо от языка, сервер состоит из трёх частей:

1. Инициализация сервера.
2. Объявление инструментов.
3. Запуск транспортного слоя.

На примере Python это выглядит предельно просто:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("demo")


@mcp.tool()
def my_tool(input: str) -> dict:
    """Описание инструмента"""
    # логика обработки
    return {"result": "..."}


if __name__ == "__main__":
    mcp.run(transport="stdio")

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

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

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

MCP-сервера на хакатоне

Dev-to-Dev: Agentic Engineering Challenge — это хакатон про инженерную инфраструктуру для агентов. Участникам предстоит спроектировать и реализовать собственный MCP-сервер, который решает рутинную задачу разработчика. Решение оценят другие участники и эксперты Codenrock. 

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