noticias

Slack Code leva agentes de IA para dentro das conversas e tenta transformar programação em trabalho coletivo

**Categoria editorial:** Inteligência Artificial / Software / Desenvolvimento

**Linha fina:** Nova camada do Slack cria canais específicos para Claude Code, Devin, GitHub Copilot e agentes da Vercel trabalharem diante de toda a equipe, com diffs, prévias e aprovações humanas.

**Meta description:** Slack Code integra Claude Code, Devin, GitHub Copilot e Vercel a canais compartilhados, levando a programação com IA do terminal para a equipe.

**Slug:** `slack-code-agentes-ia-programacao-equipe`

**Palavra-chave principal:** Slack Code

Matéria completa

Slack Code leva agentes de IA para dentro das conversas e tenta transformar programação em trabalho coletivo

Programar com inteligência artificial deixou de significar apenas um desenvolvedor conversando sozinho com um modelo dentro do terminal ou da IDE.

O Slack anunciou o Slack Code, uma nova experiência que coloca agentes de programação diretamente em canais compartilhados, permitindo que desenvolvedores, designers, gerentes de produto e outros integrantes de uma equipe acompanhem uma tarefa enquanto a IA trabalha nela. Entre os parceiros apresentados no lançamento estão Claude Code, da Anthropic, Devin, da Cognition, GitHub Copilot e agentes da Vercel.

A proposta parece simples, mas mexe em um problema cada vez mais importante do desenvolvimento assistido por IA: os agentes conseguem produzir código rapidamente, enquanto contexto, revisão, decisão e responsabilidade continuam distribuídos entre seres humanos.

O Slack quer transformar justamente essa parte em uma experiência coletiva.

O que é o Slack Code

O Slack Code cria canais dedicados a tarefas de desenvolvimento.

Quando alguém aciona um agente compatível em uma conversa, a plataforma pode abrir um espaço específico para aquele trabalho. Nesse ambiente ficam reunidos o pedido original, o plano elaborado pelo agente, alterações no código, comparações entre versões e prévias daquilo que está sendo construído.

Em vez de um desenvolvedor pedir uma alteração ao Claude Code ou ao Devin e depois apresentar o resultado ao restante da equipe, outras pessoas podem acompanhar o processo enquanto ele acontece.

Um designer pode fornecer uma referência visual durante a implementação.

Um gerente de produto pode corrigir uma interpretação errada de requisito.

Um engenheiro pode observar uma decisão arquitetural problemática antes que ela vire dezenas de arquivos modificados.

Essa diferença é importante porque altera a unidade de colaboração.

Até agora, boa parte das ferramentas de programação com IA tratava a interação entre uma pessoa e um agente como o centro do trabalho.

No modelo defendido pelo Slack, o canal passa a ser o espaço no qual humanos e agentes trabalham juntos.

O terminal não morreu — e o Slack sabe disso

Apesar da mensagem provocativa de tirar a programação com IA do terminal, o Slack Code não tenta substituir IDEs, repositórios Git, pipelines de integração contínua ou ambientes especializados de desenvolvimento.

O próprio posicionamento apresentado pelos executivos da empresa reconhece que tarefas profundas e individuais continuarão sendo realizadas em ambientes como terminais.

O Slack pretende conquistar outra parte do processo: a camada na qual uma demanda nasce, é discutida, recebe contexto, ganha aprovação e finalmente vira trabalho técnico.

É uma disputa estratégica considerável.

O terminal é excelente para quem escreve código.

O Slack está tentando responder a outra pergunta: onde trabalha todo mundo que precisa participar da criação de software, mas não necessariamente passa o dia dentro de um terminal?

É aí que a ideia de programação “multiplayer” começa a fazer sentido.

Um bug pode virar tarefa de IA sem desaparecer em um backlog

Imagine que alguém do setor comercial encontra um botão quebrado em uma aplicação.

No fluxo tradicional, essa pessoa registra o problema, alguém cria um ticket, produto prioriza a correção, engenharia analisa, um desenvolvedor implementa a mudança, abre um pull request e finalmente outra pessoa revisa o código.

Com agentes, algumas dessas etapas podem ser comprimidas.

Uma demonstração realizada pela Cognition mostrou o Devin recebendo um problema dentro do Slack, investigando a situação, trabalhando na correção e abrindo um pull request. O agente também conseguiu utilizar navegador e ferramentas de desenvolvimento para testar o resultado antes de apresentar a mudança.

Isso não significa que desaparecem planejamento, revisão ou engenharia.

