Представьте типичный тест на 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-сервер — это нотация, по которой играет система. И именно её предстоит спроектировать на хакатоне. 

AI-агенты уже пишут продакшен-код. Инструменты вроде Claude Code, Cursor и Windsurf используются в реальных проектах, генерируя тысячи строк, которые проходят ревью и деплоятся в прод. Но между «попросить модель написать функцию» и «выстроить процесс, в котором AI стабильно генерирует качественный код» — пропасть.

По теме: кейс: агентная система Codenrock Vibe оценила Python-разработчиков — совпадение с экспертами 29 из 30

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

В этой статье — конкретные техники и рекомендации: от промптинга до мульти-агентных пайплайнов. Принципы универсальны. CLAUDE.md — для Claude Code, .cursorrules — для Cursor, .github/copilot-instructions.md — для Copilot. Выбирайте среду под свои задачи.

Статья выходит в преддверии хакатона Dev-to-Dev: Agentic Engineering Challenge (26 февраля — 1 марта, онлайн) — как раз тот формат, где все эти подходы можно обкатать на практике.

1. Промпт-инженерия: шесть приёмов, которые реально работают при генерации кода

Промпт — это не пожелание. Это спецификация. Чем меньше модель додумывает — тем предсказуемее результат.

1.1. Контекст-фрейм: начни с ограничений, а не с задачи

Модель не знает ваш проект. Первые строки промпта — это рамка.

Плохо: «Напиши функцию валидации формы».

Хорошо: «Проект: Next.js 15, TypeScript strict, Zod, Prisma + PostgreSQL. Не используй any. Не добавляй зависимости. Напиши Zod-схему регистрации: email, пароль (мин. 8, 1 цифра, 1 спецсимвол), подтверждение пароля».

Один абзац контекста экономит три итерации переписывания.

1.2. Пример входа-выхода вместо описания словами

Плохо: «Функция проверки email, возвращает объект с результатом и причиной».

Хорошо: покажите конкретные примеры. user@domain.com → valid: true. test@ → valid: false, причина: нет домена. Пустая строка → valid: false, причина: пустой ввод.

Два-три примера задают формат точнее, чем абзац требований. Модель копирует паттерн, а не интерпретирует описание.

1.3. Negative prompting: скажите, чего НЕ делать

«Рефакторни processOrder. НЕ меняй сигнатуру. НЕ добавляй зависимости. НЕ трогай /src/core/. Сохрани совместимость с тестами».

Каждое «не» сужает пространство решений. Без ограничений модель может переписать полпроекта, «улучшая» то, что трогать не надо.

1.4. Chunking: одна задача — один промпт

Плохо: «Напиши CRUD API с авторизацией, валидацией и тестами».

Хорошо: разбейте на шаги. Сначала типы данных (User, CreateUserInput), потом сервисы (createUser, getUser), потом обработку ошибок, потом API-роуты. Каждый шаг — отдельный промпт. Ревьюите результат, двигаетесь дальше.

Chunking решает фундаментальную проблему: при большом объёме задачи модель теряет фокус и начинает «срезать углы» — упрощает типы, забывает edge cases, генерирует шаблонный код.

1.5. Spec-first: контракт до реализации

Не просите «напиши API». Опишите, как оно выглядит снаружи: POST /api/orders, тело запроса (productId, quantity, coupon), варианты ответов — 201 Created, 400 невалидное количество, 404 товар не найден, 409 нет в наличии, авторизация через JWT.

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

1.6. Привязка к реальности: запрет галлюцинаций

Модели выдумывают методы и пакеты, которых не существует. Решение — дать фрагмент реальной схемы или документации прямо в промпте: «Prisma. Используй ТОЛЬКО findUnique/findFirst/findMany для чтения, create/update/upsert/delete для записи. НЕ используй raw SQL. Если не уверен в методе — спроси». И приложите кусок Prisma-схемы.

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

Все шесть приёмов сводятся к одному принципу: промпт — это спецификация, а не пожелание.

2. CLAUDE.md: онбординг-документ для AI-агента

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

Что это такое

CLAUDE.md — это не документация и не README. Это онбординг для AI-агента. Точно так же, как вы вводите нового разработчика в проект — объясняете архитектуру, показываете паттерны, предупреждаете о граблях — вы делаете это для модели. Один раз. Дальше агент читает этот файл перед каждой задачей и работает в рамках ваших правил.

Claude Code автоматически загружает CLAUDE.md при старте сессии. Cursor использует аналогичный механизм через .cursorrules, Windsurf — .windsurfrules. Принцип одинаковый, формат файла отличается.

Структура из пяти секций

Проект — краткое описание, стек, архитектура. Одним абзацем: «SaaS-платформа. Next.js 15, Prisma, PostgreSQL, мультисхемная архитектура».

Структура директорий — где что лежит. src/app/api/ — роуты, src/models/ — схемы, src/components/ — компоненты. Агент должен знать, куда класть новый файл.

Паттерны кода — один-два примера типичного эндпоинта или компонента. Не описание, а реальный фрагмент. Модель копирует стиль из примера.

Правила — что делать всегда: async/await вместо промисов, валидация через Zod, формат ошибок, согласование новых зависимостей.

