Slack Code: Coding Agents acabaram de se mudar para o canal do time

A coisa mais importante sobre um coding agent não é mais quão bem ele escreve código. É quem pode ver o que ele está fazendo. Até este mês, a resposta honesta para a maioria dos times era: um developer, em terminal privado ou browser tab, esperando lembrar depois o que o agent realmente fez. Slack Code, lançado em 20 de agosto, é a maior tentativa até agora de mudar essa resposta para "todo mundo do projeto, por default."

Li o anúncio de lançamento, o follow-up post do Slack e a coverage. O model por baixo é o mesmo Claude Code, Devin ou Copilot que você já conhece. O que muda é a sala onde o trabalho acontece, e isso importa mais do que boa parte da coverage sugere.

Principais conclusões - Slack Code adiciona "code channels": project spaces compartilhados em que um coding agent marcado, Claude Code, Devin, GitHub Copilot, Vercel, com ChatGPT chegando, trabalha abertamente, com diffs, live previews e human approval antes do shipping. - Funciona em qualquer Slack plan desde day one, embora access a cada agent seja comprado separadamente. Channels auto-archive quando o trabalho termina e mantêm audit log. - A mudança real é supervisory: agent work sai de uma private session observada por uma pessoa e vira shared artefact observado por um time. Corrige gaps de attribution/review e cria outros, bystander apathy, approval theatre, channel context como attack surface. - Também é distribution move. Slack passou um ano construindo agent plumbing, MCP server, real-time search, Slackbot MCP client, e code channels são a surface que torna isso visível. - Trate "uma pessoa aprova o trabalho antes de ship" como design goal, não garantia. Seu review process ainda precisa ser real.

O que aconteceu

Em 20 de agosto, Slack lançou Slack Code em todos seus planos, incluindo free workspaces. A mecânica, segundo launch coverage e TechRepublic:

• Você marca um coding agent em qualquer conversa Slack. O agent cria um code channel dedicado à task, seja corrigir bug, atualizar página ou construir feature.

• Todo mundo no channel vê a mesma conversation da qual o agent trabalha, revisa code diffs propostos, confere live HTML previews, deixa feedback que o agent incorpora e aprova trabalho final. Nada ship sem human sign-off.

• Quando o trabalho termina, o channel se arquiva automaticamente e mantém audit log.

• Launch partners são Claude da Anthropic, Devin da Cognition, GitHub Copilot e Vercel, com ChatGPT da OpenAI anunciado para breve. Slack pretende abrir code channel APIs à developer community para qualquer custom agent participar.

Quem entra no channel é configurável. Katie Steigman, VP of Product do Slack, disse à 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 do Slack, resumiu a intenção: "AI only creates value when it's part of how a team actually works."

Slack Code, lançado 20 de agosto de 2026 em todos os Slack plans, coloca partner coding agents, Claude, Devin, Copilot, Vercel, ChatGPT anunciado, em "code channels" compartilhados onde o time inteiro vê conversation, diffs e live previews do agent, aprova trabalho antes do shipping e herda audit log quando channel auto-archive, segundo anúncio do Slack.

Supervision sai da sessão privada

Aqui está o que feature list esconde. Maioria da agent supervision hoje é fiction mantida por uma pessoa cansada. Agent roda no IDE de alguém ou cloud sandbox, diff chega como pull request, e "review" é o que aquele developer teve disposição para fazer às 17h. Reasoning, dead ends, três tentativas antes do que funcionou: tudo evapora. Já revisei agent output suficiente para saber que diff é parte menos informativa do processo.

Proposta real Slack Code é fazer processo virar artefact. Channel guarda conversation de onde agent trabalhou, intermediate steps, feedback recebido e approvals, e arquiva tudo como searchable record. É supervision model genuinamente diferente, mais próximo de como bons times review junior engineers do que como hoje review agents: assistir ao trabalho, não só output.

Também muda quem supervisiona. Pitch explícito é PMs, designers e teammates não técnicos poderem acompanhar. Sou cautelosamente favorável, com uma ressalva: sala cheia de watchers não é reviewer. Diff literacy não chega por osmose, e "time pode ver" pode virar "ninguém checou." Governance questions que isso levanta, quem accountable quando dez pessoas viram e ninguém owned approval, são exatamente as que trabalho no framework de agent governance, e Slack Code não responde por você. Torna visíveis, primeiro passo honesto.

Slack Code move agent supervision de private session para shared, archived channel record: conversation, intermediate steps, feedback e approvals persistem como searchable artefact, segundo product post Slack. Pergunta de accountability, quem owns approval em sala de watchers, continua sendo do customer.

Shared context corta dos dois lados

Segundo grande claim é context. Argumento Slack: task context já vive em channels, bug report, spec discussion, customer complaint, então agent deveria trabalhar onde context está, em vez de copy-paste para private prompt. Correto, e se apoia em plumbing que Slack vem shipping o ano todo: MCP server e real-time search API ficaram generally available em fevereiro, dando agents governed access a workspace messages/files, Slackbot MCP client seguiu em junho. Cobri por que MCP access a team tools é metade útil de agent context no roundup de MCP servers; channel model leva ideia à conclusão.

