Der entscheidende Unterschied ist nicht allein, dass ein Agent Slack-Nachrichten empfangen kann. Die eigentliche Entwicklungsarbeit wird für das gesamte Team sichtbar – genau dort, wo Anforderungen, Entscheidungen und Projektwissen bereits liegen. Slack bezeichnet diesen Ansatz als „Multiplayer“- beziehungsweise teamorientiertes Programmieren: Menschen und Agenten arbeiten im selben Kanal, während das Team den Prozess verfolgen kann.

So läuft ein Code-Kanal ab

Ein typischer Ablauf könnte so aussehen:

1. Ein Teammitglied schildert in Slack eine Idee, einen Fehler oder einen Änderungswunsch und erwähnt einen unterstützten Coding-Agenten.
2. Der Agent eröffnet einen eigenen Code-Kanal für die Aufgabe.
3. Die Beteiligten ergänzen Anforderungen, technische Vorgaben und den nötigen Projektkontext.
4. Der Agent erstellt einen Plan und schlägt Änderungen vor.
5. Das Team prüft den Fortschritt, Code-Diffs und – sofern die Integration dies unterstützt – eine Live-Vorschau.
6. Menschen können den Agenten korrigieren, weitere Änderungen verlangen oder den nächsten Schritt freigeben.

Damit soll der Code-Kanal mehr bieten als ein gewöhnliches Chat-Protokoll. Je nach Anbindung können die Beteiligten zwischen Unterhaltung, Plan, Code-Diffs und einer Live-Vorschau des Ergebnisses wechseln. So entsteht eine gemeinsame Sicht sowohl auf die Diskussion rund um eine Aufgabe als auch auf die daraus hervorgegangene Software.

Warum Produktmanager und Designer einbezogen werden

Slack Code richtet sich nicht nur an Entwickler. Produktmanager und Designer können ein Nutzerproblem erklären, Anforderungen ergänzen, das sichtbare Ergebnis prüfen und im selben Kanal Änderungen anstoßen, ohne dafür direkt in einem Entwickler-Terminal arbeiten zu müssen. Entwickler behalten dabei die technische Bewertung und die Details der Umsetzung.

Ein mögliches Beispiel: Ein Produktmanager meldet in Slack einen Fehler und beschreibt, wie sich die Anwendung eigentlich verhalten sollte. Ein Agent untersucht die Anfrage und schlägt eine Korrektur vor. Anschließend prüft ein Entwickler den erzeugten Diff und bewertet, ob die Änderung sicher in die bestehende Codebasis passt. Danach kann das Team entscheiden, ob ein Pull Request erstellt oder eine weitere Überarbeitungsrunde nötig wird.

Der Agent wird dadurch nicht zum abschließenden Entscheider. Vielmehr verschiebt sich der Ort der Zusammenarbeit: Seine Arbeit lässt sich von mehr Beteiligten einsehen, hinterfragen und gemeinsam weiterentwickeln.

Menschliche Freigaben bleiben wichtig

Slack Code ist als Transparenz- und Zusammenarbeitsschicht gedacht – nicht als Freibrief für ungeprüfte automatische Deployments. Teams können für wichtige Aktionen eine menschliche Freigabe verlangen, insbesondere für Änderungen, die letztlich die Produktionsumgebung erreichen könnten.

Das ist entscheidend, weil ein Agent zwar eine plausibel wirkende Lösung erzeugen kann, aber möglicherweise nicht alle fachlichen Anforderungen, Sicherheitsvorgaben oder betrieblichen Risiken eines Systems versteht. Im gemeinsamen Kanal können Entwickler und andere verantwortliche Teammitglieder den Ansatz hinterfragen, Überarbeitungen anfordern und die Entscheidung dokumentieren, bevor die Arbeit weiterläuft.

Suchbare Historie und bestehende Slack-Kontrollen

Code-Kanäle sollen den Kontext rund um die Arbeit eines Agenten bewahren. Nach Abschluss einer Aufgabe kann der Kanal archiviert werden, während Unterhaltung und Arbeitsverlauf suchbar bleiben. So entsteht eine nachvollziehbare Dokumentation: Was wurde angefordert, was hat der Agent erstellt und wie wurde das Ergebnis von Menschen geprüft?

Da der Prozess innerhalb von Slack stattfindet, können Unternehmen ihre vorhandenen Slack-Identitäten, Berechtigungen, Governance-Regeln, Sicherheitseinstellungen und Administrationskontrollen nutzen. Eine separate Kollaborationsumgebung für jede einzelne Coding-Agent-Aufgabe ist damit nicht erforderlich.

Der praktische Vorteil liegt in der Kontinuität: Anforderungen, Entscheidungen, Reviews und Agentenaktivitäten bleiben mit den Gesprächen verbunden, in denen die Arbeit ursprünglich begonnen hat.

Verfügbarkeit und Integrationen zum Start

