Парное программирование — штука не новая. Ещё в конце 90-х адепты экстремального программирования (Extreme Programming) садились по двое за один монитор: один стучит по клавишам, второй смотрит через плечо, ловит ошибки, думает на шаг вперёд. Техника спорная, многие её недолюбливают — но те, кто пробовал по-настоящему, знают: два мозга за одной задачей выдают результат, который ни один из них в одиночку бы не осилил. И вот теперь эту же идею перенесли на ИИ-агентов. Причём не в лабораторных условиях, а в виде конкретного инструмента, который уже можно запустить.
Что сделал Аксель Делафосс и почему это интересно
Аксель Делафосс — разработчик, который заметил любопытный паттерн. Работая одновременно с Claude и Codex (AI-движок от OpenAI), он обнаружил: когда оба агента проверяют один и тот же код, они дают разную обратную связь. И это не баг — это фича. Разные модели обучались на разных данных, у них разные «слепые зоны» и разные сильные стороны. Но когда их замечания совпадают — это перестаёт быть просто советом и становится сигналом, который нельзя игнорировать. Команда Акселя стала исправлять 100% замечаний, с которыми согласились оба ревьювера. Не 80%, не 95% — все до единого.
На основе этого наблюдения Аксель написал loop — CLI-инструмент, который запускает Claude и Codex бок о бок в tmux и создаёт между ними «мост» для прямого общения. Один агент пишет код, второй его ревьюит, и они итеративно улучшают результат — прямо как два живых программиста.
Как это работает технически
Архитектура loop подкупает простотой. Вот что происходит, когда вы его запускаете:
🖥️ Два параллельных TUI. Claude Code и Codex (через CLI) стартуют в отдельных окнах tmux. Каждый видит один и тот же репозиторий и работает в своём контексте.
🔗 Мост между сессиями. Специальная прослойка перебрасывает сообщения из одного окна в другое. Когда Claude пишет фрагмент кода, Codex получает его для ревью — и наоборот. Это не последовательный пайплайн, а живой диалог.
🧠 Сохранение контекста. В отличие от разовых запросов к API, контекст сохраняется между итерациями. Агенты «помнят» предыдущие обсуждения и наращивают понимание задачи с каждым циклом.
👤 Человек в петле. Поскольку оба агента работают в интерактивных терминальных интерфейсах, вы можете в любой момент вмешаться: ответить на вопрос, скорректировать направление, принять или отклонить предложение. Это не «чёрный ящик», а прозрачный процесс.
Важный нюанс: loop не изобретает новый протокол связи между агентами. Он просто умно использует tmux — мультиплексор терминала, который существует с 2007 года. Иногда самые элегантные решения строятся на инструментах, которым больше лет, чем некоторым фреймворкам.
Почему два агента объективно лучше одного: данные
Идея «разделяй и властвуй» в мультиагентной разработке — не просто красивая теория. Есть конкретные цифры.
Исследование AgentCoder, опубликованное ещё в 2023 году, показало впечатляющие результаты мультиагентного подхода к генерации кода. Три специализированных агента — программист, дизайнер тестов и исполнитель тестов — работали в связке. Результат?
📈 96,3% pass@1 на бенчмарке HumanEval с GPT-4. Для сравнения: лучший одноагентный подход на тот момент выдавал 90,2%. Кажется, что разница невелика, но на бенчмарках такого уровня каждый процент — это десятки задач, которые раньше агент просто не мог решить.
📈 91,8% pass@1 на MBPP — ещё один стандартный бенчмарк для кодогенерации. Предыдущий рекорд — 78,9%. Тут разрыв уже сложно не заметить.
📈 Вдвое меньше токенов. AgentCoder тратил ~57 000 токенов на задачу из HumanEval, тогда как конкурирующие мультиагентные фреймворки (MetaGPT, ChatDev) расходовали 138–183 тысячи. Меньше агентов, чётче роли — меньше болтовни, больше дела.
А вот самый тонкий момент: почему вообще нужно разделять написание кода и тестов между разными агентами? Когда один и тот же агент пишет и код, и тесты к нему, он начинает «подстраивать» тесты под реализацию. Тесты проверяют, что код делает — а не что он должен делать. Это хорошо знакомая проблема из мира людей: разработчик, пишущий тесты на свой же код, бессознательно обходит слабые места. Разделение ролей ломает этот порочный круг.
Навигатор и водитель: TDD-подход в мультиагентной архитектуре
Есть и более продвинутые реализации той же идеи. Разработчик Шивам Агарвал построил систему парного программирования для Claude, где два суб-агента работают по классической схеме TDD (Test-Driven Development):
🧭 Навигатор — стратег. Анализирует требования, пишет падающие тесты (тесты, которые заведомо не пройдут, потому что кода ещё нет), затем проверяет реализацию. Использует более «тяжёлую» модель — Claude Opus — для глубокого анализа.
🚗 Водитель — тактик. Пишет минимальный код, чтобы тесты прошли, затем рефакторит. Использует Claude Sonnet — модель быстрее и дешевле, идеальную для итеративной работы.
Ключевое правило: навигатор никогда не пишет код, а водитель никогда не пишет тесты. Их контексты изолированы. Это не техническое ограничение, а сознательный дизайн — чтобы тесты оставались объективными и не «загрязнялись» знанием реализации.
Если вы когда-нибудь работали в паре по TDD, эта схема покажется до боли знакомой. И в этом вся суть: лучшие агентные рабочие процессы выглядят не как футуристическая автоматизация, а как копирование проверенных человеческих практик.
Репозитории тоже хотят общаться
Пока loop решает задачу парного программирования в одном репо, другой проект — Repowire от Прассанны Равишанкара — заходит с другой стороны. Repowire — это mesh-сеть для AI-агентов, которая позволяет сессиям Claude Code в разных репозиториях общаться в реальном времени.
Представьте типичную ситуацию: у вас есть фронтенд-репозиторий и бэкенд-репозиторий. Фронтенд-агенту нужно узнать формат API-ответа. Обычно он полезет в документацию, которая, скорее всего, устарела. С Repowire он может напрямую спросить бэкенд-агента — и получить ответ на основе актуального кода.
Техническая реализация изящна: агенты живут в отдельных tmux-окнах, сгруппированных в «круги» (circles). Общение происходит только внутри круга — это своеобразный VPC (виртуальная частная сеть) для кодящих агентов. Сам автор описывает разницу с конкурирующими решениями так: Repowire — это телефонный звонок (синхронный, эфемерный), а не email с менеджером проекта (асинхронный, персистентный). У Repowire нет центрального оркестратора — агенты сами решают, когда и о чём спрашивать друг друга.
Более широкая картина: куда всё движется
То, что мы видим сейчас — это начало серьёзного сдвига. Исследователи из Cursor (популярного AI-редактора кода) обнаружили, что самые эффективные агентные воркфлоу выглядят поразительно похоже на обычную человеческую командную работу. В Claude Code уже появилась экспериментальная фича Agent Teams для координации нескольких агентов. OpenAI тоже движется в эту сторону со своими мультиагентными возможностями в Codex.
Вот что, на мой взгляд, важно понять: мы наблюдаем конвергенцию. Годами AI-разработка шла по пути «один суперумный агент, который делает всё». Теперь оказывается, что несколько специализированных агентов, общающихся друг с другом, работают лучше. Почти как в человеческих командах — кто бы мог подумать.
Делафосс точно формулирует эту мысль: будущее агентных рабочих процессов выглядит не как магическая автоматизация, а как знакомая командная работа. И это, пожалуй, самый здоровый подход. Вместо того чтобы ждать AGI, который «сам всё сделает», мы строим инструменты, которые встраиваются в существующие процессы разработки.
Открытые вопросы и подводные камни
Но не всё так гладко. Когда два агента работают в цикле, они могут наплодить больше изменений, чем вы ожидали. Делафосс сам признаёт: это обычно хорошо, но делает человеческое ревью сложнее. Как просматривать PR на 500 строк, когда вы ожидали 50?
Сообщество пока ищет ответы на несколько фундаментальных вопросов:
🤔 Как дробить работу? Один большой PR или несколько маленьких? Когда агенты генерируют много кода, атомарные коммиты и отдельные PR для каждой логической единицы — это не роскошь, а необходимость.
🤔 Где хранить план работы? В PLAN.md в репозитории? В описании PR? Агенты сами могут генерировать и обновлять планы, но людям нужно их видеть.
🤔 Нужны ли «доказательства работы»? Скриншоты, видеозаписи, логи — что-то, что позволяет человеку быстро понять, что именно агенты сделали и почему.
🤔 Как управлять стоимостью? Каждая итерация диалога между агентами — это токены. Два агента болтают друг с другом — расход удваивается. При плотном цикле обратной связи счёт за API может неприятно удивить.
Что всё это значит для вас
Если вы работаете с несколькими AI-инструментами — а по данным из сообщества, многие разработчики используют одновременно Claude Code и Cursor, или Claude и Codex — идея мультиагентного взаимодействия уже актуальна. Вы и так получаете разные перспективы от разных моделей. loop просто формализует этот процесс и делает его автоматическим.
Для тимлидов и техлидов здесь другой ракурс: мультиагентное ревью может снять заметную часть нагрузки с человеческих ревьюеров. Не заменить их — именно снять рутину. Когда два агента уже согласились, что в коде есть проблема, человеку остаётся только подтвердить — а не искать её самому.
А в более отдалённой перспективе мы, возможно, увидим что-то вроде «офиса» из AI-агентов: фронтендер, бэкендер, тестировщик, DevOps-инженер — каждый в своей роли, каждый со своей моделью, каждый в своём репозитории. Звучит как научная фантастика? Все кусочки паззла уже на столе. Осталось собрать.
Источники
🔗 Agent-to-agent pair programming — Axel Delafosse (оригинальная статья)
🔗 loop — CLI для мультиагентного парного программирования (GitHub)
🔗 Когда ИИ-программисты работают в паре — Telegraph
🔗 Claude Code TDD Pair Programming Sub-agents — Medium
🔗 Repowire: mesh-сеть для AI-агентов (GitHub)
🔗 AgentCoder: Multi-Agent Code Generation — arXiv