Slack Code: Coding Agents sind gerade in den Team Channel eingezogen

Das Wichtigste an einem Coding Agent ist nicht mehr, wie gut er Code schreibt. Es ist, wer sehen kann, was er tut. Bis zu diesem Monat lautete die ehrliche Antwort für die meisten Teams: ein einzelner Developer, in einem privaten Terminal oder Browser Tab, in der Hoffnung, sich später daran zu erinnern, was der Agent tatsächlich gemacht hat. Slack Code, gestartet am 20. August, ist der bisher größte Versuch, diese Antwort standardmäßig in "jeder im Project" zu ändern.

Ich habe die Launch-Ankündigung, Slacks eigenen Follow-up-Post und die Coverage gelesen. Das Model darunter ist dasselbe Claude Code, Devin oder Copilot, das Sie bereits kennen. Was sich ändert, ist der Raum, in dem die Arbeit stattfindet, und das ist wichtiger, als ein Großteil der Berichterstattung vermuten lässt.

Wichtigste Erkenntnisse - Slack Code fügt "code channels" hinzu: gemeinsame Project Spaces, in denen ein getaggter Coding Agent, Claude Code, Devin, GitHub Copilot, Vercel, mit ChatGPT in Vorbereitung, offen arbeitet, mit Diffs, Live Previews und einem Human Approval Step, bevor etwas ausgeliefert wird. - Es läuft ab Day One auf jedem Slack Plan, auch wenn Access zu jedem Agent separat gekauft wird. Channels auto-archivieren sich nach Abschluss der Arbeit und behalten ein Audit Log. - Die eigentliche Verschiebung ist supervisory: Agent Work wandert aus einer privaten Session, die eine Person beobachtet, in ein Shared Artefact, das ein Team beobachtet. Das behebt Attribution- und Review-Gaps und schafft neue, Bystander Apathy, Approval Theatre, Channel Context als Attack Surface. - Es ist auch ein Distribution Move. Slack hat ein Jahr lang Agent Plumbing gebaut, MCP Server, Real-time Search, Slackbot MCP Client, und Code Channels sind die Surface, die es sichtbar macht. - Behandeln Sie "eine Person genehmigt die Arbeit, bevor sie shipped" als Design Goal, nicht als Garantie. Ihr Review Process muss weiterhin real sein.

Was passiert ist

Am 20. August launchte Slack Slack Code auf allen Plänen, einschließlich Free Workspaces. Die Mechanik, laut Launch Coverage und TechRepublics Bericht:

• Sie taggen einen Coding Agent in einer beliebigen Slack Conversation. Der Agent startet einen dedizierten Code Channel für die Task, ob Bug Fix, Page Update oder Feature Build.

• Jeder im Channel sieht dieselbe Conversation, von der aus der Agent arbeitet, reviewed Code Diffs, wenn sie vorgeschlagen werden, prüft Live HTML Previews, hinterlässt Feedback, das der Agent übernimmt, und genehmigt die fertige Arbeit. Nichts shipped ohne Human Sign-off.

• Wenn die Arbeit abgeschlossen ist, archiviert sich der Channel selbst und behält ein Audit Log.

• Launch Partner sind Anthropics Claude, Cognitions Devin, GitHub Copilot und Vercel, OpenAIs ChatGPT ist als kommende Integration angekündigt. Slack will die Code Channel APIs für die breitere Developer Community öffnen, damit jeder Custom Agent teilnehmen kann.

Wer in einem Channel landet, ist konfigurierbar. Katie Steigman, Slacks VP of Product, sagte Reworked: "You could have the agent just bring in the user who tagged the agent to make the code channel or you could configure the agent to make inferences on its own as to who should be in the channel based on the context it has." Rob Seaman, Slacks EVP und General Manager, formulierte die Absicht: "AI only creates value when it's part of how a team actually works."

