Salesforce introduced Slack Code on August 20, 2026 — a tool built to run agentic, team-based software development inside Slack itself, with parts of the underlying work released to the public in the same announcement. For engineering teams that already use Slack as their coordination layer, that is a meaningful shift: instead of a developer running a coding agent in an IDE sidebar and then pasting its output into a channel so teammates can see it, the agent's work — its changes, its test runs, its status updates — now lives natively where the rest of the team is already watching, commenting, and making decisions.

According to SiliconANGLE AI, Salesforce frames Slack Code explicitly around bringing agentic coding "into the open," surfacing agent activity to the whole team rather than keeping it inside one engineer's private session, and open-sourcing pieces of the tooling behind it.

The IDE was never the whole workflow

Coding agents have mostly lived inside or alongside the code editor — that's where tools like Cursor, GitHub Copilot, and Claude Code operate by default. But a large share of the coordination around engineering work — planning, code review, "can someone look at this," incident response — already happens in Slack, not the editor. Putting an agent's output directly into that layer removes a translation step: no copy-pasting a diff or a test result into a thread just to get a teammate's eyes on it. The work and the conversation about the work sit in the same place.

What open-sourcing part of it signals

Salesforce choosing to open-source part of Slack Code, rather than keep the whole thing proprietary, matters for teams that are wary of handing an opaque agent write access to both their codebase and their primary communication channel. It gives engineering orgs a way to inspect, extend, or self-host pieces of the integration instead of trusting a black box. In our estimation, this is also a straightforward distribution play: open availability lowers the bar for other tools and internal agents to plug into the same Slack-native workflow, which benefits Salesforce more the more teams treat Slack as the default place agentic coding happens.

What this means for teams building with agents

For teams already running agents against real codebases, moving that work into a shared channel changes a few practical things:

• Audit trail by default: agent commits and decisions land in a shared, searchable channel instead of a private IDE session, which matters when someone needs to review or roll back an agent-driven change after the fact.
• Permissioning becomes a Slack problem, not just a repo problem: who can direct an agent, approve its output, or trigger a merge now runs through Slack's channel and workspace permissions as much as through Git.
• Review friction may drop, but so does the natural checkpoint of a pull request; teams will need to decide explicitly how much of an agent's output ships without a human gate.
• Existing CI/CD and code review tooling likely needs an integration point with an agent-in-channel workflow rather than treating it as a separate system bolted on afterward.

None of this requires teams to change how they write code — it changes where the record of that work lives, and who can see and act on it as it happens.

AiiN's takeaway

This is another data point in a pattern we've been tracking: agentic coding is spreading out from the editor into the tools teams already use to coordinate. Salesforce putting agent-driven development directly into Slack, and opening part of it up, reinforces the idea that the interface for agentic coding is becoming less about the IDE and more about wherever a team's decisions actually get made. If agent work is going to land in a shared channel by default, the permissions and review layer around that channel — not just the coding agent itself — is what teams should be evaluating next.