Как устроена кастомная система AI-агентов ai-bro для разработки

Современные разработчики нередко создают собственные инструменты для автоматизации рутинных задач. В материале рассматривается устройство независимого набора навыков ai-bro, который проектировался как альтернатива существующим шаблонным решениям для работы с искусственным интеллектом.

Автор проекта проанализировал популярные подходы вроде строгой методологии TDD в плагинах и многословных спецификаций в OpenSpec, выявив их практические ограничения. На основе этого опыта была сформирована собственная концепция взаимодействия с AI-агентами, разделенная на последовательные этапы обсуждения, планирования и реализации.

Почему стандартные подходы не подошли

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

Другой известный инструмент, OpenSpec, привлек внимание регламентированным процессом спецификации-ориентированной разработки (SDD), однако его спецификации оказались слишком объемными и многочисленными. Подобная жесткая стандартизация снижает общую гибкость рабочего процесса, из-за чего потребовалось создание собственной модульной системы навыков.

Концепция и этапы работы ai-bro

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

Обсуждение задачи

Взаимодействие с AI-агентом начинается с этапа обсуждения, так как прямое выполнение команд часто приводит к непредсказуемым результатам из-за готовности моделей беспрекословно следовать любым инструкциям. Для этого применяется специальный навык диалога, в рамках которого модель заводит разговор и задает вопросы строго по одному, предотвращая лавину неструктурированных уточнений. Такой подход позволяет выбрать правильную стратегию в зависимости от специфики запроса и сберечь контекст главного оркестратора, перекладывая нагрузку на вспомогательные модули.

Спецификации и планы

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

Реализация и итерации

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

Стандартная итерационная цепочка выглядит следующим образом:

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

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

Финализация

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

Оркестрация моделей и разделение по тирам

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

В зависимости от сложности и неопределенности поставленной задачи задействуются разные категории моделей:

• junior — выполняют простые рутинные задачи с очевидными последовательными шагами;
• middle — обрабатывают запросы со средним уровнем неопределенности умеренного объема;
• senior — берут на себя наиболее сложные архитектурные и логические задачи;
• critical — выделенный уровень для контроля безопасности и финансовых логических модулей.

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