Запрещено — что не делать никогда: any в TypeScript, console.log в продакшене, прямые SQL-запросы, изменение ядра без явного указания.

Три ошибки, которые убивают эффективность

Слишком длинный. Больше 1000 строк сложно поддерживать в актуальном состоянии. Чем больше правил — тем чаще они противоречат друг другу, и модель начинает выбирать между конфликтующими инструкциями. Держите документ компактным.

Слишком абстрактный. «Пиши чистый код» — бесполезно. «Каждый API-эндпоинт возвращает { data, error, meta } — вот пример» — работает. Без реальных фрагментов кода CLAUDE.md превращается в корпоративную миссию на стене.

Устаревший. Переименовали директорию, сменили ORM, обновили фреймворк — а CLAUDE.md описывает прошлую архитектуру. Агент будет генерировать код для проекта, которого больше нет.

Практический совет

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

3. Model Context Protocol: как устроен мост между агентом и реальным миром

Промпт и CLAUDE.md дают агенту знания о проекте. Но чтобы агент мог действовать — создавать задачи, отправлять письма, запрашивать данные из базы — ему нужен протокол взаимодействия с внешним миром. Это Model Context Protocol (MCP).

Архитектура: три роли

Host — приложение, в котором живёт агент: Claude Code, Cursor, Windsurf. Client — компонент внутри хоста, который держит соединение с конкретным сервером. Server — отдельный процесс, предоставляющий возможности: доступ к файлам, базам данных, API-сервисам.

Один Host содержит несколько Client, каждый Client подключён к одному Server. Host видит инструменты всех серверов и сам решает, какой вызвать.

Три примитива

Tools — функции, которые агент вызывает: создать задачу, выполнить SQL-запрос, отправить письмо. Это основной примитив; 90% серверов используют только tools.

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

Prompts — шаблоны для типовых сценариев. Используются реже, но полезны для стандартизации повторяющихся задач.

Транспорт и протокол

Два варианта транспорта. stdio — для локальных серверов: хост запускает процесс и общается через stdin/stdout. Просто, быстро, без сети. Streamable HTTP — для удалённых серверов: HTTP-запросы + стриминг через Server-Sent Events. Подходит для облачных деплоев. (Streamable HTTP заменил устаревший SSE-транспорт — в старых туториалах можно встретить SSE, но новые серверы пишут на Streamable HTTP.)

Под капотом — JSON-RPC 2.0. Каждый вызов инструмента — пара запрос/ответ. Всё типизировано через JSON Schema — модель точно знает, какие аргументы передать.

Как агент выбирает инструмент

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

Описание «работает с данными» бесполезно. Описание «Возвращает список открытых задач проекта. Принимает статус фильтрации. Если задач нет — пустой массив» — работает. Плохое описание = tool не будет вызван, даже если он делает именно то, что нужно.

Практика: строим MCP-сервер за 5 шагов

Шаг 1. Инициализация. npx @modelcontextprotocol/create-server todo-server — готовая структура проекта: index.ts, tsconfig, зависимости.

Шаг 2. Tools. У каждого tool четыре составляющих: имя (add_todo), описание на естественном языке, схема параметров через Zod и обработчик — async-функция. Критически важно: у каждого параметра .describe(). Агент читает именно эти описания.

Шаг 3. Resources. Текущее состояние данных в JSON — чтение без побочных эффектов.

Шаг 4. Подключение. В .mcp.json добавляете сервер: имя и команду запуска. Перезапуск IDE — агент видит tools.

Шаг 5. Отладка. npx @modelcontextprotocol/inspector — визуальный клиент, показывающий то, что видит агент: список tools, параметры, описания. Можно вызвать любой tool вручную.

Три грабли

Абстрактные описания. «Работает с задачами» — агент не поймёт. «Добавляет задачу в TODO-список. Принимает название и приоритет. Возвращает ID» — поймёт сразу.

Нет error handling. Когда tool падает с необработанным исключением, агент получает stack trace и пытается его «починить» — обычно делая хуже. Оборачивайте в try/catch и возвращайте понятное сообщение.

Переусложнённые параметры. Tool с 10 обязательными полями — лабиринт. Агент запутается и начнёт галлюцинировать значения. Лучше пять простых tools, чем один универсальный.

Экосистема

MCP отвязывает инструмент от модели. Написали сервер один раз — он работает с Claude, GPT, Gemini, с любой моделью, поддерживающей протокол. Каталог готовых серверов: github.com/modelcontextprotocol/servers. Спецификация: spec.modelcontextprotocol.io.

4. Git Worktrees: параллельная работа с AI без конфликтов

Одна из неочевидных проблем AI-разработки: агент занят долгой задачей в одной ветке, а вам нужно параллельно делать что-то в другой. Переключать ветки нельзя — агент работает с файлами. Клонировать репозиторий заново — долго и неудобно. Решение — git worktrees.

Что это такое

Git worktree — это дополнительная рабочая копия того же репозитория, привязанная к другой ветке. Один .git, несколько директорий с кодом. Каждая может быть открыта в своей сессии AI-агента одновременно.

Зачем это AI-разработчику

