Scale · pm · 7 min read

Slack Just Made Coding Agents Multiplayer. That's a Bigger Deal Than It Sounds.

Slack Code puts Claude, Devin, Copilot and Vercel's agent in shared channels where PMs can steer them. Here's what changes, and what doesn't.

Published August 23, 2026 ·

slack coding agents collaboration product management code review

On August 20, Slack launched Slack Code: dedicated channels where AI coding agents do their work in front of the whole team. Tag Claude Code, Devin, GitHub Copilot, or Vercel’s agent from any conversation, and it spins up a project-specific channel with code diffs, live previews, a running plan, and an approval step before anything ships. The channel archives itself when the job’s done and leaves an audit log.

It’s free on every Slack plan, including free workspaces, from day one.

Most coverage framed this as Salesforce chasing an AI story. That’s part of it. But the interesting thing is what it does to the shape of the work.

Every coding agent until now has been single-player

Think about how agent work happens today. One person opens a terminal or a browser tab, talks to one agent, and nobody else sees anything until a pull request shows up. The reasoning, the dead ends, the moment the agent misread the request — all of it happens in private.

That’s fine when the person driving is an engineer who can spot a bad turn. It’s the entire problem when they aren’t.

Slack Code’s bet is that moving that work into a shared channel changes who can participate. Slack’s interim CEO Rob Seaman put it this way in the launch briefing: “code is no longer the bottleneck. Ideas, taste, judgment, craft — those are the things that are the bottleneck, and you’ve effectively extended the population that can contribute ideas, taste, judgment, and craft to anybody that exists in your Slack.”

Strip the pitch out and there’s a real claim underneath: the constraint on shipping software has moved from typing to deciding, and deciding is a thing product people are already good at.

The most useful detail is who was demoing it

Katie Steigman, Slack’s VP of Product, is a product manager, not an engineer. She described her own workflow: she puts up pull requests, and she almost always tags an engineer rather than just requesting approval. “Almost every time, an engineer will say something like, ‘Come on, you can make that a little bit tighter,’ or they’ll actually give it some specific technical guidance, and the agent will take one more rev.”

That’s the honest version of what this unlocks, and it’s worth sitting with. She isn’t shipping unreviewed code. She’s taking the first 80% off an engineer’s plate and pulling them in for the judgment call. The agent does the typing; the engineer does the taste; the PM does the framing and the follow-through.

If you’re a PM wondering whether this means you can now ship features alone — no. It means you can now show up with a working diff instead of a ticket.

What Cognition’s numbers actually say

Jeff Wang, Cognition’s president of new enterprise, offered the velocity stat: internal merged PR count up 10x over a few months while headcount rose about 40%.

Take that seriously and skeptically at once. It’s a vendor’s internal number from the company that makes Devin, measuring merged PRs — a metric that rewards volume, not value. But the second thing he said is the one that matters for this audience: “Believe it or not, a lot of our bugs are reported by our sales team. They report it in Slack, and then someone who’s technical applies them to fix the bug.”

Seaman’s follow-up was the whole thesis in one sentence: “So much of that stuff never even made its way to a product manager into a backlog because the communication vehicles weren’t there.”

Every PM reading this knows that graveyard. The bug someone mentioned in a channel, that never became a ticket, that’s still there six months later. Slack Code is aimed squarely at it.

The part you should be uneasy about

Asked whether opening agent access to everyone would flood companies with AI slop, Slack’s answer was that visibility is the antidote — people can see your work and tell you it’s bad.

That’s a decent argument, and it’s better than nothing. But visibility only works if someone competent is actually watching. A code channel with one participant is a terminal with worse ergonomics. If your org adopts this and nobody senior joins the channels, you’ve built a slop pipeline with an audit log.

The harder thing is what Wang said about the approval step. Today a human has to approve before code ships. He predicted that “maybe in the next year it’s just going to go through automatically.”

That’s the vendor telling you where this goes. Right now the merge gate is the safety mechanism that makes non-engineer participation reasonable. If it comes out, everything above changes character. Decide who owns that setting in your org before the default moves.

The market data is worth holding alongside the demo, too. Gartner predicted more than 40% of agentic AI projects will be cancelled by the end of 2027. McKinsey’s most recent State of AI survey found 62% of organisations experimenting with agents, about a third scaling AI at all, and only 39% reporting bottom-line impact. Enthusiasm is not adoption.

Two things that are quietly well designed

Permissions. Agents act using the invoking user’s access — in Slack and in the systems they touch. Seaman was direct: no god permissions, no bot-level permissions. An agent sees the channels it’s added to and the conversation that triggered it. Devin runs in sandboxes with an optional no-internet mode. Compare that to the usual pattern of provisioning a service account with broad access that nobody audits, and it’s a meaningful improvement.

It still lands as a normal pull request. Agent output goes into GitHub as an ordinary PR, so whatever review rules, CI, and release gates you already have still apply. Slack lowers the barrier to getting a first draft up; the due diligence stays where it was.

What to actually do this week

If your team uses Slack and already pays for a coding agent: turn it on. It costs nothing and it makes agent work legible to people who currently only see outcomes.

Start with bug fixes, not features. Small, verifiable, obviously-right-or-wrong changes are where a non-engineer can judge the result honestly. Feature work is where you’ll fool yourself.

Put a senior engineer in the channels on purpose. Not as a gatekeeper — as the person whose “make that tighter” makes the whole model work. The Steigman workflow is the reference implementation. Copy it.

Write down your merge-gate policy now. One sentence, in your team docs: who can approve agent-written code, and for which parts of the codebase. You want that decision made deliberately, while a human still has to make it.

The era of one person whispering to an agent in a private tab is ending. Whether the crowd makes the output better or just makes the mess visible depends almost entirely on who you invite into the room.