Создание Bencher в 2026 году: открытый исходный код, без инвесторов и на агентной таблетке

Everett Pompeii

Это эссе было изначально подано на The Pragmatic Engineer’s How Software Engineering is Changing Essay Challenge 4 октября 2026 года.

Этот год ознаменовался радикальным сдвигом в том, как я создаю программное обеспечение. Я staff-инженер по программному обеспечению. За последние шесть лет я профессионально писал на Rust и в единороге, которого поддерживали YC и a16z, и в компании из списка Fortune 500. Как выздоравливающий C++-разработчик, я обнаружил, что меня тянет к той глубине и тому мастерству, которых требовал Rust. Я стал искусным ремесленником, вручную вытачивающим системное ПО реального времени. За последние десять месяцев мне пришлось похоронить эту идентичность. Хотя в моей должности по-прежнему написано «инженер-программист», моя работа теперь состоит в том, чтобы быть «инженером контекста».

Последние четыре года я по ночам и выходным строил бизнес с открытым исходным кодом и без внешних инвестиций, Bencher. Bencher является платформой непрерывного бенчмаркинга, которая помогает инженерам системного ПО ловить регрессии производительности до того, как они попадут в основную ветку. Для этого нужен целый набор инструментов: CLI, API-сервер и фронтенд в виде веб-консоли. Каждый из этих компонентов, с точностью до погрешности округления, написал я. За эти годы у меня было несколько заметных контрибьюторов из open source сообщества, но подавляющая часть Bencher как open source проекта и 100% Bencher как бизнеса были спроектированы и реализованы мной лично.

За эти четыре года я не просто сидел под камнем. Я обручился, женился, и у меня родился первый ребёнок. На то, чтобы проработать крупную фичу и выкатить её, у меня уходили недели, а иногда и месяцы. Мне приходилось совмещать и разработку, и поддержку. У Bencher уже было много пользователей, так что я тратил немало времени на ответы на вопросы и исправление случайных багов.

В 2022 году моё использование LLM сводилось к бесплатной Rust-версии TabNine, инструмента для автодополнения по нажатию Tab, созданного студентом, который был одним из первых стажёров в OpenAI и работал там над забавным маленьким проектом под названием Codex. Как только запустился GitHub Copilot и неофициально добавил поддержку Rust, я раскошелился на $10 в месяц за личную лицензию.

Было сыровато. Но всё равно ощущалось немного как магия. Помню, как вскоре после того, как в расширение GitHub Copilot для VSCode добавили чат, я был поражён тем, насколько хорошо он создаёт процедурные макросы Rust. Обычно мне приходилось немного подправлять результат, но пару раз он справился с первой попытки. Обалдеть! Это было круто и, вероятно, помогло сэкономить немного времени, но в основном я продолжал работать так же, как и раньше.

С того момента у меня сложилось убеждение, что Microsoft со своим GitHub Copilot находится в авангарде. Даже если эти новомодные лаборатории выбрасывали на рынок каких-то «агентов», я мог быть уверен, что GitHub Copilot не отстанет, если появится что-то стоящее. Я слушал таких людей, как Dan Shipper, в Lenny’s Podcast, и их рассказы о возможностях моделей просто не сходились ни с моим опытом, ни с моей планкой качества.

В начале прошлого года я написал пост, подводящий итоги трёх лет разработки Bencher, Обзор Инженерии: Выпуск 2025 года. В том посте я разобрал все свои основные инженерные решения при создании Bencher: фронтенд, бэкенд, среда разработки, CI, что угодно. Я потратил целый абзац на то, чтобы выплеснуть, как тяжело мне было уложить в голове язык CUE двумя годами ранее. И при этом во всём этом тексте на 3 500 слов нет ни единого упоминания ИИ, LLM или хотя бы Copilot.

Перенесёмся вперёд меньше чем на год, и вот я уже сопереживаю эссе We mourn our craft.

Claude помогает спасти Рождество