Параллельные сессии. Агент пишет фичу в feature/auth — вы открываете вторую сессию Claude Code в worktree на feature/api и работаете одновременно. Никаких конфликтов, никаких git stash.

Изолированные эксперименты. Хотите попробовать радикальный рефакторинг? Создайте worktree, дайте агенту задачу. Если результат не понравился — просто удалите директорию. Основная ветка не тронута.

Code review. Нужно проверить чужой PR? Worktree на ветку PR — и агент ревьюит код, пока ваша основная работа не прерывается.

Как использовать

Создать worktree:

git worktree add ../my-project-feature feature/new-api

Теперь в ../my-project-feature — полная копия проекта на ветке feature/new-api. Открываете там отдельную сессию Claude Code — и работаете параллельно с основной.

Список всех worktrees:

git worktree list

Удалить, когда больше не нужен:

git worktree remove ../my-project-feature

Worktrees в Claude Code

В Claude Code есть встроенная поддержка worktrees. При запуске подзадач через Task tool можно указать isolation: "worktree" — агент автоматически создаст временный worktree, выполнит задачу в изолированной копии репозитория, и вернёт результат. Если изменения не нужны — worktree удалится сам. Если нужны — вы получите путь и ветку для мёрджа.

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

Практический паттерн

Типичная структура для AI-разработки:

~/projects/
├── my-app/              # основная ветка (main)
├── my-app-feature-auth/ # worktree: feature/auth (сессия агента 1)
├── my-app-feature-api/  # worktree: feature/api (сессия агента 2)
└── my-app-hotfix/       # worktree: hotfix/urgent (ручная работа)

Все четыре директории — один репозиторий, один .git. Коммиты видны везде. Ветки мёрджатся как обычно.

5. Паттерны ошибок AI-генерируемого кода

Код компилируется, линтер молчит, тесты зелёные. А потом — метод, которого не существует, пакет-призрак из npm и SQL-инъекция в единственном эндпоинте. AI-генерация порождает не больше багов, чем ручной код, но паттерны другие. Знание паттернов — половина решения.

5.1. Галлюцинации API

Модель уверенно вызывает метод, которого нет в библиотеке. Классика из Prisma: AI пишет prisma.user.findByEmail("test@example.com") — выглядит логично, но такого метода не существует. Правильно — findUnique с параметром where: { email }. Модель «помнит» паттерны из тысяч ORM и микширует их.

Strict TypeScript ловит это на этапе компиляции. Без строгих типов — уедет в прод.

5.2. Устаревший синтаксис

AI обучен на миллионах репозиториев, значительная часть — legacy. componentDidMount вместо useEffect. var вместо const/let. new Buffer() вместо Buffer.from(). В открытых репозиториях deprecated-кода накоплено за десятилетия, и модели неизбежно на нём обучаются.

Лечение — явно указать в CLAUDE.md: «React только хуки. Node.js >= 20. Не используй deprecated API».

5.3. Security-дыры

Модель не различает trusted и untrusted input. Типичный случай: AI подставляет пользовательский ввод прямо в SQL-строку — классическая SQL-инъекция. Правильно — параметризованные запросы.

То же с XSS (innerHTML = userInput), path traversal (fs.readFile(userInput)), command injection (exec(userInput)). AI оптимизирует на «работает», а не на «безопасно». Безопасность — отдельная задача, которую нужно явно ставить.

5.4. Happy path only

AI отлично пишет основной сценарий, но систематически забывает: null / undefined — что если пользователь не найден? Пустой массив — items[0].name упадёт с TypeError. Сетевые таймауты — fetch без AbortController и таймаута может висеть минутами, блокируя ресурсы. Race conditions — два запроса обновляют один ресурс.

Модель пишет код для идеального мира. Пользователи живут в неидеальном.

5.5. Phantom dependencies

AI импортирует пакет, которого нет в npm. Например, json-schema-validator-pro — название правдоподобно, но пакет не существует. AI его выдумал.

Это не просто ошибка сборки. Исследования показывают, что AI-модели стабильно генерируют одни и те же несуществующие имена пакетов. Атакующие регистрируют такие имена и заливают вредоносный код — dependency confusion на AI-галлюцинациях. Каждый незнакомый import — npm info перед установкой.

Как ловить систематически

• Strict TypeScript + ESLint — ловит галлюцинации API и deprecated-паттерны на этапе компиляции. Первая линия обороны, бесплатная.
• AI vs AI — один агент пишет, другой ревьюит с промптом «найди уязвимости и edge cases». Но важно: тесты — отдельным запросом, по спецификации, а не по коду. Если AI неверно понял задачу — и код, и тесты, написанные вместе, будут «согласованно» неправильными.
• npm audit + npm info — проверка зависимостей на существование и уязвимости.
• CLAUDE.md с запрещёнными паттернами — явный список «не делай так» снижает повторение ошибок на порядок.

6. Мульти-агентные воркфлоу: разделяй и властвуй

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

Чем уже задача — тем точнее результат. Мульти-агентный воркфлоу — это когда несколько агентов с разными ролями и контекстами решают одну задачу.

Паттерн 1: Pipeline (конвейер)

