Slack Code puts the approval in a channel — name one approver anyway

What shipped

Slack Code turns an AI coding task into a dedicated channel. You mention an agent, the work happens in the open, and the channel keeps four views of it.

Read the commercials and the architecture together and the strategy is legible. Slack is not competing with Claude Code or Devin; it is standing downstream of all five, taking the position every one of them has to pass through to reach a team. The margin on generation stays with the agent vendors. The surface where the work becomes a team's work stays with Slack.

The bottleneck really did move to review

Anyone running coding agents at volume has already met this. An agent that opens twelve pull requests a day adds nothing if the team merges four, and detaching the agent from the editor does not create throughput — it relocates the queue to the humans, which is the whole argument of background coding agents. Generation stopped being the constraint some time in 2025. Verification never did.

So a product whose entire value proposition is "here is where the reviewing happens" is aimed at the correct problem, and the four tabs are a sensible decomposition of it. Each tab is a different artefact with a wildly different review cost, and that difference is the most useful thing in the announcement:

• The plan is the cheap gate. Two minutes of reading catches the wrong file, the wrong approach and the wrong scope, before a line exists. It is the highest-leverage checkpoint any agent product can offer and the one most teams skip.
• The preview is a cheap oracle for a narrow class of work. If the change is visible, looking at it beats reading it. If the change is a permission check or a migration, the preview is decorative.
• The diff is the expensive gate, and it grows superlinearly. Review effort does not scale with lines; it scales with the number of interactions a reader has to hold in their head. This is where rubber-stamping starts, and where a channel makes it easier.

A product that makes the plan tab prominent is doing you a favour whether or not it meant to. Approving a plan is a real decision. Approving a 600-line diff at 5pm in a channel with eleven other people in it is a ritual.

An approval visible to twelve people is an approval nobody has to give

Here is the part that is not in any of the coverage. Moving an approval from a terminal to a channel changes its social structure, and not in the direction the announcement implies.

In a terminal, the approval prompt is addressed to exactly one person, who is also the person who wrote the prompt, holds the intent, and will be asked about it in three weeks. Identity, context and accountability are the same human by construction. That is not a design achievement — it is an accident of the interface — but it is worth an enormous amount, and it is the first thing a shared channel gives up.

The failure mode has a name outside software. When a request is addressed to a group rather than a person, each member is less likely to act, and the effect strengthens as the group grows — everyone assumes someone better placed will handle it. A coding channel adds a nastier twist: approving is an act of taking on risk, so the incentive gradient points away from whoever knows the code well enough to see what could go wrong. The person who clicks approve is disproportionately the person for whom the diff looks fine, and a diff looks fine in proportion to how little of the surrounding system you know.

Two things follow, and neither is exotic:

• Name the approver before the run starts, not after the diff lands. One human, in the channel topic or the opening message, for that piece of work. This costs nothing and restores the property the terminal had for free. Accountability & ownership covers why the named role has to exist in advance to mean anything.
• Make the audience reviewers, not approvers. The rest of the channel is genuinely valuable — comments, catches, context the named approver lacks — and that value survives perfectly well without giving eleven people a button. Visibility is the feature. Distributed authority is a side effect you can decline.

The general version of this problem, including what happens when several people talk to the same agent at once, is in shared & multi-user agents; the mechanics of building a gate that catches anything are in approval & confirmation UX.

You have also just built an audit trail, in a system with a chat retention policy

A Slack Code channel accumulates something most engineering organisations have wanted for years and never had: the reason a change was made, sitting next to the change. Git records the diff and the commit message. It does not record the request in the requester's own words, the plan the agent proposed, the objection someone raised in the thread, or the fact that the approver read the preview and not the diff. All of that is now in a channel.

That is a real governance gain, and it arrives with two defects worth fixing before you rely on it:

• Retention. These channels are governed by your workspace's message-retention policy, which an admin configured while thinking about chat rather than about change records — and on some plans older history is not reachable at all. If the justification for a production change lives only there, your audit trail has a lifespan set by an unrelated decision. Set retention on coding channels the way you would set it on a change record — see retention & legal hold.
• Location. The record of who approved what should be reachable from the commit, not only from a search in another product. A link from the pull request to the channel, written by the integration, is a one-line fix that keeps the two halves joined.

The steelman

It would be easy to read this as chat-washing a terminal workflow, and that reading is too cheap. Three things here are genuinely better than what most teams do now.

First, the work becomes legible to people who were never going to open a terminal. A designer who can see a live preview and say "that is not the empty state we designed" is catching a defect at the only moment it is cheap to catch. Second, the agent field is treated as plural: five vendors in one surface, chosen per task, is closer to how teams actually work than any single-vendor console — and it prices the agents separately, which is honest about where the value sits. Third, apprenticeship. Agent work done privately in a terminal teaches nobody; a junior engineer reading a senior's plan tab is learning the part of the job that is hardest to teach.

None of that is undone by the approval problem. It just means the approval problem is worth ten minutes of policy rather than a shrug.

What to actually do

If you are turning this on next week

Write three lines of channel convention before the first run: one named approver per piece of work, stated up front; the plan tab is reviewed by that person before the agent is allowed to write code; and the channel's retention is set to match your change-record retention rather than your chat default. That is the whole policy, and it converts most of the diffusion risk into a rule people can follow without thinking about it.

If you already run coding agents at volume

Measure the thing this product is aimed at. Merged-without-edits rate and time-from-proposal-to-decision tell you whether the review queue is actually clearing; pull requests opened tells you nothing. If those two numbers do not improve after adopting a shared review surface, you have added an audience, not capacity — and the fix is upstream, in making runs self-verifying, per background coding agents.

If you are building an agent product of your own

Note what Slack decided was worth owning. Not the model, not the loop, not the tools: the surface where a human decides. Review cost is the metric your interface actually optimises — designing for review makes the case — and the design questions that matter are which artefact you put in front of the approver, and whether the approver is a person or an audience.

Further reading

On this wiki:

• Background coding agents — why detaching from the editor moves the bottleneck to review.
• Approval & confirmation UX — designing a gate that catches something.
• Shared & multi-user agents — what changes when several humans share one agent.
• Agent UX: designing for review — review cost as the metric your interface optimises.
• Human-in-the-loop — where to place a checkpoint, and the rubber-stamp trap.
• Claude Code vs Codex CLI vs Antigravity CLI vs OpenCode — the terminal agents this surface sits above.

Sources:

• SiliconANGLE — Salesforce introduces Slack Code to bring agentic team coding into the open
• Computerworld — New 'Slack Code' turns AI coding into a team activity
• TNW — Slack launches Slack Code, where teams and AI agents build together
• Salesforce Ben — Salesforce brings vibe-coding to Slack with new Slack Code