Как мы перестроили отбор резюме с AI-нативным воркфлоу

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

Всё это стоило $65 и заняло около 13 минут для 115 кандидатов. Но интереснее стоимости оказались методологические вопросы, которые всплыли по ходу: когда использовать флот агентов вместо одного, как предотвратить инфляцию AI-оценок и что значит закодировать «превосходство» в то, что машина реально может исполнить.

1. Что такое динамический воркфлоу

Начнём с концепции, потому что на ней строится всё остальное.

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

Динамический воркфлоу — это другая модель: код, который оркестрирует флот AI-агентов. Его определяющие свойства:

• Детерминированный поток управления + AI-суждение, разделённые между собой. Циклы, диспетчеризация, агрегация и контроль квот обрабатываются кодом (воспроизводимо, аудируемо); субъективное суждение (достаточно ли сильное это резюме?) делегируется AI-агентам.
• Параллелизм с разветвлением (fan-out). Один вызов parallel(...) может одновременно запустить десятки или сотни независимых агентов, каждый работает над своим фрагментом без взаимного влияния на остальных.
• Многоэтапные пайплайны. Результат одного этапа поступает на вход следующему. Код обрабатывает фильтрацию, ранжирование и дедупликацию между этапами.
• Структурированный вывод. Каждый агент возвращает JSON, соответствующий схеме — а не свободный текст чата — так что дальнейший код может напрямую его использовать.

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

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

Более глубокое техническое введение: A harness for every task: dynamic workflows in Claude Code

2. Воркфлоу найма: цели и дизайн

Проблема

У нас была конкретная боль: более сотни кандидатов в статусе «первичный обзор» в нашей базе данных найма Notion, и не было реалистичного способа обработать их вручную без дрейфа стандарта — планка, которую применяешь на резюме №80, почти никогда не совпадает с планкой на резюме №5.

Я хотел проверить одну конкретную идею: можем ли мы абстрагировать «как выглядит превосходство в эпоху AI-агентов» в машиноисполнимую, человекочитаемую рубрику, а затем прогнать всех 115 кандидатов по ней с одной и той же калибровкой?

Цель явно не заключалась в том, чтобы AI принимал решения о найме. Цель была такой:

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

Три ключевых дизайн-решения

Решение 1: критерии и код полностью разделены

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

criteria/
├── 00-philosophy.md          Overall philosophy: what we're hiring for + the "raise the bar" rule
├── 01-pedigree.md            Strong academic / early foundation    (weight 20%)
├── 02-ai-agent-fluency.md    AI-native capability                  (weight 35%)
├── 03-grit-problem-solving.md  Problem-solving & overcoming difficulty  (weight 30%)
├── 04-talent-lens.md         Top-talent signal                     (weight 15%)
└── scoring.md                Scoring formula + grade bands + 5% quota rule

Эти четыре измерения — наш «стандарт превосходства для эпохи AI-агентов, v0.1». Логика за каждым из них:

• AI-native компетентность имеет наибольший вес (35%). В 2026 году то, действительно ли человек использует агентские инструменты, такие как Claude Code, как ключевую часть своей работы — это значимый разделитель продуктивности. Мы специально штрафуем «нашпиговывание» ключевыми словами — упоминание «Claude Code» без проверяемых проектных доказательств считается слабым сигналом.
• Твёрдые доказательства навыка решения проблем (30%). Мы ищем «боевые шрамы»: вещи, построенные самостоятельно с нуля, истории преодоления реальных препятствий — а не уровень воспроизведения из туториала.
• Прочная база (20%). Академическая подготовка служит косвенным показателем потенциала — это сигнал, а не требование. Диплом престижного университета в сочетании со средним результатом штрафуется; самоучка без престижного диплома, но с реальной проделанной работой, получает бонус.
• Сигнал топ-таланта (15%). Это измерение намеренно субъективно. В промпте задаётся вопрос: захотела бы команда вроде Anthropic или основатель вроде Маска немедленно связаться с этим человеком? Оно улавливает инициативность, вкус и скорость, которые остальные три измерения не захватывают.

Решение 2: закодировать «поднять планку» как жёсткое ограничение, а не как лозунг

