Как принимать тестовое задание, написанное с ИИ: спецификация против черновика

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

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

Что вы покупаете

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

Никто не просит пересобрать машину с чистого образа. Вопрос проще: число 2 останется двойкой, когда окно чата закрыто?

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

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

Соберите крошечный retry-gate.

POST /retry?key=... может отработать успешно максимум 2 раза для одного ключа. Третий вызов возвращает 429 и не увеличивает счётчик. GET /retry?key=... возвращает уже использованное число. Состояние лежит на диске. Остановка и повторный запуск процесса не должны сбрасывать счётчик.

Не коммитьте секреты, токены и транскрипт работы с моделью. Черновик можно набросать моделью. Тесты коммитьте первыми. В README назовите случай, который тесты не покрывают, и опишите последовательность red-green своими словами. Таймстампы коммитов не доказательство — их можно переписать.

Строчка про «своими словами» тихо делает много работы. История git выглядит как доказательство ровно до первого rebase. Короткий абзац от руки подделкой из буфера не собирается, зато даёт вам конкретный вопрос на созвоне.

Задание, которое можно провалить по-настоящему

Дальше — форма ответа, по которой удобно сверять рубрику. Счётчик на два успеха для ключа, третий вызов — 429 без инкремента, GET отдаёт использованное число. Реализация учебная: класс читает и пишет json-файл по имени ключа, чистит ключ до букв, цифр, дефиса и подчёркивания, режет до 64 знаков, а на пустом ключе кидает исключение. Директорию создаёт при инициализации, поэтому «перезапуск» — это просто второй объект, смотрящий в ту же папку. Кластер для этой идеи не нужен. Нужен файл, который живёт дольше процесса.

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

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

Проверка на коробке занимает пять минут: python -m pytest test_gate.py -q, потом поднятый процесс, два POST с кодом ответа через curl, GET, затем стоп и старт заново. Если счётчик после перезапуска вернулся к нулю — зелёное демо было памятью сессии, и это провал независимо от того, какой вежливый README.

Демо и контракт: таблица различий

Протокол проверки

1. Прогоните тесты кандидата на своей машине, до всякого чтения README.
2. Поднимите сервис, сделайте два POST. Оба должны пройти.
3. Спросите GET и запишите число — не заглядывая в код.
4. Убейте процесс, поднимите заново. Третий POST обязан дать 429, а отказанный вызов не должен двигать счётчик. GET — те же 2.
5. Отправьте ключ, который чистится в пустую строку. Ждём исключение и пустую директорию.
6. Возьмите любую красную ассерцию из истории и попросите объяснить, почему она падала. Без прокрутки чата.

Скрипт-ревьюер тут полезен тем, что не даёт оценивать по вайбу. Открыл итоговый json с used, сверил с двойкой, вернул exit code — вот и пометка в файле кандидата. Автоматизация здесь крошечная, эффект — отсутствие вкусовщины.

Где ошибаются ревьюеры

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

Если задание делаете вы

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

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