Юрий Панчул, автор проекта basics-graphics-music (BGM), опубликовал отчёт о нестандартном подходе к разработке Bash-скриптов. Вместо того чтобы писать код самостоятельно, он запустил два ИИ-агента — Claude и Codex — в отдельных клонах одного и того же репозитория. Каждому агенту была поставлена задача доработать скрипт поддержки Xilinx, при этом агенты должны были анализировать работу конкурента, указывать на ошибки и заимствовать удачные идеи. Итоговый материал, сгенерированный ИИ по заданному промпту, описывает процесс сближения двух независимых решений к единому результату. Сам Панчул честно оговаривается: он не виртуоз Bash-скриптинга, но способен оценить качество кода на Bash, и этого оказалось достаточно, чтобы поставить полезный опыт. Отчёт опубликован на русском и английском языках, а исходные сессии сохранены в репозитории в каталоге misc/ai_sessions/20261003_xilinx_support.

Проект BGM представляет собой коллекцию переносимых примеров на SystemVerilog для проектирования на ПЛИС и заказных микросхем. Скрипты позволяют выбрать плату, синтезировать проект, выполнить размещение и трассировку, а затем прошить устройство. Сейчас BGM поддерживает 54 различные платы, включая линейки Terasic DE, Digilent Arty, Nexys и Basys, семейство Sipeed Tang, iCEBreaker, OrangeCrab, Karnix, «Марсоход», ALINX и OMDAZZ. За этими платами стоят пять наборов инструментов: Intel Quartus, AMD Vivado, Gowin EDA, средства Lattice и открытый поток на основе Yosys. Общее число конфигураций достигает 112 каталогов, поскольку одна плата может иметь несколько вариантов — например, для Tang Nano 9K существует восемнадцать каталогов с разными модулями, экранами и способами сборки. Ещё четырнадцать каталогов приходится на Tang Primer 20K Dock и по семь — на iCEBreaker и Tang Nano 20K. Этот зверинец не нужно уничтожать — он и есть реальность преподавания цифровой схемотехники, а скрипты существуют, чтобы его спрятать.

Техническая проблема, с которой столкнулся проект, связана с изменением структуры каталогов Vivado. До версии 2024.2 инструмент устанавливался по пути вида <родительский каталог>/Xilinx/Vivado/2023.1, и скрипт искал его в $HOME, /opt и /tools. Начиная с версии 2024.2 компания AMD изменила схему: номер версии теперь стоит выше названия продукта, а каталог вендора может называться не Xilinx, а AMD. Это привело к тому, что скрипт перестал находить Vivado. Более того, при установке без каталога версии скрипт перебирал внутренние подкаталоги самого Vivado, такие как tps, scripts и lib, принимая их за номера версий, сортировал по алфавиту и выбирал последний, после чего выводил предупреждение о нескольких установленных версиях. Студент, столкнувшийся с такой ошибкой, получал неработающую конфигурацию и терял время на диагностику. Именно такие краевые случаи, связанные с обработкой путей, проверкой версий и генерацией предупреждений, и стали полигоном для соревнования двух агентов.

Контекст эксперимента выходит за рамки одного скрипта. BGM активно используется в образовательных семинарах и курсах по цифровой схемотехнике. География применения включает Американский университет в Центральной Азии в Бишкеке (2022), LaLambda в Тбилиси (2023), Университет ADA в Баку и Hacker Dojo в Кремниевой долине (2024), Автономный университет Нижней Калифорнии в Тихуане, Российско-Армянский университет и Институт проблем информатики и автоматизации НАН РА в Ереване (2025). Отдельно стоит Школа синтеза цифровых схем, семинары которой проходят в 25 университетах России и Белоруссии, — это самый массовый потребитель этих примеров. Для преподавателей BGM ценен тем, что убирает сложность вендорских инструментов с первой недели курса, позволяя студентам сразу запускать лабораторные работы на разных платах одними и теми же командами. Когда в аудитории оказываются студент с Tang Nano 9K и студент с Nexys A7, оба должны уметь запустить одну и ту же лабораторную из одного репозитория одними и теми же двумя командами. Каждый час, потраченный на слой Bash-скриптов, возвращается сотней часов, которые другие люди не потратят на борьбу с инструментами.

Метод соревнования двух ИИ-агентов представляет интерес для российского рынка разработки и образования. В условиях, когда доступ к некоторым зарубежным инструментам и облачным сервисам ограничен, локальные решения на основе открытых моделей или доступных API становятся особенно актуальными. Подход, при котором два агента независимо анализируют задачу и критикуют друг друга, может снизить вероятность ошибок, связанных с галлюцинациями или неполным пониманием контекста. Для проектов, поддерживающих десятки плат и несколько наборов инструментов, такая методика позволяет быстрее выявлять краевые случаи, которые человек мог бы пропустить. Кроме того, сам отчёт опубликован на русском и английском языках, что делает его доступным для широкой аудитории. Показательно, что автор не скрывает происхождение текста: он прямо указывает, что пост сгенерирован ИИ от первой до последней буквы, за исключением картинки, и прикладывает промпт — это задаёт планку честности для подобных экспериментов.

По сравнению с традиционными методами разработки, где один программист пишет код и затем проходит ревью, схема с двумя ИИ-агентами добавляет этап автоматической взаимной проверки. Это не заменяет человеческую экспертизу, но может ускорить итерации и повысить качество рутинных частей — таких как обработка путей, проверка версий и генерация предупреждений. В случае с BGM задача осложняется тем, что скрипты должны работать на разных операционных системах и с разными наборами инструментов. Альтернативой могло бы быть написание тестов для каждого сценария, однако поддержка 112 конфигураций делает полное покрытие трудоёмким. ИИ-агенты в этом смысле выступают как дополнительный уровень защиты от регрессий.

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