Two desk lamps facing each other over a sheet of paper marked in red pencil
Back to blog
EngineeringAI Automation

2481 перекрёстная проверка: Claude Code и Codex проверяют друг друга

Два месяца мы поручали Claude Code и Codex проверять работу друг друга до публикации. После 2481 проверки стали видны цифры и правило, которое нам пришлось добавить.

S
Sno AI Team
September 22, 2026
|
6 min read
|
139 views
Share:

Claude Code заканчивает работу, а Codex читает её до публикации. Когда пишет Codex, читает Claude.

Банк работает так же. Никто не одобряет собственный кредит. Один человек готовит документы, другой ставит подпись, и никто не считает это оскорблением. Наш вариант мы называем Dual Brain: два AI-агента работают в паре над одной задачей, один её выполняет, другой проверяет. Это встроено в Sno Station, и мы работаем так с середины июля.

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

Сколько их было

С 19 июля по 21 сентября два AI-агента проверили работу друг друга 2481 раз. Они работали в 63 из этих дней, то есть проводили около 39 проверок в день. Они прочитали 3,2 миллиона строк в 9452 файлах.

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

Я думал, что большая часть работы пройдёт проверку.

Среди проверок, завершившихся вердиктом, 431 закончилась одобрением. Ещё 1953 потребовали доработки. То есть в четырёх случаях из пяти второй AI-агент возвращал работу.

Четыре из пяти. Это не небрежные черновики уставшего стажёра. Модель уже запустила тесты и сказала, что работа закончена.

Код и планы

Затем я отдельно подсчитал проверки кода и проверки планов.

Код проходил проверку в 27 процентах случаев. 398 одобрений из 1475 проверок. Не блестяще, но с этим можно жить.

Планы проходили проверку в 3,6 процента случаев. 33 из 907.

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

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

Большинство самых серьёзных замечаний возникло именно из-за этого разрыва. За тот же период проверяющие отметили 4277 серьёзных проблем в 1395 проверках. Я не проверил каждую из них, и не все они настоящие. Но реальные проблемы обычно были одного типа: кто-то уверенно утверждал то, на что никто на самом деле не посмотрел.

Что пошло не так

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

Но всё не так просто. Проверяющий всегда что-нибудь находит.

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

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

А автор охотно исправляет каждую, добавляя что-нибудь новое.

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

Ни один из этих механизмов ни разу не сработал в рабочей системе. А под ними в самом исправлении всё ещё пряталась ошибка определения идентичности в одной строке. Её никто не заметил за всеми укреплениями. Это как увеличить усиление, чтобы услышать тихий инструмент, и услышать в основном шипение.

Правило, которое мы добавили

Поэтому мы записали правило — самый полезный результат всего эксперимента.

Замечание не означает приказ добавить код.

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

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

Есть и предел. Три раунда для кода. Один для тестов. После этого спор передают человеку — вероятно, ему он и должен был достаться.

Чего это стоит

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

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

Две головы лучше одной. Оказывается, это верно, даже если ни одна из них не человеческая.

Sno Station — открытое ПО, и перекрёстная проверка входит в него. Найти его можно на sno.ai.

S

Written by Sno AI Team

Contributing writer at Sno.ai, sharing insights about AI, productivity, and knowledge management.

Related Articles

Comments

Comments coming soon. Configure Giscus at giscus.app

2481 перекрёстное ревью Claude Code и Codex: что нашли