O que é esse projeto de automação com Slack e IA

Um desenvolvedor compartilhou no Dev.to e Hacker News um projeto de fim de semana que chamou atenção: um bot no Slack que usa IA para interpretar mensagens em linguagem natural e abrir pull requests no GitHub automaticamente. A ideia e simples - ao invés de acessar o GitHub e criar um PR manualmente, você simplesmente manda uma mensagem no Slack.

O caso de uso principal: correções rápidas de bugs ou atualizações de configuração que seguem um padrão previsível. Em vez de alternar entre janelas, fazer checkout de branch, editar arquivo, commitar e abrir PR, você escreve algo como 'corrige o timeout do serviço X de 30 para 60 segundos' e o agente faz todo o processo.

Para equipes que já vivem dentro do Slack, esse tipo de automação elimina context switch e pode acelerar significativamente tarefas rotineiras de manutenção de código.

Como o agente funciona por baixo dos panos

A arquitetura do projeto combina três componentes principais: Slack como interface de entrada, um LLM para interpretar a intenção do usuário e gerar o código ou diff necessário, e a API do GitHub para criar branches e pull requests programaticamente.

O fluxo de execução e o seguinte: usuário envia mensagem no canal Slack configurado, o bot recebe via Slack Events API, a mensagem e enviada para um LLM (GPT-4 ou Claude) com contexto do repositório, o LLM retorna o diff ou o arquivo modificado, o bot usa a API do GitHub para criar uma branch, commitar a mudança e abrir o PR automaticamente.

O diferencial em relação a automações mais simples e o uso do LLM para interpretar pedidos em linguagem natural sem precisar de templates rígidos. O agente consegue lidar com pedidos vagos e inferir o que precisa ser mudado.

dica
Dica

Para começar simples, limite o escopo do agente a um tipo específico de mudança (ex: apenas arquivos de configuração YAML ou apenas variáveis de ambiente). Isso reduz o risco de o LLM gerar mudanças indesejadas.

Principais recursos e capacidades

O projeto implementado tem algumas capacidades notáveis. A mais importante e a interpretação de intenção: o agente consegue distinguir entre 'muda o timeout' (atualização de valor) e 'adiciona suporte a timeout' (nova funcionalidade) e age de forma diferente em cada caso.

Outros recursos implementados no projeto:

  • Preview do diff: antes de criar o PR, o bot mostra o diff proposto no próprio Slack para aprovação
  • Contexto de repositório: o agente acessa a estrutura do repo para entender onde fazer a mudança
  • Criação automática de branch: nomenclatura padronizada (feat/, fix/, chore/) baseada no tipo de mudança
  • Descrição do PR gerada: o LLM também redige a descrição do pull request automaticamente
  • Rollback por mensagem: digitar 'cancela' no thread fecha o PR e deleta a branch

Como começar: montando seu próprio agente

Para replicar o projeto, você precisa de: conta no Slack com permissão para criar apps, token do GitHub com permissão de repo, e acesso a API de um LLM (OpenAI, Anthropic ou similar).

Passo 1: Crie um Slack App em api.slack.com. Configure Event Subscriptions para receber mensagens de canais específicos. Guarde o Bot Token e o Signing Secret.

Passo 2: Configure um webhook ou servidor para receber os eventos do Slack. Pode ser um simples servidor Node.js/Python ou um serviço serverless como AWS Lambda.

Passo 3: Implemente a integração com o LLM. Monte o prompt com instruções sobre o repositório alvo e o contexto da mensagem recebida.

Passo 4: Use a API do GitHub (Octokit para Node.js ou PyGithub para Python) para criar a branch, fazer o commit e abrir o PR com os dados retornados pelo LLM.

aviso
Atenção

Sempre implemente uma etapa de confirmação humana antes de criar o PR. O LLM pode interpretar o pedido de forma diferente do esperado. Um simples 'confirma?' no thread evita surpresas desagradáveis no repositório.

Exemplo prático: sessão real de uso

Para ilustrar, uma interação típica com o agente no Slack:

