Агенты программирования принимают решения последовательно: сначала составляется план, затем он реализуется и тестируется. Любая ошибка, допущенная на раннем этапе, усугубляется, поскольку последующие шаги строятся на том же ошибочном предположении. Самопроверка — это признанная техника снижения рисков, которую уже поддерживает GitHub Copilot, но модель, анализирующая собственный вывод, всё ещё ограничена теми же обучающими данными и слепыми зонами, которые его породили.
GitHub устранил это ограничение на этой неделе, выпустив Rubber Duck — функцию кросс-модельной проверки, доступную сейчас в экспериментальном режиме в GitHub Copilot CLI.

Rubber Duck — это специальный агент-рецензент, работающий на модели из другого семейства ИИ, отличного от того, которое обрабатывает основной сеанс Copilot. Когда разработчик выбирает модель Claude в качестве оркестратора в селекторе моделей, Rubber Duck запускается на GPT-5.4. Разные семейства моделей несут разные предубеждения, заложенные при обучении, поэтому проверка от дополнительного семейства выявляет ошибки, которые основная модель может постоянно упускать.
Задача рецензента узконаправленна. Он создаёт краткий список проблем: предположения, которые основной агент сделал без достаточных оснований, граничные случаи, которые были упущены из виду, и детали реализации, которые конфликтуют с требованиями в других частях кодовой базы.
«Наши оценки показывают, что связка Claude Sonnet + Rubber Duck закрывает 74,7% разрыва в производительности между Sonnet и Opus по отдельности, демонстрируя лучшие результаты при решении сложных многозадачных и длительных задач», — пояснили исследователи Ник МакКенна и Бартек Перц.
Улучшения были более заметны на сложных проблемах. На задачах, охватывающих три или более файлов, которые обычно требуют 70 или более шагов, Sonnet в паре с Rubber Duck показал результат на 3,8% выше, чем базовый Sonnet, и на 4,8% выше на самом сложном подмножестве задач, выявленном в ходе трёх испытаний.
GitHub представил три примера ошибок, которые обнаружил Rubber Duck в ходе тестирования. В первом случае, связанном с асинхронным планировщиком OpenLibrary, Rubber Duck выявил, что предложенный планировщик завершал работу сразу после запуска, не выполнив ни одной задачи, и что одна из запланированных задач сама по себе являлась бесконечным циклом. Во втором случае, касающемся обработки фасетов Solr, Rubber Duck обнаружил цикл, который молча перезаписывал один и тот же ключ словаря на каждой итерации, из-за чего три из четырёх категорий фасетов исключались из поисковых запросов без каких-либо ошибок. В третьем примере, связанном с процессом подтверждения email в NodeBB, Rubber Duck определил, что три файла читали данные из ключа Redis, в который новый код перестал записывать, что молча сломало бы интерфейс подтверждения и процессы очистки при развёртывании.
Rubber Duck можно запустить автоматически или по запросу. GitHub Copilot вызывает его автоматически на трёх контрольных точках: после того, как агент составит план, после сложной реализации и после написания тестов, но перед их запуском. Агент также может реактивно вызвать Rubber Duck, если зациклится. Разработчики могут запросить критический разбор в любой момент сессии; Copilot обратится к Rubber Duck, учтёт обратную связь и покажет, что было изменено и почему.
Дизайн намеренно ограничивает частоту активации Rubber Duck. Цель — выявлять ценную информацию именно на тех контрольных точках, где это наиболее важно, не добавляя шума к рутинным задачам. Rubber Duck работает через существующий инструмент задач Copilot, ту же инфраструктуру, что используется для других под-агентов.
Rubber Duck доступен сейчас в экспериментальном режиме в GitHub Copilot CLI. Разработчики получают к нему доступ, выполнив слеш-команду /experimental. Для работы функции требуется выбранная модель Claude в селекторе моделей и доступ к GPT-5.4. GitHub активировал Rubber Duck для всех моделей семейства Claude в роли оркестратора, включая Opus, Sonnet и Haiku, и заявляет, что исследует дополнительные комбинации семейств моделей для будущих конфигураций.