Slack Code, am 20. August 2026 auf allen Slack Plans gestartet, bringt Partner Coding Agents, Claude, Devin, Copilot, Vercel, ChatGPT angekündigt, in gemeinsame "code channels", in denen das gesamte Team Conversation, Diffs und Live Previews des Agents sieht, die Arbeit vor dem Shipping genehmigt und ein Audit Log übernimmt, wenn der Channel auto-archiviert wird, laut Slack Announcement.

Supervision verlässt die private Session

Hier ist die Sache, die die Feature List verbirgt. Die meiste Agent Supervision ist heute eine Fiktion, die von einer müden Person aufrechterhalten wird. Der Agent läuft in jemandes IDE oder Cloud Sandbox, der Diff kommt als Pull Request, und der "Review" ist das, wofür dieser eine Developer um 17 Uhr noch Energie hatte. Das Reasoning, die Dead Ends, die drei Versuche vor dem einen, der funktionierte: alles verschwindet. Ich habe genug Agent Output reviewed, um zu wissen, dass der Diff der am wenigsten informative Teil des Prozesses ist.

Slacks eigentlicher Vorschlag ist, den Prozess selbst zum Artefact zu machen. Der Channel hält die Conversation, von der aus der Agent gearbeitet hat, Intermediate Steps, Feedback und Approvals, und archiviert danach alles als Searchable Record. Das ist ein wirklich anderes Supervision Model und näher daran, wie gute Teams Junior Engineers reviewen, als daran, wie sie heute Agents reviewen: die Arbeit beobachten, nicht nur den Output.

Es verändert auch, wer supervises. Der Pitch ist ausdrücklich, dass PMs, Designers und Non-technical Teammates folgen können. Ich bin vorsichtig dafür, mit einem Vorbehalt, auf den ich zurückkomme: Ein Raum voller Beobachter ist nicht dasselbe wie ein Reviewer. Diff Literacy entsteht nicht durch Osmose, und "das Team kann es sehen" kann leise zu "niemand hat es geprüft" werden. Die Governance Questions, die daraus entstehen, wer accountable ist, wenn zehn Menschen zugesehen haben und niemand das Approval owned, sind genau die, die ich im Agent Governance Framework durcharbeite, und Slack Code beantwortet sie nicht für Sie. Es macht sie sichtbar, was der ehrliche erste Schritt ist.

Slack Code verschiebt Agent Supervision von einer privaten Session in einen gemeinsamen, archivierten Channel Record: Conversation, Intermediate Steps, Feedback und Approvals bleiben als Searchable Artefact erhalten, laut Slacks Product Post. Die Accountability-Frage, wer das Approval in einem Raum voller Beobachter owns, bleibt beim Customer.

Shared Context schneidet in beide Richtungen

Der zweite große Claim betrifft Context. Slacks Argument lautet, dass der Context für eine Task bereits in Channels lebt, Bug Report, Spec Discussion, Customer Complaint, also sollte der Agent dort arbeiten, wo der Context ist, statt ihn in einen privaten Prompt copy-pasten zu lassen. Das ist richtig und baut auf Plumbing auf, das Slack das ganze Jahr shipped hat: MCP Server und Real-time Search API wurden im Februar Generally Available und geben Agents governed Access auf Workspace Messages und Files, der Slackbot MCP Client folgte im Juni. Ich habe im MCP-Servers-Roundup beschrieben, warum MCP Access auf Team Tools die nützliche Hälfte von Agent Context ist; das Channel Model führt diese Idee zu Ende.

Aber Shared Context ist auch Shared Exposure. Ein Agent, der einen Channel liest, liest alles darin, einschließlich der Message, in der jemand "nur kurz" ein Credential gepastet hat, und External Content, das von einem Customer weitergeleitet wurde. Jeder Security Researcher, den ich kenne, sagt dasselbe: Content, den ein Agent lesen kann, kann ihn instruieren. Ein Shared Channel ist eine größere Prompt-Injection-Surface als eine private Session, Punkt. Bevor Sie einen Agenten mit Write Access auf einen busy Channel richten, sollten Sie bewusst entscheiden, welche Channels er liest und welche Tools er berühren darf. Das ist Architecture Work, nicht Settings Work, und derselbe Trade-off, den ich in Agentic Architecture beschreibe: Capability und Blast Radius wachsen zusammen.