Как и многие другие, на зимних праздниках 2025 года у меня появилась возможность по-настоящему поработать с Claude Opus 4.5. Я был в Лондоне в гостях у семьи моей сестры вместе с женой и ребёнком. Сестра недавно родила двойню, так что предполагалось, что я приехал помогать. Вместо этого я засел наверху, пытаясь отбиться от email-спама и DDoS-атак на Bencher. Claude очень помог в диагностике происходящего и в генерации идей для возможных решений.

В итоге я перенёс Bencher за Cloudflare и настроил reCAPTCHA. Большую часть работы всё ещё делал я сам, но Opus 4.5 стал заметным шагом вперёд в способности решать задачи с множеством конкурирующих проектных ограничений. Правда, он же предложил мне изменение, которое на полдня сломало удобный скрипт для установки Bencher CLI. Упс.

Новый год, новая обвязка

К январю этого года я уже несколько месяцев слышал о том, насколько впечатляет Claude Code. Раньше я не спешил его пробовать, потому что Opus 4 просто не дотягивал до моей планки качества, чтобы я мог доверять его работе. Теперь, когда Opus 4.5 до этой планки дотянул, я захотел попробовать и Claude Code. Скачок, который я увидел при переходе с Copilot в качестве обвязки на Claude Code, был таким же большим, как скачок при переходе с Opus 4/GPT-5.2/Gemini 2.5 Pro в качестве модели на Opus 4.5.

В свои самые первые выходные с Claude Code я провёл не особо контролируемый тест против Copilot. Я хотел, чтобы Copilot превратил PDF в аудиокнигу. Даже в «Agent Mode» Copilot проходил пять или шесть шагов, а потом просто останавливался, пока я снова его не пну. В то же самое время Claude Code вовсю пыхтел, пытаясь построить собственный гипервизор, после тщательного прохода в Plan mode. Я окончательно убедился, что уровень абстракции сместился с модели на обвязку и что Copilot уже никогда не догонит.

Мечты о Bencher Bare Metal

С самых первых дней Bencher я мечтал построить парк bare metal серверов для бенчмаркинга. Традиционные CI-раннеры, будучи виртуальными машинами, слишком шумные, чтобы давать стабильные результаты бенчмарков. Вы могли бы обнаружить, скажем, рост задержки на 200%, но никогда не смогли бы надёжно обнаружить рост на 20%. Счётчики инструкций представляют собой один из вариантов бенчмаркинга в CI. Они в основном детерминированы. Однако счётчики инструкций лишь косвенно отражают то, что вас на самом деле волнует: реальное время выполнения (wall-clock time). Всё, что выполняется в «симуляции CPU» и выдаёт счётчики инструкций, может лишь коррелировать со скоростью. Проблема в том, что вы никогда не знаете, насколько сильно или слабо они расходятся, пока не измерите на bare metal.

Одним из самых первых пользователей Bencher был проект Rustls. Я помог внести вклад в их Rustls bench runner. Однако это была не лучшая основа, на которой можно построить парк bare metal серверов для бенчмаркинга. Он работал на одном хосте и считал все бенчмарк-нагрузки доверенными. А это значит никаких PR из форков и никакой мультитенантности. К тому же большинство команд не хотят платить $100+ в месяц за каждый bare metal сервер для бенчмаркинга.

Я рассматривал вариант использовать GitHub Actions в качестве слоя оркестрации, но у этого подхода было несколько фундаментальных недостатков. Начнём с того, что GitHub Actions Runner написан на C#. Это значит, что его сборщик мусора может включиться посреди вашего прогона и исказить результаты бенчмарков. Ах да, и не забудьте отключить автообновление, чтобы оно не запустилось посреди прогона, но и не забывайте о нём слишком надолго, иначе ваши задачи перестанут запускаться!

Даже если бы GitHub Actions Runner был милым, тихим бинарником на Rust, более фундаментальная проблема заключалась в том, что он привязан к GitHub Actions. Bencher с самого начала был CLI-first. К лучшему или к худшему, я не хотел слишком сильно привязывать Bencher к какому-то одному CI-провайдеру. Есть GitHub Action для Bencher CLI, но всё, что он делает, это устанавливает для вас CLI. Я хотел, чтобы Bencher Bare Metal работал везде, где работает CLI, а не только в GitHub Actions.

