Сегодня я рад показать мой новый проект, над которым я работал последние 2 месяца - Builder.
Это бесплатный и открытый агент для программирования, созданный специально для профессиональных агентных инженеров, который работает с вашей существующей подпиской на токены.
Зачем своё, если есть CC и Codex?
Я больше пяти месяцев пользовался ClaudeCode, потом долгое время - Codex CLI и десктоп-приложением, Opencode, Junie и другими. И у всех этих крупных проектов есть три главных проблемы для меня.
Непрозрачность
Существующие инструменты непрозрачны для профессионального инженера. В Junie вместо реальных команд, которые выполняет агент, видны только однострочные описания того, что происходит. В Codex вызовы команд агрессивно скрываются и доступны только в режиме транскрипта. А в Claude Code вместо того, чтобы дать модели свободу работать через bash-команды, используется свой непрозрачный кастомный набор инструментов для чтения, записи файлов и поиска.
Это, может быть, подходит тем, кто не хочет смотреть на код и не хочет разбираться в том, что происходит. Но для инженера, который понимает процесс и хочет работать с моделью коллаборативно, как с парным программистом, - это плохо подходит. И ни одна агентная обёртка, которую я знаю, до сих пор не фокусируется на инженерах.
Раздутый функционал
Во многих агентных harness’ах есть большое количество фич “вайбкодеров”, которые нужны людям со специфическими workflow. При обычной работе агентным инженерам они только усложняют задачу. Я говорю, например, про режим планирования, 38+ постоянных уведомлений в ClaudeCode, режимы оркестрации, Swarm, плагины, Explorer-агенты и т.д.
Всё это не только мешает модели и засоряет контекст, но ещё и портит пользовательский опыт - а пользу от подобных “улучшений” никто до сих пор не доказал по сравнению с обычным промптингом и итеративной работой с агентом. Поэтому я хотел агента без режима планирования (который только ограничивает модель), и без свистоперделок, которые красиво оформляют ответы, заставляя модель галлюцинировать (смотрю на тебя, Junie). Отдельного упоминания заслуживают MCP, которые давно считаются антипаттерном в агентной разработке: они засоряют контекст бесполезными инструментами, и большинство из них не могут использоваться совместно с bash-тулами.
Всё это заменяется более эффективными стратегиями для инженеров, которые управляют моделью как агентом по написанию кода, а не делегируют ей собственное мышление.
Нестабильность и закрытость
В подобных харнесах часто есть своё видение того, как вещи должны делаться, - и это видение постоянно меняется. С каждым обновлением можно рассчитывать на то, что workflow тоже как-нибудь поменяется. Непонятно, что происходит под капотом: какой там системный промпт, как происходит компакшн, нет нужных настроек, нет возможности адекватно переключать модели или провайдеров. Непонятно, что попадает в контекст, когда происходит инвалидация кэша и что изменилось в последнем обновлении, которое могло сломать ваш workflow без спроса.
Мне просто надоело, что в один прекрасный день я сажусь за работу, а мой агент резко начинает галлюцинировать - а всё оказывается из-за очередного скрытого бага в харнесе, который что-то инвалидировал под капотом и отправлял модели неверные данные. Поэтому я решил написать свой харнес.
Чем лучше Builder
Совместная работа над архитектурой
Многие harness’ы не дают моделям работать вместе с пользователем над продуктовым и архитектурным дизайном. Одна из ключевых вещей в моей обёртке - это возможность для агента всегда задать вопрос, как только у него возникает проблема, блокер, или он находит в коде что-то, что хотел бы отрефакторить или улучшить.
На практике это результирует в намного лучшем качестве работы: агенты больше не пытаются, как бульдозер, продраться сквозь все проблемы и в итоге реализовывать ужасные нерабочие решения или уничтожать архитектуру. Вместо этого задают вопрос и решают проблему вместе с юзером.
Инструментированный workflow вместо слепого доверия
Вторая ключевая вещь - это развитие агентных harness’ов от простого цикла, в котором крутится агент и которому просто доверяют сделать всё правильно, до чёткого инструментированного workflow, который не даст агенту совершать глупых ошибок. Многие агенты начинают галлюцинировать - и это нормально для текущего уровня моделей. Даже люди забывают о чём-то, теряют контекст, упускают мелочи, которые на самом деле могут быть важными. Поэтому в Builder за работой вашего агента всегда наблюдает отдельный параллельный агент, который проверяет выдачу на качество и соответствие правилам вашего проекта.
Качество вместо экономии токенов
Крупные оболочки для агентов сейчас ориентированы на быстрые фиксы, минимально возможные решения, экономию контекста и токенов. По сути, вы платите качеством результата и своим временем, которое потом тратите на исправление за моделью - ради пары тысяч сэкономленных токенов и на 20% более быстрое выполнение.
В дизайне Builder я ориентируюсь в первую очередь на качество выдачи: правильную архитектуру, безопасность кода, производительность, решения из первых принципов - а не на хаки, которые сейчас являются вариантом по умолчанию для практически всех агентов.
Что уже есть
Я уже полностью заменил Codex CLI на Builder и больше не открываю его. Использую для всех задач, включая рабочие.
Текущий функционал:
- Агентный цикл, эквивалентный Codex CLI
- Фоновые задачи, фоновые агенты, субагенты, оркестрация
- Супервайзер - параллельный агент, который постоянно наблюдает за моделью и улучшает её результаты
- Авто и ручной компакт контекста в нескольких режимах; нативный компакшн Codex поддерживается через настройки, но я давно пользуюсь собственным компактом Билдера, который в несколько раз лучше по качеству
- Два режима отображения: компактный и детальный. В детальном режиме доступна вся подробная информация о том, что делала модель - что-то вроде режима просмотра транскрипта, но с намного большим количеством данных, чем в Codex или Claude Code
- Вопросы от модели к пользователю
- Функционал стиринга модели и постановки промптов в очередь
- Нативный просмотр картинок и PDF
- Нативный поиск в вебе
- История промптов и сессий
- Уведомления (включая системные) об окончании работы модели
- Поддержка стандарта agents.md
- Поддержка Agent Skills
- Syntax highlight кода
- Кастомные slash-команды и множество встроенных
- Редактирование и форк переписок
- Множество горячих клавиш
- Тоглы для OpenAI: быстрый режим, model verbosity, режим мышления
Сейчас активно веду работу над управлением worktree, а также готовлю архитектуру для нативного десктоп-приложения.
Закончил ревью кода
Чего не будет
Чтобы вы могли решить, стоит ли вам пользоваться Builder, вот что конфликтует с его философией и не будет реализовано:
- Поддержка MCP - засоряет контекст и несовместим с bash-тулами
- Режим планирования - пережиток моделей антропик, который ограничивает модель
- UI-свистоперделки для тех, кто не занимается серьёзным программированием
- Микрокомпакт и всё, что инвалидирует кэши - это стоит очень много денег
- Сэндбокс - в ClaudeCode, Codex и Junie до сих пор нет нормального сэндбоксинга, и я давно пользуюсь ими без него. Как профессиональный инженер я просто не попадаю в ситуации, когда модель что-то удаляет. Сейчас безопасность обеспечивается адекватным промптингом; редактирование файлов при этом настраиваемо и можно ограничить доступ. Сэндбоксинг не спасёт вас ни на какой операционке от деструктивных действий - так что я решил просто не надевать шляпу из фольги.
- WebFetch или аналог - для этого уже есть CLI, стандарты Markdown и скиллы. Не нужен лишний инструмент, который отдаёт модели обработанную LLM’кой статью с Medium. Просто используйте любой CLI-скрипт вроде jina.ai, если агенту нужен доступ к интернету.
- Подписки Gemini и Anthropic - потому что это теперь у нас нелегально.
Текущее состояние
Продукт вполне готов к использованию, но я понимаю, что в первую очередь ориентировался на тот функционал, который использую сам, чтобы побыстрее начать догфудить. Поэтому я не тестировал работу агента на Windows и Linux, не тестировал работу с голым API-ключом и не реализовывал поддержку других провайдеров моделей.
Пожалуйста, пишите о любых проблемах и недостающих фичах - заводите issue на GitHub, и я постараюсь всё адресовать. Буду рад любой обратной связи.
Буду также рад звёздочкам на GitHub.