Slack Codes Context Advantage, der Agent arbeitet dort, wo der Task Context bereits lebt, beruht auf MCP-basiertem Workspace Access, den Slack im Februar 2026 Generally Available gemacht hat, laut Unite.AI. Derselbe Shared Context vergrößert Prompt-Injection- und Credential-Exposure-Surface, ein Trade-off, den die Launch Materials nicht adressieren.

Attribution und Review, die unglamourösen Gewinne

Die am wenigsten flashy Teile dieses Launches sind die, die ich tatsächlich kaufen würde. Zuerst Attribution: In einem Code Channel sitzt jede Agent Action unter der Identity des Agents, in einem Workspace, der bereits weiß, wer alle sind, mit einem Audit Log, das das Project überlebt. Das klingt basic. Ist es auch. Es ist außerdem mehr Attribution Infrastructure, als die meisten Teams heute für Agent Work besitzen, wo "der Agent hat es gemacht" und "ich habe es gemacht" in derselben Git History verschwimmen. Regulated Industries fragen seit einem Jahr genau nach diesem langweiligen Ding.

Zweitens Review. Diffs und Live Previews im Channel, Feedback, das der Agent übernimmt, und ein harter Approval Gate vor Shipping. Beachten Sie aber, was fehlt: Slacks Materials beschreiben, dass eine Person die Arbeit genehmigt, aber nichts, was ich gesehen habe, spezifiziert, wer diese Person sein muss, was ihr gezeigt wird oder was passiert, wenn der konfigurierte Reviewer im Urlaub ist. Approval als Checkbox erzeugt Approval Theatre: ein grüner Button, den alle zu klicken lernen. Die Teams, die hier Value bekommen, sind diejenigen, die das Approval an einen echten Code Owner mit echtem Diff Review verdrahten und Channel Output des Agents als Evidence behalten, nicht als Review selbst.

Auch der Competitive Context zählt. Microsoft brachte im September 2025 einen Copilot Coding Agent in Teams Threads, und Block shipte im Juli sein Open-Source Buzz, wie Reworked berichtet. Das Chat Window wird zur umkämpften Surface für Agent Work, und Slacks Advantage ist unglamourös: Dort ist das Team bereits. Distribution schlägt Cleverness in Collaboration Software, jedes Mal.

Slack Code gibt jedem Agent eine eigene Identity in Channels und behält pro archiviertem Project ein Audit Log, laut TechRepublic, aber der Approval Gate, "a person approves the work before it ships", spezifiziert weder Reviewer Identity noch Review Standards. Microsofts Teams Copilot Agent, September 2025, und Blocks Open-Source Buzz, Juli 2026, sind die direkten Vergleichspunkte, laut Reworked.

Was Sie jetzt tun sollten

Wenn Ihr Team Slack nutzt und Coding Agents verwendet, drei Schritte.

1. Diese Woche: Wählen Sie eine Low-stakes, klar spezifizierte Task, einen Copy Change oder kleinen Bug mit klarer Reproduction, und führen Sie sie in einem Code Channel mit zwei oder drei Beobachtern aus. Sie testen nicht den Agenten; Sie testen das Review Behaviour Ihres Teams. Beobachten Sie, ob tatsächlich jemand den Diff liest.

2. Bevor etwas Reales shipped: Entscheiden Sie schriftlich, wer für Agent Work in jedem Repo Approver ist und was diese Person prüfen muss. Wenn Ihre Antwort "wer auch immer im Channel ist" lautet, haben Sie keinen Review Process, sondern einen Button.

3. Vor breitem Rollout: Begrenzen Sie, welche Channels der Agent lesen darf und welche Credentials seine Environment hält. Channel History ist Context, und Context ist eine Attack Surface. Starten Sie eng und erweitern Sie auf Evidence.