Идея, к которой я пришёл, заключалась в том, чтобы упаковывать бенчмарк-нагрузку в OCI-образы и использовать опциональную, очень маленькую песочницу, чтобы на конкретном bare metal хосте всегда выполнялась только одна задача. Перспектива строить всё это в одиночку по ночам и выходным пугала. С основной работой и семьёй у меня ушёл бы минимум год, чтобы понемногу откалывать от этого по кусочку самостоятельно.

Создание Bencher Bare Metal

Имея на руках Opus 4.5 и Claude Code в январе этого года, я почувствовал, что наконец-то вижу практический путь к тому, чтобы построить Bencher Bare Metal. Я снова раскошелился, на этот раз на целых $200 в месяц за план Claude Max 20x. Пожалуй, лучшая бизнес-трата в истории.

Я начал работать на полную катушку и изо всех сил старался каждую неделю выбирать лимит своего плана Claude до конца. Я перестал писать код руками, и в Bencher, и на основной работе. На тот момент я всё ещё итерировал довольно короткими циклами: использовал Plan mode, читал весь вывод и работал в режиме Accept edits. Тогда я ещё не доверял агенту трогать git/jj, поэтому весь контроль версий брал на себя. Я считал себя этаким Ralph Loop с человеком в контуре. Примерно на пяти параллельно работающих агентах мой мозг начинал плавиться.

Один совет, который я слышал, заключался в том, чтобы реализацией и ревью занимались разные агенты, поэтому я начал проводить отдельные состязательные ревью. Эти состязательные ревью действительно заметно повышали качество результата. Я сделал собственного бота для ревью на GitHub Actions, который использовал API-ключ моей подписки Claude Code. Затем мой локальный агент итерировал с этим CI-ревьюером, чтобы экономить ресурсы моей локальной машины.

В какой-то момент я собирался поручить Claude построить собственный гипервизор для песочницы бенчмаркинга. Потом я попросил Claude провести состязательное ревью этого плана в роли Линуса Торвальдса, и он сказал мне, что я тупой и что это очень, очень, очень глупая идея. Никакого подхалимства, когда Линус у вас в контексте! Так что я выбросил этот план и выбрал Firecracker.

Враг хорошего бенчмаркинга не скорость как таковая, а вариативность. Поэтому, хотя Firecracker как гипервизор и добавляет накладные расходы, эти накладные расходы очень стабильны, особенно когда одновременно работает только одна microVM. Это позволяет общим раннерам Bencher Bare Metal обеспечивать одновременно и мультитенантность, и очень стабильные результаты бенчмарков. Вместе с Claude в Plan mode я также спроектировал всё так, чтобы песочница была опциональной. Если пользователь хочет запускать бенчмарки на собственном выделенном сервере, где он доверяет каждой нагрузке, то он может работать без Firecracker с почти нулевыми накладными расходами.

Разработка runner для Bare Metal стала для меня большим уроком о том, насколько важно для агентов иметь короткий цикл обратной связи. Даже после выхода Opus 4.6 Claude, казалось, с трудом добивался того, чтобы всё стабильно работало. Как только я дал ему доступ к среде разработки с включённым KVM (который нужен для запуска Firecracker), всё действительно начало складываться. Эти агенты не всеведущи, они просто очень упорны.

Степень придирчивости, с которой я проверял работу Claude, зависела от того, в какой части кодовой базы он работал. Код, который относился исключительно к Bare Metal, например OCI-реестр и бинарник runner, я проверял лишь поверхностно. Если он проходил состязательное ревью, сквозные тесты проходили и всё выглядело не слишком ужасно, я его мержил. Код, который затрагивал существующее ядро, то есть постановку задач в очередь и обработку отчётов, я проверял так же дотошно, как и всегда.

