Codar Dentro Do Slack: Avanço Real Ou Só Mais Uma Interface Para O Mesmo Agente?

Semana passada fiz uma lista rápida, só para mim, de todos os lugares onde alguma equipe que acompanho gerencia agente de código hoje. Terminal, com CLI dedicada. IDE, com plugin ou modo agente embutido. Painel web do provedor, para ver histórico de execuções e gastar token. Repositório, via pull request aberto por bot. Parei em quatro sem nem contar as ferramentas de observabilidade que também prometem ser "onde você acompanha o que o agente fez". Cada uma dessas superfícies nasceu resolvendo um problema específico e, quase sempre, terminou anunciando que virou o hub definitivo.

Foi com essa lista ainda fresca que vi a notícia do Slack Code, lançado em 21 de agosto: agentes de código — Claude Code, Devin da Cognition, GitHub Copilot e o agente da Vercel — embutidos em canais dedicados do Slack, com a promessa de que o time inteiro assiste, guia, revisa e lança software junto, em tempo real. Três dias depois, mais cobertura sobre o NanoClaw, integração que deixa qualquer pessoa criar um time inteiro de agentes — cada um com identidade, papel, skill e memória próprios — a partir de uma única mensagem enviada num canal.

Não testei nenhuma das duas ferramentas e não vou fingir que testei. O que fiz foi ler a cobertura, comparar com o que já vi de padrão nesse tipo de anúncio nos últimos dois anos, e tentar responder uma pergunta que acho mais interessante que "isso é bom": colocar o agente dentro do canal de chat resolve um problema real de fluxo de trabalho, ou é só mais uma superfície empilhada em cima das que já existem? Este post é minha tentativa de responder com honestidade, inclusive sobre o quanto ainda não sei.

Vou separar bem o que o Slack Code faz do que o NanoClaw faz, porque são coisas diferentes sendo anunciadas na mesma semana e frequentemente citadas juntas como se fossem uma coisa só. Depois vou colocar o argumento a favor de trazer agente para o chat, o argumento contra, e onde eu pessoalmente fico depois de pesar os dois.

---

O Que O Slack Code Realmente Faz

O Slack Code, segundo a cobertura da Dataconomy sobre o lançamento de 21 de agosto, é um canal dedicado dentro do Slack onde um agente de código roda e o time observa, participa e reage em tempo real. A lista de agentes suportados no lançamento inclui o Claude Code da Anthropic, o Devin da Cognition, o GitHub Copilot e o agente de código da Vercel — ou seja, não é um agente proprietário do Slack, é uma camada de hospedagem e colaboração em cima de agentes que já existem em outras superfícies.

A proposta declarada é que o time inteiro assista, guie, revise e lance software em conjunto. Isso é uma frase de marketing, mas vale decompor o que ela implica tecnicamente. Assistir significa que a execução do agente — os passos, as decisões, talvez o diff sendo gerado — fica visível para quem está no canal, não só para quem disparou a tarefa. Guiar significa que mais de uma pessoa pode interromper ou redirecionar o agente sem acesso ao terminal ou ao ambiente onde ele roda. Revisar sugere que a aprovação acontece no mesmo lugar da execução, sem trocar de aba. Lançar junto é a parte mais ambiciosa: o ciclo terminando ali mesmo, sem sair do canal para abrir pull request em outro sistema.

Separado disso, e é importante não confundir os dois anúncios, o Slack lançou também o "Add to Slack" — um caminho de deploy enterprise construído em conjunto com dez plataformas de criação de agentes, incluindo o NanoClaw. Segundo o blog oficial do Slack, esse caminho permite colocar um agente customizado num canal sem escrever código de integração, sem webhook, sem setup técnico. É a infraestrutura que torna o Slack Code e ferramentas como o NanoClaw fáceis de instalar — decisão de plataforma normalmente invisível para quem usa só o produto final, mas que explica por que várias integrações apareceram juntas na mesma janela de tempo.

Vale registrar o que não está claro na cobertura disponível até agora: como funciona a resolução de conflito quando duas pessoas guiam o agente em direções diferentes no mesmo canal, qual é o modelo de permissão para quem pode aprovar um lançamento, e se "assistir em tempo real" significa replay de log ou stream de fato interativo. São detalhes que só ficam claros com uso, e é exatamente o tipo de coisa que eu não vou inventar aqui.

---

O Que O NanoClaw Realmente Faz

