For most of modern software development, the act of writing code has remained largely private. An engineer works inside an IDE, commits a set of changes, and exposes the result to the rest of the team through a pull request. Collaboration happens around the code, usually after much of the implementation has already taken place.
AI coding agents are beginning to change that sequence.
Slack just introduced Slack Code, a new type of channel where teams can plan work, prompt supported agents, and review the results together. The release places software creation inside the same environment where requirements are discussed, product decisions are made, and feedback is exchanged.
The more consequential change is that implementation can now begin as a visible team activity rather than an exchange between one developer and one machine.
How Slack Code works in practice
Slack Code provides the shared workspace, while the connected AI provider supplies the agent and determines how its usage is billed. The practical setup therefore varies slightly between Claude, Cursor, Devin, and Vercel:
- A supported agent must be installed first. Slack currently supports Claude, Cursor, Devin, and Vercel. Code channels are available across all Slack plans, although some agents require a separate paid account.
- Mentioning the agent can create a temporary code channel automatically. The channel can be public or private, and members can add colleagues or another supported agent. Everyone inside it can provide instructions, share files, review changes, and approve the output.
- Usage is charged by the connected AI service rather than included as a Slack allowance. With Claude, work performed in a channel or thread draws from a centrally funded Claude organization usage balance. Anyone in the channel can assign work, with the resulting usage billed to the organization. Owners can set organization-wide and per-channel spending limits. Direct messages work differently: they use the sender’s own Claude account and its usual usage limits.
- Other agents follow their own account and billing models. Cursor, for example, requires an administrator to connect a repository provider, select a default repository, and enable usage-based pricing. When prompted in Slack, it starts a cloud agent inside an isolated virtual machine, reads the conversation context, works on the repository, and returns a GitHub pull request.
- The generated work remains reviewable inside Slack. Depending on the agent, the channel can display code diffs, live HTML previews, files, links, and other generated artifacts. Team members can comment on individual code lines or submit several comments as a consolidated review.
- Code channels are designed to be temporary. Teams can close or archive them when the task is finished. Archived conversations remain searchable, while inactive channels are removed from the dedicated sidebar section after seven days.
From shared output to shared process
Traditional engineering tools make the result of development visible. Tickets describe the intended work, commits record changes, and pull requests give colleagues something concrete to inspect, but they reveal relatively little about how the implementation was produced.
An engineer may have considered several approaches, ruled out two of them, discovered an undocumented dependency, and adjusted the solution accordingly. Much of that reasoning stays inside the developer’s head or disappears when an AI conversation is closed.
A shared agent channel like Slack Code can preserve a larger portion of that process. The initial request, follow-up instructions, agent output, corrections, and approvals can all remain available to the team. A colleague joining later can see why a particular direction was chosen instead of reconstructing the decision from the final diff.
That could improve one of the persistent problems in software teams: context tends to be distributed across meetings, private messages, tickets, documentation, and individual memory. Bringing the conversation and the implementation closer together creates a clearer record of how a feature evolved.
A conversation still needs an owner
When a developer writes a piece of code, ownership is usually easy to trace. Agent-generated code complicates that relationship.
Several people may contribute to the prompt with Slack Code, which raises questions that software teams will need to answer explicitly: who defines the technical boundaries of the task? Who checks whether the agent understood the wider architecture? Who is responsible when a change passes automated tests but introduces operational risk elsewhere? At what point does a conversational suggestion become an engineering decision?
The ease of participation could otherwise create an unusual failure mode: everyone contributes to the implementation, while nobody fully owns it.
Review becomes the limiting factor
Coding agents can produce changes much faster than teams can evaluate them. GitHub recently illustrated the problem through the example of an agent returning a pull request containing more than 1,000 changed lines. The agent completed the assignment quickly, but the resulting diff was difficult for a reviewer to understand and verify.
But a fast conversation can still generate a large, interconnected implementation that exceeds the team’s review capacity. Teams need to direct agents toward bounded tasks, explicit constraints, and small, independently reviewable changes. The structure of the request becomes part of the software delivery system.
Tests, linting, security scans, branch protection, required reviews, and CODEOWNERS create predictable boundaries around probabilistic agent behavior. GitHub’s own description of the developer as an orchestrator of agents depends heavily on this separation: agents handle ambiguous work, while established engineering controls determine what can enter production.
The IDE becomes one surface among several
The IDE is unlikely to lose its importance. Complex debugging, architectural exploration, performance analysis, and careful refactoring still benefit from an environment designed for deep technical work.
Its position within the development process is changing, however. An issue can already trigger an agent that works in the background and submits a pull request. A developer can manage several parallel agent sessions from a control center. Now, a team can begin creating software inside a shared workplace conversation. Implementation is spreading across repositories, issue trackers, agent interfaces, collaboration platforms, and automated pipelines.
The next challenge for engineering organizations will be maintaining continuity across those surfaces: requirements, agent instructions, technical decisions, code changes, test results, and approvals need to form one traceable chain. Software development has always been collaborative. Only up until now, the code itself usually emerged from an individual workspace before entering the team’s view. Agentic development brings the team into the production process earlier. That could make software creation more transparent and collective, and we’re here for it!