@devbot atualiza o retry limit do payment-service de 3 para 5

# Bot responde:
Entendido! Aqui esta o que vou alterar:

  arquivo: services/payment/config.yaml
  linha 42: retry_limit: 3 -> retry_limit: 5

Confirma? (sim/não)

# Usuário: sim

PR criado: GitHub.com/org/repo/pull/347
Branch: fix/payment-retry-limit
Titulo: fix: aumenta retry limit do payment-service de 3 para 5

Todo o processo leva menos de 30 segundos, sem sair do Slack. Para mudanças simples em arquivos de configuração, a redução de frição e significativa.

Comparação com alternativas existentes

Já existem ferramentas que fazem algo parecido. O GitHub Copilot Workspace e o mais próximo em funcionalidade, mas exige abrir o GitHub no browser. O Devin e o Cursor também podem criar PRs, mas são ambientes de desenvolvimento completos, não um bot de Slack.

A proposta de valor do projeto descrito e a integração dentro do Slack, onde as equipes já operam. Não e necessário sair do fluxo de comunicação para executar mudanças simples.

Comparado com bots de Slack mais simples baseados em comandos slash, a diferença e que não ha comandos fixos - o usuário pode pedir em linguagem natural qualquer variação da mudança.

Pontos positivos e limitações

Os pontos fortes são claros para casos de uso específicos. Mudanças de configuração, atualização de dependências, renomeação de variáveis, adição de comentários - todas essas tarefas são perfeitas para um agente assim. A redução de context switch e real.

As limitações são igualmente importantes de considerar. O agente não e adequado para mudanças complexas que exigem entendimento profundo do código, como refatorações ou novas funcionalidades. O LLM pode gerar código incorreto com confiança, e sem uma suite de testes automatizados rodando na PR, o risco de merging de código bugado aumenta.

Outro ponto: o custo de API do LLM pode ser relevante para equipes com muito volume. Cada pedido ao agente consome tokens para interpretar o contexto do repositório e gerar o diff.

Casos de uso onde o agente brilha

Times de DevOps/SRE: atualizações de configuração em YAML, Terraform ou Helm charts sem precisar de acesso direto ao repositório. Um analista pode solicitar a mudança sem conhecer Git.

Manutenção de dependências: atualização de versões em package.json, requirements.txt ou Gemfile pode ser automatizada com o agente.

Correções de typo e documentação: mudanças em README, comentários ou strings de mensagem de erro são casos ideais - baixo risco, alto volume.

Times com muitos stakeholders não-técnicos: PMs ou designers podem solicitar mudanças de texto ou configuração sem precisar aprender Git.

Dicas para quem vai implementar

dica
Dica

Comece com um canal Slack dedicado e um único repositório de configuração. Expanda gradualmente para outros repos conforme ganha confiança na qualidade das sugestões do LLM.

pro
Pro tip

Adicione um GitHub Action que roda testes automáticos em toda PR criada pelo bot e posta o resultado de volta no thread do Slack. Assim a confirmação de qualidade e automática.

aviso
Atenção

Configure CODEOWNERS e branch protection no GitHub para garantir que PRs criados pelo bot sempre precisam de pelo menos uma revisão humana antes do merge. Nunca deixe o agente fazer merge autonomamente.

dica
Dica

Logue todas as interações com o agente (pedido original, diff gerado, decisão do usuário). Esse histórico e valioso para auditar mudanças e melhorar o prompt com o tempo.

Vale a pena construir esse tipo de agente?

Para times que usam Slack como hub de comunicação e tem muito volume de mudanças simples e repetitivas: sim, definitivamente. A redução de frição em tarefas rotineiras de manutenção tem valor real.

Para times com poucos desenvolvedores ou mudanças complexas: o investimento em setup e manutenção do bot pode não compensar. O GitHub web interface e suficiente nesses casos.

O próximo passo para quem quiser experimentar: o artigo original no Dev.to tem o código fonte do projeto. Comece clonando o repositório e testando em um ambiente de sandbox antes de conectar ao repositório de produção.