IA no fluxo de trabalho já não é novidade — virou rotina. A diferença entre gastar uma fortuna em token e usar bem está numa meia dúzia de hábitos. Aprendi isso na prática, testando com um time de engenharia que atendi, ajustando o que não funcionava até sobrar só o que valia a pena repetir.
Modelo certo para cada tarefa
A regra que mais rendeu foi separar o papel do modelo pela tarefa. Modelo forte (e caro) entra pra planejar e revisar o plano; modelo médio entra pra implementar o que já foi planejado; modelo pequeno fica com a tarefa mecânica — renomear, mover arquivo, aplicar um padrão repetitivo.
O motivo é simples: um plano bem feito pelo modelo caro faz o modelo barato executar bem. A lógica virou praticamente um lema no time: planejar com o melhor, implementar com o custo-benefício. Gastar mais na etapa de pensar economiza gastar menos — e melhor — na etapa de fazer.
Um arquivo de instruções, uma fonte de verdade
Toda ferramenta de IA que passa pelo repositório lê algum arquivo de instruções na raiz — só que cada uma procura um nome diferente. A saída foi manter um único arquivo com as regras do projeto (padrão de código, comandos, o que nunca fazer) e apontar os outros nomes pra ele, pra não duplicar e desalinhar.
# Como trabalhar neste repo
- Responda direto, sem rodeio — resultado primeiro, explicação só se eu pedir.
- Rode os testes antes de qualquer commit.
- Siga o padrão de nome que já existe; não invente um novo.
- Nunca commite arquivo .env nem credencial.
Pra manter duas ferramentas lendo o mesmo conteúdo sem copiar e colar, um symlink resolve — um arquivo aponta pro outro, uma fonte só:
ln -s CLAUDE.md AGENTS.md
Revisão automática de PR
Toda PR aberta dispara uma revisão por IA — ela aponta problema de lógica, coisa que passou batido, sugestão de simplificação. PR em modo rascunho não dispara nada: eu trabalho em draft enquanto ainda estou mexendo, e só marco como pronta quando quero a revisão de verdade.
Os comentários viram insumo, não decisão automática — quem aceita ou descarta é o dev. Dá pra montar esse fluxo com GitHub Actions; o passo a passo rende um post à parte, fica pra próxima.
Esse post à parte já saiu: o revisor de PR que roda no GitHub Actions, com o gatilho, a permissão mínima e o formato do comentário.
Dois agentes sem se atropelar: git worktree
Quando dois agentes de IA trabalham no mesmo repositório ao mesmo tempo, o risco é um pisar no arquivo que o outro está mexendo. A saída é git worktree: cada agente ganha uma pasta própria, com sua própria branch, apontando pro mesmo repositório — sem clonar de novo, sem conflito de arquivo.
git worktree add ../repo-tarefa-b branch-b
Depois é só fazer o merge normal de cada branch quando a tarefa terminar. Simples, mas resolve um problema que não tem solução boa se os dois agentes disputarem a mesma pasta de trabalho.
O custo importa
Runner de CI hospedado (o padrão do GitHub Actions) estava saindo por volta de US$200 por mês. Trocar pra um runner próprio, rodando numa VPS de US$27 por mês, derrubou isso pra US$1–2 por dia — com um fallback em cascata: se o runner da VPS cair, sobe um na nuvem; se esse também falhar, volta pro runner hospedado do GitHub.
Antes de adotar um modelo novo, meça o custo por tarefa, não só a nota da resposta. Teve modelo que saía a US$15 por tarefa e foi reprovado; a alternativa saía a US$3 e ficou. Sem essa conta, é fácil trocar de modelo achando que melhorou e só ter trocado o preço.
Onde a IA brilha sozinha
Limpeza de código morto é tarefa perfeita pra IA com supervisão. Um passe só removeu mais de 3.000 linhas mortas e 4 dependências inteiras de um app em produção — revisão humana no diff, bateria de teste verde, merge. Ninguém ia gastar um dia inteiro caçando isso manualmente.
Mas o processo em volta continua sendo engenharia normal: diff revisado, CI obrigatória, PR pequena. IA acelera a produção de código; a revisão continua sendo o gargalo — por isso PR pequena importa mais com IA, não menos.
Armadilha real: nenhuma dessas tarefas — nem a mecânica — passa direto sem revisão humana e CI verde. A vez que isso foi pulado foi a vez que custou mais tempo consertando do que teria custado revisando.
Uma última, que economiza token e evita resposta ruim: não despeje o repositório inteiro no contexto. Aponte os arquivos certos. Janela de contexto grande não substitui instrução precisa — é só mais lugar pra IA se perder.
Resumo em hábitos
- Modelo forte pra planejar, modelo custo-benefício pra implementar.
- Um arquivo de instruções na raiz do repo — as outras ferramentas apontam pra ele.
- PR em draft enquanto trabalha; só dispara revisão quando marca como pronta.
- Dois agentes, duas worktrees — cada um na sua pasta, sua branch.
- Meça o custo por tarefa antes de trocar de modelo; não confie só na nota da resposta.
- Diff revisado, CI obrigatória, PR pequena — sempre, mesmo com IA. Principalmente com IA.
