Slack Code makes starting software cheap and leaves checking it exactly where it was. Salesforce launched it on August 20 as shared “code channels” where anyone can tag a coding agent and watch it build. That changes who can start a project at your company. It doesn’t change who can finish one.
So before Monday, name the one person who approves what these agents build. Without that name, we’d keep the feature switched off.
Key points
- What does Slack Code actually do? It turns a chat channel into a workspace where agents write code and people steer.
- Why is the approver the real bottleneck? Because a build that nobody reviews is a liability, and review takes the scarce skill.
- What does the Asana example prove? That a strong reviewer makes the savings possible, and not much else.
- What should a 50-person firm decide before Monday? Four things, kept on one page. Name one approver, scope each agent’s reach, list what never goes live from a channel, and set how long you keep the archive.
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 lead can see what’s being built without opening a developer tool.
Salesforce says Slack Code works on any Slack plan, with access to each partner agent (Claude, Devin, GitHub Copilot, ChatGPT, Vercel) required separately. When the work finishes, the channel archives itself and stays searchable as a record. 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. The page doesn’t give pricing and says packaging may change. 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’s example has an engineer checking the changes and the preview before a merge, and its page says high-stakes work is packaged for an expert to approve. 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.
Count the attention involved. If five people each start two projects a week, that’s ten reviews a week. At an hour each, a quarter of one person’s working week goes to reading what other people’s agents built. That’s our hypothetical, but the shape holds for any firm with more starters than reviewers.
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?
That a strong reviewer makes the savings possible, and not much else. In a customer story OpenAI published on August 18, 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 else the story 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. The review stayed human and stayed constant. Asana is a large company with engineers on staff. The twice-a-day check is the part a 40-person firm can copy, and the $6 million comparison isn’t. The savings are vendor-published and self-reported, and we haven’t verified them.
The pattern repeats across tools. Whenever creation gets cheaper, someone gets a new pile of checking. Spreadsheet macros did it, and shared drives did it. The firms that coped had named an owner before the pile arrived. The ones that didn’t discovered the pile when a customer found the mistake.
What should a 50-person firm decide before Monday?
Four things, kept on one page. Name one approver, scope each agent’s reach, list what never goes live from a channel, and set how long you keep the archive. Each takes an hour to settle and removes a way for a quick build to turn into a slow problem.
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 set aside to review. If you can’t name one, don’t allow builds past the preview stage.
A narrow reach for each agent. Connect it to a test workspace, not your live customer data and not your accounting system.
A list of what never goes live from a channel. Anything that handles payments, personal information or customer logins needs your approver and a second look.
A retention period for the archive. Each finished channel stays searchable, and keeping it tells you later who asked for what.
Take an example that’s ours. The operations lead at a 50-person distributor asks an agent to build a quote calculator, and the agent builds a working preview in an afternoon. Under these rules the lead can use the preview internally the same day, but nothing goes to a customer until the approver has checked the pricing logic against ten real past quotes. That check takes an hour. It’s the hour that stops a wrong quote going out.
The sceptic calls this shadow IT with a friendlier face. People who couldn’t build software yesterday can now spin up a project in a chat, and nobody is tracking what they’ve made. The risk is real, and Slack Code makes it easier to create. Slack’s design answers part of it, since projects live in visible channels with an archive, which beats a personal laptop folder. 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.
Slack Code also raises the 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. Only 5% of firms have AI agent controls in place, so write the approval rule first.
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. Slack also says availability varies by region and depends on customer agreements, so check Canadian availability on your plan with your Slack account rep. If admin controls let you whitelist exactly who can start a channel and what each agent can reach, we’d ease off the approver rule, because that shrinks the risk before review even begins.
One more point on the approver. Give that person the authority to say no, and tell the rest of the firm in advance that the answer can be no. A reviewer who is expected to wave things through isn’t a control, just a signature. If the approver is an agency, put the review turnaround in the retainer so a Friday-afternoon build doesn’t sit untouched for a week.
Name the approver today. The rest can wait for Monday.
Salesforce’s own framing is that experts approve the high-stakes steps. We’d go further for a small firm and treat every step that touches customers, money or staff records as high-stakes until the approver says otherwise.
Staff using their own agents on work accounts need rules too; see our policy for personal AI agents at work. Builds that ship need owners, and enterprise AI roadmap promises are now a contract matter.
Frequently asked questions
What is Slack Code?
It’s a Slack feature where a coding agent builds software inside a shared channel while people watch, steer and approve. Salesforce launched it on August 20, 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.
Archive entry dated August 21, 2026, written and fact-checked on October 8, 2026. Sources are linked on the claims they support.