scoring.md включает твёрдое правило: кандидаты, достигшие высшего уровня (S), должны составлять ≤ 5% от всего пула. После завершения всех оценок код применяет глобальный лимит: даже если многие кандидаты технически набирают баллы в диапазоне S, пройти дальше могут только топ-5%. Это напрямую борется с известным сбоем — AI-оценка по своей природе снисходительна. Без жёсткого ограничения она оценит половину пула как «превосходную».

Решение 3: добавить противодействующую (adversarial) проверку для выявления завышенных оценок

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

Воркфлоу

Настройка 📋 База данных найма Notion — извлечение через Notion CLI → один файл структурированных данных на каждого кандидата

AI Этап 1: Оценка (115 агентов параллельно)

• Читает 6 MD-файлов критериев + файл данных этого кандидата
• Активно посещает ссылки на GitHub / портфолио для проверки доказательств
• Выводит структурированный JSON: оценки по 4 измерениям + обоснование + основные моменты + флаги риска

Code Детерминированный синтез

• Вычисляет взвешенные суммы
• Глобальная сортировка по рангу, расчёт слотов 5%-ной квоты
• Отбирает лучших кандидатов в очередь на противодействующую проверку

AI Этап 2: Противодействующая проверка (Агенты параллельно)

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

Code Детерминированный вердикт

• Пересортировывает с использованием калиброванных оценок
• Применяет жёсткий лимит 5%
• Присваивает финальные градации: S / A / B / C / D

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

Синие этапы (оценка / проверка) — это AI. Серые этапы (синтез / вердикт) — это код. Такое разделение сделано намеренно: всё математическое — взвешивание, ранжирование, применение квот — отдаётся коду для воспроизводимости; всё, что требует суждения — достаточно ли силён этот человек? — отдаётся AI.

3. Что мы увидели: результаты и выводы

Все кандидаты ниже анонимизированы. Мы описываем тип работы, а не имена или идентифицирующие детали.

Что мы запустили

Распределение

5%-ная квота (5 слотов) осталась полностью неиспользованной — не квота остановила кого-либо; дело было в абсолютном пороге баллов. Никто не преодолел планку диапазона A самостоятельно. Ниже — подробнее о том, почему это на самом деле полезный сигнал.

Как выглядела верхушка рейтинга (анонимизировано)

Без исключения, кандидаты с наивысшими рейтингами были людьми, которые действительно строили агентов — а не людьми, которые просто слышали про AI:

• №1: Аспирант, построивший с нуля многоагентную мастерскую в стиле Claude Code — включая главный цикл агента, парсинг вызовов инструментов, сжатие контекста, порождение суб-агентов и защитные механизмы. Весь код проверяем, а не просто описан.
• №2: Другой аспирант, который развернул реальную, публично доступную многоагентную систему (прикладное решение для вертикальной отрасли), с академическими результатами в дополнение.
• Далее по списку: человек, написавший с нуля движок оркестрации агентов на Go; человек, выпустивший легковесного кодирующего агента, изучив архитектуру Claude Code; человек, самостоятельно создавший игру с локальной LLM за семь дней, используя AI-инструменты на всех этапах.

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

Три наблюдения

Наблюдение 1: противодействующая проверка действительно выявила завышенные оценки

Самый явный пример — два кандидата с наивысшим рейтингом. После этапа оценки у обоих взвешенная сумма составила около 82 баллов — достаточно, чтобы попасть в диапазон A и приблизиться к порогу S. После противодействующей проверки оба оказались около 75 баллов, с очень конкретным обоснованием:

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

«Настоящий, проверяемый AI-native builder. Но заявленная публикация в топовом журнале фигурирует только в заметках рекрутера, без независимо проверяемого источника. Backend основной системы закрыт; личный вклад невозможно подтвердить. Использование неподтверждённых академических регалий для попадания в высший уровень — это инфляция оценки на основе ключевых слов.»

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

Наблюдение 2: S:0 / A:0 — это не баг, это зеркало

Первый инстинкт — спросить, не была ли планка установлена неверно. Но если честно посмотреть на пул:

• У значительной доли кандидатов резюме были очень скудными — ключевые измерения (опыт с AI, проверяемая работа) просто отсутствовали.
• Многие соискатели на роли Agent Engineer имели нулевые доказательства использования агентских инструментов и никакой ссылки на GitHub.
• В пуле также оказались деловые письма рекрутеров и системные уведомления LinkedIn — они были корректно определены как нерелевантные и оценены в 0 баллов, что попутно показало, что нашу базу данных найма нужно почистить.

