Vai al contenuto
Analisi
Above

Slack Code: i coding agent sono appena entrati nel canale del team

Slack Code porta coding agent come Claude Code e Devin in project channel condivisi dove chiunque può osservare, revieware e approvare il loro lavoro. Il cambiamento interessante non è la qualità del codice, ma supervision, shared context, attribution e review.

Di Adam Maguire Wilson10 min di lettura
In questa pagina

La cosa più importante di un coding agent non è più quanto bene scriva codice. È chi può vedere cosa sta facendo. Fino a questo mese, la risposta onesta per la maggior parte dei team era: un developer, in un terminal privato o browser tab, sperando di ricordare dopo cosa avesse davvero fatto l'agent. Slack Code, lanciato il 20 agosto, è il tentativo più grande finora di cambiare la risposta in "tutti sul progetto, by default."

Ho letto l'annuncio di lancio, il follow-up post di Slack e la coverage. Il model sotto è lo stesso Claude Code, Devin o Copilot che conoscete già. Ciò che cambia è la stanza in cui avviene il lavoro, e si scopre che conta più di quanto suggerisca gran parte della coverage.

Punti chiave - Slack Code aggiunge "code channels": spazi di progetto condivisi dove un coding agent taggato, Claude Code, Devin, GitHub Copilot, Vercel, con ChatGPT in arrivo, lavora apertamente, con diff, live preview e human approval prima dello shipping. - Funziona su ogni Slack plan dal day one, anche se l'access a ciascun agent si compra separatamente. I channel si auto-archiviano al completamento e mantengono un audit log. - Il vero shift è supervisory: agent work passa da una private session osservata da una persona a uno shared artefact osservato da un team. Risolve gap di attribution e review, e ne crea di nuovi, bystander apathy, approval theatre, channel context come attack surface. - È anche un distribution move. Slack ha passato un anno a costruire agent plumbing, MCP server, real-time search, Slackbot MCP client, e i code channel sono la surface che lo rende visibile. - Trattate "una persona approva il lavoro prima che venga spedito" come design goal, non garanzia. Il vostro review process deve ancora essere reale.

Cosa è successo

Il 20 agosto Slack ha lanciato Slack Code su tutti i propri piani, free workspace inclusi. La meccanica, secondo la launch coverage e TechRepublic:

  • Taggate un coding agent in una qualsiasi conversazione Slack. L'agent avvia un code channel dedicato alla task, che sia correggere un bug, aggiornare una pagina o costruire una feature.

  • Tutti nel channel vedono la stessa conversazione da cui l'agent lavora, reviewano i code diff mentre vengono proposti, controllano live HTML preview, lasciano feedback che l'agent incorpora e approvano il lavoro finito. Niente ship senza human sign-off.

  • Quando il lavoro è completo, il channel si archivia automaticamente e conserva un audit log.

  • I launch partner sono Claude di Anthropic, Devin di Cognition, GitHub Copilot e Vercel, con ChatGPT di OpenAI annunciato come prossimo. Slack vuole aprire le code channel API alla developer community più ampia, in modo che qualsiasi custom agent possa partecipare.

Chi entra in un channel è configurabile. Katie Steigman, VP of Product di Slack, ha detto a 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, EVP e general manager di Slack, ha riassunto l'intento: "AI only creates value when it's part of how a team actually works."

Slack Code, lanciato il 20 agosto 2026 su tutti i piani Slack, mette partner coding agent, Claude, Devin, Copilot, Vercel, con ChatGPT annunciato, in "code channels" condivisi dove tutto il team vede conversation, diff e live preview dell'agent, approva il lavoro prima dello shipping e eredita un audit log quando il channel si auto-archivia, secondo l'annuncio Slack.

La supervision esce dalla session privata

Ecco ciò che la feature list nasconde. La maggior parte dell'agent supervision oggi è una fiction mantenuta da una persona stanca. L'agent gira nell'IDE di qualcuno o in una cloud sandbox, il diff arriva come pull request e il "review" è qualunque cosa quel developer avesse voglia di fare alle 17. Reasoning, dead end, tre tentativi prima di quello riuscito: tutto evapora. Ho reviewato abbastanza agent output da sapere che il diff è la parte meno informativa del processo.