O NanoClaw é uma proposta mais ambiciosa e, na minha leitura, mais interessante do ponto de vista estrutural. Segundo a cobertura da VentureBeat e da Dataconomy sobre o lançamento de 20 e 24 de agosto, a ideia central é que qualquer pessoa cria um time inteiro de agentes a partir de uma única mensagem enviada num canal do Slack. Cada agente criado ganha identidade própria, papel definido, conjunto de skills, instruções e memória — inclusive avatar customizado, o que é um detalhe pequeno mas que sinaliza a intenção do produto: não é um bot genérico respondendo pergunta, é algo desenhado para parecer um colega persistente.

O ponto que separa isso de "mais um bot de Slack" é a persistência e a portabilidade. Os agentes criados pelo NanoClaw podem trabalhar em canais e em Slack Canvases compartilhados, o que sugere colaboração assíncrona sobre documento vivo, não só resposta a comando pontual. E, mais notável ainda, esses agentes podem ser acionados fora do Slack — em outras plataformas como Telegram e WhatsApp. Isso quer dizer que a identidade do agente não fica presa à superfície onde foi criada; o "funcionário" que você montou numa mensagem do Slack continua existindo e pode ser chamado de outro canal de mensagem inteiramente diferente.

O CEO da NanoCo, Gavriel Cohen, foi citado pela VentureBeat com uma frase que resume bem a aposta da empresa: "nos próximos 12 a 18 meses, todo mundo num time vai ser gestor de agentes." É uma declaração de visão de produto, não um dado verificável, e trato como tal — mas ela é útil porque expõe a tese por trás do NanoClaw com clareza. A aposta não é que o agente substitui a pessoa. É que a pessoa passa a gerenciar múltiplos agentes como quem gerencia um time, e o Slack — ou WhatsApp, ou Telegram — vira o lugar onde essa gestão acontece porque já é o lugar onde a gestão de pessoas acontece.

Isso é uma proposta de produto diferente da do Slack Code. O Slack Code traz agentes de código já estabelecidos para um canal de observação e colaboração síncrona em torno de uma tarefa de engenharia específica. O NanoClaw propõe criar e reter identidades de agente com papel definido, que podem ou não ser sobre código, e que existem através de múltiplas superfícies de mensagem. São duas apostas complementares saindo quase juntas, e acho que a coincidência de datas — não a coincidência de tese — é o que fez tanta gente comentar as duas como se fossem a mesma coisa.

---

O Argumento A Favor: Visibilidade É Um Problema Real

Antes de bater no ceticismo, quero levar a sério o argumento a favor, porque ele existe e não é bobo. O problema que colocar o agente no chat tenta resolver é real: hoje, na maioria dos times que rodam agente de código, a execução acontece num lugar que só uma pessoa vê — o terminal dela, a IDE dela, o painel dela — e o resto do time só descobre o que aconteceu quando o pull request chega pronto ou quando alguém manda print no canal. Já escrevi sobre esse tema em o retorno do terminal como interface para agentes de código, e uma das tensões que aparece ali é exatamente essa: quanto mais a execução do agente volta para uma superfície pessoal e isolada, como o terminal, menos naturalmente ela se torna visível para o resto do time.

Imagine um cenário hipotético — e deixo claro que é hipotético — de um time que recebe, direto no canal do projeto, uma notificação de que o agente terminou de investigar um bug de produção e está propondo três hipóteses, cada uma com um trecho de código candidato. Nesse cenário, qualquer pessoa do time — não só quem disparou a tarefa — pode olhar, comentar "essa segunda hipótese já vimos isso antes, não é isso", e redirecionar o agente sem precisar pedir acesso a nada, sem esperar a pessoa dona da tarefa voltar do almoço. Isso é colaboração síncrona em cima de um trabalho que hoje é, por padrão, solitário. Se o Slack Code de fato entrega esse cenário com fidelidade, ele resolve algo que ferramenta nenhuma de terminal ou IDE resolve sozinha, porque terminal e IDE são, por desenho, superfícies de uma pessoa.

Tem uma segunda dimensão do argumento a favor que é menos sobre colaboração e mais sobre redução de context switching — mas aqui com uma ressalva importante que vou aprofundar na próxima seção. Se a pessoa já vive dentro do Slack o dia inteiro, para reunião, para decisão, para conversa de projeto, cada alternância entre Slack e terminal é uma perda de atenção pequena, mas repetida dezenas de vezes por dia. Trazer parte do fluxo de agente para dentro do canal onde a conversa sobre o trabalho já acontece elimina, ao menos em tese, uma dessas alternâncias.

