Por Grego
O Slack acabou de tocar um ponto sensível do workflow de desenvolvimento: o momento exato em que o trabalho de um agente se torna visível para o time.
Com o Slack Code, a empresa propõe canais dedicados onde você pode invocar agentes como Claude Code, Devin, Vercel Agent ou GitHub Copilot, acompanhar o que estão fazendo, revisar diffs, ver previews, deixar feedback e aprovar antes de fazer o deploy.
Quando a tarefa termina, o canal é arquivado.
E fica como audit log.
Parece mais uma integração entre Slack e ferramentas de IA.
Não é.
O sinal importante é outro: o review loop dos agentes está saindo do PR.
O PR chega tarde em uma parte cada vez mais importante do trabalho
O pull request continua sendo excelente para revisar uma mudança terminada.
Te mostra o diff.
Roda os checks.
Dispara code owners.
Conserva comentários.
Permite aprovar ou bloquear o merge.
Mas o trabalho com agentes não começa aí.
Começa antes, quando alguém define uma intenção:
arruma esse bug
muda essa tela
prepara uma versão inicial
revisa esse comportamento
Depois o agente interpreta, planeja, executa, pede esclarecimentos, recebe correções e ajusta.
Muitas das decisões importantes ocorrem antes de existir um PR final.
E se o time só vê o diff, chega atrasado.
Slack Code move a revisão para o processo
O interessante do Slack Code não é apenas poder mencionar um agente desde o Slack.
O interessante é que converte uma tarefa agêntica em um espaço compartilhado.
Ai vivem:
- o pedido original;
- o plano do agente;
- as perguntas;
- as correções humanas;
- as mudanças;
- os previews;
- os comentários;
- a aprovação;
- e o registro final do que aconteceu.
Esse formato encaixa melhor com agentes do que um PR isolado.
Porque o valor não está só em saber o que mudou.
Também está em saber como se decidiu mudar.
Revisar intenção, não só código
Um agente pode produzir um diff tecnicamente correto e ainda assim ter entendido mal a tarefa.
Pode passar nos testes, mas tocar uma área do sistema que ninguém queria modificar.
Pode resolver o bug, mas ignorar uma restrição de produto que estava na conversa inicial.
Por isso o review começa a se mover para cima no workflow.
Não é mais só perguntar:
Esse código está bom?
Também tem que perguntar:
Essa era a tarefa correta?
O agente entendeu o limite?
O time aprovou o caminho?
Que feedback recebeu antes do resultado final?
Esse contexto raramente fica completo no GitHub.
Em troca, vive naturalmente na conversa.
Slack tem uma vantagem óbvia
O Slack já é onde muitos times decidem o que vale a pena fazer.
Ali aparece o bug report informal.
Ali produto pergunta se algo é urgente.
Ali suporte cola uma captura.
Ali design dá contexto.
Ali engenharia negocia escopo.
Se o agente trabalha desse lugar, o contexto não precisa ser copiado manualmente para outro sistema.
Já está lá.
O Slack não precisa virar GitHub para que isso importe.
Basta com capturar o momento anterior ao PR: o momento onde o trabalho se define, se corrige e se aprova.
Em workflows com agentes, esse momento ficou muito mais valioso.
O audit log vira parte do produto
O detalhe de arquivar o canal ao terminar não é menor.
Para uma empresa, saber o que mudou não é suficiente.
Também importa saber:
- quem pediu a mudança;
- qual agente a executou;
- que instruções recebeu;
- que opções descartou;
- quem corrigiu o rumo;
- quem aprovou;
- que preview foi revisado;
- e o que terminou chegando ao deploy.
Em desenvolvimento tradicional, muitas daquelas conversas ficavam espalhadas entre Slack, Jira, GitHub, Linear e reuniões.
Com agentes, essa dispersão fica mais perigosa.
Porque o agente pode executar muito mais rápido do que o time consegue reconstruir a história depois.
A auditabilidade deixa de ser um detalhe de compliance.
Vira a condição para dar mais autonomia para o sistema.
O mercado está buscando onde o agente vive
Slack Code não aparece no vácuo.
Cursor está levando agentes para repos, PRs, cloud tasks e execução persistente.
Codex separa o harness das superfícies onde se usa.
Cloudflare OS explora workspaces com permissões granulares para agentes.
GitHub tenta que Copilot viva cada vez mais perto do ciclo completo de desenvolvimento.
Todos estão rodeando a mesma pergunta:
Onde o trabalho de um agente deveria viver?
Pode ser a IDE.
Pode ser o repo.
Pode ser o browser.
Pode ser Slack.
Pode ser uma plataforma nova.
Mas a direção é clara: o agente precisa de um lugar onde o time possa vê-lo trabalhar, corrigi-lo, aprová-lo e reconstruir depois o que aconteceu.
O PR por si só não é suficiente para isso.
O PR não desaparece
O pull request continua sendo necessário.
É o lugar natural para validar a mudança contra o repositório:
- diff;
- tests;
- checks;
- code ownership;
- branch protection;
- merge.
Mas pode deixar de ser o lugar principal onde se entende o trabalho.
Em um workflow agêntico, o PR começa a parecer mais com o recibo final.
Importante.
Necessário.
Auditable.
Mas incompleto.
A história completa vive antes: na intenção, no plano, nas iterações, no feedback e nas aprovações humanas que levaram o agente até esse diff.
Slack Code aponta exatamente para esse espaço.
Por isso importa.
Não porque Slack tenha inventado o coding agent.
Mas porque entendeu que o problema já não é só gerar código.
É coordenar humanos e agentes em torno de uma tarefa compartilhada sem perder visibilidade.
A próxima grande batalha das dev tools talvez não seja quem escreve código melhor.
Pode ser quem conserva melhor a história de como esse código chegou a existir.