Architect → Coder → Reviewer → Tester. Каждый агент получает результат предыдущего. Architect создаёт спецификацию и интерфейсы. Coder реализует строго по спецификации. Reviewer ищет баги и security-проблемы. Tester пишет тесты.

Ключевое: каждый видит только свой кусок контекста. Изолированный контекст заставляет агента работать строго в своей роли.

Паттерн 2: Router + Specialists (маршрутизатор)

Router → [DB Agent | API Agent | UI Agent | DevOps Agent]. Router анализирует задачу и направляет к специалисту. «Добавь индекс в таблицу» — к DB Agent. «Сверстай форму» — к UI Agent. Каждый имеет свой системный промпт с узким контекстом: DB Agent знает схему базы, UI Agent — дизайн-систему. Когда задача затрагивает несколько областей — Router декомпозирует и отправляет подзадачи параллельно.

Паттерн 3: Adversarial (состязательный)

Generator Critic → итоговый результат. Generator пишет код. Critic ломает: edge cases, невалидные входы, race conditions. Generator исправляет. Цикл повторяется, пока Critic не примет.

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

Реализация

В Claude Code мульти-агентность реализуется через Task tool — запуск подзадачи в чистом контексте. Подагент не видит историю основного разговора, а только то, что ему передали. Это и есть изоляция: подагент-тестировщик не знает, что «хотел» кодер, и тестирует непредвзято. Агенты обмениваются через файлы: Architect пишет spec.md, Coder читает spec.md и пишет код, Tester читает код и пишет тесты. Никакого общего контекста — только артефакты.

В сочетании с git worktrees это особенно мощно: каждый агент работает в изолированной копии репозитория, изменения мёрджатся только после ревью.

Когда это оверинжиниринг

Правило: если задача декомпозируется на роли — используйте мульти-агентный воркфлоу. Если нет — одного агента достаточно. Конвейер из четырёх агентов для функции на 10 строк — пустая трата контекста и времени.

Заключение

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

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

1. Промпт-инженерия — контекст, примеры, ограничения, спецификация. Перестать давать абстрактные задачи.
2. CLAUDE.md — 50 строк онбординга для агента. Расширять по мере обнаружения ошибок.
3. MCP — подключить готовые серверы для инструментов, которыми пользуетесь. Попробовать написать свой.
4. Git worktrees — параллельная работа нескольких агентов над одним проектом без конфликтов.
5. Защита от ошибок — strict TypeScript, тесты отдельно от кода, явные запреты.
6. Мульти-агентные воркфлоу — для задач, которые декомпозируются на роли.

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

Все эти подходы можно попробовать на практике на хакатоне Dev-to-Dev: Agentic Engineering Challenge — 26 февраля — 1 марта, онлайн, бесплатно. Как раз тот формат, где агентная инженерия проверяется делом.

4 февраля 2026 года Андрей Карпатый — сооснователь OpenAI и автор термина «вайб-кодинг» — написал в X пост к годовщине своего прошлогоднего твита. Среди прочего он предложил новый термин для того, как выглядит работа разработчика сегодня.

Agentic — потому что теперь по умолчанию ты 99% времени не пишешь код напрямую. Ты оркестрируешь агентов, которые пишут его, а сам осуществляешь контроль. Engineering — чтобы подчеркнуть, что в этом есть и искусство, и наука, и профессиональная экспертиза. Этому можно учиться и со временем становиться лучше — у этой практики своя, особая глубина.

Андрей Карпатый, сооснователь OpenAI

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

Именно вокруг этой идеи мы построили концепцию хакатона Dev-to-Dev: Agentic Engineering Challenge.

Почему не вайб-кодинг

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

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

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

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

Агенты на каждом этапе: что уже работает

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

Анализ и исследование

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

Anthropic встроила этот подход в исследовательский модуль Claude. Ведущий агент координирует процесс и делегирует подзадачи специализированным субагентам, которые работают параллельно: один анализирует документацию, другой ищет аналоги в open-source, третий проверяет баг-трекер. Результат — структурированный отчёт с контекстом, а не набор ссылок.

Что делают агенты:

• Анализируют существующий код, документацию и историю задач.
• Исследуют аналогичные решения, сравнивают подходы.
• Формируют отчёт о технических рисках, зависимостях и ограничениях.
• Собирают требования из разрозненных источников: чатов, тикетов, документов.

Проектирование и архитектура

Агенты не заменяют архитектора. Они позволяют быстрее перебрать варианты, оценить их по заданным критериям и зафиксировать обоснование решения.

Дэйв Норрис, Developer Advocate в Salesforce с 30+ сертификациями и статусом Certified Technical Architect, описал свой подход: инженер формулирует требования и ограничения, а модель генерирует варианты решений, сравнивает их по критериям (производительность, масштабируемость, стоимость поддержки) и формирует структурированный документ с обоснованием. Финальное решение остаётся за человеком — AI ускоряет исследование вариантов, но не снимает ответственности.

Что делают агенты:

• Генерируют варианты архитектуры на основе требований и ограничений.
• Проводят анализ совместимости с существующей системой.
• Создают диаграммы взаимодействия компонентов и потоков данных.
• Оценивают каждый вариант по заданным критериям.
• Формируют спецификации для передачи на этап разработки.

