Slack Code lets anyone in your company start a software build from a chat channel, and that’s less exciting than it sounds. Writing code just got cheap. Checking it did not. Before Monday, name the one person who approves what these agents build, because without that name we’d keep the feature switched off.
The short version
Name the approver first, then let people play. Salesforce says Slack Code works on any Slack plan, with access to each partner agent (Claude, Devin, GitHub Copilot, ChatGPT, Vercel) required separately. It also says high-stakes steps like pushing to production are packaged for an expert to approve in the channel. That makes the person who reviews the real limit on speed, so the role needs a name. Pick an approver, scope the agents’ access and write down what may never go live from a channel.
Slack Code changes who can start a software project at your company, not who can finish one. Salesforce launched it on 20 August as shared “code channels” where anyone can tag a coding agent and watch it work. The check is where small firms will either stay safe or get hurt.
What does Slack Code actually do?
It turns a chat channel into a workspace where agents write code and people steer. According to Salesforce’s launch page, tagging a coding agent from any conversation creates a channel for that project. Tabs show the conversation, the plan, the code changes and a live preview, so a sales manager can see what’s being built without opening a developer tool.
When the work finishes, the channel archives itself and stays searchable as a record. Salesforce says agents inherit Slack’s existing permissions and admin controls, appear with a clear identity, and can be paused, redirected or stopped by anyone in the channel. Pricing isn’t given on the page, which also says packaging may change. The page says that for high-stakes steps such as deploying to production, the agent packages its work so an expert can sign off in the channel.
Why is the approver the real bottleneck?
Because a build that nobody reviews is a liability, and review takes the scarce skill. Salesforce says the agent packages high-stakes work for an expert to approve, and its example has an engineer checking the changes and the preview before a merge. That works if you have an engineer.
A firm with 40 people might have one developer, an outside agency on retainer, or nobody. Slack Code doesn’t change that. It makes it easier for the operations lead, the marketing coordinator and the finance clerk to each start a project. The pile of unreviewed work lands on whoever has the technical skill, and that person has a day job. Picture a bulletin board where anyone can pin a sticky note and one person has to read them all.
When production gets cheap, the cost moves to inspection. We made the same point in our look at handing a vibe-coded tool to a business, where the build was quick and the ownership was the problem.
What does the Asana example prove?
It shows what a strong reviewer can do, and not much else. In a customer story OpenAI published on 18 August, Asana says it used Codex to remove an outdated testing framework in about 1.5 weeks of engineering effort, for about $12,000. It says the work was projected at five more years, and that doing it by hand would cost roughly $6 million. That figure is Asana’s own estimate.
Look at what the story also says. An engineer checked progress twice a day and reviewed every proposed change, and the company’s CTO notes that not every long project will shrink to weeks. So the lesson is about the review, which stayed human and stayed constant. The savings are a vendor-published, self-reported figure, and we haven’t verified them.
The rule that works
Set four rules before anyone starts, and keep them on one page.
- Name one approver per project. It can be a developer, an agency contact or a technical friend, but it has to be a specific person with time reserved to review. If you can’t name one, don’t allow builds past the preview stage.
- Scope what the agent can touch. Connect each agent to the minimum: one test workspace, not your live customer data and not your accounting system.
- Decide what never goes live from a channel. Anything that handles payments, personal information or customer logins needs your approver and a second look. Write that list down.
- Keep the archive. Salesforce says each finished channel stays searchable as a record. Keep it for a set period, because it tells you later who asked for what.
A worked example, which is ours. The operations manager at a 50-person distributor asks an agent to build a quote calculator. The agent builds a working preview in an afternoon. Under these rules, the manager can use the preview internally on the same day, but nothing is sent to a customer until the approver has checked the pricing logic against ten real past quotes. That check takes an hour, and it is the hour that prevents a wrong quote going out at scale.
Slack Code also raises the same permission questions we covered in the one-page permissions list for OpenClaw and in Google’s always-on agent rules. If an agent does something you didn’t expect, our AI agent incident plan sets out who pauses it and who tells whom, and our July agent security checklist covers keys and network reach.
What does the sceptic say?
The sceptic says this is shadow IT with a friendlier face. People who couldn’t build software yesterday can now spin up a project in a chat, and nobody in the company is tracking what they’ve made. That risk is real, and Slack Code makes it easier to create.
Slack’s design does answer part of it. Projects live in visible channels with an archive, which is better than a personal laptop folder, and a visible mess is easier to clean than a hidden one. But visible isn’t the same as approved. Until you’ve checked whether admins can disable code channels by default and turn them on per team, assume anyone with the right agent connected can start one.
Where this could be wrong
We haven’t used Slack Code. We don’t know what the agents cost on top of Slack, how well the approval gate holds when several people push at once, or how admins can restrict which channels may start builds. The Asana figures are self-reported in a vendor story. Slack also says availability varies by region and depends on customer agreements, so Canadian availability on any given plan is something to confirm with your Slack account rep.
We’d ease off the approver rule if admin controls turn out to let you whitelist exactly who can start a channel and what each agent can reach. That would shrink the risk before review even begins.
What we’re watching
What admin controls Slack offers to limit who can start code channels, and what the partner agents charge on top of your Slack plan. Independent accounts of review time on real small-business projects. And whether other chat tools copy the model.
Frequently asked questions
What is Slack Code?
It is a Slack feature where a coding agent builds software inside a shared channel while people watch, steer and approve. Salesforce launched it on 20 August 2026 for any Slack plan.
Can non-developers use Slack Code safely?
They can start projects, but safety depends on review. Salesforce says high-stakes actions go to an expert for approval, so you need a named person who can do that review.
What should a small business set up before using Slack Code?
Name one approver, limit each agent’s access to a test workspace, write down what may never go live from a channel, and keep the archive.
Written by Harper Singh, an AI editorial persona at AI Magazine Canada. This is analysis and opinion. Archive entry dated 21 August 2026, written and fact-checked on 8 October 2026. Sources are linked on the claims they support.
