Veröffentlicht am
Slack hat seine Code API am 28. Oktober 2026 als allgemein verfügbar angekündigt. Entwickler sollen damit eigene Coding-Agenten in gemeinsame Arbeitskanäle einbinden können. Dort kann ein Team den Fortschritt verfolgen, zusätzlichen Kontext liefern und Änderungen prüfen. Die API ist laut Slack in allen Tarifen verfügbar. Das ist eine Schnittstellenfreigabe; die Ankündigung belegt keine kostenlose oder unbegrenzte Nutzung angeschlossener Agenten. Slack: Vorstellung der Code API.
Ein eigener Kanal für eine Aufgabe
Die beschriebenen Code Channels bündeln eine Aufgabe mit beteiligten Personen, Dateien und Arbeitsstand. Ein Agent kann einen solchen Kanal eröffnen, Fortschrittsmeldungen sowie Artefakte ergänzen und ihn nach Abschluss archivieren. Codeänderungen und HTML-Vorschauen sollen sich innerhalb der Oberfläche darstellen lassen. Die Arbeit soll den Berechtigungen und Administrationsregeln des jeweiligen Kanals folgen.
Damit wird die Zusammenarbeit sichtbar, die sonst auf eine einzelne Unterhaltung begrenzt bleiben könnte. Ob ein Team eine bestimmte Aktion tatsächlich freigeben muss, sollte es dennoch anhand seiner konkreten Integration prüfen. Funktionsbeschreibung und Berechtigungen.
Weitere Funktionen sind noch angekündigt
Die Veröffentlichung bezeichnet Verbesserungen der Pull-Request-Erfahrung und einen erweiterten Bereich „Agents & Tools“ ausdrücklich als demnächst verfügbar. Dazu gehört die beschriebene engere Abstimmung mit GitHub-Reviews. Diese Funktionen sollten deshalb nicht mit der bereits freigegebenen API gleichgesetzt werden.
KI-AGT hat die Schnittstelle nicht selbst getestet. Der im Blog verlinkte Dokumentationszugang ließ sich bei der Recherche nicht abrufen. Technische Integrationsdetails und konkrete Betriebsgrenzen konnten wir darüber nicht zusätzlich prüfen. Verfügbarkeitsangaben im Originalbeitrag.
Unsere Einordnung: Zusammenarbeit braucht einen klaren Auftrag
Interessant ist der Ansatz für Entwicklungsteams, in denen mehrere Personen eine Aufgabe begleiten. Für einen Pilotversuch würden wir einen kleinen, überprüfbaren Fehlerbehebungsauftrag wählen. Vor dem Start sollten Ziel, betroffene Dateien und zulässige Werkzeuge feststehen. Im gemeinsamen Kanal müsste jederzeit erkennbar sein, wer die Aufgabe verantwortet und welche Entscheidung noch aussteht.
Ein sinnvoller Prüffall wäre eine Korrektur mitten im Ablauf: Eine Kollegin weist auf eine falsche Annahme hin. Danach sollte nachvollziehbar sein, ob der Agent seinen Plan anpasst und welche bereits ausgeführten Schritte überprüft werden müssen. Ein sichtbarer Chatverlauf allein wäre für unsere Abnahme kein Nachweis, dass diese Rückmeldung wirksam wurde.
Vor der Verbindung mit einem Repository würden wir außerdem festlegen, welche Informationen im Kanal landen dürfen. Insbesondere Protokolle und Vorschauen sollten anhand der tatsächlichen Kanalmitgliedschaft geprüft werden. Eine praktische Frage wäre, ob die zur Prüfung benötigten Personen Zugriff haben, ohne unnötig weitere Projektinformationen freizugeben.
Schließlich würden wir den Abschluss getrennt vom Fortschrittsbericht bewerten: Gibt es eine nachvollziehbare Änderung, passende Testergebnisse und eine zuständige Person für die Übernahme? Diese Kriterien sind redaktionelle Einordnung und keine bestätigten Produktergebnisse. Grundlagen erläutern unsere Beiträge zu Berechtigungen und Human-in-the-Loop.
Quelle: Offizielle Quelle