FAQ

Was ist Slack Code?

Eine Slack Feature, gestartet am 20. August 2026, mit der Teams Partner Coding Agents, Claude Code, Devin, GitHub Copilot, Vercel, ChatGPT angekündigt, in einer Conversation taggen können. Der Agent öffnet einen dedizierten "code channel" für die Task, in dem das Team die Arbeit beobachtet, Diffs und Previews reviewed und das Ergebnis vor dem Shipping genehmigt. Der Channel archiviert sich automatisch nach Abschluss.

Brauche ich einen bezahlten Slack Plan?

Nein. Slack Code ist auf jedem Plan verfügbar, einschließlich Free Workspaces. Aber Access zu jedem Coding Agent wird separat beim jeweiligen Vendor gekauft, die praktischen Kosten hängen also davon ab, welche Agents Sie bereits bezahlen.

Ersetzt Slack Code Code Review?

Nein, und es so zu behandeln, ist das Hauptrisiko. Es verlagert Review in einen gemeinsamen, archivierten Channel und fügt einen Approval Gate hinzu, aber die Qualität des Reviews hängt weiterhin von einem benannten Human ab, der den Diff liest. Ein sichtbarer Process ohne Owner ist schlechter als ein privater mit gewissenhaftem Reviewer, weil er supervised aussieht.

Ist es sicher, einen Agenten einen ganzen Channel lesen zu lassen?

Es hängt davon ab, was im Channel steht. Alles, was der Agent lesen kann, kann ihn beeinflussen, einschließlich gepasteter Credentials und weitergeleitetem External Content. Begrenzen Sie Read Access eng, halten Sie Agent Credentials least-privilege und behandeln Sie Channel Content als Untrusted Input, denn aus Sicht des Agents ist er das.

Fazit

Slack Code wird Agents nicht besseren Code schreiben lassen. Dafür ist es nicht da. Es macht Agent Work standardmäßig sichtbar, attributable und reviewable, an dem Ort, an dem das Team bereits lebt, und das sind genau die drei Dinge, die den meisten Agent Deployments still fehlen. Der Haken ist, dass Visibility nicht Supervision bedeutet. Der Channel gibt Ihnen Record und Gate; ob jemand tatsächlich zusieht, bleibt Ihr Problem. Beobachten Sie, wie Teams den Approver konfigurieren, nicht den Agenten. Dort entscheidet sich, ob das funktioniert oder Theatre wird.

Wenn Sie herausarbeiten, wie Agents in Team Workflows kommen, ohne die Kontrolle über Review zu verlieren, ist das ein Gespräch, das ich regelmäßig mit Clients führe. Kontakt aufnehmen.

Quellen

• Salesforce, "Introducing Slack Code: Agentic Coding for Teams": https://www.salesforce.com/introducing-slack-code/ (veröffentlicht 2026-08-19, abgerufen 2026-08-29)

• Slack, "Slack Code: Where Your Team and Agents Build Together": https://slack.com/blog/news/slack-code-channels-for-agents (veröffentlicht 2026-08-28, abgerufen 2026-08-29)

• Unite.AI, "Slack Code Puts AI Coding Agents in Dedicated Project Channels": https://www.unite.ai/slack-code-puts-ai-coding-agents-in-dedicated-project-channels/ (veröffentlicht 2026-08-20, abgerufen 2026-08-29)

• TechRepublic, "Slack Code: AI Coding Agents Get Shared Channels for Review and Oversight": https://www.techrepublic.com/article/news-slack-code-ai-coding-agents/ (veröffentlicht 2026-08-21, abgerufen 2026-08-29)

• Reworked, "Slack Code Puts AI Coding Agents in Shared Channels": https://www.reworked.co/collaboration-productivity/slack-code-brings-collaborative-ai-coding-into-channels/ (veröffentlicht 2026-08-20, abgerufen 2026-08-29)