La vera proposta di Slack Code è rendere il processo stesso l'artefact. Il channel conserva la conversation da cui l'agent ha lavorato, gli intermediate step, il feedback ricevuto e gli approval, poi archivia tutto come searchable record. È un supervision model realmente diverso, e più vicino a come i buoni team reviewano junior engineer che a come oggi reviewano agent: guardare il lavoro, non solo l'output.

Cambia anche chi supervisiona. Il pitch è esplicito: PM, designer e teammate non tecnici possono seguire. Sono cautamente favorevole, con una riserva: una stanza piena di osservatori non è un reviewer. La diff literacy non arriva per osmosi, e "il team può vederlo" può diventare silenziosamente "nessuno l'ha controllato." Le governance question che questo solleva, chi è accountable quando dieci persone hanno guardato e nessuno ha owned l'approval, sono esattamente quelle che affronto nel framework di agent governance, e Slack Code non le risolve per voi. Le rende visibili, che è il primo passo onesto.

Slack Code sposta agent supervision da una private session a uno shared, archived channel record: conversation, intermediate step, feedback e approval persistono come searchable artefact, secondo il product post di Slack. La domanda di accountability, chi owns l'approval in una stanza di osservatori, resta al customer.

Lo shared context taglia in entrambe le direzioni

Il secondo grande claim riguarda il context. L'argomento di Slack è che il context di una task vive già nei channel, bug report, spec discussion, customer complaint, quindi l'agent dovrebbe lavorare dove sta il context invece di farselo copy-paste in un private prompt. È corretto e si basa su plumbing che Slack ha ship tutto l'anno: MCP server e real-time search API sono diventati generally available a febbraio, dando agli agents governed access ai workspace message e file, e Slackbot MCP client è seguito a giugno. Ho spiegato perché MCP access ai team tool è la metà utile dell'agent context nel roundup dei MCP server; il channel model porta l'idea alla conclusione.

Ma shared context è anche shared exposure. Un agent che legge un channel legge tutto, compreso il messaggio dove qualcuno ha incollato un credential "solo per un minuto" e l'external content inoltrato da un customer. Ogni security researcher che conosco dice la stessa cosa: content che un agent può leggere è content che può istruirlo. Uno shared channel è una prompt-injection surface più grande di una private session, punto. Prima di puntare un agent con write access a un busy channel, vale essere deliberati su quali channel legge e quali tool può toccare. È architecture work, non settings work, e lo stesso trade-off che descrivo in agentic architecture: capability e blast radius crescono insieme.

Il vantaggio di context di Slack Code, l'agent lavora dove il task context già vive, poggia sul MCP-based workspace access che Slack ha reso generally available a febbraio 2026, secondo Unite.AI. Lo stesso shared context amplia prompt-injection e credential-exposure surface, trade-off non affrontato nei launch material.

Attribution e review, le vittorie poco glamour

Le parti meno flashy del launch sono quelle che comprerei davvero. Prima attribution: in un code channel, ogni agent action è sotto l'identity dell'agent, in un workspace che sa già chi è ciascuno, con un audit log che sopravvive al project. Sembra basic. Lo è. È anche più attribution infrastructure di quella che la maggior parte dei team ha oggi per agent work, dove "l'ha fatto l'agent" e "l'ho fatto io" sfumano nella stessa git history. Le regulated industry chiedono esattamente questa cosa noiosa da un anno.

Secondo review. Diff e live preview nel channel, feedback incorporato dall'agent e hard approval gate prima dello shipping. Notate cosa manca: i material di Slack descrivono una persona che approva il lavoro, ma niente di ciò che ho visto specifica chi deve essere, cosa vede o cosa succede se il reviewer configurato è in ferie. Approval come checkbox produce approval theatre: green button che tutti imparano a cliccare. I team che otterranno valore saranno quelli che collegano l'approval a un vero code owner con vero diff review e tengono il channel output dell'agent come evidence, non come review stesso.

