Slack announced something this week that’s worth pausing on — not because it’s flashy, but because it quietly answers a question I didn’t realize was still open: when an AI coding agent does work, who else gets to see it happen?
What actually shipped
Slack Code, launched August 21. It’s a new feature that lets AI coding agents — Anthropic’s Claude, Cognition’s Devin, GitHub Copilot, and Vercel’s agent, with OpenAI’s ChatGPT “coming soon” — work inside dedicated Slack channels instead of a private terminal or browser tab.
Here’s how it works in practice: someone @mentions one of these agents in a project channel. Slack spins up a temporary “code channel” — a dedicated space where the agent posts its plan, its code changes (shown as a “diff,” a side-by-side view of exactly what got added or removed), and live previews as it works. Anyone on the team can watch, jump in with feedback, or redirect the agent mid-task. A designer can drop a Figma file into the middle of an agent’s work and have it get incorporated without restarting anything. When the task is done, the channel auto-archives but stays searchable — a built-in audit trail of what the agent did and who weighed in.
The pitch, in Slack’s own words: AI coding has been “single-player” — one person, one agent, invisible to the team until the work shows up finished. Slack Code makes it multiplayer.
Cognition’s numbers back up that this isn’t just marketing language — they reported their internal count of merged pull requests (a “pull request,” or PR, is the standard way a code change gets proposed and approved before it ships) went up 10x in a few months, while headcount only grew about 40%.
Why this is the pattern to watch, not the feature
I’d flag this less as “a new coding tool” and more as the second data point on a trend I called out with Claude Cowork back in mid-August: agents are moving from tools you configure to teammates you supervise.
Cowork was about an agent carrying your identity and session state across devices. Slack Code is about an agent carrying its work into a shared space by default, instead of a private one. Different mechanism, same underlying shift — agentic work is becoming ambient and visible rather than something you deliberately export and share after the fact.
That’s a real improvement over the status quo. Anyone who’s managed a technical team knows the failure mode Slack is targeting: someone disappears into a private AI session for two hours, comes back with a finished PR, and nobody had a chance to catch a wrong assumption before it got baked in. Making that process visible in real time — where a PM or a non-technical teammate can flag “that’s not quite what we meant” before the agent runs further with it — is a legitimately good governance instinct. Slack’s product VP put it well: visibility is “a guard against [AI slop], because people can see your work, people can comment on your work.” I agree with that as far as it goes.
Where the actual risk lives
Here’s the part that matters more than the demo: Slack’s security model for this is that agents inherit exactly the permissions of the person who invoked them — no separate bot-level access, no new service identity, no elevated “god mode” for the agent. If you can see a channel and a repo, the agent you summon in that channel can act with that same access. Nothing more.
That’s the correct design principle. It’s also not a solved problem — it’s a scoped one. The visibility Slack is selling (“everyone can see the agent’s work”) only functions as a safeguard if someone with the judgment to catch a mistake is actually watching that specific channel at that specific moment. A code channel that spins up, runs, and archives within a few hours — which Slack says happens for the majority of tasks — can complete an entire request-to-merge cycle without anyone outside the person who triggered it ever looking in. Visibility that exists in principle isn’t the same as review that happens in practice.
The other detail worth sitting with: Cognition’s own exec said he expects human sign-off on every merge to eventually disappear entirely — “I suspect maybe in the next year it’s just going to go through automatically.” That’s a reasonable prediction about where efficiency pressure pushes this. It’s also exactly the point where “the team can see it happen” quietly becomes “the team could have seen it happen, if anyone had been looking.” The permissions model is sound. The assumption that visibility equals oversight is the part I’d stress-test before rolling this out anywhere with real stakes — a codebase touching protected health information, financial data, or anything regulator-adjacent.
The takeaway
Don’t evaluate Slack Code as “AI coding gets a nicer UI.” Evaluate it as the industry formalizing a pattern that used to be ad hoc: agents doing real work inside the exact permission boundary of whoever invoked them, in a space designed to be watched rather than reviewed after the fact. That’s progress — it’s a better default than the private-tab status quo it’s replacing. But “designed to be watched” and “actually watched, by someone with the standing to say no” are two different guarantees, and only one of them ships out of the box.
That’s the same question I’ll keep asking of every tool in this category: not whether the agent can act, but whether anyone with the judgment to catch a problem is actually positioned — and incentivized — to look before it ships.