Significa que o custo operacional entre perceber um problema e começar a trabalhar nele pode cair drasticamente.

Para pequenas correções, protótipos e alterações bem especificadas, essa diferença pode ser enorme.

O recurso mais importante talvez não seja escrever código

A parte mais interessante do Slack Code não é a capacidade de gerar código.

Claude Code, Devin, Copilot e outros agentes já fazem isso.

A novidade está na observabilidade.

Alterações podem aparecer como diffs.

Interfaces podem ser exibidas em prévias.

O plano utilizado pelo agente pode ficar visível.

Pessoas podem interferir durante a execução.

Depois que a tarefa termina, o canal pode ser arquivado, preservando um histórico pesquisável do processo.

Em empresas grandes, esse histórico pode acabar sendo tão importante quanto a geração de código propriamente dita.

Um dos maiores problemas de agentes autônomos é descobrir posteriormente por que determinada alteração foi realizada.

Quando prompts, decisões, resultados intermediários e aprovações ficam espalhados entre terminais, chats privados, IDEs e ferramentas externas, reconstruir o raciocínio de uma mudança pode se tornar difícil.

O Slack tenta transformar a conversa em parte do registro operacional.

O gargalo da programação está mudando

A tese mais ambiciosa apresentada pela empresa é que escrever código está deixando de ser o principal gargalo da produção de software.

Rob Seaman, CEO interino do Slack, argumentou durante a apresentação do produto que ideias, julgamento, gosto e capacidade de decidir o que deve ser construído passam a representar uma parcela maior da restrição quando agentes conseguem gerar implementação rapidamente.

Essa interpretação não é exclusivamente do Slack.

O avanço dos agentes está expondo uma situação conhecida por equipes experientes: gerar mais linhas de código não significa necessariamente produzir software melhor.

Requisitos ruins continuam ruins.

Arquitetura inadequada continua inadequada.

Dependências continuam quebrando.

Dívida técnica continua acumulando.

E alguém continua precisando entender se a solução realmente atende ao problema.

À medida que a geração de código fica mais barata, revisão, especificação, segurança e validação podem se tornar proporcionalmente mais caras.

Essa é uma das consequências menos glamourosas da revolução dos agentes.

O perigo da fábrica de código automático

Existe também um risco evidente.

Se qualquer integrante da organização puder solicitar alterações diretamente a agentes, empresas podem produzir código mais rapidamente do que conseguem revisar.

É o equivalente digital de aumentar drasticamente a velocidade de uma linha de produção sem ampliar o setor de controle de qualidade.

O problema não seria apenas código incorreto.

Pode surgir duplicação de funcionalidades, decisões arquiteturais conflitantes, dependências desnecessárias, vulnerabilidades ou simplesmente implementações perfeitamente funcionais para problemas que nunca deveriam ter sido resolvidos daquela maneira.

A própria discussão sobre desenvolvimento assistido por IA já começa a apontar a revisão humana como um possível novo gargalo da engenharia.

A transparência do Slack Code pode ajudar, mas não resolve automaticamente essa questão.

Um canal visível não significa que alguém realmente leu o código.

A segurança depende de algo mais importante do que o modelo

Para empresas, outra questão crítica são permissões.

Segundo o Slack, os agentes que trabalham nesses canais atuam em nome do usuário e obedecem às permissões que ele já possui, em vez de receber uma espécie de credencial universal para acessar sistemas corporativos.

A empresa afirma que não existe um modo de “superusuário” concedido automaticamente ao agente e que as permissões continuam subordinadas às listas de controle de acesso do usuário que iniciou a operação.

É uma decisão arquitetural sensata.

Mas ela não elimina riscos.

Um funcionário pode possuir acesso legítimo a dados sensíveis e ainda assim fornecer contexto demais a um agente.

Uma instrução maliciosa escondida em documentação ou conteúdo externo pode interferir no comportamento de sistemas automatizados.

Credenciais conectadas a ferramentas externas continuam sendo ativos valiosos.

E quanto maior a autonomia oferecida ao agente, maior precisa ser a qualidade dos mecanismos de auditoria e aprovação.

As garantias apresentadas pelo Slack descrevem o modelo de segurança pretendido pela empresa; a eficácia desse modelo em implantações reais dependerá das integrações, das configurações e dos agentes utilizados.

Slack está construindo algo maior que um recurso para programadores

O Slack Code também deve ser observado dentro de uma estratégia mais ampla da Salesforce.

