Как проектировать технические задания, устойчивые к AI

Автор — Тристан Хьюм, руководитель команды оптимизации производительности в Anthropic. Тристан разработал — и неоднократно переработал — тестовое задание, которое помогло нанять десятки инженеров по производительности.

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

С начала 2024 года наша команда по оптимизации производительности использует тестовое задание, в котором кандидаты оптимизируют код для симулированного ускорителя. Его выполнили более 1 000 кандидатов, и десятки из них теперь работают у нас — в том числе инженеры, запустившие наш кластер Trainium и выпустившие все модели начиная с Claude 3 Opus.

Но каждая новая модель Claude вынуждала нас переделывать задание. При одинаковом лимите времени Claude Opus 4 обошёл большинство кандидатов-людей. Это ещё позволяло выделить сильнейших — но затем Claude Opus 4.5 сравнялся даже с ними. Люди по-прежнему могут превзойти модели при неограниченном времени, однако в рамках тестового задания мы больше не могли отличить результат лучших кандидатов от результата самой мощной модели.

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

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

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

Как появилось тестовое задание

В ноябре 2023 года мы готовились к обучению и запуску Claude Opus 3. Мы получили новые кластеры TPU и GPU, приближался запуск большого кластера Trainium, расходы на ускорители существенно выросли — но инженеров по производительности для нового масштаба не хватало. Я написал в Twitter с просьбой присылать резюме на почту, и это привлекло больше перспективных кандидатов, чем мы могли обработать через стандартный процесс найма, который требует значительного времени от сотрудников и кандидатов.

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

Цели дизайна

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

Формат тестового задания также имеет преимущества перед живыми интервью при оценке навыков оптимизации производительности:

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

Реалистичная среда: Никто не наблюдает и не ждёт комментариев вслух. Кандидаты работают в своём редакторе без отвлекающих факторов.

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

Совместимость с AI-помощью: Общие рекомендации Anthropic для кандидатов предписывают выполнять тестовые задания без AI, если не указано иное. Для этого задания мы явно указываем обратное.

Задачи с более длинным горизонтом сложнее полностью решить AI, поэтому кандидаты могут использовать AI-инструменты (как на работе), при этом всё равно демонстрируя собственные навыки.

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

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

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

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

Интересным: Быстрые циклы разработки, интересные задачи с глубиной и пространство для творчества.

Симулированная машина

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

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

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

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

Первые результаты

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

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

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

Затем Claude Opus 4 его победил

К маю 2025 года Claude 3.7 Sonnet уже дошёл до того, что более 50% кандидатов получили бы лучший результат, полностью делегировав задание Claude Code. Затем я протестировал пре-релизную версию Claude Opus 4 на задании. Он предложил более оптимизированное решение, чем почти все люди в рамках 4-часового лимита.

Это было не первое интервью, побеждённое моделью Claude. В 2023 году я специально разработал вопрос для живого интервью, потому что наши тогдашние вопросы были основаны на распространённых задачах, о которых ранние модели Claude имели много знаний и легко их решали. Я попытался создать вопрос, требующий больше навыков решения задач, чем знаний, основанный на реальной (но нишевой) проблеме, которую я решал на работе. Claude 3 Opus справился с первой частью; Claude 3.5 Sonnet — со второй. Мы всё ещё используем его, потому что наши другие живые вопросы тоже не устойчивы к AI.

Для тестового задания было очевидное решение. Задача имела гораздо больше глубины, чем кто-либо мог исследовать за 4 часа, поэтому я использовал Claude Opus 4, чтобы определить, где он начинает испытывать затруднения. Это стало новой отправной точкой для версии 2. Я написал более чистый стартовый код, добавил новые функции машины для большей глубины и убрал многоядерность (которую Claude уже решил и которая только замедляла циклы разработки, не добавляя информативности).

Я также сократил лимит времени с 4 часов до 2. Изначально я выбрал 4 часа на основе отзывов кандидатов, предпочитавших меньший риск потерять время при зависании на баге или непонимании, но накладные расходы на планирование вызывали многонедельные задержки в нашем процессе. Два часа гораздо проще вписать в выходные.

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

Затем Claude Opus 4.5 победил и её

Когда я тестировал пре-релизный чекпоинт Claude Opus 4.5, я наблюдал, как Claude Code работает над задачей 2 часа, постепенно улучшая решение. Он устранил начальные узкие места, реализовал все распространённые микрооптимизации и достиг нашего порога прохождения менее чем за час.

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

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