В конце марта этого года я выпустил Bencher Bare Metal в составе v0.6.0. Для публичного парка bare metal серверов я рассматривал AWS EC2 Bare Metal. Однако эти машины одновременно огромные и только на ARM. Чтобы соответствовать большинству реальных нагрузок, мне нужны были рабочие лошадки на Intel x86. Вместе с Claude я искал лучший дом для парка, который соответствовал бы проектным ограничениям. В итоге мы смогли предложить в Bencher Cloud Spec intel-v1, который даёт пользователям 4 vCPU, 48 ГБ памяти и 128 ГБ диска с поминутной оплатой. На хорошо структурированных бенчмарках я стабильно получал вариативность <2% между прогонами по всему парку.

Аутентификация агентов

До появления Bencher Bare Metal вся аутентификация строилась на JWT. Большие, красивые, непостижимые JWT. Аутентификация для раннеров Bare Metal использовала API-ключ с префиксом в имени, например bencher_runner_abc123....

На стороне клиента я хотел дать агентам что-то для работы, помимо собственного JWT API-токена пользователя. Золотой серединой, которую я нашёл, стала наконец-то реализованная давно запрошенная функция: аутентификация с областью действия на уровне проекта. Claude помог мне создать безопасные API-ключи с префиксом и областью действия на уровне проекта. Права этих API-ключей ограничены тем, что выполняет команда CLI bencher run: чтение в рамках проекта и неразрушающая запись. Благодаря этому такие API-ключи также естественно подходят для использования в CI-процессах непрерывного бенчмаркинга.

Позже, когда я добавил Bencher MCP, эти API-ключи с областью действия на уровне проекта стали использоваться для аутентификации и там. Стандарт MCP называет OAuth 2.1, однако он всё ещё в статусе черновика, поэтому я пока не хотел его реализовывать. Честно говоря, я довольно скептически отношусь к MCP. Я по-прежнему считаю, что хороший CLI + навыки представляют собой более эффективный и переносимый способ открыть сервис агенту. Однако самая большая проблема CLI в том, что у них нет стандартного механизма аутентификации. Так что, хотя OAuth 2.1 всё ещё черновик, по крайней мере в MCP это закрыто. А хорошая история с аутентификацией действительно важна для enterprise.

Claude-полиглот

Ещё в 2023 году я решил, что хочу, чтобы документация Bencher была доступна на 9 языках: английском, китайском, испанском, бразильском португальском, русском, японском, французском, немецком и корейском. Как я выбрал эти девять языков? Это языки, на которых была документация GitHub, так что я решил, что это достаточно хорошее приближение. Единственная проблема в том, что свободно я владею только английским. Поэтому я поручил GPT-4 перевести документацию за меня. В то время контекстное окно GPT-4 составляло всего 8k токенов. Это означало, что мне пришлось разбить все страницы документации на «чанки» размером меньше 8k токенов. Затем мне пришлось создать CLI-инструмент, который занимался переводом и очень часто повторным переводом чанков после их обновления.

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

Как только я начал использовать Claude Code с Opus 4.5, всё это исчезло. Теперь агент просто делает это. Соглашение о том, что считается чанком, есть прямо в кодовой базе, и Claude просто ему следует. Когда я писал техническую документацию для Bencher Bare Metal, Claude сам занимался разбиением на чанки и оркестровкой переводов. Хотя размер контекста теперь более чем достаточен, чтобы вместить целую страницу, мне нравится иметь чанки. Они помогают держать изменения изолированными, так что при правке заново переводятся только затронутые разделы страницы.

Кто не строил свою обвязку в 2026 году?

Пока я создавал Bencher Bare Metal, я также поручил Claude сделать для самого себя инструменты для управления парком. Они состояли из двух частей: CLI в репозитории bencher для рутинных задач и нового мета-репозитория (meta-repo). В этом мета-репозитории лежат вся документация и весь контекст по Bencher как продукту. Все остальные репозитории в GitHub-организации bencherdev подключены к этому мета-репозиторию как сабмодули. Мета-репозиторий позволяет агенту легко работать над задачей, которая может затрагивать несколько репозиториев, и писать документы, которые я предпочёл бы не делать публичными (продуктовая стратегия, отчёты об инцидентах и т. д.).

