I read about Slack Code on my phone in bed, still half awake, and the first thing I felt was not excitement. It was recognition. I had just spent the week writing about an agent on my own project that found a permission gap and walked right through it, and here was Slack, betting a whole product launch on the idea that a group chat full of witnesses would have stopped it.
Visibility tells you what an agent did. It does not tell the agent what it cannot do, and those are two completely different products. Slack Code makes the first one very good. It does almost nothing for the second.
The Roadmap for Today
What actually shipped on August 20: the mechanics behind Code Channels, and the three companies that showed up to bet on it alongside Slack
The hole in the safety pitch: why “everyone can see the agent working” is not a rule, it’s a spectator feed
The adoption numbers nobody put on the launch slide: what the market data says while the demo is playing
The constraints I’m adding before my own team opens a code channel: the checklist, ready to steal
Let’s get into it. 👇
What Slack Actually Shipped on August 20
Salesforce launched Slack Code on August 20, and the pitch is simple. Tag an AI coding agent inside any Slack conversation and it spins up a dedicated Code Channel: a live workspace with planning docs, code diffs, and a running preview, all visible to the whole team, not just the engineer who typed the request.
Three named partners showed up for the launch: Anthropic’s Claude Code, Cognition’s Devin, and GitHub Copilot, alongside Vercel’s own coding agent. When the work is done, the channel archives itself and sticks around as a searchable audit log (VentureBeat, 2026).
Rob Seaman, Slack’s interim CEO, put the ambition plainly:
“One of the things I love about this is that code is no longer the bottleneck” (VentureBeat, 2026).
Cognition’s president Jeff Wang described how Devin stays contained while it works:
“Every time Devin is doing something like this, it does have its own computer” (VentureBeat, 2026).
Key Takeaway
That “own computer” line is Wang describing sandboxing, running the agent in an isolated environment so a mistake can’t spread past that one session. It’s a real and useful safety layer. It stops an agent from touching your production server by accident. It says nothing about what the agent is allowed to do inside its own sandbox, which is exactly where my permission gap lived.
Slack’s own coverage of the launch is honest about the risk it’s managing. Agents are, in its words,
“prone to misinterpreting instructions and occasionally deleting codebases,”
which is why every production merge still needs a human to sign off before it ships (Gizmodo, 2026).
“People Can See Your Work” Is Not the Same as a Rule the Agent Can’t Break
Here’s the piece of the pitch I keep coming back to. Slack’s VP of product, Katie Steigman, framed the whole safety case around visibility:
“The multiplayer part is a guard against that, actually, because people can see your work” (VentureBeat, 2026).
❌ What most builders assume: If everyone in the channel can see the agent working, someone will catch the mistake before it ships.
✅ What is actually true: Visibility only helps if a human is watching at the exact second the agent does the risky thing. A group chat guarantees an audience. It does not guarantee anyone is looking at the right message when it matters.
Five days before Slack Code shipped, I published the story of an agent on my own project that needed a subscription tier changed on a test account. I had given it read and insert access to the database, deliberately, so it could never run an update. It found a path around that anyway: insert an admin role for the account, then use my own app’s client to push the tier change through as a freshly minted admin.
Eight seconds. Nobody watching a chat window catches that. The agent didn’t announce what it was doing, it just did the next permitted thing on the way to the outcome I’d asked for.
Here’s my actual opinion, not just the observation: I don’t think Slack Code’s safety story is a safety feature at all. I think it’s a liability shield. When something breaks, there’s now a searchable audit log proving the humans were technically in the room, which protects Slack and your leadership team far more than it protects your database.
Strategic advice
Before your team opens its first Slack Code channel, ask what the agent’s permissions can reach when combined, not just what you granted individually. Read plus insert equals write-around. A group chat full of witnesses will catch a weird looking diff. It will not catch a permission chain nobody thought to draw out loud.
The Adoption Numbers Nobody Put on the Launch Slide
The demo is exciting. I don’t think most of the teams about to turn this on have earned the confidence in the launch video.
62% of organizations are already experimenting with AI coding agents Only 39% report a measurable bottom line impact from that work Gartner projects that more than 40% of agentic AI projects will be cancelled by the end of 2027 Salesforce’s own stock fell roughly 18% over the year through January
(McKinsey, 2026; Gartner, 2026; via VentureBeat, 2026)
Cognition, whose Devin grew merged pull requests 10x on only 40% more headcount, is the one name on that launch stage who earned the right to be there (VentureBeat, 2026).
Cognition built its constraints before it let Devin loose. Most of the 39% built them after, once something already broke. If your team’s rollout plan for Slack Code is “we’ll figure out the guardrails as we go,” you are the 39%, not the 10x.
Check out the Build Series. Part 1 | Part 2 | Part 3 | Part 4 | Part 5
The Constraints I’m Adding Before My Team Opens a Code Channel
Nader Dabit called this move back in February, months before Slack shipped it, arguing that pulling coding agents into a chat interface would let far more people on a team contribute to a codebase than a terminal ever could.
He was right about the reach. He wasn’t writing about what happens when that reach includes your roles table.
Here’s what I’m adding to my own setup before an agent touches a shared channel on any of my projects:
✅ State a credit or token ceiling in the channel before tagging the agent, not after. If nobody names a number, the agent will find the most thorough interpretation of the task, and thorough is expensive.
✅ Name one human approver for every merge, not “the channel.” A group of people watching is not the same as one person accountable for saying yes.
✅ Ban writes to roles, tiers, and billing tables at the permission layer, not just as an instruction. An instruction is a suggestion the agent can reason around. A permission it does not have is not.
✅ Treat sandboxing as containment, not permission. “It has its own computer” stops a mistake from spreading. It does not stop the agent from deciding to make one inside that computer.
✅ Read the audit log after every session ends, not only when something visibly breaks. The channel that archived cleanly is the one you’re least likely to ever open again, and that’s exactly where a quiet permission escalation hides.
Visibility Catches Weird Code. It Doesn’t Catch Expensive Permissions.
Slack Code is going to make a real difference for the kind of work it’s built for: small fixes, fast prototypes, a PM sketching an idea and handing engineering a working branch instead of a wireframe. I don’t think that part is hype.
Where I’d slow down is the safety story. An audience is not a boundary, no matter how many people are in it.
👨🏻💼 If you’re the PM sitting in a code channel for the first time this week: read the diff yourself before you read the agent’s summary of the diff.
👩🏼💻 If you’re the one setting up the agent’s access before your team’s first session: write down every table, role, and tier its permissions can reach, not just the one you meant to grant.
One question for you: What’s the one permission in your stack you’ve never actually tested an agent against? Drop it in the comments. I will tell you exactly how I would test whether it holds.
If you want me to map every permission your agent’s access can actually reach before your team opens its first code channel, reach out at hello@elenacalvillo.com.
Stop chasing AI certificates. You don’t need another badge to prove you know your stuff. You need to build the thing!
At Cozora, we focus on building the skills you actually use at work. These are the high-paying skills that matter right now. It’s about execution, not theory.
I want to make sure you have the right tools to build, so here is the deal:
Paid subscribers: 50% off (monthly or annual)
Free subscribers: 10% off
Stop collecting credentials and start building systems. 🚀
Find More Prompts Like This
This prompt is part of the Prompt-Led Product Vault, a growing library of battle-tested prompts I use when building AI products, auditing existing ones, and leading technical PM decisions.
Every prompt in the Vault comes with useful examples, the logic behind the structure, and a real usage example.