E existe um argumento organizacional que conecto com algo que já escrevi antes. Em squads de agentes e o modelo humano-no-loop, a ideia central era que times mistos de humano e agente funcionam melhor quando o ponto de intervenção humana é claro e acessível, não escondido atrás de uma ferramenta que só o operador técnico sabe usar. Um canal de Slack, por mais que pareça banal, é a superfície mais democrática que existe num time de engenharia — todo mundo já sabe usar, do estagiário ao gerente de produto. Se o ponto de intervenção humana muda do terminal para o canal, o universo de quem consegue intervir aumenta, e isso não é pouca coisa.

---

O Argumento Contra: O Histórico De "Isto Vira O Hub" Não É Bom

Agora o outro lado, onde o meu ceticismo mora. A frase "isto vai ser onde você gerencia [coisa] a partir de agora" é uma das mais repetidas na história recente de ferramenta de desenvolvedor, e a taxa de acerto dela é baixa. Já vimos IDE prometer virar hub central de tudo — terminal embutido, banco de dados embutido, deploy embutido — e o resultado, na prática, foi a maioria dos times continuar com terminal separado, painel de infraestrutura separado, observabilidade separada. O próprio Slack já passou por isso: prometeu ser o "sistema operacional do trabalho" há alguns anos, e o que sobrou foi um ótimo canal de mensagem com integrações razoáveis, não um substituto de nada.

O risco técnico específico de colocar agente de código dentro de um canal de chat é de fragmentação, não de consolidação. Hoje já existe uma superfície de terminal fortalecida — escrevi sobre isso em o Warp e a aposta de terminal como ambiente agêntico open source — e uma disputa ativa entre CLI e IDE por onde o trabalho de fato acontece. Adicionar uma terceira, ou quarta, superfície de gestão de agente não substitui as anteriores automaticamente; ela se soma, a menos que alguma das outras seja explicitamente descontinuada pelo time. E ferramenta nenhuma se autodescontinua por vontade própria — quem decide isso é o time, com atrito, meses depois do hype inicial.

Existe também um problema de granularidade que a cobertura disponível não resolve. Código não é conversa; é um artefato com estrutura, dependência e necessidade de revisão linha a linha. Um canal de chat é otimizado para mensagem curta, sequencial, difícil de referenciar depois. Revisar um diff de duzentas linhas dentro de uma thread de Slack é uma experiência genuinamente pior do que revisar o mesmo diff numa interface desenhada para isso, com syntax highlighting, blame, comparação lado a lado. O Slack Code pode ter resolvido isso — não tenho como saber sem ver a interface — mas é o tipo de problema que "colocar no chat" tende a piorar, não melhorar.

E tem o argumento que mais me preocupa no caso específico do NanoClaw: criar agente com identidade e memória próprias a partir de uma mensagem é trivialmente fácil, e isso é ao mesmo tempo a força e o risco do produto. Se o custo de criar um novo "colega" agente cai para uma linha de texto, a tendência natural — já vimos esse padrão em toda ferramenta de baixo atrito de criação, de planilha a microsserviço — é a proliferação descontrolada. Daqui a alguns meses, um time que adotou o NanoClaw sem governança pode ter uma dúzia de agentes com papel sobreposto e ninguém sabendo ao certo qual "colega" ainda está ativo. Isso conecta direto com o Agent Operations Lead como nova função de liderança: times que rodam agente em escala precisam de alguém cuidando do inventário, e uma ferramenta que reduz o atrito de criação torna esse trabalho mais urgente, não menos.

Por fim, existe um argumento sobre a natureza do Slack como empresa e produto que vale considerar com honestidade. O "Add to Slack" foi construído em parceria com dez plataformas de agente diferentes, o que é bom para escolha, mas também sinaliza que o Slack está posicionando o canal como a camada de distribuição para qualquer agente de terceiro — não necessariamente como o melhor ambiente de execução para nenhum deles em particular. Ser a vitrine não é o mesmo que ser a ferramenta certa para o trabalho.

---

Onde Eu Fico Depois De Pesar Os Dois Lados

Não tenho como saber ainda se isso pega. Digo isso sem meio-termo porque acho que é a resposta honesta, e o histórico de "ferramenta de chat vira hub de tudo" realmente não é bom — mas também não é zero. Slack conseguiu virar o padrão de comunicação assíncrona em boa parte da indústria de tecnologia, então não é impossível que consiga também virar padrão de colaboração síncrona em torno de execução de agente. A diferença é que a primeira vitória exigiu resolver um problema que praticamente não tinha solução boa antes (e-mail e IRC eram ruins mesmo). A segunda está competindo com terminal, IDE e painel web, que já são soluções razoavelmente boas para o que fazem.