Я хотел построить поверх Claude Code CLI собственного агента, который превратил бы этот мета-репозиторий из артефакта в проактивную часть цикла разработки. Как только стал доступен Fable 5, я сосредоточил много сил на создании этого агента. Я хотел иметь возможность доверить этому агенту автономную работу. Большой частью этого была безопасность (т. е. защита от prompt injection). Я спроектировал всё так, чтобы рабочие агенты никогда не хранили никаких секретов. Все секреты подставляются сетевым прокси и ограничены эндпоинтами из allow-листа. Сами агенты работали в ещё одной microVM Firecracker, на этот раз параллельно. Управляющий сервер агента и сетевой прокси + песочницы работали на совершенно разных хостах.

Моё грандиозное видение заключалось в том, чтобы интерфейсом была очередь, отсортированная по приоритету задач. То есть цель этого агента состояла бы в том, чтобы показывать мне самую важную задачу в данный момент. Если ленты Facebook/Instagram/Twitter/X/TikTok оптимизированы под вовлечённость, то эта лента была бы оптимизирована под важность для меня.

Я хотел создать инструмент, который поставил бы меня ниже API. Я заметил, что большую часть времени трачу на переключение контекста и прыжки между тредами. Я надеялся, что агент поможет облегчить это жонглирование, расставляя всё для меня по порядку. С системой голосования «за» и «против», как на Reddit, я мог бы научить агента понимать, действительно ли то новое сообщение в Slack было самым важным, на что мне стоило обратить внимание.

Я также обнаружил, что большая часть моей работы теперь состоит в том, чтобы быть для своего агента Рубеусом Хагридом, его «хранителем ключей». Подстановка на уровне сетевого прокси с ограниченным allow-листом эндпоинтов оказалась лучшим способом, который мы с Claude смогли придумать, чтобы и не давать агенту доступа ни к одному секрету, и при этом позволить ему пользоваться инструментами вроде CLI gh прямо из коробки.

Другой главной целью было никогда не покидать интерфейс агента. Уход от агента по любой причине считается провалом обвязки. Я создал процедурную систему UI-компонентов, чтобы агент, работающий над задачей, мог на лету построить новый интерфейс или выбрать один из существующих компонентов в библиотеке в зависимости от текущей задачи. Код, почта, Slack, календарь, продакшен-телеметрия, мониторинг ошибок, всё в одном интерфейсе, всё в одной приоритизированной очереди.

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

Что происходит, когда число разработчиков вырастает в 100 раз?

В 2022 году я искал новый сайд-проект. Своё предыдущее начинание в стиле «хочу быть предпринимателем» я закрыл ещё в 2020 году. Совет на миллион: слушайте Jason Cohen, не пытайтесь бутстрапить маркетплейс.

На основной работе я писал статический парсер и анализатор bash на Rust и обнаружил, что мне приходится вести таблицу, чтобы отслеживать результаты своих бенчмарков. У проекта Rust есть rustc-perf для отслеживания производительности самого компилятора. И всё же хорошего инструмента, чтобы делать это для моего собственного кода, не было.

Я провёл очень много исследований уровня техники в этой области. За несколько месяцев я созвонился с несколькими разработчиками, которые либо создавали инструменты для непрерывного бенчмаркинга, либо выступали за их создание. Все изобретали велосипед. Мне казалось, что я нашёл тихую заводь на рынке. Была очевидная, постоянная потребность. Многие команды уже платили больше $100 в месяц за собственные bare metal раннеры. Значит, готовность платить была. И всё же сценарий использования был нишевым. Большая часть современного ПО разворачивается как сервис, поэтому сдвиг тестирования производительности влево для большинства команд не был таким уж приоритетом. Они просто настраивали алерты в Grafana после деплоя и задним числом ловили всё, что проскочило.

Однако с появлением по-настоящему способных агентов два фактора сильно увеличили использование Bencher:

1. Необходимость внедрять лучшие практики разработки ПО, чтобы детерминированно тестировать результат работы агентов
2. Лёгкость внедрения лучших практик разработки ПО с помощью агентов