Nos últimos meses, a plataforma vem preparando uma infraestrutura na qual agentes deixam de aparecer apenas como chatbots isolados e passam a operar como participantes do ambiente de trabalho.

Em junho, por exemplo, o Slack apresentou um cliente MCP integrado ao Slackbot, permitindo conectar diferentes aplicações e serviços e coordenar operações a partir das conversas. A empresa também vem criando ferramentas para implantação e gerenciamento de agentes de terceiros.

Código é um excelente ponto de entrada porque os resultados podem ser medidos.

O agente recebeu uma tarefa.

Produziu uma alteração.

O código passou ou não nos testes.

O pull request foi aceito ou rejeitado.

Mas a arquitetura não precisa permanecer restrita à engenharia.

Se o modelo funcionar, canais semelhantes poderão acomodar agentes responsáveis por documentos jurídicos, campanhas de marketing, análises financeiras ou outros trabalhos que exijam interação entre pessoas, contexto corporativo e automação.

Nesse cenário, o Slack deixa de ser apenas o lugar onde funcionários conversam.

Tenta se tornar o lugar onde humanos supervisionam máquinas trabalhando.

Quem ganha primeiro

Equipes de desenvolvimento distribuídas provavelmente estão entre as primeiras beneficiadas.

Projetos nos quais produto, design e engenharia já utilizam Slack intensivamente podem reduzir parte do vai-e-volta entre chats, tickets, terminais, ferramentas de prototipação e revisão.

Também existe potencial para pessoas menos técnicas participarem de processos anteriormente restritos aos desenvolvedores.

Isso não significa que todos se transformam em programadores.

Significa que determinadas decisões podem chegar mais perto da implementação.

Uma pessoa de produto pode explicar diretamente ao agente o comportamento esperado.

Um designer pode apontar uma inconsistência visual.

Um engenheiro continua responsável por identificar aquilo que parece razoável em uma demonstração, mas compromete manutenção, segurança ou arquitetura.

A IA reduz a distância entre intenção e implementação.

Ela não elimina a diferença entre intenção e boa engenharia.

Análise da equipe

O Slack Code é interessante justamente porque não tenta vencer Claude Code, Devin ou Copilot produzindo outro agente.

A estratégia é posicionar o Slack acima deles.

Quem controlar a camada de colaboração pode acabar controlando o local onde diferentes agentes recebem contexto, interagem com pessoas e têm seu trabalho aprovado.

Esse posicionamento é potencialmente mais poderoso do que disputar qual modelo escreve a função mais rapidamente.

Também explica por que a abertura para diferentes fornecedores importa.

Para o Slack, pode ser mais vantajoso tornar-se o sistema operacional social dos agentes empresariais do que obrigar clientes a utilizar apenas uma inteligência artificial proprietária.

Mas existe uma condição.

A plataforma precisa evitar transformar facilidade de geração em inflação de software.

Quando criar uma alteração custa poucos minutos, recusar uma alteração ruim passa a ser uma habilidade organizacional importante.

Governança, arquitetura, testes automatizados e revisão humana deixam de parecer burocracia e passam a funcionar como mecanismos de controle de velocidade.

O verdadeiro teste do Slack Code não será descobrir quantas linhas de código seus agentes conseguem produzir.

Será descobrir se equipes conseguem tomar decisões melhores quando máquinas começam a produzir software na velocidade de uma conversa.

O que observar a partir de agora

A evolução do Slack Code dependerá menos da novidade inicial e mais da qualidade das integrações.

Será importante acompanhar como permissões funcionam em ambientes empresariais complexos, quanto contexto cada agente recebe, como custos de utilização são administrados e de que maneira as empresas evitam excesso de tarefas automáticas concorrentes.

Outro indicador será a relação entre quantidade de código produzido e quantidade de código realmente incorporado aos produtos.

Se agentes criarem dezenas de pull requests para cada alteração relevante, a produtividade aparente poderá esconder um custo crescente de revisão.

Mas, se o modelo funcionar, o Slack pode participar de uma transformação importante na engenharia de software.

A primeira fase da programação com IA colocou um copiloto ao lado do desenvolvedor.

A segunda criou agentes capazes de trabalhar durante minutos ou horas praticamente sozinhos.

O Slack está apostando que a próxima fase será coletiva: humanos e vários agentes observando, discutindo e construindo o mesmo produto no mesmo espaço.

Nesse cenário, o terminal continua existindo.

Só deixa de ser o único lugar onde a inteligência artificial participa da criação de software.

👉 Dúvida? Então veja mais em: https://pixbugtech.com/linksuteis