Два ИИ-агента в одном редакторе: как Claude и GPT проверяют код друг друга

Разработчик создал инструмент, который связывает два ИИ-агента в едином воркфлоу — один пишет код, а второй проверяет его, не видя объяснений первого. Но не всё так однозначно, как кажется из заголовка.

Два ИИ-агента не обязательно должны соглашаться. Полезнее — когда один из них может задать другому неудобный вопрос до того, как код попадёт в продакшн.

Пары, которые не существуют в природе

Заголовок звучит соблазнительно: Claude Fable 5.1 и GPT-6 Astra, shoulder to shoulder, ревьюят код в тандеме. Антропик и OpenAI, вечные конкуренты, наконец объединились ради вашего pull request'а. Красивая картинка. Вот только она не совсем честная.

Разработчик Денис Бабкевич, создавший инструмент OMP Tandem, в тексте сам признаёт: в реальном кейсе использовался Claude через алиас sonnet с GPT-6 Astra в роли «пира». Связка Fable 5.1 + Astra — это пример конфигурации, а не протестированная связка. Заголовок работает на маркетинг, а не на точность. Но идея за ним стоит серьёзная.

Что такое OMP Tandem

OMP Tandem — это open-source «мост» между двумя ИИ-агентами, работающий поверх платформы Oh My Pi (OMP). Не обёртка над API двух моделей, а полноценный интеграционный слой через MCP (Model Context Protocol).

Суть проста: у вас есть основной кодинг-агент — например, Claude Code или Codex CLI. Выพยายаете к нему второго агента через OMP. Второй агент не дублирует работу первого, а выполняет роль независимого ревьюера или соисследователя.

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

Главная фишка: независимость ревьюера

Конструктивный момент, на который автор делает главную ставку — тайминг.

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

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

Разница между «оценить предложенное решение» и «самостоятельно найти решение — а потом сравнить» принципиальна. Это как разница между рецензентом статьи, которому показали черновик, и экспертом, которого попросили разобраться в проблеме независимо.

Не только ревью

Ревью готового коммита — лишь одна точка входа. Tandem умеет больше:

• Пир может оспорить архитектурное предположение до реализации
• Пока координатор проверяет одну часть кода, пир исследует подозрительный участок параллельно
• Роли «координатор» и «пир» — это роли в воркфлоу, а не иерархия «умный — глупый»

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

История диалога сохраняется, так что можно сменить цель, не теряя контекст.

Работа со снапшотами

Ещё один важный нюанс: ревью привязано к конкретному состоянию файлов, а не к «тому, что лежит на диске прямо сейчас».

Tandem поддерживает два источника: worktree (рабочие изменения) и staged (подготовленный коммит). Материал сохраняется в момент захвата. Если вы потом подредактировали файлы, сохранённое ревью это отразит — с пометкой, что оно, возможно, устарело.

Файлы за пределами захвата не покрываются молча. Если ревьюеру нужен неизменённый вызывающий код или тест — его нужно явно добавить в контекст. Следующий шаг — новый, расширенный снапшот, а не добавление файлов «задним числом» в старое ревью.

Честная позиция: отчёт говорит вам, что именно проверялось и актуально ли это ещё. Он не превращает проверку пяти файлов в заявление о всём репозитории.

Реальный кейс: три эпизода, один баг

В репозитории есть задокументированный кейс — три эпизода ревью с машиночитаемыми доказательствами. Результаты не выглядят как победный марш.

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

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

Третий эпизод — этот самый расширенный ревью — сам упал по тайм-ауту. Но его ответы сохранились, а статус не перезаписали как успешный, поскольку формально задача не завершилась.

После первого исправления независимая проверка нашла другой риск: блокировки публикации SQLite могли мешать отмене. Это был статический фикс, не воспроизведённый по времени. Отдельный рантайм-тест потом подтвердил взаимодействие, исправил его и прошёл регрессии.

Итого: три эпизода, 598 секунд настенных часов, примерно $5,68 записанных затрат. Полная стоимость неизвестна — часть учётных данных пира отсутствует, а человеческая подготовка и локальные проверки не попали в запись.

Чего нет в статье

И это критически важно: сравнительных результатов не опубликовано. Автор подготовил четырёхсторонний бенчмарк-протокол (один агент, саморевью, обычная передача между агентами и процесс Tandem), но сами цифры не представлены.

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

Кроме того, кейс использовал Claude sonnet, а не обещанный в заголовке Fable 5.1. Это значит, что для громкой связки из заголовка мы вообще не имеем никаких данных.

Границы, которые нельзя игнорировать

Автор честно перечисляет ограничения, и это один из сильных моментов статьи:

• work-режим — не песочница ОС. Внешний процесс OMP не наследует ограничения шелл-песочницы хост-агента.
• Локальное хранение — не офлайн-инференс. Настроенные провайдеры получают контекст задачи. MIT-лицензия на софт не отменяет использование облачных моделей.
• Завершённый отчёт — не доказательство корректности кода. Находки и исправления по-прежнему требуют верификации.

Для инструмента, который работает с незнакомым кодом и генерирует патчи, это не формальности — это реальные риски.

Что нужно для запуска

Tandem 3.3.0 требует macOS, Linux или WSL с Linux-инструментами. Нужен Python 3.12+ и настроенный хост-агент. Установка через Homebrew и плагины для Claude Code или Codex CLI описана в документации.

Автор рекомендует начать с локальной диагностики — /omp-tandem:setup с запросом «local diagnosis only». Это проверяет конфигурацию без обращения к модели. Живой запрос к провайдеру — отдельный явно одобренный шаг.

Важно: сессию хост-клиента нужно держать открытой до завершения задачи. Сохранённая история — не detached-сервис.

Итого: инструмент для узких мест

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

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

Хотите проверить? Автор приглашает попробовать Tandem на хорошо знакомом изменении и поделиться результатами. Именно обратная связь от реальных пользователей сейчас ценнее, чем красивые диаграммы и громкие имена моделей в заголовках.