Slack Code põe o agente no canal — aprovação humana ainda segura o deploy

O Slack Code funciona em um canal dedicado ao trabalho de um agente: a equipe acompanha a conversa, o plano, as diferenças de código e uma prévia do resultado. O anúncio da Salesforce descreve a aprovação humana antes que o agente envie mudanças finais à produção. O canal torna a proposta visível; ele não transforma a participação na conversa em autorização para fazer o deploy.

Na prática, alguém apresenta uma tarefa, o agente abre uma sessão compartilhada e colegas de produto, design ou engenharia podem orientar e examinar o trabalho. A disponibilidade depende de um agente compatível instalado e da liberação gradual do recurso. Mesmo quando todos conseguem ver uma prévia, a decisão sobre uma mudança crítica continua exigindo uma pessoa com responsabilidade pela entrega.

Do relato do bug ao canal de código

O fluxo pode começar em uma conversa comum do Slack, com um relato de bug ou um pedido de alteração. Ao mencionar um agente compatível e especificar a tarefa, a equipe inicia um canal de código associado àquela conversa. O agente leva o contexto para a sessão e passa a publicar seu trabalho em um lugar ao qual outros participantes podem ser adicionados.

Considere um exemplo hipotético: uma gerente de produto relata que um botão de uma página está difícil de ler. Ela pede ao agente uma correção e convida uma engenheira para examinar a proposta. A gerente pode esclarecer o resultado esperado enquanto a engenheira avalia o código; nenhuma dessas intervenções, isoladamente, equivale a liberar a alteração em produção.

O canal mantém o pedido e as respostas ligados ao trabalho produzido. Isso ajuda quando a tarefa exige esclarecimentos sucessivos: quem chega depois pode recuperar a conversa que motivou a mudança e entender por que o agente seguiu determinado caminho. A sessão também pode ser encerrada quando o trabalho termina, preservando o histórico para consulta.

O que a equipe consegue examinar

O plano, o diff e a prévia mostram aspectos diferentes da proposta. O plano expõe a abordagem do agente; o diff permite inspecionar as linhas criadas ou alteradas; a prévia mostra o resultado gerado antes da liberação. A cobertura do TechRadar Pro descreve esse acompanhamento coletivo em tarefas como corrigir bugs e atualizar páginas.

Esses artefatos não são substitutos entre si. Uma prévia pode mostrar que a interface parece correta, mas não demonstra que os testes passaram ou que uma alteração não afetará outra parte da aplicação. O diff revela o alcance da edição, mas precisa ser interpretado à luz do comportamento esperado e do contexto do repositório. Por isso, a revisão de produto e a revisão técnica podem ocorrer na mesma sessão sem se confundirem.

A diferença em relação a uma sessão individual no IDE está em quem acompanha o trabalho enquanto ele evolui. Numa sessão isolada, a pessoa que conduz o agente decide quando compartilhar o resultado e quanto contexto levar aos colegas. No canal, participantes autorizados podem acrescentar informações, comentar a proposta e pedir outra direção antes da entrega. O IDE ainda pode ser necessário para trabalhar no código; o canal oferece um espaço comum para coordenar as decisões.

Quando a revisão vira autorização

Orientar o agente durante a tarefa e aprovar a entrega são atos distintos. Um participante pode apontar um erro, solicitar um ajuste ou interromper uma resposta em andamento. Para o envio de mudanças finais à produção, o fluxo apresentado para o Slack Code prevê que o agente submeta o trabalho à avaliação de uma pessoa. Ver o resultado no canal, portanto, não é o mesmo que autorizar um deploy.

Uma proposta também pode envolver a abertura de uma pull request antes da implantação. Nesse caso, faz diferença saber quem pode autorizar essa ação, quem revisa o diff, quem faz o merge e quem tem permissão para publicar em produção. A descrição do canal compartilhado não estabelece, por si só, as regras de proteção de branches, os testes obrigatórios ou as permissões da plataforma de entrega de cada organização.

Essa separação define o alcance da promessa do título. A aprovação humana faz parte do fluxo descrito para ações críticas do agente; ela não dispensa os controles técnicos que a equipe já aplica ao repositório e ao deploy. Se uma organização precisa de revisores específicos ou de verificações automáticas antes do merge, deve conferir como essas exigências se encaixam na integração do agente escolhido.

Quem pode usar e quais agentes entram

O guia do Slack Code informa que o recurso é previsto para todos os planos com um agente compatível instalado, mas sua liberação ocorre gradualmente. Assim, a elegibilidade do plano não significa que a opção já apareça em todo workspace. Dependendo do aplicativo, também pode ser necessária uma conta paga separada para usar o agente.

Entre os agentes listados no guia estão Claude, Devin, GitHub Copilot e Vercel. A lista inclui outros aplicativos e pode mudar; por isso, a compatibilidade deve ser conferida para o agente específico que a equipe pretende instalar. A licença do Slack e o direito de usar o serviço do parceiro são condições diferentes: acesso ao canal de código não fornece automaticamente uma assinatura desse parceiro.

O canal pode ser público ou privado, e participantes adicionais ou outros agentes podem ser convidados à sessão. Essa escolha determina quem poderá acompanhar a conversa e os artefatos compartilhados. Para uma tarefa que envolve código ou informações internas, a equipe precisa relacionar a visibilidade do canal às permissões do aplicativo e aos dados aos quais o agente terá acesso.

O limite prático da colaboração

O canal compartilhado é mais útil quando a tarefa produz algo que diferentes pessoas precisam avaliar, como uma correção de interface que exige tanto validação do comportamento quanto revisão do código. Para uma pergunta curta, uma conversa com o agente pode bastar. Para um trabalho com proposta, comentários e aprovação, manter contexto e artefatos juntos reduz a necessidade de reconstruir a decisão em mensagens separadas.

Antes de tratar o fluxo como parte da entrega de software, a organização precisa responder a perguntas concretas: quem pode chamar o agente, quais repositórios ele alcança, quem pode entrar no canal e quem autoriza uma ação externa? Também importa saber onde ficam os resultados dos testes e como a aprovação no canal se relaciona com as regras de merge e de produção. Essas respostas dependem da configuração adotada, não apenas da presença do Slack Code.

O resultado é uma divisão de trabalho mais clara: o agente prepara e expõe a proposta; pessoas com papéis diferentes ajudam a avaliá-la; uma pessoa autorizada decide sobre a liberação crítica. O valor do canal está em tornar esse percurso acompanhável pela equipe, mantendo a aprovação de produção como uma decisão explícita.

Leia também:

• Meta absorve a Stilla — o agente empresarial continuará funcionando
• Ema põe agentes em RH, TI e finanças — a aprovação humana vira o limite
• OpenLeash põe aprovação humana antes do clique destrutivo da IA