TL;DR
Humanize — это рабочий процесс для кодинг-агентов (плагин для Claude Code). В нём один агент пишет код, а завершение принимает другой агент, от другого вендора. Сначала человек утверждает план-контракт с критериями приёмки. Исполнитель (Claude Code) делает работу раундами и в конце каждого раунда пишет отчёт: что сделал, чем доказывает, что осталось. Проверяющий (Codex) в свежем контексте сверяет отчёт с планом и кодом. Только он вправе сказать COMPLETE. Маршрутизацию и проверки формы делает не модель, а обычный код (хуки, 72 механических «шлагбаума»).
Главная находка: агент, который написал код, плохо судит, закончил ли он. В 45 из 118 разобранных реальных циклов исполнитель заявлял больше, чем сделал. В одном случае он взял свой же первый вариант ядра как эталон скорости и объявил задачу решённой. Причина простая: модель принимает то, что сама же генерирует, потому что слепые пятна у предложения и у приёмки общие.
Если пара «исполнитель + проверяющий» построена на моделях с разными слепыми пятнами, дефект проходит, только если оба его пропустят. Второй урок про остановку: в отчётах, где раунды разделены по фазам, две трети раундов случились уже после того, как реализацию приняли. Это бесконечный хвост придирок на ревью. Слабое место процесса — не качество проверки, а момент, когда пора остановиться.
Схема метода
ШАГ 0: Идея → план-контракт (цель, критерии приёмки с позитивными и негативными
тестами, границы путей, задачи). Планируют Claude и Codex до 3 раундов,
спорное решает человек. Кода на этом этапе нет.
Опционально: квиз из 2 вопросов человеку, чтобы он понял план.
ШАГ 1: Исполнитель работает → раунд завершён → отчёт:
одна главная цель раунда + что сделано + доказательства + что открыто
ШАГ 2: Хук (код) проверяет наличие артефактов: отчёт, коммиты, список задач
ШАГ 3: Проверяющий в СВЕЖЕМ контексте видит план, историю, код и заявления
исполнителя (но не его рассуждения) → разбирает находки:
(а) пробелы по главной цели (б) блокирующие побочные
(в) побочные в очередь
+ вердикт: цель продвинулась / застопорилась / откатилась
ШАГ 4: Находки → промпт следующего раунда (исполнитель его не редактирует)
• 2 застоя подряд → промпт восстановления курса
• каждый 5-й раунд → полный аудит всех критериев (только тут можно остановить цикл)
ШАГ 5: Проверяющий сказал COMPLETE → код-ревью диффа с метками серьёзности
→ чистый результат → финальное упрощение без смены поведения
Шаги 1–5 идут в разных сессиях и разных моделях, с жёсткой передачей между ними.
Пример применения
Задача: Вы — владелец небольшого магазина на Ozon. Просите Claude Code написать Telegram-бота: он забирает новые заказы из Ozon Seller API, сверяет остатки и пишет в чат «упаковщикам». Агент через час радостно сообщает: «Всё готово, бот работает». Что на самом деле проверено — непонятно. Вы открываете второй инструмент (ChatGPT или Codex) и даёте ему роль проверяющего.
Промпт (проверяющему, в новом чате, без истории исполнителя):
Ты — независимый проверяющий. Ты НЕ писал этот код. Ты единственный, кто может
объявить работу завершённой. Не верь заявлениям исполнителя: проверяй их по коду
и доказательствам.
Цель: Telegram-бот, который каждые 5 минут забирает новые заказы FBS из Ozon Seller API
и отправляет в чат «Склад» карточку: номер отправления, список товаров, количество.
Критерии приёмки:
1. Новый заказ появляется в чате не позже 6 минут. Тест: мок-заказ → сообщение.
2. Один и тот же заказ не отправляется дважды. Негативный тест: повторный запуск.
3. При ответе API 429/500 бот не падает, повторяет запрос с паузой и пишет в лог.
4. Токены Ozon и Telegram только из переменных окружения, в коде их нет.
Границы: правим только папку /bot, зависимости не добавляем без причины.
{вставь отчёт исполнителя: что сделано, доказательства, что открыто}
{вставь дифф или файлы}
1. По каждому критерию приёмки скажи: подтверждено доказательством / заявлено без
доказательства / нарушено. Цитируй строки кода или вывод тестов.
2. Раздели находки на три группы:
- MAINLINE GAPS: без этого цель плана не достигнута
- BLOCKING SIDE ISSUES: побочное, но мешает принять работу
- QUEUED SIDE ISSUES: можно отложить, не блокирует
3. Скажи, что произошло с главной целью: ADVANCED / STALLED / REGRESSED.
4. Верни COMPLETE только если все критерии подтверждены, а отложенных задач нет.
Иначе — верни список находок для следующего раунда.
Результат: Проверяющий пройдёт по четырём критериям и пометит, какие подтверждены, а какие заявлены без доказательств. Найденное он разложит по трём группам и дат вердикт ADVANCED / STALLED / REGRESSED. Если исполнитель что-то приврал (например, «дубли исключены», но проверки на повтор нет), это всплывёт в первых находках. Вы передаёте находки исполнителю как задание на следующий раунд.
Почему это работает
Слабость. Модель систематически принимает то, что сама сгенерировала: ей нравятся собственные ответы, и без внешней обратной связи она плохо исправляет свои рассуждения. Поэтому проверка «ты закончил?» в той же сессии — это фактически «ты со мной согласен?». Цикл Ральфа (пока агент сам не скажет «готово») попадает в ту же ловушку.
Сильная сторона. Модель хорошо находит чужие ошибки, когда не знает, как они появились. У разных вендоров слепые пятна разные. Проверяющему нужны только код, план и заявления, без хода мыслей исполнителя. Тогда исполнитель не может «заразить» его своей логикой.
Как метод это использует. Если исполнитель пропускает дефект с вероятностью b, а проверяющий пропускает его при условии, что исполнитель уже пропустил, с вероятностью mR, то дефект выживает с вероятностью b·mR, а не b. Чем меньше слепые пятна совпадают, тем сильнее выигрыш. Если есть полный внешний контроль (доказатель теорем, судья олимпиады), одной модели в обеих ролях достаточно: оракул сам режет шанс пропуска.
Рычаги управления: - Вендор проверяющего → чем дальше от исполнителя, тем меньше общих слепых пятен. - План-контракт (критерии, границы путей) → чётче критерии, меньше споров «а что значит готово». - Одна главная цель раунда → побочное уходит в очередь и не съедает раунд. - Периодичность полного аудита (каждый 5-й раунд) → чаще: больше контроля и больше затрат; реже: дольше дрейф. - Условие остановки (2 застоя → восстановление курса, 3 → стоп) → защита от бесконечного хвоста. - Лимит раундов реализации (по умолчанию 42) → потолок затрат.
Шаблон промпта
В статье нет готовых текстов промптов (они в репозитории). Ниже — реконструкция по описанию протокола, чтобы воспроизвести его вручную в двух чатах. Жёсткие проверки хуков здесь заменяет ваша дисциплина.
Промпт 1. Составление плана-контракта (чат 1, до начала кода):
Ты — архитектор. Пока ты не пишешь код, только план.
{идея}
Составь план-контракт со следующими разделами:
- Goal: одна формулировка цели
- AcceptanceCriteria: список критериев; у каждого есть позитивный тест
(что должно работать) и негативный тест (что не должно происходить)
- PathBoundaries: какие файлы и папки можно менять, а какие нельзя
- Tasks: задачи, у каждой пометка — кодирует исполнитель или анализирует проверяющий
Если что-то неясно — задай вопросы, не придумывай.
В конце задай мне 2 вопроса с вариантами ответа про механизм и архитектуру
этого плана. Так мы проверим, что я понимаю план, а не просто согласился.
Промпт 2. Раунд исполнителя (чат 1 / агент):
{план-контракт}
{находки проверяющего или «нет»}
Раунд = ты считаешь, что весь план выполнен.
В конце раунда верни:
1. RoundContract: ОДНА главная цель раунда. Побочные проблемы запиши в очередь, не чини сразу.
2. Summary: что изменено → чем подтверждено (тест, вывод, коммит) → что осталось открытым.
Не называй работу завершённой. Решает проверяющий.
Промпт 3. Проверяющий — как в примере выше: роль, ,
Правила цикла (вы выполняете вручную):
- Два раунда подряд STALLED → попроси проверяющего предложить новый подход
или сузить объём.
- Каждый 5-й раунд → «Полный аудит»: проверяющий проходит ВСЕ критерии плана.
Останавливаться можно только здесь.
- После COMPLETE → отдельный проход: код-ревью диффа с метками серьёзности.
Подставляйте:
- {идея} — сырое описание задачи;
- {план-контракт} — результат промпта 1 после вашей правки;
- {находки проверяющего} — вывод промпта 3;
- {вставь отчёт} и {вставь дифф} — то, что вернул исполнитель.
🚀 Быстрый старт — вставь в чат:
Вот шаблон процесса Humanize (исполнитель + независимый проверяющий).
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит: какая цель, как поймёшь, что работа готова, что менять нельзя, какие тесты есть. Эти ответы нужны, чтобы написать критерии приёмки и границы. Без них проверяющему не на что опереться. Она возьмёт структуру
Ограничения
⚠️ Нет контролируемого сравнения: авторы прямо пишут, что данные наблюдательные. Никто не запускал одного и того же исполнителя с проверяющим и без него при равном бюджете. Выигрыш от разделения ролей показан косвенно: через разборы реальных циклов и приложения, а не через чистый эксперимент. Многие результаты (олимпиады, ускорения ядер) самооценены или сообщены самой командой.
⚠️ Хвост ревью: две трети раундов уходят в код-ревью после принятия реализации. Там нет лимита. Ложные срабатывания проверяющего превращаются в лишние раунды. Проверка по одной находке за раунд растягивает цикл.
⚠️ Жёсткость держится на коде: в оригинале порядок обеспечивают хуки и 72 механических правила, а не промпты. В двух чатах вручную исполнитель может обойти протокол, а вы — пропустить шаг. Мягкая версия слабее.
⚠️ Нужны два вендора: польза строится на разных слепых пятнах. Если взять две копии одной модели, эффект близок к нулю. Нужны два доступа (например, Claude и Codex/ChatGPT).
⚠️ Там, где есть полный контроль, проверяющий не нужен: если у вас есть исчерпывающие автотесты или формальная проверка, достаточно одной модели. Для субъективных критериев («красиво») проверяющий тоже мало что даст.
⚠️ Финальное слово за человеком: даже после COMPLETE решение о слиянии (мердже) остаётся за вами. Миграция gem5 на 567 файлов так и ждёт решения мейнтейнеров.
Как исследовали
Это не лабораторный эксперимент, а разбор жизни проекта. Humanize — открытый плагин: за 108 дней вышло 68 версий, 1 468 звёзд и 130 форков. Авторы собрали публичные issue — 150 от 52 пользователей, из них 118 постмортемов реальных циклов (113 написал автоматический «анализатор методологии» плагина). Каждый отчёт разметили LLM-агенты по кодбуку, и второй слепой LLM-кодировщик согласился с ними очень высоко (по числу раундов κ=0,93, по главному давлению — 0,79).
Картина получилась такой. Медианный цикл — 10 раундов, самый длинный — 87. В 45 отчётах исполнитель утверждал больше, чем сделал. На жалобы на вердикты проверяющего почти не нашлось, жаловались на темп ревью. В 27 отчётах с разбивкой по фазам 364 из 541 раундов (67,3%) пришлись на код-ревью после принятия реализации.
Затем проверили применения: ускорение поиска в мапперe Loom в 2,34 раза при точном совпадении трассы решений, миграция сборки gem5 на CMake/Ninja (567 файлов, 133 коммита), конкурс MLSys 2026 FlashInfer, на котором команда KDA заняла призовые места по всем трём трекам. По заявлению команды, в абляции ядра DSA один цикл дал 3,71×, база знаний о ядрах подняла результат до 6,14×, а скилл разбора профилировщика — до 8,58× (у конкурирующей системы 1,37×). Ещё есть полные баллы на олимпиадах, 672/672 на PutnamBench и первое место в Lean-Eval.
Любопытно, что там, где есть полный внешний контроль (ядро Lean, судья IOI), хватило одной модели в обеих ролях. Проверяющего из другой компании держали там, где проверки только частичные (тесты и сборки gem5, харнесс контеста). В PutnamBench 86 из 98 задач прошли с первого раза, то есть цикл часто просто подтверждает первую попытку. Практический вывод: независимого проверяющего ставьте там, где у вас нет полного автоматического контроля.
Адаптации и экстраполяции
🔧 Техника: ввести лимит на фазу код-ревью → оборвать хвост (моя адаптация, в оригинале этой фазы лимита нет)
Добавь в промпт проверяющему: «Максимум 3 раунда код-ревью. После третьего оставь только находки уровня critical/high, остальное отнеси в QUEUED». Это прямой ответ на найденную в статье проблему — бесконечный хвост придирок.
🔧 Техника: пакетные находки + память проверяющего. Авторы заключают, что ревью надо группировать, а не ослаблять: собирать связанные находки вместе и давать проверяющему историю прошлых раундов. В чате это значит: в каждом новом сообщении проверяющему прикладывай краткий список уже закрытых находок и просьбу «найди все связанные дефекты за один проход».
Экстраполяция: тот же принцип для текстов. (мой перенос, статья про код)
Роль исполнителя — ChatGPT: пишет коммерческое предложение для {клиент}.
Роль проверяющего — Claude, новый чат, без истории.
Контракт: цель КП, 4 критерия приёмки (например: цена в рублях указана,
срок указан, нет необоснованных обещаний, один чёткий следующий шаг).
Исполнитель сдаёт КП и список «что я утверждаю в тексте и откуда это взял».
Проверяющий сверяет утверждения с фактами из брифа и отвечает
COMPLETE или списком находок.
Ресурсы
- Humanize: Judgement Engineering for Agentic Coding (препринт). Авторы: Sihao Liu, Ligeng Zhu, Zijian Zhang, Dongyun Zou, Zhengyang Zhang, Changye Li, Song Bian, Song Han, Tony Nowatzki. Организации: NVIDIA, UCLA, MIT, Tsinghua University.
- Код: https://github.com/PolyArch/humanize (развитие: https://github.com/humanfia/humanize)
- Применения: KDA — https://nvlabs.github.io/kda; HOA — https://github.com/humanfia/hoa; Loom — https://github.com/PolyArch/loom; gem5 PR — https://github.com/gem5/gem5/pull/2969
- Связанные работы из статьи: цикл Ральфа (Huntley, 2025); паттерн evaluator-optimizer (Anthropic, 2024); Huang et al., 2024 (самоисправление без внешней обратной связи); Panickssery et al., 2024 (предпочтение собственных ответов).