Перейти к содержанию

Selena Lab · Опыт

Проверка кода, написанного ИИ: как два агента ошиблись

Воспроизводимая запись опыта: проверку кода вели два независимых агента. Оба уверенно объяснили красную проверку — и оба ошиблись. Вопрос закрыл сам файл workflow.

Вернуться в Selena Lab6 минОбновлено: 2026-08-29

01

Что проверяли

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

Записи опытов публикуются здесь только тогда, когда установку, входные данные и наблюдаемый результат можно воспроизвести. Этот — можно. Это одно наблюдение, а не исследование: n = 1.

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

Схема из двух частей. Было: владелец стоит между ChatGPT Work, Codex и Claude Code и вручную переносит отчёты из одного чата в другой. Стало: все трое читают один и тот же репозиторий GitHub напрямую, а владелец решает только то, что необратимо. До и после. Раньше отчёты между инструментами переносил человек; теперь задача, код и машинные проверки лежат в GitHub, и каждый инструмент читает их сам.

02

Установка

Claude Code поднимается из файла workflow через опубликованный GitHub Action и срабатывает от @claude в комментарии к pull request или задаче. То есть вызывается вручную, но дальше читает сам PR, diff и результаты CI, а не присланный пересказ.

Репозиторий — форк. Вместе с ним достались чужие workflow, включая проверку Contributor License Agreement.

Путь одной задачи: владелец формулирует замысел, проект хранит документы и данные, Codex и Claude Cowork независимо проверяют замысел, появляется утверждённое ТЗ, Codex пишет код в отдельной ветке, затем GitHub CI, Codex и Claude Code проверяют один и тот же коммит; ошибки возвращаются с конкретной правкой; владелец только мержит, тратит и публикует. Проверка происходит дважды: сначала замысел, до первой строки кода, потом сам код — и оба проверяющих смотрят один и тот же коммит.
КомпонентРольОплата
Рабочее пространство проектаДокументы, данные, ТЗПодписка
CodexПишет код и миграции, проверяет собственный diffПодписка
Claude CodeНезависимый аудит и security, запускается как GitHub ActionOAuth-токен подписки, без API-ключа
GitHubОбщий источник: задача, код, diff, машинные проверки
Четыре компонента и зона ответственности каждого.

03

Входные данные

Весь опыт шёл на четырёх артефактах — все они на месте, и каждый можно открыть заново.

  • Один pull request, открыт с 26 августа 2026.
  • Одна стабильно падающая проверка: Verify CLA signature.
  • История коммитов репозитория.
  • Файл workflow с проверкой CLA и файл со списком подписантов, который он читает.

04

Два уверенных объяснения, оба неверные

Первый агент сообщил: красная отметка косметическая, у агентских коммитов она падает всегда, можно мержить мимо. Правдоподобно — предыдущий pull request действительно был влит с той же красной отметкой.

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

Ни один из них не открыл файл workflow. Оба рассуждали о том, что проверка с таким названием, вероятно, делает.

05

Что сказал сам файл

Проверка не читает авторов коммитов вообще. Она берёт GitHub-логин автора pull request и ищет его в файле подписантов.

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

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

AUTHOR: ${{ github.event.pull_request.user.login }}
Строка, которая закрыла вопрос, — из workflow проверки CLA.

06

Результат

Гипотеза подтвердилась в узком смысле и провалилась в широком.

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

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

07

Границы

Это один случай, и читать его нужно как один случай.

  • n = 1. Он показывает, что такой отказ возможен, а не насколько часто он случается.
  • Это не контролируемое сравнение. Агенты получили разные запросы и разный доступ. Качество моделей здесь не сравнивается.
  • Это не доказательство ненадёжности агентов вообще. Это доказательство ненадёжности рассуждения о файле без чтения файла — что одинаково верно и для людей.
  • Вечно красная проверка — сопутствующая причина. Статус, который всегда красный, перестают читать. Этот отказ организационный, а не технический.

08

Что осталось неизвестным

Два вопроса, которые этот опыт поднимает и не закрывает.

  • Добавляет ли второй проверяющий точности, если от обоих требовать ссылки на конкретные строки источника. Здесь это не проверялось.
  • Как часто правдоподобные объяснения без источника переживают проверку двумя агентами, если никто не открывает исходный файл.

09

Как воспроизвести

Это воспроизводится на любом репозитории, форкнутом от проекта с собственной проверкой CLA.

  1. Форкните репозиторий, в котором есть собственная проверка CLA.
  2. Откройте pull request с аккаунта, которого нет в списке подписантов исходного проекта.
  3. Спросите агента, почему проверка падает, не давая ему файл workflow.
  4. Попросите второго агента перепроверить первого — тоже без файла.
  5. Откройте каталог workflow сами и сравните все три ответа.

Проверьте Public Readiness сайта

Запустите бесплатный evidence-based аудит. Он использует только публичные данные сайта и делает 0 платных AI provider calls.

Запустить Public Readiness

Нужна система, а не только диагностика?

Selena Systems разбирает процесс, определяет безопасную границу автоматизации и строит рабочий контур вместе с вашей командой.

Обсудить AI-систему