Slack Code changes AI-powered team coding collaboration

Slack reportedly put AI coding in the team channel

Slack has reportedly introduced Slack Code, a shared workspace inside Slack where teams collaborate with AI coding agents on real software projects — and if the reporting holds, it is the most structurally interesting agent-coding launch of the quarter. The reason is simple: for two years the bottleneck in AI-assisted development has not been the model. It has been the handoff between the developer's terminal and the rest of the team.

One disclosure before the detail, because it shapes everything below: at the time of this retrofit, every product specific traces to a single trade-press report in Express Computer. No vendor announcement page could be confirmed against Slack's own properties. Treat launch specifics as reported, not established — and read the analysis of why a shared surface matters as the part that stands on its own either way.

What was reported

According to the Express Computer report, Slack Code organizes work into code channels, each associated with a specific project, where the agent, the conversation, the plan, the code changes, and a live preview all live together — visible to everyone added to the channel. A code channel is created automatically when a supported coding agent is tagged in an existing conversation, with everyone in that conversation added and permissions following the project's existing Slack ACLs.

The agents named in the report are Claude Code, Devin, GitHub Copilot, ChatGPT, and Vercel agents — roughly the set serious teams already pay for, which suggests (if accurate) a bring-your-own-agent posture rather than a single-model play. The flagship workflow in the report: a product manager spots a bug in a channel, asks a coding agent for help, and the agent uses the existing conversation — screenshots, documents, prior discussion — as context, proposes a change, and creates the code channel. An engineer reviews the code, runs the preview, and tells the agent what to fix. Nobody opened a terminal.

When the work ships, the channel is archived — and the history stays as an audit record of who asked for what, what the agent produced, and who approved, per the same report.

The handoff problem, up close

To see why this matters, replay the status quo. A single engineer fires up an agent in a terminal, generates a pull request, and narrates what happened at standup the next morning. The actual work — the prompts, the false starts, the tradeoffs considered and discarded, the live preview that proved the fix — never leaves that developer's screen. The team receives the diff. It does not receive the reasoning.

That missing reasoning is where reviews go to die. A reviewer staring at a 400-line agent-generated diff with no record of intent faces two bad options: rubber-stamp it, or reconstruct the author's thinking from commit messages at midnight. Most teams alternate between the two, and both are expensive — the first in production incidents, the second in reviewer hours. The cost is not theoretical; it is the quiet tax on every AI-assisted PR merged this year.

A shared channel attacks the tax at its root. The conversation about the feature, the screenshots that motivated it, the bug report it was meant to fix, the code written, and the preview proving it works — co-located, timestamped, reviewable inline. Engineers review and approve where the work happened. PMs request tweaks in the same thread. Designers flag spacing against the live preview, not a screenshot of a screenshot.

Why the vendor direction corroborates the pattern

Strip away the launch specifics and the pattern still has a second leg: the vendor's own platform framing. Slack's blog index currently leads with an agentic-platform story — tooling to customise, extend, and unify a team's stack inside Slack — alongside built-in AI positioned as working "right where you work." That is a company telling you, in its own navigation, that agent workflows belong in the channel rather than in a separate tool. Whatever the exact Slack Code packaging turns out to be, the direction of travel is vendor-confirmed even where the feature details are not.

This also fits the industry-wide movement of agents toward shared surfaces: review threads that agents can act on, chat mentions that dispatch work, previews attached to conversations instead of localhost ports. The terminal was the right first home for agent coding. It is the wrong permanent one for team coding.

The workflows worth trying first

The report surfaces four workflows, all realistic for teams already living in Slack:

• New feature build — collaborative spec-to-PR, with the agent drafting while the team reviews in real time instead of after the fact.
• Webpage update — copy changes, layout tweaks, component swaps shipped without scheduling a meeting around them.
• Bug fix — the PM-as-developer beat: a non-engineer surfaces the problem with full channel context attached, the agent writes the fix, an engineer approves.
• Team onboarding — new hires read channel history to see how the team actually ships, not a sanitised wiki that describes how it shipped two reorgs ago.

The fourth is the sleeper. Channel history is institutional memory that does not rot — and an archived code channel doubles as the compliance-friendly audit trail (who asked, who wrote, who approved) that regulated teams usually reconstruct after the fact. For the surrounding discipline of structuring agent work so it survives review, see our agent session playbook and the production shipping checklist.

What to verify before you adopt

Because the sourcing here is single-threaded, any team evaluating this should confirm the following against Slack's own documentation before committing process to it: that code channels exist as described and how they are created; exactly which agents are supported at launch versus on the roadmap; how permissions inherit from existing Slack ACLs, especially for private channels and guests; what the archived-channel audit record actually retains and for how long; and what the pricing and plan-gating looks like. None of those answers exist in the confirmed record yet. Adopt the pattern — shared surface, agent in the channel, history as audit trail — while verifying the product.

Where it stops, and the durable layer beneath

Here is the part no launch announcement will tell you. A collaboration surface, however good, produces code that still ships to actual users on web, iOS, and Android. And the moment it ships, you hit the problem every shipped codebase hits: the button that looked right in the agent's live preview behaves differently in Safari than in an Android WebView than in a native shell.

The collaboration layer moves. The model moves. The agent moves. The component the user touches must not. That is the durable layer: one component definition, one API surface, identical behaviour on every platform — the part worth investing in once, so it does not matter which agent, model, or channel tool you use next year. If you want that layer handled rather than rebuilt per project, start from OTF's templates.

What this gets you

Three things, all worth more than the headline: a team that learns together because history is shared rather than narrated; an audit trail you trust because it was captured rather than reconstructed; and a workflow where non-engineers contribute without learning Git. AI coding finally lives where the team lives — reportedly, now, in Slack. Verify the launch against the vendor before betting a quarter on it. Bet on the shared-surface pattern regardless.

Sources

• Express Computer: AI coding gets a shared workspace with Slack Code — sole confirmed report; all product specifics attributed here, launch details treated as reported
• Slack blog — vendor platform direction: agentic platform story and built-in AI positioned where teams work
• OTF templates — the durable cross-platform component layer referenced in this article