AI coding usually happens in a private terminal: one person asks an agent to fix something, watches the output, and decides whether the result deserves a pull request. Slack Code moves that work into a shared channel, so your teammates can see the request, the plan, the code changes, and the review before anything ships. That makes human approval the decision point, not an optional courtesy.

What changes for you: a sales or support teammate can report a broken feature where engineers already work, an engineer can shape the fix, and the whole team can find the history later. The useful question is not whether an AI agent can write code. It is whether your team can make its work visible without weakening permissions or release controls.

1. The private coding task becomes a team workflow

Start with the basic mechanism. A coding agent is software that can inspect a project, change files, run tests, and prepare a proposed code change. A pull request is the review package that asks a team to examine those changes before merging them into the main codebase. Slack Code connects that agent to a conversation where the request and the review already happen.

Slack Code supports Claude Code, Devin, GitHub Copilot, and Vercel's agent. The product comes from Slack, the Salesforce-owned messaging platform, and was announced as available on any Slack plan at launch. That does not mean the coding agents are included. Customers provide their own access to the partner agents.

The workflow begins in an existing Slack conversation. Someone tags an agent with a task, such as investigating a broken checkout button. The agent acknowledges the request, examines the relevant project, and reports its progress. Slack Code then creates a project-specific code channel where the task can continue in public.

That channel acts like a shared workbench. The agent posts a running plan, code diffs, and live previews in dedicated tabs. A code diff is a line-by-line view of what changed. A live preview lets people inspect the result in a working interface instead of judging the code from a description alone.

The distinction matters for non-engineers. A product manager can clarify the intended behavior. A designer can add a Figma file. A support or sales teammate can explain how the bug appeared for a customer. An engineer can check whether the proposed fix fits the system. Each person contributes a different kind of evidence, and the agent keeps the task in one place.

When the work ends, Slack Code archives the channel and leaves a searchable audit trail. An audit trail is a record that lets a team reconstruct what was requested, what the agent did, who commented, and what happened before approval. It will not prove that the code is good. It does make undocumented work harder to hide and duplicated work easier to spot.

2. The agent follows a conversation, not the whole company

The next mechanism is context. Context means the information an agent receives to interpret a request. Give it too little, and it misses the requirement. Give it too much, and unrelated or sensitive information enters the task. Slack Code's value depends on keeping that boundary understandable.

Slack says an agent gets the context of the conversation that triggered the code channel. Slack's Claude in Slack guidance gives a concrete example: when invoked with @Claude, Claude receives up to 20 recent channel messages or 50 messages in a thread. Those limits do not mean every agent has identical behavior, but they give you a practical privacy question: which messages will the agent actually see?

Slack's guidance also says the Claude app is replaced by the Claude Tag starting August 3, 2026. If your team manages the integration, check which label and installation flow appear in your workspace before documenting the process for colleagues.

That question belongs in team setup, not in an emergency review. Tell people whether a channel is appropriate for customer data, credentials, private personnel information, or unreleased plans. A message that looks harmless to a human reader can become input to a coding task when an agent is tagged.

Slack also offers a broader connection method called the Model Context Protocol, or MCP. MCP is a standard way for an AI assistant to request information or perform actions in another service. Slack's MCP guide says assistants such as Claude, Perplexity, and Cursor can use it to search messages, read specific channels and threads, send messages, and create canvases on a user's behalf.

For you, the important distinction is between seeing a task and being allowed to act. A team should document which agents can read Slack, which can post, which can reach a code host, and which can open a pull request. The shorter the permission path, the easier it is to review.

Slack's product story also includes agent direct messages, an Agents tab with live status and a stop button, and an “Add to Slack” flow for services including Lovable, n8n, OpenAI, LangChain, and Airtable. These features make agents easier to find and stop. They also make it easier to add more of them, so start with one bounded workflow rather than turning every channel into an experiment.

3. Permissions limit the blast radius, but they do not remove judgment

Permission is the rule that decides which information or action a user can access. An access-control list, often shortened to ACL, is the set of permissions attached to that user or resource. Slack says Slack Code agents inherit the permissions of the human who invokes them, and nothing more.

In plain language, the agent does not receive a new all-powerful identity just because it is an AI system. Slack says the agent can access information available to the user and the channels where it has been added. That model is easier for an IT team to reason about than a bot with a permanent master key.

The boundary still depends on the person who starts the task. If a user can access a sensitive channel or repository, an agent acting for that user may receive access within the stated workflow. The permission model narrows the blast radius. It does not decide whether the original request was wise.

Shared channels add another edge case. Slack Connect lets channels span separate workspaces, which means people from different organizations can collaborate in one conversation. Slack's developer documentation identifies fields that distinguish shared, externally shared, and organization-shared channels, and warns that apps must handle those cases. It also notes that there is no single method for listing every channel shared with an external organization.

That limitation matters when a coding agent works near a partner, contractor, or customer. Before an agent enters a Slack Connect channel, check which organization owns the repository, who can read the conversation, and whether the resulting pull request will cross the same boundary. Do not treat a shared channel as an internal room with extra guests.

