TL;DR: Slack Code porta il lavoro degli agenti AI in canali condivisi, dove richiesta, diff, anteprima e approvazione restano visibili al team. Un agente nell’IDE parte invece dal repository, dal terminale e dai test. Per una PMI sceglierei l’IDE come ambiente operativo predefinito: Slack è un buon piano di coordinamento, ma il codice di produzione deve restare vicino ai controlli che possono smentirlo.

Cosa cambia con Slack Code

Il 20 agosto 2026 Slack ha presentato Slack Code, una funzione che crea canali dedicati ai task di sviluppo. Si tagga un agente compatibile, per esempio Claude Code, Devin, Vercel Agent o GitHub Copilot, e il sistema apre uno spazio di progetto. Il team può seguire la conversazione, esaminare le modifiche, vedere un’anteprima HTML, dare feedback e approvare il risultato. A lavoro concluso, il canale si archivia e lascia una traccia delle attività.

L’idea è sensata: molti requisiti tecnici nascono già in chat. Bug report, screenshot, decisioni del cliente e limiti di budget sono dispersi tra messaggi e riunioni. Portare l’agente dove quel contesto esiste riduce il passaggio iniziale dal problema al task. Ma non risolve automaticamente la parte più difficile: dimostrare che la modifica funziona nel repository reale.

Il criterio di confronto

Confronto Slack Code e un coding agent nell’IDE su quattro criteri operativi:

  • qualità del contesto disponibile all’agente;
  • velocità del ciclo modifica, test e correzione;
  • visibilità per chi non sviluppa;
  • controllo su permessi, dati e rilascio.

Non sto confrontando i modelli. Lo stesso agente può comparire in entrambi gli ambienti. Il punto è dove vivono le prove necessarie per decidere se il suo output è accettabile.

Slack Code: pro e contro concreti

Il vantaggio principale è il contesto organizzativo. Product owner, designer, commerciale e sviluppatore vedono la stessa richiesta e possono correggerla senza ricostruire il ragionamento altrove. Per aggiornare una landing page, preparare un prototipo interno o trasformare una discussione in una piccola automazione, il canale accorcia il percorso. Diff, anteprima e approvazione nello stesso spazio rendono anche più difficile il classico equivoco: «pensavo fosse già pronto».

Il secondo vantaggio è l’audit leggibile. Una pull request resta il riferimento tecnico, ma raramente conserva tutto il contesto commerciale che ha prodotto la modifica. Un canale dedicato può documentare chi ha chiesto cosa, quali vincoli sono cambiati e chi ha approvato. Per una piccola agenzia WordPress, questa traccia vale soprattutto nei task in cui cliente e sviluppatore devono chiudere insieme il perimetro.

Il limite è che una conversazione condivisa non equivale a un ambiente di sviluppo. Nel canale è facile vedere una diff convincente; è più difficile capire se quella modifica rompe un hook WordPress, una migrazione, la cache o un flusso di pagamento. Più persone partecipano, più cresce anche il rumore: feedback contraddittori, richieste fuori scope e approvazioni date sull’anteprima invece che sui test.

C’è poi il tema dei permessi. Un canale privato protegge la conversazione dagli altri membri del workspace, ma non sostituisce il principio del minimo privilegio. L’agente deve ricevere solo repository, tool e ambienti necessari. Secret, file .env, dump di produzione e dati dei clienti non vanno incollati nella chat. La comodità del contesto condiviso allarga la superficie informativa: va governata prima di invitare l’agente.

Agente nell’IDE: pro e contro concreti

Nell’IDE il contesto è tecnico. Gli agenti moderni possono leggere e modificare file, cercare nel codebase, eseguire comandi e iterare dopo un errore. La sessione resta vicina al repository e allo sviluppatore che deve valutarla. Questo conta quando il risultato dipende da una suite di test, da WPCS, da Composer, da una build frontend o da una verifica su staging.

Per WordPress la differenza è pratica. Un agente nell’IDE può seguire le istruzioni del progetto, verificare escaping e sanitizzazione, lanciare test e controllare la versione PHP prima di proporre un rilascio. Su un tema o plugin in produzione, il feedback più utile non è un’emoji nel canale: è un test che fallisce, una query non preparata o un diff che mostra una regressione.

Il contro è la scarsa visibilità per il resto del team. Se la sessione resta sul computer dello sviluppatore, decisioni e motivazioni possono sparire. Il tecnico diventa traduttore tra chat, ticket e codice; proprio il passaggio che Slack Code prova a eliminare. Anche la qualità del contesto può peggiorare se l’agente vede il repository ma non conosce la ragione commerciale della modifica.

Questo problema si riduce con istruzioni portabili e criteri di accettazione scritti. Ne ho parlato nella guida su come rendere portabili le istruzioni dei coding agent: il contesto utile non deve dipendere dalla memoria di una chat. Deve viaggiare con il progetto e poter essere controllato anche nella sessione successiva.

Implicazioni per PMI, automazioni e web

Per un team piccolo userei Slack Code solo per task con forte componente collaborativa e rischio tecnico limitato: prototipi, pagine informative, script interni non critici, raccolta dei requisiti e revisione dell’anteprima. Il canale deve produrre un brief verificabile, non sostituire repository, staging e CI.

Per plugin WordPress, integrazioni con API, automazioni che muovono dati, refactoring e sicurezza sceglierei l’agente nell’IDE. Qui servono filesystem isolato, permessi espliciti, test e rollback. È lo stesso motivo per cui il costo del modello non basta: come nel confronto tra modello AI e harness operativo, il valore arriva dal sistema di controllo attorno al modello.

La configurazione minima è semplice. Slack raccoglie richiesta, vincoli e approvazione funzionale. Un ticket o un file di progetto trasferisce quei criteri nel repository. L’agente nell’IDE implementa in un branch isolato, esegue test e prepara la diff. La pull request resta il gate tecnico. Il canale riceve il link all’anteprima e l’esito, non le credenziali.

La take: IDE prima, Slack dopo

Se una PMI deve abilitarne uno solo, sceglierei l’agente nell’IDE. È meno spettacolare per chi osserva, ma mette il modello vicino alle evidenze che contano: codice, test, terminale e cronologia Git. Slack Code diventa utile quando esiste già una disciplina di rilascio e serve rendere il processo comprensibile al resto del team.

Il canale condiviso è un ottimo posto per decidere cosa costruire. Non è il posto in cui dichiarare che il codice è pronto. Quella risposta deve ancora arrivare dal repository.

Fonti