Block (та самая компания за Square, Cash App и — почему-то — Tidal) на днях рассказала, как у неё устроена разработка изнутри, и цифры звучат одновременно впечатляюще и тревожно. Внутренний инструмент Builderbot делает больше 200 000 операций в день, доводит до мержа около 1 500 pull request’ов в неделю и, по данным самой компании, даёт примерно 15% всех изменений прод-кода (именно изменений, не долю кодовой базы) во всём Block. «То, что раньше занимало месяцы, теперь занимает дни», — пишут они сами.
Фон у этой истории невесёлый: всё это подаётся через несколько месяцев после того, как Block сократила штат примерно с 10 000 до почти 6 000 человек, и сама компания увязывает это с переходом на «intelligence tools» и меньшие AI-native команды. Инженер теперь может параллельно вести несколько агентских задач, переключаясь между ними и принимая решения, пока боты пишут PR’ы.
Можно спорить, хорошо это или плохо. Интереснее другое: что у них реально под капотом — и что из этого может утащить себе обычная команда, у которой нет масштаба Block и собственного фреймворка.
Что такое Builderbot и причём тут Goose
Builderbot — это не «ещё один кодинг-агент». Это control plane поверх парка агентов, построенный на открытом фреймворке Block — goose. Goose выложен в open source, работает локально (desktop-приложение, CLI и API), ходит в инструменты через MCP — то есть его, в отличие от внутреннего Builderbot, можно взять и попробовать.
Рабочий цикл выглядит так:
инженер в Slack-треде пишет
@builderbotи ставит задачу (часто прямо из тикета Linear/Jira);бот заводит ветку, генерит изменения, открывает pull request;
дальше включается обратная связь от CI: агент видит результаты прогонов, правит код, гоняет снова;
человек ревьюит и принимает решение о мерже.
Ключевое тут — не «агент пишет код». Ключевое — что весь этот парк ботов управляется из одного чата, а контур замкнут на CI и PR.
Острый угол: на масштабе агент — это не про код, а про обвязку
Когда показывают одиночного агента в демо, кажется, что вся магия в модели. На масштабе Block видно обратное: сама по себе генерация кода — самая простая часть. Узким местом становится всё вокруг.
Посмотрите, во что превращается «кодинг-агент», когда их много и они делают 200k операций в день:
Control plane. Нужно место, откуда людьми рулится парк агентов. У Block это Slack-тред — дёшево, наглядно, уже у всех есть.
Очередь и throughput. 1 500 PR в неделю — это не только генерация, это 1 500 ревью, 1 500 прогонов CI, 1 500 потенциальных конфликтов. Агенты упираются не в «ум», а в пропускную способность пайплайна.
Права и изоляция. Бот, который умеет открывать PR и трогать инфру, по правам — это разработчик. Дать ему scoped-токены, песочницу и явные границы важнее, чем выбрать модель. Сам Block, кстати, отдельно оговаривает, что Builderbot работает только с исходным кодом и системными конфигами и не имеет доступа к клиентским данным, платежам и PII — разумная граница по умолчанию.
Аудит. Когда 15% прод-кода идёт от ботов, «кто это написал и почему» становится не философией, а требованием.
Другими словами, на масштабе кодинг-агенты — это, по сути, Platform/DevOps-задача: CI/CD, IAM, очереди, observability, audit. Не «AI заменил разработчиков», а «AI добавил армию очень продуктивных джунов, которым теперь нужны ревью, права и пайплайн».
Что можно украсть обычной команде
Builderbot вам не продадут — это внутренний инструмент. Но паттерн воспроизводим, а его фундамент (goose) открыт. Что реально стоит позаимствовать, не дожидаясь своих 200k операций в день:
Чат как пульт. Не отдельная панель, а тред в Slack/Mattermost, где видно, что делает каждый агент. Низкий порог входа, естественная видимость для команды.
Замкнуть агента на CI, а не на «доверие». Агент не «пишет правильно», агент итерится по фидбеку тестов. Без зелёного CI его PR — черновик.
Права по минимуму. Отдельный сервисный аккаунт, scoped-токены, песочница. Агент с правами тимлида — это инцидент, который ещё не случился.
Человек на мерже. Block оставляет решение о мерже за человеком. На 1 500 PR в неделю это, кстати, отдельная нагрузка — о которой в пресс-релизах обычно молчат.
Где здесь маркетинг
Теперь честно, потому что цифры красивые, а контекст скользкий.
«200 000 операций в день» — это их собственная метрика, и что считается операцией, со стороны не видно: вызов инструмента, сообщение, шаг агента? «15% production code changes» — это тоже их внутренняя метрика, и без разбивки по типам PR непонятно, сколько там миграций, бойлерплейта и переименований (это боты делают отлично и легко надувают процент), а сколько сложной доменной логики. И 1 500 смерженных PR — это ещё и 1 500 PR ревью-нагрузки на оставшихся людей.
И главное: всё это рассказывается на фоне сокращения 4 000 человек как история успеха.