Minha posição, então, não é "vai vingar" nem "é só hype". É que o valor real dessas ferramentas depende do tipo de tarefa e do tamanho do time, e vale testar com esse recorte em mente em vez de adotar ou rejeitar em bloco. Um cenário hipotético em que faria sentido: um time de produto pequeno, com pessoas não técnicas que precisam acompanhar uma automação sem aprender a ler log de terminal — ali, o agente narrando o progresso num canal, com possibilidade de interromper com uma frase em português, é ganho líquido de visibilidade que nenhuma CLI oferece. Outro cenário, esse em que eu desconfiaria fortemente: um time de engenharia sênior fazendo refatoração complexa, com dependência fina entre arquivos — ali, forçar a revisão para dentro de uma thread de chat provavelmente piora a qualidade da revisão, e o time volta para IDE e pull request tradicional em poucas semanas.

O ponto que mais me interessa observar daqui para frente não é se o Slack Code ou o NanoClaw "vencem". É se alguma equipe consegue, de fato, descontinuar uma das superfícies antigas depois de adotar uma dessas novas — trocar terminal por canal, não somar canal a terminal. Esse é o teste real de qualquer alegação de hub. Enquanto isso não acontecer em escala visível, o padrão mais provável, a julgar pelo histórico da própria indústria, é engenheiro comparando três notificações do mesmo agente em três lugares diferentes: uma no terminal, uma no PR, e agora uma no Slack — e nenhuma delas suficientemente completa para dispensar as outras duas.

Vale reconhecer, por fim, uma diferença estrutural entre os dois que talvez explique destinos diferentes. O Slack Code depende de agentes de terceiro — Claude Code, Devin, Copilot, Vercel — continuarem investindo numa integração que não é o produto principal deles; se qualquer um decidir que a energia de engenharia vale mais na própria CLI, a experiência dentro do Slack fica defasada rápido. O NanoClaw é o produto principal de uma empresa cuja aposta inteira é essa camada de orquestração — mais investimento contínuo, mas também mais dependência de uma empresa menor se manter no mercado. Nenhuma equação é obviamente melhor; são apostas diferentes com riscos diferentes.

---

Conclusão

Não escrevi este post para dizer que Slack Code e NanoClaw são irrelevantes, nem para dizer que são o futuro óbvio de como equipes vão trabalhar com agente. Escrevi porque acho que a pergunta "onde eu devo gerenciar meus agentes" está sendo respondida por marketing de produto com uma frequência maior do que por evidência de uso real, e isso vale sempre a pena desacelerar e separar. Cada nova superfície que promete ser o hub definitivo carrega um pedaço de verdade — neste caso, visibilidade e colaboração síncrona são problemas reais que terminal e IDE não resolvem bem — e um pedaço de exagero, que é a ideia de que resolver esse problema significa substituir tudo o que veio antes.

A parte mais honesta que posso oferecer é que o teste desse tipo de ferramenta nunca é o lançamento, é o trimestre seguinte: quantos times que adotaram continuam usando sem forçar, quantos voltaram para o fluxo antigo, e — o sinal mais confiável de todos — quantos conseguiram de fato desligar uma superfície anterior em vez de só somar mais uma. Não tenho esse dado ainda para o Slack Code nem para o NanoClaw, porque as duas ferramentas têm poucos dias de existência pública no momento em que escrevo isso. Qualquer alegação de sucesso ou fracasso agora seria eu inventando confiança que não tenho.

O que fica, para quem lidera time técnico e está decidindo se vale testar, é uma pergunta mais simples do que "isso é revolucionário": o problema que essa ferramenta resolve — visibilidade, colaboração, redução de troca de contexto — é o problema que mais dói no seu time hoje, ou é um problema que você já resolveu de outro jeito e que ganharia pouco com mais uma camada? Se for a primeira resposta, vale o piloto pequeno, com critério claro de quando abandonar. Se for a segunda, o risco real não é perder a novidade — é gastar o trimestre migrando fluxo que já funcionava para uma superfície nova só porque ela apareceu primeiro na sua timeline.

Fontes:

• Dataconomy — Slack launches Code for AI coding collaboration
• Slack — Add to Slack
• VentureBeat — NanoClaw comes to Slack, letting you create persistent AI agent teams and colleagues from a single message
• Dataconomy — NanoClaw enables creation of AI agent teams in Slack