Разработка

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

Борис Черный, руководитель направления Claude Code в Anthropic, рассказал, что его команда создала Cowork — инструмент для автоматизации рабочих задач — примерно за полторы недели. Практически весь код написан AI-агентами. Основное время инженеров ушло на формулировку требований, архитектурные ограничения и ревью. Черный отмечает, что уже более двух месяцев не пишет код вручную, параллельно управляя 5–10 агентами.

Это впечатляющий результат, но стоит учитывать контекст: команда Anthropic работает с собственными моделями и инструментами, имеет глубокую экспертизу в промпт-инженерии, и Cowork — относительно ограниченный по скоупу продукт. Экстраполировать этот опыт на произвольный enterprise-проект напрямую нельзя.

Что делают агенты:

• Генерируют код по спецификациям с сохранением контекста проекта.
• Проверяют собственный код на типичные ошибки, уязвимости и несоответствия.
• Следуют code style, архитектурным паттернам и конвенциям.
• Создают документацию параллельно с кодом.
• Декомпозируют задачи и координируют работу между несколькими агентами.

Тестирование и контроль качества

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

Команда DriveOS в NVIDIA разработала агентную платформу Hephaestus (HEPH) для автоматической генерации тестов. Система анализирует документацию и примеры кода с помощью LLM, затем генерирует тесты, компилирует, запускает и анализирует покрытие, используя результаты для уточнения следующих итераций. В пилотных проектах команды-участники сэкономили до 10 недель работы — хотя это верхняя граница для конкретных пилотов, а не средний показатель.

Что делают агенты:

• Генерируют тест-кейсы на основе спецификаций, в том числе негативные сценарии.
• Запускают тесты, анализируют результаты и предлагают исправления.
• Проводят аудит безопасности: ищут уязвимости и небезопасные паттерны.
• Профилируют производительность и выявляют узкие места.

Публикация и деплой

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

Postman, платформа для работы с API, демонстрирует подход, при котором агент встроен в релизный контур: при изменении OpenAPI-спецификации в pull request запускается автоматическая генерация тестов безопасности, результаты добавляются к PR. Postman также предоставляет MCP-сервер, через который AI-агенты могут управлять коллекциями, запускать тесты и работать с окружениями через естественный язык.

Что делают агенты:

• Формируют changelog и release notes из истории задач.
• Запускают и контролируют этапы CI/CD.
• Проводят поэтапный релиз и инициируют откат при аномалиях.
• Обновляют документацию, API-спецификации и миграционные инструкции.
• Уведомляют команду о статусе релиза.

Мониторинг и реагирование

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

В Microsoft Research разработана система TRIANGLE — мультиагентная платформа для триажа (классификации и маршрутизации) инцидентов. При появлении инцидента один агент анализирует описание и сопоставляет с историческими данными, затем несколько специализированных агентов обмениваются аргументами и определяют ответственную команду. Система обрабатывает ~600 млн логов в день и улучшает точность триажа более чем на 20% по сравнению с предыдущими методами.

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

Что делают агенты на этом этапе:

• Классифицируют инциденты и маршрутизируют к ответственным командам.
• Сопоставляют сбои с конкретными релизами и изменениями в коде.
• Обнаруживают аномалии и признаки деградации.
• Анализируют влияние релизов на продуктовые метрики.

Техническая поддержка и обратная связь

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

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

Прецеденты: агентный подход до Карпатого

Хотя термин «агентная инженерия» появился в феврале 2026, сам подход развивался раньше. В апреле 2025 года IT_ONE совместно с SK FinTech Hub провели IT_ONE Cup. ML Challenge на платформе Codenrock. Один из треков — разработка AI-системы, которая восстанавливает структуру UI из готовых веб-приложений без исходников и вносит изменения на основе текстовых описаний.

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

MCP: инфраструктура для агентов

Model Context Protocol (MCP) — открытый стандарт от Anthropic, который позволяет AI-агентам подключаться к внешним инструментам, базам данных, API и сервисам через единый интерфейс. Если агенты — это операторы, то MCP-серверы — точки подключения к реальному миру.

MCP быстро стал де-факто стандартом: Microsoft встроила поддержку в Visual Studio 2026, SDK доступны на всех основных языках, а количество активных MCP-серверов в индустрии исчисляется тысячами.

Хороший пример системного внедрения — Shopify. По словам Фархана Тавара, вице-президента и руководителя инженерного департамента компании (1000+ инженеров), Shopify создала около дюжины MCP-серверов для внутренних систем: Slack, G Suite, Salesforce и других. Стратегия — «MCP everything»: сделать каждый внутренний источник данных доступным для агентов через единый протокол.

Что делает MCP-сервер хорошим:

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

Ограничения и что стоит учитывать

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