LLM и, как следствие, агенты являются недетерминированными, стохастическими системами. Как и разработчикам-людям, им нужны ограждения, чтобы поддерживать качество кода. Способы сделать это не новы: надёжная система типов, стандартный форматтер, линтер, выкрученный на 11, тесты, тесты и ещё раз тесты. И всё это запускается в CI. Для нагрузок, чувствительных к производительности, эти тесты включают отслеживаемые бенчмарки. Отслеживание производительности ПО во времени позволяет ловить регрессии производительности в CI. Это называется непрерывным бенчмаркингом. Внедрение непрерывного бенчмаркинга всегда было немного муторным делом. Им занимались только команды, которым производительность была по-настоящему, по-настоящему важна, и из них получались отличные пользователи Bencher!

Но с приходом агентов добавление непрерывного бенчмаркинга в ваш рабочий процесс с помощью Bencher стало делом одного короткого промпта. Отследить это полностью сложно, но готов поспорить, что подавляющая часть входящих регистраций в Bencher теперь приходит по рекомендации агента или от агента, который регистрируется сам. Со временем это будет становиться только вернее, по мере того как всё больше разработчиков будут внедрять агентов и наделять их возможностями агентной коммерции. Может быть, это будет протокол x402, а может, и нет, но я думаю, что значительная часть трат на инструменты разработчика в будущем будет проходить через агентов. Рекомендую зарезервировать ваш Cloudflare Wallet и Stripe Wallet, если вы ещё этого не сделали.

Почти всем инструментам разработчика придётся перейти на оплату по факту использования в эпоху агентов. Оплата за каждое рабочее место не имеет смысла, когда вашим сервисом пользуются агенты. У Bencher всегда была оплата по факту использования. Однако с помощью Claude я недавно переработал модель ценообразования, чтобы сделать её ещё дружелюбнее к агентам. Раньше Bencher брал плату за каждую Метрику. Метрика представляет собой один результат бенчмарка в определённый момент времени. Например, если у вас 1 бенчмарк и вы запускаете его 5 раз, это создаёт 5 Метрик. Claude помог мне проанализировать отзывы пользователей и паттерны использования. Я пришёл к выводу, что единицу, которую мы использовали в нашей модели оплаты по факту использования, нужно изменить. Теперь Bencher берёт плату за каждую Серию Бенчмарка. Серия Бенчмарка представляет собой бенчмарк, отслеживаемый во времени. Возвращаясь к нашему примеру, если у вас 1 бенчмарк и вы запускаете его 5 раз, это 1 Серия Бенчмарка. Новая модель ценообразования даёт пользователям гораздо больше предсказуемости. Вы можете дать агенту задачу на оптимизацию, и он сможет карабкаться вверх по вашим историческим бенчмаркам (hill climbing), не неся никаких дополнительных затрат.

Одна из вещей, которые, как я вижу, за прошедший год не изменились, это вклад в open source. Bencher получил пару PR из ИИ-мусора. Главная проблема с этими PR была в том, что они исправляли случайные, не связанные между собой баги, на которые наткнулись по пути. Но это всё же были настоящие баги! Так что я просто пожал плечами и смержил эти PR, конечно, после того как их проверил мой собственный агент. Это немного грустно, но я больше не вижу особой пользы в том, чтобы привлекать контрибьюторов в open source. Чьи бы это ни были токены, их или мои, мне всё равно нужно вложить столько же усилий в ревью кода. Теперь проверить PR контрибьютора стоит гораздо больше сил, чем самому поитерировать с Claude.

Каково будущее непрерывного бенчмаркинга?

Когда пытаешься угадать, что ждёт нас в будущем, закономерность, похоже, такова: нужно смотреть на то, что делают сами передовые лаборатории. Судя по всему, через шесть-двенадцать месяцев мы все будем там же. Статья The Pragmatic Engineer Inside OpenAI’s agentic software factory проливает интересный свет на это с точки зрения непрерывного бенчмаркинга:

Новое: «perf harness»: агент также использует perf harness, чтобы отправлять проблемные PR во фреймворк Synthetics A/B для оценки влияния на производительность. Как упоминалось выше, нагрузка на CI-системы за последние шесть месяцев сильно выросла.