Salesforce zufolge war Slack Code zum Start in allen Slack-Tarifen verfügbar. Als ursprüngliche Integrationspartner wurden Anthropic, GitHub, Cognition und Vercel genannt. Auch ChatGPT wurde als Agent aufgeführt, der sich an den Arbeitsabläufen beteiligen kann.

Die konkrete Nutzererfahrung kann sich je nach Integration unterscheiden. Funktionen wie Pläne, Diffs, Vorschauen und Freigabeaktionen hängen davon ab, welche Möglichkeiten der jeweilige Agent innerhalb von Slack bereitstellt. „Unterstützt“ bedeutet daher nicht automatisch, dass jeder Agent identische Bedienelemente anbietet.

Salesforce’ größere Slack-Strategie

Salesforce stellte Slack Code auf der Dreamforce als Versuch dar, Softwareentwicklung zu einer Mannschaftsaufgabe zu machen und Slack zugleich als Koordinationsschicht für mehrere Anbieter von KI-Agenten zu etablieren. Teams sollen also Coding-Agenten konkurrierender Anbieter über eine gemeinsame Arbeitsoberfläche einsetzen können, statt sich auf ein einziges proprietäres Salesforce-Modell festlegen zu müssen.

Darüber hinaus hat Salesforce angekündigt, die zugrunde liegenden Schnittstellen breiter zu öffnen. Langfristig könnten Unternehmen eigene Agenten und gemeinsame Kanäle auch für Aufgaben außerhalb der Softwareentwicklung erstellen – etwa zur Koordination von Marketingkampagnen oder zur Prüfung juristischer Dokumente. Diese Beispiele beschreiben eine geplante Erweiterung und bedeuten nicht, dass sämtliche nichttechnischen Workflows bereits zum Start allgemein verfügbar sind.

Fazit

Die Grundidee von Slack Code ist schnell erklärt: Einen Coding-Agenten erwähnen, ihm einen eigenen Projektkanal geben und das gesamte Team beobachten, anleiten, prüfen und freigeben lassen. Die Besonderheit liegt somit weniger in der reinen Codegenerierung als im gemeinsam sichtbaren Kontext rund um den Code.

Für Teams, die ohnehin in Slack arbeiten, könnte das KI-gestützte Entwickeln dadurch für Produkt- und Designteams leichter nachvollziehbar werden, ohne die technische Prüfung durch Entwickler aufzugeben. Wie gut der Ansatz funktioniert, hängt allerdings weiterhin von der Qualität der jeweiligen Agenten-Integration und von klaren Freigaberegeln im Unternehmen ab.

Der entscheidende Unterschied ist nicht allein, dass ein Agent Slack-Nachrichten empfangen kann. Die eigentliche Entwicklungsarbeit wird für das gesamte Team sichtbar – genau dort, wo Anforderungen, Entscheidungen und Projektwissen bereits liegen. Slack bezeichnet diesen Ansatz als „Multiplayer“- beziehungsweise teamorientiertes Programmieren: Menschen und Agenten arbeiten im selben Kanal, während das Team den Prozess verfolgen kann.

So läuft ein Code-Kanal ab

Ein typischer Ablauf könnte so aussehen:

1. Ein Teammitglied schildert in Slack eine Idee, einen Fehler oder einen Änderungswunsch und erwähnt einen unterstützten Coding-Agenten.
2. Der Agent eröffnet einen eigenen Code-Kanal für die Aufgabe.
3. Die Beteiligten ergänzen Anforderungen, technische Vorgaben und den nötigen Projektkontext.
4. Der Agent erstellt einen Plan und schlägt Änderungen vor.
5. Das Team prüft den Fortschritt, Code-Diffs und – sofern die Integration dies unterstützt – eine Live-Vorschau.
6. Menschen können den Agenten korrigieren, weitere Änderungen verlangen oder den nächsten Schritt freigeben.

Damit soll der Code-Kanal mehr bieten als ein gewöhnliches Chat-Protokoll. Je nach Anbindung können die Beteiligten zwischen Unterhaltung, Plan, Code-Diffs und einer Live-Vorschau des Ergebnisses wechseln. So entsteht eine gemeinsame Sicht sowohl auf die Diskussion rund um eine Aufgabe als auch auf die daraus hervorgegangene Software.

Warum Produktmanager und Designer einbezogen werden

Slack Code richtet sich nicht nur an Entwickler. Produktmanager und Designer können ein Nutzerproblem erklären, Anforderungen ergänzen, das sichtbare Ergebnis prüfen und im selben Kanal Änderungen anstoßen, ohne dafür direkt in einem Entwickler-Terminal arbeiten zu müssen. Entwickler behalten dabei die technische Bewertung und die Details der Umsetzung.

Ein mögliches Beispiel: Ein Produktmanager meldet in Slack einen Fehler und beschreibt, wie sich die Anwendung eigentlich verhalten sollte. Ein Agent untersucht die Anfrage und schlägt eine Korrektur vor. Anschließend prüft ein Entwickler den erzeugten Diff und bewertet, ob die Änderung sicher in die bestehende Codebasis passt. Danach kann das Team entscheiden, ob ein Pull Request erstellt oder eine weitere Überarbeitungsrunde nötig wird.