• Галлюцинации. LLM генерируют правдоподобный, но некорректный код. Без тестов и ревью агентная система — генератор технического долга.
• Стоимость. Каждый вызов агента — это API-запрос. При масштабировании затраты растут быстро, особенно при мультиагентных пайплайнах с итерациями.
• Безопасность. Агент с доступом к продакшен-данным, деплою и внутренним API — это поверхность атаки. Принцип наименьших привилегий обязателен.
• Зависимость от моделей. Смена провайдера или деградация модели может сломать весь пайплайн. Нужны абстракции и фоллбэки.
• Потеря экспертизы. Если команда перестаёт читать и понимать код, который генерируют агенты, она теряет способность отлаживать и развивать систему.

Эти ограничения не отменяют ценности подхода — но определяют границы его применимости.

Задача хакатона: MCP-сервер для разработчиков

На Dev-to-Dev: Agentic Engineering Challenge участники создадут MCP-сервер с полезными инструментами для разработчиков. Формат Dev-to-Dev означает: вы решаете свою собственную боль — рутину, переключения между инструментами, повторяющиеся действия, которые давно просят автоматизации.

Примеры направлений:

• Инспектор зависимостей и лицензий.
• Парсер CI-логов с диагностикой ошибок.
• Поисковик TODO/FIXME и техдолга с приоритизацией.
• Генератор release notes из git-лога.
• Анализатор покрытия тестами с рекомендациями.
• Аудитор Dockerfile и docker-compose конфигураций.

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

Рекомендуемый подход

Этап 1: исследование. Определите конкретную рутинную задачу, которую решаете. Изучите существующие MCP-серверы и решения в этой области. Сформулируйте ценностное предложение: что делает ваш сервер, для кого, какой эффект даёт.

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

Этап 3: разработка. Используйте AI-агентов для генерации кода — но по вашей спецификации. Контролируйте, тестируйте, корректируйте. Документация — параллельно с кодом, не после.

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

Победители получат памятные награды, а их проекты — поддержку и медийность от платформы Codenrock.

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

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

Освоить её можно только на практике. Dev-to-Dev — хорошая точка входа.

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

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

Мы продемонстрируем их возможности на примере E-CUP 2025 — масштабного соревнования от Ozon Tech, охватывающего основные направления прикладного машинного обучения в трех треках:

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

Рекомендательные системы

Пример формулировки. Задача первого трека E-CUP 2025 — помочь миллионам покупателей экономить время на поиске и получать идеальные вещи первыми. Участникам необходимо разработать рекомендательную систему, которая предскажет, какой товар пользователь купит следующим в категории apparel (одежда, обувь, аксессуары), и сформировать персональный топ рекомендаций.

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

Особенности задачи

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

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

Работа с данными: с чего начинается рекомендация

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

• Pandas — классический инструмент для анализа и обработки табличных данных. Отлично подойдёт, если объём данных не выходит за рамки пары миллионов строк. Удобен для быстрой отладки, фильтрации, агрегаций и первых экспериментов.
• Polars — современная альтернатива Pandas, написанная на Rust. Обеспечивает более высокую производительность, особенно при работе с большими таблицами, множеством join’ов и агрегаций. Удобный инструмент для ноутбуков и скриптов, где важна скорость.
• PySpark — если данных действительно много и требуется распределённая обработка. Полезен, если в соревновании данные объёмные и уже представлены в Spark-формате, либо нужно работать с несколькими источниками. Хорошо масштабируется и поддерживается в промышленной среде.

Совет: начните с Pandas или Polars для исследования и первых итераций. Если данные слишком велики или появляется узкое место в обработке — переходите на PySpark.

Выбор технологий

Рекомендательные системы традиционно опираются на два подхода к фильтрации: 

• Коллаборативный — учёт предпочтений пользователей.
• Контентный — учёт свойств объектов. 

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

• LensKit — лёгкая в использовании библиотека с реализацией самых распространённых алгоритмов. Подходит для быстрого старта и получения первых результатов, особенно новичкам.
• Surprise (scikit-surprise) — популярный Python-пакет для коллаборативной фильтрации. Поддерживает готовые реализации матричных разложений для обнаружения скрытых предпочтений, kNN для поиска похожих пользователей или товаров, а также другие алгоритмы.

Если вы хотите выйти за рамки базовых методов и попробовать более продвинутые подходы к рекомендательным системам, в open-source среде есть мощные фреймворки для опытных ML-специалистов.

RecBole — универсальный фреймворк на Python/PyTorch, включающий более 100 моделей для разных типов рекомендаций:

• классические (matrix factorization),
• последовательные (например, GRU4Rec, SASRec),
• учитывающие контекст (время, категорию, устройство и др.).

Microsoft Recommenders — набор примеров и библиотек для построения рекомендательных систем, изначально разработанный Microsoft, а теперь развиваемый как проект Linux Foundation. Включает готовые ноутбуки с реализациями коллаборативной фильтрации, глубоких моделей и гибридных подходов. 

TorchRec — библиотека от PyTorch/Meta, ориентированная на масштабные рекомендательные системы. Поддерживает работу с разреженными признаками (sparse features), характерными для товарных и пользовательских данных, и включает инструменты для распределённого обучения — т.е. возможность обучать модель сразу на нескольких GPU/серверов.

