Slack Code Moves Code Review Into Chat. Governance Breaks.

Salesforce launched Slack Code on August 20, putting Claude Code, Devin, GitHub Copilot, ChatGPT, and Vercel's agent into dedicated Slack channels with Conversation, Plan, Code Diffs, and Live Preview tabs visible to anyone in the channel. The product is available on any Slack plan at launch. The premise is that code review should happen where teams already talk. The governance implication nobody is discussing: the PR-based controls most engineering teams rely on did not get an invitation to this channel.

What Slack Code actually does#

Tag a coding agent from any Slack conversation and it spins up a dedicated code channel for that task. The whole team sees the plan, the diffs, and a live preview as they arrive. When the work finishes, the channel archives itself but stays fully searchable as institutional context. According to Slack's own data, over 70% of code channels spin up and close within a single day.

That speed is the pitch. It is also the risk.

The CODEOWNERS bypass nobody named#

Most engineering teams enforce review requirements through a combination of branch protection rules and CODEOWNERS files. Those controls sit at the PR layer. A required reviewer in CODEOWNERS cannot approve a code change mid-thread in Slack, but nothing stops them from nudging the agent before a PR exists. By the time the diff reaches GitHub, the substantive decisions, what the agent built, which direction it took after someone redirected it, have already happened upstream of any protected branch.

Slack's own scenario illustrates this directly: a product manager spots a bug, asks a coding agent to draft a fix, brings in an engineer to check the diff, and the PM gives the agent the go-ahead to submit a PR. According to Salesforce, the flow runs with "no ticket, no meeting, no waiting." That is efficient. It is also a PM approving a code path before the engineer who owns that module has formally reviewed it. CODEOWNERS does not govern what happens in the channel.

The new audit artifact#

The archived code channel is genuinely useful. A searchable log of an agent's plan, its intermediate diffs, and the human interventions that redirected it is richer context than a PR description written after the fact. Compliance teams at regulated companies have asked for exactly this kind of decision trail.

The problem is that no compliance framework was written expecting it. SOC 2 readiness guides, FedRAMP controls, and most internal security policies describe what must be reviewed before code ships. They do not describe how to treat a Slack archive as an authoritative record of agent decision-making. That gap is not theoretical. It will surface the first time an auditor asks who approved a production change and the answer is "a thread in a code channel."

Approval fatigue, now cross-functional#

Code review fatigue is a documented problem in engineering. Non-engineers reviewing code diffs in Slack threads is a harder version of the same problem, with fewer tools to support it. Vercel's CTO Malte Ubl described the appeal directly: "A whole team can gather in one Code Channel, watch the agent work, steer it together, and ship a preview." That is collaborative. It is also a product manager or designer in the approval chain for a backend change they may not have the context to evaluate safely.

The multiplayer framing is correct. The governance model has not caught up to it.

Where automated review has to go#

Hyrax's six agent domains, covering security, code quality, reliability, API and data, ops, and UX, run against the full codebase regardless of how a change arrives. A PR submitted from a Slack Code channel is still a PR. The 13-step verification still runs. The fix either passes or it does not.

But the deeper question Slack Code raises is whether automated review should be able to engage earlier, at the plan stage, before an agent has already written and previewed a change that everyone in the channel has emotionally committed to shipping. A security problem caught in a diff that a PM has already approved is harder to pull back than one caught in a plan. The architecture of Slack Code, with its explicit Plan tab visible before any code is written, creates a natural intervention point. The tooling to use it does not yet exist at scale.

The governance gap is the product gap#

Slack Code is a real shift. Moving agent work into shared channels, making plans and diffs visible by default, keeping a searchable archive, these are improvements over the current norm of one developer and one private browser tab. The The Next Web noted that the archived channel "survives as an audit log." That framing is optimistic. An audit log is only useful if someone has defined what it needs to capture and who is authorized to interpret it.

The teams that treat Slack Code as a chat toy will get fast delivery and invisible governance debt. The teams that treat it as a governance event will ask which controls moved into the channel alongside the agent, and what fills the gap for the controls that did not.

Hyrax is live at hyrax.dev.