Slack just shipped a feature that moves AI-assisted coding out of the solo IDE and into a shared team channel. It’s called Slack Code, and the core mechanic is simple: you call an AI agent in a message, it spins up a temporary channel, and everyone works on the task together in public until the pull request is done. Then the channel closes and the thread archives for context.
Which Agents It Supports
At launch, Slack Code connects to Anthropic’s Claude, Cognition’s Devin, GitHub Copilot, and Vercel. OpenAI’s ChatGPT is listed as coming soon. The tool is a multiplayer wrapper on top of agents teams are already using, not a new IDE or language.
The Internal Number to Know
Slack reports that more than 70% of its own internal code channels open and close within a single day, often completing the full arc from idea to merged pull request. Internal metrics from the vendor deserve skepticism, but the directional claim about task speed is worth noting.
What Actually Changes for Small Teams
The meaningful shift is audience. Standard AI-assisted dev today is private: an engineer prompts an agent, iterates alone, and brings the output back for review. Slack Code makes the iteration visible from the start. A customer support lead who can reproduce a bug can participate in fixing it. A product manager can show the agent what to build instead of filing a ticket.
Slack’s own documentation also mentions co-writing marketing plans and redlining legal contracts as use cases, which suggests the company is positioning this as a general collaborative workflow, not an engineering-only tool.
The Catch
Generating code faster does not make code review easier. Non-technical participants can describe what they want, but assessing whether the output is secure or architecturally sound still requires a qualified engineer. Slack confirms code channels inherit workspace permissions and can route high-stakes changes for human approval, but that only covers access control inside Slack. Repository permissions, dependency auditing, secrets management, and deployment gates all still need separate governance.
Teams where the bottleneck is requirement gathering and ticket scoping will see real benefit. Teams where code review and deployment cause the primary delays will find that faster generation just moves the constraint downstream.