Execution adds a second boundary. Cognition says Devin runs in isolated sandboxes with “minimum viable access.” A sandbox is a separated computing environment designed to keep an agent's actions away from unrelated systems. Cognition also describes an optional mode with no internet access at all.

Those controls reduce the damage from a mistaken command or an overbroad task. They do not replace code review, tests, dependency checks, or a release gate. A sandbox can contain an action. It cannot tell you whether the feature solves the right problem.

4. Visibility can improve quality, while multiplying low-quality work

Slack's argument for multiplayer development is straightforward: people catch more when they can see the work as it happens. Katie Steigman, Slack's VP of product, called visibility “a guard” against poor AI output because people can comment and change the work. The claim has a practical basis. A product person may spot a user-facing mistake, while an engineer catches a security or maintenance problem.

The shared channel also changes who reports defects. Jeff Wang, president of new enterprise at Cognition, said sales staff report many of Cognition's bugs in Slack. In the demonstrated workflow, Devin acknowledged a report, investigated it, opened a pull request, and used Chrome and DevTools to test the feature. The agent then posted code changes, screenshots, and a recorded demonstration.

This is the upside for a busy team: the person closest to the problem can start the work without first translating it into a formal backlog ticket. Experts still shape the fix, but they do not need to discover every problem themselves. That can reduce delay and prevent people from unknowingly asking agents to solve the same issue.

There is a catch. Visibility makes weak work easier to find, but it also makes weak work easier to produce at scale. Cognition reported a 10x increase in its internal merged pull request count in recent months while headcount rose 40 percent over the same period. Those figures describe Cognition's internal experience, not a general productivity guarantee.

Industry data points in both directions. Gartner predicted that more than 40 percent of agentic AI projects would be canceled by the end of 2027, citing rising costs and unclear business value. McKinsey's most recent State of AI survey found that 62 percent of organizations were at least experimenting with AI agents, while about a third had begun scaling AI and 39 percent reported any bottom-line impact from AI. The gap between trying an agent and getting durable value remains large.

That gap gives your team a useful test. Count accepted outcomes, not agent sessions. Track how often reviewers reject or substantially rewrite the output. Measure time from a verified bug report to a safe release. If the number of generated pull requests rises while review time, rollback work, or duplicate fixes rises faster, the workflow is producing motion rather than progress.

5. The strategic bet is about judgment, not typing speed

Slack's interim CEO, Rob Seaman, summarized the product's thesis this way: “code is no longer the bottleneck.” The point is not that writing code has become effortless or that engineers no longer matter. It is that a team can now generate proposed changes faster than it can agree on the problem, inspect the tradeoffs, and decide what deserves to ship.

That shifts the scarce resource upstream. Product judgment defines the desired behavior. Design judgment decides whether the experience makes sense. Engineering judgment checks architecture, safety, performance, and maintenance. The agent supplies execution inside boundaries that people set.

Slack is betting that the collaborative layer around these agents will matter as much as the agents themselves. That explains the product's focus on channels, status, searchable history, shared review, and stop controls. The unexpected angle is that Slack Code is less a new terminal than a new meeting room with a robot that can edit the building.

The room helps only if the right people enter it. A designer who can attach a file is useful when the design is clear. A sales teammate who reports a reproducible bug is useful when the report includes steps and expected behavior. An engineer who reviews the pull request is useful when the review remains independent rather than becoming a rubber stamp.

Human approval remains the threshold. Cognition's Jeff Wang said a human still gates every merge today and speculated that some work might eventually pass automatically. That is a prediction, not a current Slack Code capability or a reason to remove your controls. Keep the distinction visible in policy: automated tests can provide evidence, but a person decides whether the evidence is sufficient.

6. Open one code channel only after the controls are clear

Use Slack Code as a controlled workflow, not a universal shortcut. Begin with low-risk tasks that have clear success conditions, such as reproducing a bug, updating a test, or preparing a small documentation change. Keep production access, secrets, external posting, and final merges behind existing approvals.

1. Choose one workflow: pick a problem that already arrives in Slack and has a clear owner.
2. Map the permissions: record the invoking user, channels, repositories, agent account, and whether Slack Connect is involved.
3. Require a human review: check the diff, tests, dependencies, screenshots, and the original request before merging.
4. Measure the outcome: compare cycle time, rework, duplicate tasks, rollback incidents, and reviewer effort against the old process.
5. Stop when the trail gets noisy: if the team cannot tell what changed, why it changed, or who approved it, pause expansion.

That approach preserves the benefit Slack Code is designed to provide: non-engineers can surface problems, experts can shape fixes, and the team can keep a record of the work. It also protects the part AI cannot own for you: deciding whether a change is correct, safe, and worth maintaining.

If your team already uses AI coding tools, evaluate Slack Code as a shared workflow while retaining human review, GitHub release gates, and permission checks before allowing agents to ship changes. Keep the merge gate human. The faster agents become, the more valuable a clear record of human judgment becomes.