Anche il competitive context conta. Microsoft ha messo un Copilot coding agent nelle Teams thread a settembre 2025, e Block ha ship il suo open-source Buzz a luglio, come nota Reworked. La chat window sta diventando una contested surface per agent work, e il vantaggio di Slack è poco glamour: è dove il team è già. Distribution batte cleverness nel collaboration software, sempre.

Slack Code dà a ogni agent una propria identity nei channel e conserva audit log per archived project, secondo TechRepublic, ma l'approval gate, "a person approves the work before it ships", non specifica reviewer identity o review standards. Teams Copilot agent di Microsoft, settembre 2025, e Buzz open source di Block, luglio 2026, sono i comparabili diretti, secondo Reworked.

Cosa fare adesso

Se il team usa Slack e coding agent, tre step.

  1. Questa settimana: scegliete una task low-stakes, ben specificata, un copy change o piccolo bug con riproduzione chiara, e fatela in code channel con due o tre persone che osservano. Non state testando l'agent; state testando il review behaviour del team. Guardate se qualcuno legge davvero il diff.

  2. Prima che qualcosa di reale ship: decidete per iscritto chi è approver dell'agent work per ogni repo e cosa deve controllare. Se la risposta è "chiunque sia nel channel", non avete review process, avete un button.

  3. Prima del broad rollout: scope quali channel l'agent può leggere e quali credential detiene il suo environment. Channel history è context, e context è attack surface. Partite stretti e allargate con evidence.

FAQ

Cos'è Slack Code?

Una feature Slack, lanciata il 20 agosto 2026, che permette ai team di taggare partner coding agent, Claude Code, Devin, GitHub Copilot, Vercel, con ChatGPT in arrivo, in una conversation. L'agent apre un "code channel" dedicato alla task, dove il team guarda il lavoro, reviewa diff e preview e approva il risultato prima dello shipping. Il channel si archivia automaticamente alla fine.

Serve un piano Slack a pagamento?

No. Slack Code è disponibile su ogni piano, free workspace inclusi. Ma l'access a ogni coding agent si compra separatamente dal vendor dell'agent, quindi il costo pratico dipende da quali agent pagate già.

Slack Code sostituisce code review?

No, e trattarlo così è il rischio principale. Sposta review in uno shared archived channel e aggiunge approval gate, ma la qualità del review dipende ancora da un named human che legge il diff. Un processo visibile senza owner è peggio di uno privato con reviewer coscienzioso, perché sembra supervised.

È sicuro lasciare che un agent legga un intero channel?

Dipende da cosa c'è nel channel. Qualunque cosa l'agent possa leggere può influenzarlo, inclusi pasted credentials e forwarded external content. Scope read access in modo stretto, mantenete agent credentials least-privilege e trattate channel content come untrusted input, perché dal punto di vista dell'agent lo è.

In sintesi

Slack Code non farà scrivere codice migliore agli agenti. Non serve a quello. Rende agent work visibile, attributable e reviewable by default, nel posto dove il team vive già, e sono le tre cose che mancano silenziosamente alla maggior parte degli agent deployment. Il catch è che visibility non è supervision. Il channel vi dà record e gate; se qualcuno sta davvero guardando resta un vostro problema. Guardate come i team configurano l'approver, non l'agent. È lì che questo funziona o diventa theatre.

Se state cercando come mettere agent nei team workflow senza perdere il controllo del review, è una conversazione che faccio regolarmente con clienti. Contattatemi.

Fonti

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

  • Slack, "Slack Code: Where Your Team and Agents Build Together": https://slack.com/blog/news/slack-code-channels-for-agents (pubblicato 2026-08-28, consultato 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/ (pubblicato 2026-08-20, consultato 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/ (pubblicato 2026-08-21, consultato 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/ (pubblicato 2026-08-20, consultato 2026-08-29)

Continua a leggere

Agent Field Notes

Ricevi il prossimo numero.

Harness per agenti, runtime, sicurezza e governance, spiegati per chi deve gestire questi sistemi.

State affrontando una decisione come questa?

Realizziamo revisioni di architettura, valutazioni di governance e comparazioni di framework con versioni bloccate per team che prendono decisioni cruciali sui sistemi di agenti.

Informazioni sull'autore

Adam Maguire Wilson

Fondatore e consulente indipendente sui sistemi di agenti IA.

adam.mw