Ошибка в функции обычно начинается с сообщения в рабочем чате, а заканчивается где-то в личном терминале разработчика. Slack Code переносит этот процесс в общий канал: агент получает задачу по упоминанию, показывает план, публикует изменения и оставляет историю работы. Для вашей команды это означает меньше невидимых экспериментов, но не отменяет проверки человеком.
20 августа 2026 года Salesforce представила Slack Code как функцию Slack для совместной работы с AI-агентами, которые пишут и проверяют программный код. На старте функцию заявили доступной на любом тарифе Slack, однако доступ к партнёрским агентам клиенты предоставляют самостоятельно. Российским командам пока рано считать внедрение готовым: условия конкретной конфигурации, хранения данных, доступа и соответствия внутренним требованиям безопасности нужно проверить до пилота.
1. Что меняется, когда агент выходит из терминала
Сначала разберём механизм без названий. AI-агент для разработки получает задачу, изучает связанный с ней код, предлагает изменения, запускает проверки и формирует результат. Раньше этот цикл часто проходил между одним сотрудником и одним агентом на компьютере сотрудника. Остальные видели уже готовый запрос на внесение изменений, а не ход работы.
Slack Code делает канал единицей работы. Канал здесь похож на отдельную папку проекта с журналом обсуждений. В ней лежат исходная проблема, уточнения, результаты проверки и решение команды. Когда сотрудник отмечает агента в разговоре, Slack создаёт специализированный кодовый канал для этой задачи. Агент публикует там диффы кода, то есть список добавленных и удалённых строк, показывает живое превью результата и ведёт план в отдельной вкладке.
После завершения канал архивируется вместе с обсуждением. Команда получает поисковый аудиторский след, то есть понятную историю: кто поставил задачу, какие файлы изменились, что проверил агент и кто одобрил итог. Это не сертификат качества. Зато спор «почему это вообще попало в релиз» получает ответ с датой и контекстом, а не коллективное воспоминание пятничного вечера.
На запуске Slack Code упоминает четыре интеграции:
- Claude Code от Anthropic, агент для работы с кодом;
- Devin от Cognition, который может исследовать ошибку, работать с браузером и открыть запрос на внесение изменений;
- GitHub Copilot, знакомый многим командам инструмент помощи при написании кода;
- Vercel's agent, интеграция для задач вокруг веб-разработки и размещения приложений.
В материалах запуска также упоминался ChatGPT как будущая интеграция. Это нужно читать именно как статус анонса, а не как подтверждение доступности. Для Anthropic в Slack опубликована отдельная русскоязычная справка. Название интеграции, дату её доступности и условия замены прежнего приложения стоит сверять с актуальной документацией Anthropic перед подключением. Devin описывает подключение через Settings → Integrations → Slack. После этого его можно отметить в канале и получать ответы в треде, то есть в цепочке сообщений внутри разговора.
Практический смысл для вас: дизайнер или менеджер продукта сможет описать дефект там, где его заметил, а инженер увидит исходный контекст и сможет направить исправление. Сама возможность отправить задачу агенту не превращает описание в хорошее техническое задание. Она сокращает путь до разговора, в котором специалист уточняет требования.
2. Как выглядит рабочий цикл от ошибки до запроса на изменение
Публичная демонстрация Cognition показывает сценарий, который Slack предлагает считать нормой. Сотрудник сообщает об ошибке в инженерном канале и отмечает Devin. Агент отвечает в треде, исследует проблему и открывает запрос на внесение изменений. Затем работа переходит в кодовый канал, где к ней подключаются инженер, менеджер продукта и дизайнер.
В демонстрации дизайнер добавил в канал файл из Figma, сервиса для проектирования интерфейсов. Devin учёл его, затем опубликовал изменения, снимки экрана и видеозапись работы функции. Такой пример показывает не магию агента, а последовательность передачи контекста: жалоба, исследование, макет, код, проверка. Каждый участник видит, на каком шаге находится задача.
У этой модели есть два понятных преимущества. Во-первых, специалист по продажам или поддержке может сообщить об ошибке без отдельной формы и ожидания, пока проблема доберётся до списка задач. Во-вторых, два разработчика реже запускают одинаковую работу, потому что активная задача видна в канале. Выигрыш возникает из прозрачности процесса, а не из самого слова «агент».
- Опишите симптом в существующем рабочем канале: что произошло, где это видно и как воспроизвести ошибку.
- Отметьте нужного агента и дождитесь его плана, прежде чем просить исправить всё сразу.
- Проверьте дифф и превью. Сравните результат с исходной задачей, а не с тем, насколько убедительно агент его описал.
- Передайте запрос человеку, который отвечает за код, продуктовую логику или безопасность.
Последний пункт не формальность. В описанном рабочем процессе команда сохраняет одобрение человека перед финальным изменением. При этом из доступных материалов не следует, что Slack Code сам технически блокирует слияние без такого одобрения. Запросы на внесение изменений в GitHub могут сохранять привычные правила выпуска, если команда уже их использует. Поэтому важно отдельно проверить настройки репозитория и внутренний порядок ревью.
Открытый канал помогает увидеть намерение и ход работы, но не доказывает, что результат верен. Тест может не заметить ошибку в редком сценарии, превью может не показать нагрузку, а агент может решить не ту задачу очень аккуратно. Поэтому договоритесь заранее, кто проверяет бизнес-логику, кто смотрит безопасность и кто имеет право остановить слияние.
3. Почему видимость снижает риск «AI-мусора», но не убирает его
«AI-мусор» означает правдоподобный результат, который выглядит профессионально, но плохо решает исходную проблему. Такой код особенно опасен, когда его принимает человек, который не видит промежуточных решений и не знает ограничений проекта. Slack строит защиту на обратной идее: если работа происходит на виду, её легче поправить до слияния.
Katie Steigman, вице-президент Slack по продукту, назвала публичность защитой от такого результата:
“The multiplayer part is a guard against that, actually, because people can see your work, people can comment on your work”.
В практическом смысле это означает доступ к обсуждению для тех, кто умеет задать неприятный, но полезный вопрос: зачем менять этот модуль, что сломается в старом сценарии и кто проверил пограничный случай.
Однако видимость работает только при наличии людей, которые смотрят. Если канал превращается в ленту автоматических сообщений, аудит остаётся на бумаге. Для каждой команды стоит закрепить одного ответственного проверяющего и минимальный набор условий: тесты пройдены, дифф понятен, затронутые права проверены, запрос согласован владельцем кода. Иначе «вместе с командой» быстро превращается в «все видели, никто не прочитал».
Данные рынка объясняют, почему осторожность здесь уместна. По прогнозу Gartner, более 40 процентов проектов с агентным ИИ отменят к концу 2027 года. В опросе McKinsey 62 процента организаций сообщили, что экспериментируют с AI-агентами, примерно треть начала масштабирование, а лишь 39 процентов увидели какое-либо влияние на финансовый результат. Эти цифры относятся к агентам в целом, а не к Slack Code. Они не доказывают эффективность или неэффективность конкретного продукта, но показывают разрыв между экспериментом и устойчивой пользой.
У Cognition есть собственная оценка: компания сообщила о росте числа объединённых запросов на изменение в 10x за последние месяцы при росте штата на 40 процентов. Это внутренний показатель Cognition, а не независимое измерение качества и не гарантия для вашей команды. Больше объединённых запросов означает меньше ручных операций только в том случае, если команда успевает их проверять.
Вывод для рабочего процесса: начинайте с задач, где результат легко измерить. Исправление воспроизводимой ошибки, обновление теста или небольшая правка интерфейса дают понятный критерий. Не отдавайте агенту без отдельного контроля миграцию данных, права доступа и изменения, последствия которых невозможно быстро откатить.
4. Как работает модель доступа и где остаётся риск
Для корпоративного внедрения важнее всего не красивое превью, а границы доступа. Slack заявляет, что агенты наследуют права пользователя, который их вызывает, и не получают больше. Права доступа, или ACL, это список разрешений. Он определяет, какие каналы, файлы и подключённые системы может видеть конкретный человек.
В этой модели агент не получает самостоятельную «сверхучётную запись». В Slack он видит информацию, доступную вызвавшему его пользователю, и каналы, в которые его добавили. При создании кодового канала агент получает контекст исходного разговора. На стороне Devin задачи выполняются в изолированных песочницах. Песочница здесь означает отдельную среду, которая ограничивает влияние процесса на остальную систему.
Cognition описывает для Devin режим minimum viable access, то есть минимально необходимый доступ, и опциональный режим без интернета. Последний сокращает поверхность атаки, но одновременно лишает агента части внешних данных и инструментов. Слово «опциональный» важно: это настройка, которую команда должна выбрать и проверить, а не автоматическая гарантия безопасности.
Наследование прав уменьшает число новых учётных записей для IT-отдела, но не решает все проблемы. Если у сотрудника уже слишком широкий доступ, агент унаследует и его. Если в исходном канале случайно опубликован секрет, он станет частью контекста задачи. Если подключённый сервис разрешает опасное действие без дополнительного подтверждения, видимость в Slack не заменит ограничение на стороне сервиса.
Перед пилотом проверьте четыре вещи:
- Доступ: какие каналы и репозитории видит пользователь, который будет вызывать агента.
- Хранение: где остаются сообщения, диффы, превью и архив кодового канала.
- Срок: как долго сохраняется история и кто может найти её поиском.
- Регион: соответствует ли обработка данных требованиям вашей компании и российским правилам.
В публикации SiliconANGLE от 20 августа 2026 года и доступных на момент запуска материалах партнёров подробно описаны основные сценарии интеграций, но не все параметры хранения, уровни доступа, коммерческие условия и региональные требования. Это не означает, что таких сведений не существует. Перед внедрением их нужно запросить у поставщика и сопоставить с внутренними правилами компании. Вопросы о применении российских требований к данным следует отдельно обсудить с квалифицированным юристом.
5. Что Slack продаёт на самом деле и как оценить пользу
Slack Code выглядит как функция для программирования, но стратегически Slack продаёт место, где люди управляют работой агентов. В приложении появляются личные диалоги с агентами, вкладка Agents с текущим статусом сессий и кнопкой остановки, а также поток Add to Slack для подключения агентов из Lovable, n8n, OpenAI, LangChain и Airtable через OAuth. OAuth означает способ выдать приложению ограниченный доступ без передачи ему пароля.
Это важный сдвиг. Когда код становится дешевле создавать, ограничением становятся выбор задачи, проверка результата и согласование между людьми. Rob Seaman, временный руководитель Slack, сформулировал тезис так:
“One of the things I love about this is that code is no longer the bottleneck”.
Но это позиция компании, а не установленный закон экономики разработки. Код не исчезает из списка трудных задач. Труднее становится отличить полезное изменение от очень уверенного лишнего.
Для пользователя польза распределяется неравномерно. Неспециалист получает короткий путь от найденной проблемы до разговора с технической командой. Инженер видит контекст и может направить агента, не пересказывая всю историю в личном сообщении. Руководитель получает журнал решений. Каждый выигрыш появляется только при условии, что команда не путает доступность инструмента с готовностью выпускать его результат.
Оцените пилот по четырём измерениям:
- Скорость реакции: сократилось ли время от сообщения об ошибке до понятного плана исправления.
- Повторная работа: стало ли меньше одинаковых задач, которые запускают разные сотрудники.
- Качество проверки: видит ли ответственный человек дифф, тесты, превью и исходные требования до одобрения.
- Цена контроля: не тратит ли команда на чтение и исправление агентского результата больше времени, чем экономит.
Внутренняя метрика вроде роста числа запросов на изменение полезна лишь вместе с качественными показателями. Считайте отменённые изменения, откаты и ошибки после выпуска. Если таких данных нет, начните с одного типа задач и зафиксируйте исходное время выполнения. Иначе пилот измерит шум: канал станет активнее, а продукт не станет лучше.
Решение на этой неделе: пилотировать, ждать или пропустить
Пилотируйте Slack Code, если у команды уже есть Slack, понятные владельцы кода, тесты и обязательное человеческое одобрение по внутренним правилам. Возьмите одну небольшую категорию задач, ограничьте доступ агента и сохраните стандартные проверки GitHub. Так вы проверите главный тезис продукта: помогает ли общий канал быстрее и безопаснее превращать проблему в проверяемое изменение.
Подождите, если неясно, где хранятся данные, кто видит архивы или какие ограничения действуют для вашей российской инфраструктуры. Документация Anthropic и Devin подтверждает отдельные интеграции, но не отвечает автоматически за всю конфигурацию Slack Code. До письменного ответа поставщика не передавайте в агентский канал секреты, персональные данные и код, для которого действуют специальные требования.
Пропустите инструмент, если команда пока не умеет назначать проверяющего или регулярно принимает изменения без тестов. Общий экран усилит такой процесс, но не исправит его. В лучшем случае вы получите удобный журнал плохих решений.
Рабочий порог простой: разрешайте агенту предлагать изменения, когда человек сохраняет последнее слово, права доступа ограничены, а результат можно проверить и откатить. Тогда Slack Code становится способом сделать разработку видимой для всей команды. Для российского бизнеса это ещё и повод сначала проверить условия обработки данных, а затем спокойно решить, приносит ли общий рабочий канал больше пользы, чем контроля требует.