Иными словами, строгая рубрика чисто разделила сигнал от шума. Настоящие builders (топ-6) и «успешные генералисты» (средний уровень) оказались в явно различных местах. В этом и суть — лучше упустить нескольких, чем завысить всех.

Это также поднимает открытый вопрос, достойный обсуждения: не слишком ли жёсток текущий порог диапазона A (78 баллов) для кандидатов-студентов с сильными профилями GitHub, но без пока сложившегося профессионального опыта? Интересно, что сами агенты противодействующей проверки описали двух лучших кандидатов как «кандидатов с высоким потенциалом» — но взвешенный балл удержал их в диапазоне B. Решение о том, стоит ли ослаблять этот порог для кандидатов с высоким потенциалом на раннем этапе карьеры, лучше принимать после того, как мы увидим реальное качество интервью из группы B. Хорошая новость: это изменение — одна цифра в одном Markdown-файле. Код не требуется.

Наблюдение 3: «критерии как код» делает разногласия продуктивными

Разговоры о стандартах найма обычно остаются размытыми — «мы хотим людей с драйвом», «того, кто может разобраться сам». Поскольку эта рубрика записана с весами и опорными примерами, разговор сразу становится конкретным: «Должна ли AI-компетентность весить 35% или 40%?» «Насколько выигрывает выдающийся builder без престижного диплома?» «Должна ли квота быть 5% или 8%?» — каждое разногласие соответствует конкретной строке в Markdown-файле, которую можно изменить, версионировать и обсудить. Стандарт становится активом, который поддерживают, а не консенсусом, который повторяют на каждой встрече.

4. Стоимость и ROI

Точные расходы

Мы использовали Claude Opus 4.8 (высший уровень). Точная разбивка по категориям токенов:

Это примерно $0.57 на кандидата.

Неочевидная находка: запись в кэш — крупнейшая статья расходов

Естественное предположение — что, поскольку все 115 агентов читают одни и те же 6 файлов критериев, кэширование промптов должно сильно помочь. Оно не помогает так, как ожидается.

Кэширование промптов работает по точному совпадению префикса, а каждая сессия агента независима. 125 агентов означают 125 независимых сессий — каждая с разным описанием задачи (разные данные кандидата) — так что кэш, записанный агентом A, не может быть использован агентом B. Кэширование действительно помогает внутри многошагового выполнения каждого отдельного агента (читает критерии → посещает GitHub → посещает портфолио → выводит результат, повторно считывая ранее прочитанный контент на каждом шаге).

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

Как думать про ROI

Прямое сравнение с ручным обзором: HR-менеджер, внимательно читающий одно резюме, проверяющий GitHub и делающий заметки — консервативно 5–10 минут на кандидата. На 115 кандидатах это 10–19 часов сфокусированной работы, при этом стандарты будут дрейфовать на всём протяжении.

Этот воркфлоу дал:

Но более важный ROI — это внимание: воркфлоу перенаправил человеческое внимание с 83 явно неподходящих кандидатов на 6 настоящих builders на вершине. Это самое ценное, что может дать первичный скрининг.

Можно ли сделать дешевле?

Да, но, вероятно, в этом нет необходимости. Если бы это стало высокочастотной, крупнообъёмной операцией (сотни кандидатов ежедневно), практическая оптимизация была бы такой:

• Использовать Sonnet на этапе оценки, Opus — только для противодействующей проверки — вероятно, снижение стоимости на 70–80% при минимальной потере качества.
• Или использовать более дешёвую модель для грубого первичного прохода, а затем Opus — для детальной оценки верхнего уровня.

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

Более широкая картина

Что по-настоящему интересно в этом эксперименте — не то, что «AI умеет скринить резюме» — это не новая идея. Дело в том, что модель динамического воркфлоу — код, оркестрирующий флот AI-агентов — впервые делает определённые категории работы структурируемыми, воспроизводимыми и итерируемыми.

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

Эта рубрика — версия v0.1. Она не идеальна. Но теперь это версионируемый, обсуждаемый, улучшаемый актив — а не неявное согласие, живущее в чьей-то голове. Именно этот сдвиг, больше, чем любой отдельный результат, и был истинной сутью этого эксперимента.