By Grego
Slack just touched a sensitive part of development workflow: the exact moment when an agent’s work becomes visible to the team.
With Slack Code, the company proposes dedicated channels where you can invoke agents like Claude Code, Devin, Vercel Agent, or GitHub Copilot, follow what they’re doing, review diffs, look at previews, leave feedback, and approve before shipping.
When the task ends, the channel is archived.
And it remains as an audit log.
That looks like just another integration between Slack and AI tools.
It’s not.
The important signal is different: the agent review loop is moving out of the PR.
The PR arrives late to an increasingly important part of the work
The pull request is still excellent for reviewing a finished change.
It shows you the diff.
It runs the checks.
It fires code owners.
It preserves comments.
It allows you to approve or block the merge.
But work with agents doesn’t start there.
It starts earlier, when someone defines an intent:
fix this bug
change this screen
prepare an initial version
review this behavior
Then the agent interprets, plans, executes, asks for clarifications, receives corrections, and adjusts.
Many of the important decisions happen before a final PR even exists.
And if the team only looks at the diff, they arrive late.
Slack Code moves review toward the process
What’s interesting about Slack Code isn’t just that you can mention an agent from Slack.
What’s interesting is that it converts an agentic task into a shared space.
There lives:
- the original request;
- the agent’s plan;
- the questions;
- the human corrections;
- the changes;
- the previews;
- the comments;
- the approval;
- and the final record of what happened.
That format fits better with agents than an isolated PR.
Because the value isn’t just in knowing what changed.
It’s also in knowing how it was decided to change it.
Review intent, not just code
An agent can produce a technically correct diff and still misunderstand the task.
It can pass the tests but touch a part of the system that nobody wanted to modify.
It can solve the bug but ignore a product constraint that was in the initial conversation.
That’s why review is moving up in the workflow.
It’s no longer just about asking:
Is this code good?
You also have to ask:
Was this the right task?
Did the agent understand the boundary?
Did the team approve the approach?
What feedback did it receive before the final result?
That context is rarely complete on GitHub.
Instead, it lives naturally in the conversation.
Slack has an obvious advantage
Slack is already where many teams decide what’s worth doing.
That’s where the informal bug report shows up.
That’s where product asks if something is urgent.
That’s where support pastes a screenshot.
That’s where design gives context.
That’s where engineering negotiates scope.
If the agent works from that place, context doesn’t have to be manually copied to another system.
It’s already there.
Slack doesn’t need to become GitHub for this to matter.
It’s enough to capture the moment before the PR: the moment where work is defined, corrected, and approved.
In agent workflows, that moment became much more valuable.
The audit log becomes part of the product
The detail of archiving the channel when done is not minor.
For a company, knowing what changed isn’t enough.
It also matters to know:
- who requested the change;
- which agent executed it;
- what instructions it received;
- what options it discarded;
- who corrected the course;
- who approved;
- what preview was reviewed;
- and what finally made it to deploy.
In traditional development, many of those conversations were scattered across Slack, Jira, GitHub, Linear, and meetings.
With agents, that dispersion becomes more dangerous.
Because the agent can execute much faster than the team can reconstruct the story afterward.
Auditability stops being a compliance detail.
It becomes the condition for giving the system more autonomy.
The market is looking for where the agent lives
Slack Code doesn’t appear in a vacuum.
Cursor is moving agents toward repos, PRs, cloud tasks, and persistent execution.
Codex separates the harness from the surfaces where it’s used.
Cloudflare OS explores workspaces with granular permissions for agents.
GitHub is trying to get Copilot to live increasingly close to the complete development cycle.
They’re all circling the same question:
Where should an agent’s work live?
It could be the IDE.
It could be the repo.
It could be the browser.
It could be Slack.
It could be a new platform.
But the direction is clear: the agent needs a place where the team can see it working, correct it, approve it, and reconstruct afterward what happened.
The PR alone isn’t enough for that.
The PR doesn’t disappear
The pull request is still necessary.
It’s the natural place to validate the change against the repository:
- diff;
- tests;
- checks;
- code ownership;
- branch protection;
- merge.
But it can stop being the main place where work is understood.
In an agentic workflow, the PR starts to look more like the final receipt.
Important.
Necessary.
Auditable.
But incomplete.
The full story lives before: in the intent, the plan, the iterations, the feedback, and the human approvals that got the agent to that diff.
Slack Code points exactly to that space.
That’s why it matters.
Not because Slack invented the coding agent.
But because it understood that the problem is no longer just generating code.
It’s coordinating humans and agents around a shared task without losing visibility.
The next big battle of dev tools might not be who writes better code.
It might be who preserves better the history of how that code came to exist.