Der Agent wird dadurch nicht zum abschließenden Entscheider. Vielmehr verschiebt sich der Ort der Zusammenarbeit: Seine Arbeit lässt sich von mehr Beteiligten einsehen, hinterfragen und gemeinsam weiterentwickeln.

Menschliche Freigaben bleiben wichtig

Slack Code ist als Transparenz- und Zusammenarbeitsschicht gedacht – nicht als Freibrief für ungeprüfte automatische Deployments. Teams können für wichtige Aktionen eine menschliche Freigabe verlangen, insbesondere für Änderungen, die letztlich die Produktionsumgebung erreichen könnten.

Das ist entscheidend, weil ein Agent zwar eine plausibel wirkende Lösung erzeugen kann, aber möglicherweise nicht alle fachlichen Anforderungen, Sicherheitsvorgaben oder betrieblichen Risiken eines Systems versteht. Im gemeinsamen Kanal können Entwickler und andere verantwortliche Teammitglieder den Ansatz hinterfragen, Überarbeitungen anfordern und die Entscheidung dokumentieren, bevor die Arbeit weiterläuft.

Suchbare Historie und bestehende Slack-Kontrollen

Code-Kanäle sollen den Kontext rund um die Arbeit eines Agenten bewahren. Nach Abschluss einer Aufgabe kann der Kanal archiviert werden, während Unterhaltung und Arbeitsverlauf suchbar bleiben. So entsteht eine nachvollziehbare Dokumentation: Was wurde angefordert, was hat der Agent erstellt und wie wurde das Ergebnis von Menschen geprüft?

Da der Prozess innerhalb von Slack stattfindet, können Unternehmen ihre vorhandenen Slack-Identitäten, Berechtigungen, Governance-Regeln, Sicherheitseinstellungen und Administrationskontrollen nutzen. Eine separate Kollaborationsumgebung für jede einzelne Coding-Agent-Aufgabe ist damit nicht erforderlich.

Der praktische Vorteil liegt in der Kontinuität: Anforderungen, Entscheidungen, Reviews und Agentenaktivitäten bleiben mit den Gesprächen verbunden, in denen die Arbeit ursprünglich begonnen hat.

Verfügbarkeit und Integrationen zum Start

Salesforce zufolge war Slack Code zum Start in allen Slack-Tarifen verfügbar. Als ursprüngliche Integrationspartner wurden Anthropic, GitHub, Cognition und Vercel genannt. Auch ChatGPT wurde als Agent aufgeführt, der sich an den Arbeitsabläufen beteiligen kann.

Die konkrete Nutzererfahrung kann sich je nach Integration unterscheiden. Funktionen wie Pläne, Diffs, Vorschauen und Freigabeaktionen hängen davon ab, welche Möglichkeiten der jeweilige Agent innerhalb von Slack bereitstellt. „Unterstützt“ bedeutet daher nicht automatisch, dass jeder Agent identische Bedienelemente anbietet.

Salesforce’ größere Slack-Strategie

Salesforce stellte Slack Code auf der Dreamforce als Versuch dar, Softwareentwicklung zu einer Mannschaftsaufgabe zu machen und Slack zugleich als Koordinationsschicht für mehrere Anbieter von KI-Agenten zu etablieren. Teams sollen also Coding-Agenten konkurrierender Anbieter über eine gemeinsame Arbeitsoberfläche einsetzen können, statt sich auf ein einziges proprietäres Salesforce-Modell festlegen zu müssen.

Darüber hinaus hat Salesforce angekündigt, die zugrunde liegenden Schnittstellen breiter zu öffnen. Langfristig könnten Unternehmen eigene Agenten und gemeinsame Kanäle auch für Aufgaben außerhalb der Softwareentwicklung erstellen – etwa zur Koordination von Marketingkampagnen oder zur Prüfung juristischer Dokumente. Diese Beispiele beschreiben eine geplante Erweiterung und bedeuten nicht, dass sämtliche nichttechnischen Workflows bereits zum Start allgemein verfügbar sind.

Fazit

Die Grundidee von Slack Code ist schnell erklärt: Einen Coding-Agenten erwähnen, ihm einen eigenen Projektkanal geben und das gesamte Team beobachten, anleiten, prüfen und freigeben lassen. Die Besonderheit liegt somit weniger in der reinen Codegenerierung als im gemeinsam sichtbaren Kontext rund um den Code.

Für Teams, die ohnehin in Slack arbeiten, könnte das KI-gestützte Entwickeln dadurch für Produkt- und Designteams leichter nachvollziehbar werden, ohne die technische Prüfung durch Entwickler aufzugeben. Wie gut der Ansatz funktioniert, hängt allerdings weiterhin von der Qualität der jeweiligen Agenten-Integration und von klaren Freigaberegeln im Unternehmen ab.