Mas shared context também é shared exposure. Agent que lê channel lê tudo, incluindo message em que alguém colou credential "só por um minuto" e external content encaminhado de customer. Todo security researcher que conheço diz mesma coisa: content que agent pode ler é content que pode instruí-lo. Shared channel é prompt-injection surface maior que private session, ponto. Antes de apontar agent com write access para busy channel, decida deliberadamente quais channels lê e quais tools toca. É architecture work, não settings work, mesmo trade-off que descrevo em agentic architecture: capability e blast radius crescem juntos.

Vantagem de context do Slack Code, agent trabalha onde task context já vive, depende de MCP-based workspace access que Slack tornou generally available em fevereiro 2026, segundo Unite.AI. Mesmo shared context amplia prompt-injection e credential-exposure surface, trade-off não abordado nos launch materials.

Attribution e review, ganhos sem glamour

Partes menos flashy do launch são as que eu compraria. Attribution primeiro: em code channel, cada agent action fica sob identity do agent, em workspace que já sabe quem é cada um, com audit log que sobrevive project. Parece basic. É basic. Também é mais attribution infrastructure que maioria dos times tem hoje para agent work, onde "agent fez" e "eu fiz" se misturam na mesma git history. Regulated industries pedem exatamente essa coisa chata há um ano.

Review segundo. Diffs/live previews no channel, feedback incorporado, hard approval gate antes do shipping. Veja o que falta: Slack materials descrevem uma pessoa aprovando trabalho, mas nada que vi especifica quem deve ser, o que vê, ou o que acontece se reviewer configurado está de férias. Approval como checkbox produz approval theatre: green button que todos aprendem clicar. Times que ganham valor serão os que conectam approval a code owner real com diff review real, e mantêm channel output como evidence, não como review em si.

Competitive context também importa. Microsoft colocou Copilot coding agent em Teams threads em setembro 2025, Block ship open-source Buzz em julho, como Reworked observa. Chat window está virando contested surface para agent work, e vantagem Slack é sem glamour: é onde time já está. Distribution vence cleverness em collaboration software, sempre.

Slack Code dá identity própria a cada agent nos channels e mantém audit log por archived project, segundo TechRepublic, mas approval gate, "a person approves the work before it ships", não especifica reviewer identity/review standards. Teams Copilot agent Microsoft, setembro 2025, e open-source Buzz da Block, julho 2026, são comparáveis diretos, segundo Reworked.

O que fazer agora

Se seu time usa Slack e coding agents, três passos.

1. Esta semana: escolha task low-stakes bem especificada, copy change ou bug pequeno com reprodução clara, rode em code channel com duas ou três pessoas olhando. Você não testa agent; testa review behaviour do time. Veja se alguém realmente lê diff.

2. Antes de algo real ship: decida por escrito quem é approver de agent work em cada repo e o que precisa checar. Se resposta é "quem estiver no channel", não há review process, há button.

3. Antes de broad rollout: scope quais channels agent lê e quais credentials environment mantém. Channel history é context, context é attack surface. Comece narrow e amplie com evidence.

FAQ

O que é Slack Code?

Feature Slack lançada 20 agosto 2026 que permite a times marcar partner coding agents, Claude Code, Devin, GitHub Copilot, Vercel, ChatGPT chegando, numa conversation. Agent abre "code channel" dedicado à task, time observa trabalho, revisa diffs/previews, aprova resultado antes do shipping. Channel auto-archive no fim.

Preciso de Slack pago?

Não. Slack Code disponível em todo plano, free workspaces inclusive. Mas access a cada coding agent é comprado separadamente do vendor, então custo depende de agents que você já paga.

Slack Code substitui code review?

Não, e tratar assim é principal risco. Move review para shared archived channel e adiciona approval gate, mas qualidade depende de named human lendo diff. Processo visível sem owner é pior que privado com reviewer cuidadoso, porque parece supervised.

É seguro deixar agent ler channel inteiro?

Depende do conteúdo. Tudo que agent lê pode influenciar, incluindo pasted credentials e forwarded external content. Scope read access estreito, mantenha agent credentials least-privilege e trate channel content como untrusted input, porque para agent é.

Em resumo

Slack Code não fará agents escreverem código melhor. Não é para isso. Faz agent work visible, attributable e reviewable by default, no lugar onde time já vive, e são três coisas silenciosamente ausentes na maioria dos agent deployments. Catch: visibility não é supervision. Channel dá record e gate; alguém realmente estar olhando continua seu problema. Observe como times configuram approver, não agent. Ali funciona ou vira theatre.

Se está decidindo como colocar agents em team workflows sem perder controle do review, é conversa que tenho regularmente com clientes. Entre em contato.

Fontes

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

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