Как я заставил Claude и Codex соревноваться при написании Bash-скрипта

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

Сразу отмечу, что речь идет о реальной задаче в рамках проекта basics-graphics-music, а не об абстрактных тестах. Организовать соревнование двух ИИ-агентов оказалось гораздо продуктивнее, чем писать код самостоятельно или просить одну модель проверять собственную работу.

О репозитории basics-graphics-music и зоопарке плат

Проект BGM представляет собой обширную коллекцию переносимых примеров на SystemVerilog, предназначенную для работы с ПЛИС и заказными микросхемами. Пользователь выбирает плату специальной командой, после чего запускает второй скрипт для полной автоматизации синтеза, разводки и прошивки устройства. Главная ценность инфраструктуры кроется в ее скриптах и обертках, которые скрывают всю рутину от пользователя.

Масштаб поддерживаемого оборудования

На текущий момент репозиторий охватывает 54 уникальные аппаратные платформы, включая продукцию Terasic, Digilent, Sipeed, а также платы серии iCEBreaker, OrangeCrab и отечественные «Марсоход». При этом задействуется сразу пять инструментальных экосистем: Intel Quartus, AMD Vivado, Gowin EDA, инструменты Lattice и открытый стек Yosys.

Огромное число конфигураций объясняется разнообразием периферии и вариантов сборки. Например, для одной лишь платы Tang Nano 9K предусмотрено восемнадцать различных подкаталогов. Преподаватели используют такую гибкость на семинарах, где у студентов могут оказаться совершенно разные устройства, требующие запуска одинаковых лабораторных работ.

Проблема поиска сред разработки от AMD

Поводом для вмешательства стали изменения в структуре каталогов ПО Vivado. Раньше утилиты инсталлировались по предсказуемому пути с именем вендора и продукта перед версией. Начиная с выпуска 2024.2, компания AMD изменила схему именования директорий, из-за чего старый механизм инициализации перестал работать.

Хуже того, при отсутствии явного каталога версий старый скрипт начинал сканировать внутренние папки самого Vivado вроде tps или lib. В результате система выдавала сбивающие с толку предупреждения об обнаружении множества версий, а студент получал ошибку отсутствия утилиты в системном пути совсем не там, где крылась реальная проблема.

Организация эксперимента с двумя агентами

Для исправления ситуации я создал два независимых клона репозитория в изолированных директориях и подключил к работе Claude и Codex. Искусственный интеллект трудился в разных ветках, не подозревая о существовании конкурента. Мой рабочий процесс состоял из трех повторяющихся шагов:

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

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

Первый раунд сравнения реализаций

Обе модели успешно справились с базовой поддержкой новых путей, но обнаружили принципиально разные нюансы. Например, Codex уделил внимание пользователям Windows, запускающим среду под Cygwin или MSYS. В таких окружениях системная команда sort может указывать на утилиту sort.exe, не умеющую корректно сортировать версии.

Различия в подходах к диагностике

Чтобы избежать сбоев, Codex реализовал проверку бинарных файлов sort с помощью тестовой подстановки строк с версиями. Claude же сосредоточился на чистоте пользовательской оболочки: поскольку скрипт подключается через source, забытые локальные переменные засоряют сессию. Первоначальный вариант оставлял семь переменных, версия Claude одиннадцать, а вариант от Codex не оставлял мусора вовсе.

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

Второй раунд и схождение результатов

После обмена взаимными рецензиями агенты начали стремительно заимствовать лучшие практики друг друга. К финальному этапу обе версии перешли на эффективные шаблоны оболочки, внедрили строгие проверки каталогов и научились отсекать нерабочие утилиты сортировки.

Финальное тестирование на идентичных виртуальных деревьях каталогов показало абсолютную стабильность: в 11 тестовых сценариях оба скрипта выбирали абсолютно одинаковые пути. В сухом остатке Codex выдал более компактный и чистый код без лишних переменных, а Claude победил в категории информативной диагностики для обучающихся.

Главные выводы из опыта

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

Практическая польза автоматизированного тестирования

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

Все сравнительные отчеты теперь надежно задокументированы внутри репозитория, что избавляет от необходимости держать технические подробности в голове. Проект basics-graphics-music продолжает развиваться, а гибридный метод взаимодействия человека и ИИ доказал свою состоятельность на практике.