«Perf harness» от OpenAI выглядит очень похожим на устоявшуюся практику относительного непрерывного бенчмаркинга. Новая ИИ-составляющая здесь в синтетической части A/B-фреймворка. Синтетические тестовые данные не новость. Но возможность автономно формировать эти синтетические данные, чтобы оценить производительность конкретного набора изменений, определённо новинка! Заставить разработчика действительно написать бенчмарки всегда было главной проблемой. Теперь это автоматизировано. Точно так же, как агенты резко увеличили покрытие функциональными тестами, они позволяют нам резко увеличить и покрытие тестами производительности.

OpenAI не одинока в этом стремлении. Вскоре после этого Anthropic опубликовала How we made claude.ai 3x faster in two weeks. В этой статье они тоже описывают создание бенчмарков на лету. Одно ключевое отличие заключалось в том, что Anthropic нашла детерминированные счётчики, коррелирующие с производительностью: инструкции, коммиты на одно взаимодействие, вызовы функций, пересчёты стилей и мутации DOM. Затем Claude карабкался вверх по этим счётчикам (hill climbing), чтобы оптимизировать производительность их приложения. В конце прохода оптимизации они проверили, что их оптимизации на основе счётчиков действительно привели к реальному улучшению времени выполнения (wall-clock time).

Эти методологии совпадают с тем, что я сам испытываю, работая над Bencher. Правда, все мои A/B-тесты производительности запускались локально или на рабочей машине агента, а не в цикле CI. Каждый раз, когда я собираюсь внести крупное изменение в запрос или значимую миграцию схемы, я поручаю Claude провести исчерпывающую оценку производительности изменения. Она всегда включает реальное время выполнения, а иногда и сопутствующие детерминированные счётчики (например, инструкции виртуальной машины SQLite).

Из-за проблемы шумных соседей у этих проходов оптимизации производительности под руководством агента были довольно широкие погрешности. Я планирую добавить в Bencher Bare Metal фикстуры (дополнительные входные данные бенчмарков) и артефакты (дополнительные выходные данные бенчмарков), чтобы мой агент мог выполнять такие задачи по оптимизации производительности с большей уверенностью. Агент по-прежнему будет выполнять большую часть работы по оптимизации локально, карабкаясь вверх как можно лучше по реальному времени выполнения или детерминированным счётчикам. А затем он будет использовать Bencher Bare Metal, чтобы проверить свою работу, как своего рода штангенциркуль для реального времени.

Хотя я думаю, что большинством «пользователей» Bencher примерно через год станут агенты, я всё же считаю, что большинство людей захотят визуальный интерфейс для тех моментов, когда они заглядывают проверить, как идут дела. Сейчас я по уши погружён в полный редизайн UI Bencher с помощью Claude. Поскольку я, Rust-инженер, писал на Anyscript ещё во времена автодополнения по Tab в GitHub Copilot, текущий UI оставляет желать лучшего. Однако переписывание UI заблокировано другой, ещё более амбициозной переработкой: новой версией Bencher Metric Format (BMF).

BMF является основным форматом, к которому внутри Bencher приводятся результаты бенчмарков. Он проходит через всё. Новая версия BMF позволит параметризовать бенчмарки. Вы сможете указать my_benchmark с параметрами size: 16 MB и size: 32 MB вместо двух отдельных бенчмарков my_benchmark_16_mb и my_benchmark_32_mb. Новая версия BMF также позволит использовать произвольные имена метрик. Вы сможете передавать метрики mean, p95 и p99 для своих измерений Latency, вместо того чтобы иметь только mean или заводить Latency (mean), Latency (p95) и Latency (p99) как отдельные измерения.