Совет: если вы планируете работать с масштабными рекомендательными моделями, ориентированными на продакшн, стоит обратить внимание на стэк PyTorch + TorchRec. Он позволяет строить масштабируемые двухбашенные архитектуры  — пользователь и товар обрабатываются отдельными подмоделями, а результат формируется на основе сравнения их эмбеддингов. Такой подход хорошо масштабируется и особенно эффективен при отборе релевантных объектов из большого каталога.

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

Ищем скрытые связи: как семантические графы усиливают рекомендации

Семантические графы (или графы знаний) описывают предметную область в виде сети связанных сущностей. Такие графы позволяют учитывать связи между объектами, их атрибутами и категориями, помогая рекомендательным системам строить более осмысленные гипотезы — особенно при нехватке данных о пользователе или товаре.

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

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

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

Решения для более опытных разработчиков:

• PyKEEN. Фреймворк на Python для обучения эмбеддингов сущностей и связей в графах знаний. Поддерживает SOTA-модели и хорошо сочетается с рекомендательными системами.
• DGL-KE. Расширение для DGL, которое позволяет строить масштабируемые графовые эмбеддинги. Особенно подходит, если знаниевый граф очень крупный.

Делаем модель умнее с градиентным бустингом

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

• Берётся очень простая модель.
• Она делает предсказания — с ошибками.
• Следующая модель обучается на ошибках первой.
• Еще одна — снова на ошибках предыдущей.
• И так далее: каждая новая модель помогает немного скорректировать общую ошибку.
• Финальный результат — сумма всех моделей.

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

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

XGBoost, LightGBM и CatBoost — три популярные open-source библиотеки, которые считаются золотым стандартом для работы со структурированными табличными данными и отлично подходят и опытным специалистам, и начинающим ML-разработчикам. Они часто применяются в рекомендательных системах и других задачах машинного обучения, особенно когда:

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

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

Инфраструктура и развёртывание

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

• FastAPI — современный веб-фреймворк на Python, который отлично подходит для упаковки модели в REST API. С его помощью можно буквально в несколько строк кода развернуть сервис, к которому другие компоненты системы будут обращаться за рекомендациями. FastAPI автоматически генерирует документацию (Swagger UI), что ускоряет интеграцию и делает сервис понятным для команды.
• DVC (Data Version Control) — инструмент для версионирования кода, данных, моделей, параметров и метрик. Он интегрируется с Git и позволяет отслеживать, на каких данных и с какими настройками обучалась каждая версия модели. Это особенно важно в условиях соревнования или командной разработки, где важна чёткая структура и контроль изменений, однако инструмент требует хороших знаний в ML и не подходит для новичков
• MLflow и ClearML — инструменты для мониторинга экспериментов, логирования метрик, параметров и артефактов.     Они позволяют сравнивать разные подходы, отслеживать прогресс команды и выбирать лучшие модели на основе полной истории обучения.

Логистика и оптимизация маршрутов

 Пример формулировки. Задача второго трека E-CUP 2025 — оптимизировать доставку. Участникам необходимо создать алгоритм, который распределит 20 000 заказов между 200 курьерами и минимизирует суммарное время их работы, учитывая микрополигоны и индивидуальную скорость выполнения заданий. 

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

Особенности задачи

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

Что делает задачу нетривиальной:

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

Цель — не просто «оптимизировать», а сбалансировать. Важно не только минимизировать общее время, но и избежать перегрузки отдельных курьеров.

Выбор технологий

Для решения на первый план выходят:

• Комбинаторная оптимизация.
• Методы для Vehicle Routing Problem (VRP).
• Алгоритмы поиска оптимальных решений.

Один из основных open-source инструментов для этих задач, подходящий и     новичкам, и профессионалам — Google OR-Tools. Это набор быстрых портативных библиотек от Google для комбинаторной оптимизации и решения задач маршрутизации в логистике. Основные возможности:

• VRP. Решение задач маршрутизации с множеством ограничений, в том числе по временным интервалам, вместимости транспорта,     маршрутам с возвратом и без. 
• CP-SAT Solver. Мощный модуль для целочисленного линейного программирования с ограничениями. Подходит для сложных задач планирования и составления расписаний.

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

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

Превращаем карты в алгоритмы: работа с геоданными

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

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

• GraphHopper.
• OSRM (Open Source Routing Machine).

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

• OpenRouteService — сервис и библиотека с API для маршрутизации и построения изохрон — зон достижимости по заданному времени .
• pgRouting — расширение к PostGIS, которое позволяет искать маршруты прямо в базе данных.
• OR-Tools — поддерживает расчёт маршрутов     и оптимальных последовательностей точек с учётом расстояний и трафика.

Как описать логистику на языке формул

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

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

С Pyomo можно подключать внешние и встроенные open-source солверы для поиска оптимального решения задачи, заданной в виде уравнений, ограничений и целевой функции:

• CBC, HiGHS — для линейных и целочисленных задач.
• SCIP — мощный решатель для целочисленного программирования, доступный для некоммерческого использования.
• IPOPT — для задач без целочисленных переменных.

Совет. Один из плюсов Pyomo — простое переключение между солверами, буквально одной строкой кода. Это особенно удобно при экспериментах и подборе конфигураций под конкретную постановку задачи.

