Джек Дорси запускает Buzz: Slack + Git + AI-агенты в одном месте — продуманная ставка или фулл-стэк фантазия?

Джек Дорси (Block) представляет Buzz: командный чат + хостинг Git + ИИ-агенты. Ставка: избавиться от зависимости Slack/GitHub. Вопрос: выдержит ли «всё в одном» конкуренцию с блоками, которые команды почти никогда не меняют?

Простыми словами — Block Джека Дорси запустил Buzz 21 июля 2026 года: единую платформу, объединяющую командный чат, ИИ-агентов и хостинг Git. Суть: уйти от фрагментации Slack + GitHub + LLM-инструментов, использовать Buzz для всего сразу.

Контекст

Тренд, на котором едет Buzz, реален: команды действительно используют Slack, GitHub, Copilot-подобные инструменты и всё чаще — среду для запуска агентов. Каждый стык между ними — это трение: права доступа, уведомления, контекст, который не передаётся. Но контртренд тоже реален: никто не отказывается от GitHub. Или от Slack. Или от своей существующей стэка агентов.

Под капотом

• Чат: поверхность для командного общения, на старте — полный функционал Slack (каналы, тред, личные сообщения).
• Хостинг Git: полноценный Git-сервер + UI для PR и ревью. Сравним с базовой установкой GitLab.
• ИИ-агенты: агенты, запускаемые внутри каналов, с пониманием Git-контекста (репозиторий, PR, issues).
• Точка интеграции: три поверхности используют единую модель прав и идентификации — это и есть аргумент Buzz в пользу привязки пользователей.

Анализ

Ставка архитектурная, а не продуктовая. Slack + GitHub + агентный инструмент — это три отдельные системы с разными правами доступа, а агент — это тот компонент, которому больше всего нужен единый контекст (ему нужны тред из Slack, PR и трекер задач). Buzz сворачивает всё это в одну модель идентификации и прав — это действительно продуманный дизайнерский ход. Это то, как платформа для команд, «ориентированная на агентов», должна была быть построена, если бы стек пересобирали с нуля в 2026 году.

Но: стоимость перехода с GitHub — это не продукт, а десять лет истории PR, CI-настроек и графа зависимостей внутри корпоративных аккаунтов. Buzz не сможет это воспроизвести за одну ночь, как бы хорош ни был чат.

Два реалистичных пути для Buzz:

1. Новые команды / стартапы — где инерция GitHub минимальна, и «ориентированность на агентов с первого дня» — реальный аргумент.
2. Изолированные / самохостинговые решения — где организации уже используют свои Git и альтернативы Slack, и консолидация на Buzz означает меньше систем, а не больше.

Для устоявшихся команд интересный вопрос: достаточно ли агентной поверхности (чат + ИИ с пониманием репозитория) для того, чтобы оправдать запуск Buzz рядом с Slack/GitHub только для работы с агентами. Это как Zoom вошёл против Skype — клин, а не замена.

Сценарии

• Базовый случай (55%): Buzz находит клин в платформе для команд, ориентированных на агентов, для новых/маленьких команд; не вытесняет Slack или GitHub у сложившихся пользователей.
• Быстрый захват (20%): бренд Block + распределение Дорси привлекают корпоративные пилоты; выделение становится серьёзным через 12 месяцев.
• Исчезновение (25%): слишком много поверхностей для одновременной разработки; отставание в исполнении любого из них убивает уникальность.

Выводы

Для технического лидера: не переходите — оцените. Buzz стоит пилотировать на одной команде для работы с агентами, а не мигрировать полностью. Для текущих пользователей Slack/GitHub: «перепись, ориентированная на ИИ» теперь стала реальным продуктом, а не угрозой на слайдах.