Slack Code — нова функція Slack, яка вбудовує AI-агентів безпосередньо в групові канали команд: агенти бачать той самий потік повідомлень, тредів і файлів, що й розробники, і можуть діяти поруч із людьми, а не в ізольованому вікні окремого чат-бота. За даними The Register AI, це частина ширшого тренду перенесення агентів у щоденні робочі інструменти — того самого напрямку, у якому Slack уже рухався раніше, коли відкрив канали для спільного кодингу зі ШІ-агентами.
Досі типовий сценарій agentic coding виглядав однаково майже в будь-якому інструменті: розробник відкриває окреме вікно — Cursor, Claude Code, веб-чат моделі — формулює задачу, отримує результат і сам переносить його назад у командну роботу: копіює висновок у канал, додає посилання на PR, переказує колегам, що саме зробив агент. Сам агент при цьому не бачив, що команда обговорювала п'ять хвилин тому в чаті, а команда не бачила процесу роботи агента — лише кінцевий артефакт.
Slack Code прибирає цей проміжний крок: агент стає повноправним учасником каналу з доступом до спільного контексту команди, а не зовнішнім сервісом, до якого треба ходити за відповіддю.
Що конкретно змінюється для команди розробників?
Головна зміна — контекст перестає бути персональним і стає спільним за замовчуванням. Агент, вбудований у канал, працює не з ізольованим промптом одного розробника, а з тим самим робочим простором, що бачить уся команда.
- агент читає історію треду й реагує на обговорення без окремого copy-paste запиту;
- результати його роботи — код, план, статус завдання — видимі всій команді одразу, а не лише автору запиту;
- люди можуть втручатися в роботу агента прямо в каналі: уточнити задачу, скасувати дію чи перенаправити агента в інший бік.
Це змінює саму одиницю роботи з агентом: не «запит-відповідь» одного користувача, а безперервний потік, у якому агент — такий самий учасник, як і решта команди.
Чим агент-учасник каналу відрізняється від звичного чат-бота?
Ключова відмінність — у ролі. Класичний чат-бот у Slack відповідає на прямі запити: команда пише боту, бот відповідає в приватному повідомленні або в треду за явним викликом. Агент-учасник каналу натомість постійно перебуває в потоці й може діяти без явного звернення щоразу — ближче до того, як команда взаємодіє з живим колегою, а не з довідковою службою.
Для розробників agentic-продуктів це означає інший дизайн permission-моделі: агент, що «слухає» канал безперервно, потребує чіткіших меж — які дії він виконує автономно, а які вимагають явного підтвердження людини. Ми вже розбирали цю проблему детальніше, коли писали, як саме AI-агенти заходять у канали розробників — і саме межі дозволів там виявляються найчутливішим місцем архітектури.
Які ризики виникають, коли агент постійно в командному чаті?
Найочевидніший ризик — розмивання відповідальності. Коли агент і люди пишуть в одному каналі й обидва можуть ініціювати дії, команді складніше швидко визначити, хто саме відповідає за конкретний крок.
- хто відповідальний за код, який агент написав і одразу закомітив у гілку без окремого рев'ю;
- як команда в швидкому треді відрізняє повідомлення агента від повідомлення людини, особливо коли обидва пишуть стисло;
- скільки внутрішнього контексту команди — включно з чутливим — накопичує агент із часом і хто контролює доступ до цієї історії.
Це не гіпотетичні застереження, а пряме продовження самої моделі: чим глибше агент інтегрований у щоденний робочий простір, тим більше рішень про довіру команда змушена приймати неявно, просто продовжуючи писати в канал як завжди.
Висновок AiiN: що це означає для AI-білдерів
За нашою оцінкою, конкуренція agentic-продуктів зміщується від боротьби за окремий чат-інтерфейс до боротьби за право бути постійним учасником робочого простору команди. Хто володіє каналом, той володіє контекстом, у якому працює агент, — а контекст, накопичений за тижні спільної роботи, складніше відтворити конкуренту, ніж скопіювати саму модель під капотом.
Практичний висновок для команд, що будують власних агентів: варто закладати не лише якість відповіді, а й модель довіри — хто бачить дії агента, які дії потребують підтвердження, і як команда відрізняє слово агента від слова колеги в одному потоці повідомлень.
Чи замінює Slack Code окремі IDE-агенти на кшталт Cursor чи Claude Code?
Ні, ідеться про інший шар взаємодії. IDE-агенти залишаються інструментом для роботи з кодом безпосередньо в редакторі, тоді як Slack Code переносить видимість і координацію цієї роботи в командний канал, де раніше велося лише обговорення.
Чи бачать усі учасники каналу однакові дії агента?
Судячи з логіки самої функції — так, дії агента, що працює в спільному каналі, видимі всім учасникам цього каналу, а не лише людині, яка поставила задачу, на відміну від приватного чату з ботом.