Библиотеки для математического программирования позволяют формализовать и решить в рамках полностью открытого стэка (например, Pyomo + CBC/HiGHS) даже сложные задачи по распределению товаров по складам, построению сменных графиков или многоресурсному планированию. 

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

OptaPlanner — ведущий open-source движок на Java для решения задач планирования. Проект изначально разрабатывался под эгидой Red Hat. Сейчас он продолжает развитие под названием Timefold (open-core). Инструмент поддерживает эвристики, локальный поиск и другие методы оптимизации, позволяя находить приближённые решения даже в сложных случаях с множеством бизнес-правил. Отличный выбор для опытной ML-команды. 

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

Как прогнозирование усиливает модель

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

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

• LightGBM, CatBoost — бустинг снова помогает. Такие модели хорошо работают с агрегированными табличными признаками, особенно когда важна скорость и простота отладки.
• Prophet (Meta) — библиотека для моделирования сезонности, трендов и праздничных эффектов. Удобна для быстрого прототипирования и понимания структуры временного ряда.
• statsmodels — классическая библиотека для статистического моделирования. Поддерживает модели ARIMA, SARIMA и другие линейные подходы, часто применяемые в логистике.
• GluonTS — библиотека от Amazon для глубокого прогнозирования временных рядов. Поддерживает как традиционные, так и нейросетевые модели (DeepAR и прочие).
• Kats (Facebook/Meta) —инструмент с единой оболочкой для ARIMA, Prophet, нейросетевых моделей и анализа аномалий.

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

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

• Ray RLlib.
• Stable Baselines3.

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

Инфраструктура и развёртывание

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

Для совместной работы с геоданными пригодятся GeoPandas и OSMnx — открытые инструменты, которые упрощают обработку координат, дорог и границ микрополигонов.

Контроль качества 

Пример формулировки. Задача третьего трека E-CUP 2025 — защитить клиентов и репутацию Ozon, выявляя поддельные товары. Участникам необходимо разработать ML‑решение, которое по описанию и метаданным определяет, контрафакт это или нет.

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

Особенности задачи

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

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

Выбор технологии

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

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

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

Как классификация данных помогает распознавать дефекты

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

Основные инструменты и библиотеки, которые подойдут для начинающих ML-специалистов:

• PyTorch, TensorFlow/Keras — фреймворки глубокого обучения с поддержкой transfer learning. Позволяют дообучать предобученные модели под свою задачу.
• ResNet, EfficientNet — предобученные архитектуры для задач классификации, которые хорошо адаптируются даже к небольшим датасетам.

Детекция аномалий: находим отклонения

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

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

• PyOD (Python Outlier Detection). Библиотека с поддержкой более 30 алгоритмов обнаружения аномалий — от статистических до нейросетевых. Поддерживает кластеризацию, одно-классовые SVM, изоляционные леса, автокодировщики и другие методы. Особенно полезна для табличных, сенсорных и гибридных данных, где дефекты не обязательно видны на изображении.
• PySAD (Python Streaming Anomaly Detection). Библиотека для онлайн-обнаружения аномалий в потоках данных. Подходит для задач, где сведения поступают в систему в реальном времени, например, от датчиков производственной линии или видеокамер, и нужно быстро зафиксировать отклонение от нормы.

Совет: PySAD может дополнять PyOD в случаях, где важен мониторинг текущего состояния системы, а не только анализ исторических данных.

Как компьютерное зрение находит скрытые дефекты

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

Anomalib объединяет актуальные алгоритмы глубокого обучения для обнаружения и локализации аномалий. Инструмент часто показывает лучшие результаты на промышленных бенчмарках, таких как MVTec AD — набор изображений с типовыми производственными дефектами.

Совет. Главное преимущество Anomalib — простота использования. Можно взять предобученную на нормальных образцах модель, подать новое изображение и получить тепловую карту с подсвеченными аномальными участками. Это особенно ценно, когда нет готовой разметки брака.

Если есть желание углубиться в компьютерное зрение, то Anomalib поддерживает state-of-the-art методы: PaDiM, PatchCore, GANomaly, FastFlow и другие.

Развёртывание и интеграция

После разработки модели её нужно встроить в производственный процесс. Здесь пригодятся инструменты из DevOps/MLOps-практик:

• FastAPI — быстрый способ создать REST API вокруг модели. Например, система может отправлять фотографии в API, а в ответ получать метку «годен/брак» и координаты дефекта. Такой сервис подключается буквально за считаные минуты.
• DVC — для версионирования отснятых изображений, моделей и обучающих данных.
• MLflow — для отслеживания экспериментов, сравнения качества разных подходов, хранения метрик и моделей.
• FiftyOne, CVAT — удобные инструменты для визуализации и анализа предсказаний модели: можно просматривать изображения, аномалии, сегментации и вручную проверять ошибки.

Подводим итог

Даже для такого масштабного соревнования, как E-CUP, сегодня доступен мощный арсенал open-source инструментов: от моделей и алгоритмов до средств развёртывания и визуализации. Они позволяют командам быстро перейти от идеи к рабочему прототипу, не теряя время на рутину и изобретение уже решённых задач.

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

Выбор стэка для ML-соревнования в вопросах и ответах