У меня была проблема. Мы были готовы выпустить модель, при которой лучшей стратегией на нашем тестовом задании было бы делегирование Claude Code.

Рассмотрение вариантов

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

Другие предложили поднять планку до «существенно превзойти то, что Claude Code достигает самостоятельно». Проблема здесь в том, что Claude работает быстро. Люди обычно тратят половину из 2 часов на чтение и понимание задачи, прежде чем начать оптимизировать. Человек, пытающийся управлять Claude, скорее всего, постоянно отставал бы, понимая, что Claude сделал, только постфактум. Доминирующей стратегией могло стать просто наблюдение.

Сегодня инженеры по производительности в Anthropic по-прежнему много работают, но это выглядит скорее как сложная отладка, проектирование систем, анализ производительности, проверка корректности систем и упрощение кода Claude. К сожалению, всё это сложно объективно протестировать без большого количества времени или общего контекста. Разрабатывать интервью, отражающие реальную работу, всегда было сложно, но теперь это сложнее, чем когда-либо.

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

Попытка 1: Другая задача оптимизации

Я понял, что Claude может помочь мне быстро реализовать всё, что я разработаю, что мотивировало меня попробовать создать более сложное задание. Я выбрал задачу, основанную на одной из более сложных оптимизаций ядер, которые я делал в Anthropic: эффективная транспозиция данных на 2D-регистрах TPU с избеганием банковских конфликтов. Я дистиллировал её в более простую задачу на симулированной машине и попросил Claude реализовать изменения менее чем за день.

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

В моём реальном случае это бы не сработало, поэтому я исправил задачу, убрав этот подход. Затем Claude продвигался вперёд, но не мог найти наиболее эффективное решение. Казалось, у меня есть новая задача, оставалось только надеяться, что кандидаты-люди смогут решить её достаточно быстро. Но у меня оставались сомнения, поэтому я перепроверил, используя функцию «ultrathink» Claude Code с более длинными бюджетами на размышление... и он решил задачу. Он даже знал трюки для устранения банковских конфликтов.

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

Попытка 2: Уйти в более странное

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

Я подумал о самых необычных задачах оптимизации, которые мне нравились, и остановился на играх Zachtronics. Эти игры-головоломки по программированию используют необычные, сильно ограниченные наборы инструкций, которые вынуждают программировать нестандартными способами. Например, в Shenzhen I/O программы разделены между несколькими взаимодействующими чипами, каждый из которых содержит лишь около 10 инструкций с одним-двумя регистрами состояния. Умная оптимизация часто включает кодирование состояния в счётчик команд или флаги ветвления.

Я разработал новое тестовое задание, состоящее из головоломок с крошечным, сильно ограниченным набором инструкций, оптимизируя решения для минимального количества инструкций. Я реализовал одну задачу средней сложности и протестировал её на Claude Opus 4.5. Он не справился. Я добавил больше задач и попросил коллег проверить, что люди, менее погружённые в проблему, чем я, всё равно могут превзойти Claude.

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

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

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

Открытый челлендж

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

Опубликованная версия начинается с нуля (как версия 1), но использует набор инструкций версии 2 и однопоточный дизайн, поэтому количество циклов сопоставимо с версией 2.

Бенчмарки производительности (измеряется в тактах симулированной машины):

• 2164 цикла: Claude Opus 4 после многих часов в стенде тест-тайм вычислений
• 1790 циклов: Claude Opus 4.5 в обычной сессии Claude Code, примерно соответствует лучшей производительности человека за 2 часа
• 1579 циклов: Claude Opus 4.5 после 2 часов в нашем стенде тест-тайм вычислений
• 1548 циклов: Claude Sonnet 4.5 после значительно более 2 часов тест-тайм вычислений
• 1487 циклов: Claude Opus 4.5 после 11,5 часов в стенде
• 1363 цикла: Claude Opus 4.5 в улучшенном стенде тест-тайм вычислений после многих часов

Скачайте на GitHub. Если вы оптимизируете ниже 1487 циклов, превзойдя лучший результат Claude на момент запуска, отправьте код и резюме на performance-recruiting@anthropic.com.

Или вы можете подать заявку через наш стандартный процесс, который использует (теперь) устойчивое к Claude тестовое задание. Нам интересно, как долго оно продержится.