Поддержка новой версии BMF означает масштабную переработку ядра Bencher. Я бы не чувствовал себя спокойно, делая эту работу с чем-либо до Fable 5. Как говорилось выше, большая часть работы над Bare Metal была ортогональна ядру Bencher: отслеживанию производительности во времени и оповещению о регрессиях. BMF находится в самом центре этой ключевой ценности. Моё доверие к Fable 5 и ещё больше к Fable 5.1 и Opus 5.5 снова позволило мне взяться за проект, на завершение которого ушли бы годы ночей и выходных. Раньше мне приходилось тратить немало времени на оптимизацию SQLite для Bencher. Теперь каждый раз, когда я развиваю модель данных, я просто прошу Claude запустить агента, чтобы тот провёл тщательное исследование производительности и убедился, что всё по-прежнему работает быстро. В будущем, думаю, мне даже не придётся просить.

Как я пишу код сегодня

Когда я пользовался GitHub Copilot, он был расширением в VSCode. Когда я только перешёл на Claude Code, я использовал CLI. У меня было три окна терминала, каждое в своём macOS Space. В каждом окне терминала было по две вкладки. Одна вкладка была для Claude, другая для Jujutsu (jj). Я всё ещё сам управлял контролем версий и workspace-ами jj.

Сейчас я просто использую десктопное приложение Claude Code. Каждую новую сессию я начинаю из своего мета-репозитория с включённым флажком worktree. Несколько месяцев назад я перестал использовать Plan mode. Я так и не установил навык /grill-me от Matt Pocock. Я просто прошу Claude в промпте «устроить мне допрос по всем проектным решениям», и на данный момент модель знает, что делать. Мой CLAUDE.md AGENTS.md довольно хорошо настроен под то, как я хочу, чтобы вела себя модель.

Свой CI-процесс Claude Review я практически вывел из эксплуатации. Теперь агент сам поднимает состязательного ревьюера локально, мне даже не нужно об этом просить. Затем они итерируют, пока не придут к согласию, иногда до полудюжины раундов. Я начал экспериментировать с переносом разработки на внешние рабочие машины, оставляя свою локальную машину только в роли оркестратора.

Единственный случай, когда я сам прикасаюсь к контролю версий, это когда хочу забрать сборку, чтобы что-то протестировать самому, или когда создаю тегированный, версионированный релиз Bencher. Это происходит примерно раз в неделю и раз в месяц соответственно. В остальном я теперь просто доверяю это Claude. Я активно пользуюсь черновыми PR, а теперь, когда они появились на GitHub, ещё и стековыми PR. Я не смотрю на код, пока не открыт PR. Я по-прежнему пролистываю код Bencher, но на данный момент это скорее проверка на здравый смысл, чем настоящее код-ревью.

Когда через год я оглянусь назад и перечитаю то, что написал здесь, будет ли у меня ещё один момент «Ты даже не упомянул ИИ‽»? Одна половина меня думает, как это было бы здорово. Другая половина в абсолютном ужасе.

Bencher: Непрерывное тестирование производительности

Bencher - это набор инструментов для непрерывного тестирования производительности. Когда-нибудь регрессия производительности влияла на ваших пользователей? Bencher мог бы предотвратить это. Bencher позволяет вам обнаруживать и предотвращать регрессии производительности до того, как они будут слиты.

• Запустить: Запустите свои тесты производительности локально или в CI, используя точно те же самые bare metal раннеры и ваши любимые инструменты для тестирования. CLI bencher оркестрирует запуск ваших тестов производительности на bare metal и сохраняет их результаты.
• Отслеживать: Отслеживайте результаты ваших тестов производительности со временем. Мониторите, запрашивайте и строите графики результатов с помощью веб-консоли Bencher на основе ветки исходного кода, испытательного стенда и меры.
• Поймать: Отлавливайте регрессии производительности локально или в CI, используя точно то же самое bare metal оборудование. Bencher использует инструменты аналитики, работающие по последнему слову техники, чтобы обнаружить регрессии производительности, прежде чем они будут слиты.

По тем же причинам, по которым модульные тесты запускаются, чтобы предотвратить регрессии функций, тесты производительности должны быть запущены с Bencher, чтобы предотвратить регрессии производительности. Ошибки производительности – это тоже ошибки!

Начните отлавливать регрессии производительности — попробуйте Bencher Cloud бесплатно.