Passo a passo grátis

Um agente que programa enquanto você dorme — com rédea

Você manda mensagem no WhatsApp ou no Telegram, um bot orquestrador abre sessões de Claude Code e de Codex num computador só dele, cada tarefa vira um branch e um Pull Request, e de manhã você só aprova. Escrever código sim. Publicar em produção e mexer na base de dados, nunca.

1. A arquitectura em 30 segundos

1. Você → manda a tarefa por mensagem ("corrige o bug do login no repo X").
2. Bot orquestrador (ex.: Grokbot, ou um bot que você mesmo monta) → recebe a mensagem, escolhe o repo e lança uma sessão.
3. Computador do agente → uma máquina ou VM dedicada, com conta de utilizador própria. Lá dentro: git, terminal, Claude Code, Codex e o que o projecto precisar.
4. Sessão de Claude Code ou Codex → trabalha numa worktree isolada, num branch novo. Faz commit, push do branch e abre um PR em rascunho.
5. GitHub → o main está protegido: nada entra sem PR e sem a sua aprovação.
6. De manhã → o bot manda-lhe a lista de PRs. Você revê, aprova e faz merge. Ou fecha.

O orquestrador é a peça que troca. Este guia não depende de nenhuma marca: qualquer bot capaz de receber uma mensagem e correr um comando na máquina do agente serve. Confirme na documentação do seu orquestrador o que ele faz de facto.

2. O que o agente pode e o que nunca pode

• Ler o código, correr testes, lint e build localmente
• Criar branch, fazer commit, fazer push do branch
• Abrir Pull Request (de preferência em rascunho) com resumo do que mudou
• Fazer push para main/master ou force push
• Fazer merge do próprio PR
• Publicar (deploy) em produção, preview com segredos, ou mexer em DNS
• Correr migrations ou qualquer comando contra a base de dados de produção
• Ter credenciais de produção na máquina: URL da base de dados, service keys, tokens de Netlify/Vercel/Supabase/cloud
• Alterar os workflows de CI (.github/workflows)

3. Como impor isto de forma técnica (por camadas)

Pense em três camadas. As duas primeiras são o muro. A terceira é o cinto de segurança.

Camada 1 — O que não está na máquina não pode ser usado

• Computador ou VM só para o agente, com utilizador próprio. Não use o seu portátil do dia a dia, onde estão as suas sessões, chaves SSH e .env de produção.
• Zero credenciais de produção nessa máquina. Nada de service_role, DATABASE_URL de produção, tokens de deploy ou de cloud. Se precisar de base de dados para testes, use uma local ou um projecto de desenvolvimento descartável.
• Os .env da máquina só apontam para ambientes de desenvolvimento.

Camada 2 — O GitHub recusa no servidor

• Conta própria para o agente (ou uma GitHub App), com permissão Write apenas nos repos onde ele trabalha. Nunca Admin.
• Token fine-grained limitado a esses repos, com o mínimo: Contents (leitura e escrita, para fazer push do branch), Pull requests (leitura e escrita). Sem a permissão Workflows, para ele não conseguir alterar a pipeline de CI. Dê-lhe prazo de validade.
• Branch protection ou ruleset no main:
  • exigir Pull Request antes do merge;
  • exigir pelo menos 1 aprovação (o autor do PR não conta como aprovação, por isso tem de ser você);
  • bloquear force push e apagar o branch;
  • não permitir que ninguém contorne a regra — inclusive administradores.
• Segredos de deploy num Environment com aprovação obrigatória. Um branch empurrado para o mesmo repo pode disparar workflows; se os segredos de produção estiverem num Environment protegido, só correm depois de você aprovar.

Camada 3 — O agente é travado antes de tentar

No Claude Code, dá para negar comandos por configuração e bloquear com um hook que corre antes de cada comando de terminal. A ideia, em duas linhas de exemplo:

"deny": ["Bash(git push origin main:*)", "Bash(supabase db push:*)", …]
# hook antes de cada comando: se for push para o main, deploy ou migration → recusa

Por baixo, um hook de git pre-push em cada clone do agente recusa qualquer push para main ou master, mesmo sem argumentos. No Codex, o equivalente é o modo de sandbox e de aprovações, com as mesmas regras escritas no AGENTS.md.

As regras por escrito: CLAUDE.md / AGENTS.md

O agente lê estes ficheiros no início. Não são segurança, mas evitam que ele perca tempo a tentar o proibido. O essencial: trabalha sempre num branch novo, corre testes antes de entregar, abre PR em rascunho a explicar o que mudou, e pára se a tarefa precisar de algo proibido.

4. O orquestrador: como ele lança as sessões

Seja Grokbot, um bot que você programou, ou outra ferramenta, o que ele faz na máquina do agente é basicamente isto, por tarefa:

# 1. clone isolado por tarefa (worktree = pasta própria, branch próprio)
cd ~/repos/meu-projecto
git fetch origin
git worktree add ../wt/login-fix -b agente/login-fix origin/main
cd ../wt/login-fix

# 2. sessão não interactiva do Claude Code (ou do Codex)
claude -p "Corrige o bug do login descrito em ISSUE.md. Segue o CLAUDE.md."
#   alternativa: codex exec "..."   (confirme o comando na sua versão)

# 3. entrega
git push -u origin agente/login-fix
gh pr create --draft --fill

• Worktrees deixam várias sessões trabalhar em paralelo no mesmo repo, sem pisarem os ficheiros umas das outras.
• Um branch por tarefa, com prefixo fixo (agente/), para você saber logo o que veio do agente.
• Limites: número máximo de sessões ao mesmo tempo, tempo máximo por sessão e um orçamento de uso por noite. Sem limite, uma tarefa mal descrita gasta a noite toda.
• Canal: o Telegram tem bots oficiais e simples de criar. No WhatsApp, a via oficial é a API do WhatsApp Business; bibliotecas não oficiais podem levar a conta a ser bloqueada. Escolha com isso em mente.
• O bot só deve aceitar mensagens do seu número/conta. Qualquer outra pessoa é ignorada.

5. A noite e a manhã

1. Antes de dormir: manda 3 a 5 tarefas pequenas e bem descritas. "Melhora o app" não é tarefa. "No ecrã de login, o botão fica activo com o email vazio — desactiva-o e adiciona teste" é.
2. De noite: o orquestrador abre uma worktree por tarefa, corre as sessões, e cada uma termina num PR em rascunho (ou numa nota a dizer porque parou).
3. De manhã: recebe no telemóvel a lista — tarefa, link do PR, estado dos testes.
4. Revisão: abre o PR, lê o resumo e o diff, vê o CI. Se estiver bom, aprova e faz merge. Se não, comenta e manda o agente corrigir na noite seguinte, ou fecha.
5. Deploy: acontece como sempre aconteceu no seu projecto — por si ou pelo CI depois do seu merge. Nunca pelo agente.

6. Checklist rápida antes da primeira noite

• Máquina/VM dedicada, utilizador próprio, sem credenciais de produção
• Conta ou App do GitHub para o agente, só com Write nos repos certos
• Token fine-grained sem permissão Workflows, com validade
• Ruleset no main: PR obrigatório, 1 aprovação, sem force push, sem excepções
• Segredos de deploy num Environment com aprovação
• Regras de deny + hook no agente, e pre-push no clone
• CLAUDE.md/AGENTS.md com as regras
• Bot que só responde a si, com limite de sessões e de tempo
• Teste: peça ao agente para fazer push para o main. Tem de falhar.