Automações com Claude Code para devs

A maioria dos desenvolvedores trata automação como luxo, mas as automações com Claude Code inverteram essa lógica. O que antes parecia exagero, como regras de lint específicas ou preview environments bem configurados, agora é o que separa times produtivos de times travados. Codificar conhecimento em infraestrutura deixou de ser opcional.

O que são automações com Claude Code e por que elas importam

Automações com Claude Code são o conjunto de regras, testes, arquivos markdown e passos de CI que transformam conhecimento de domínio em infraestrutura executável para agentes de IA. Elas importam porque cada agente novo e cada colega que entra no projeto herda o mesmo contexto sem precisar de explicações repetidas.

O Claude Code é a ferramenta de codificação agêntica da Anthropic que roda no terminal e executa tarefas diretamente no código. Boris Cherny, um dos criadores da ferramenta, defende que automatizar o trabalho sempre foi a atividade de maior alavancagem para um engenheiro. A novidade é que agora esse esforço escala para um exército de agentes, não apenas para uma pessoa.

Quando você escreve uma regra de lint que bloqueia um padrão problemático, esse conhecimento deixa de depender de revisão manual. O mesmo vale para um passo de CI que verifica um caso específico ou para um arquivo de instruções que explica a arquitetura do projeto. Cada automação dessas é uma decisão de engenharia que passa a valer para todo mundo, inclusive para os agentes.

A mudança de escala é o ponto central. Antes, criar uma regra de 400 linhas para um caso raro não compensava, porque o problema aparecia poucas vezes. Com agentes gerando código em volume, esses casos raros se tornam frequentes, e a automação passa a ter retorno imediato.

Como codificar conhecimento de domínio em infraestrutura

Codificar conhecimento de domínio em infraestrutura significa converter o que está na cabeça dos engenheiros em artefatos que o time e os agentes podem executar. Isso inclui regras de lint, tipos, testes end-to-end, arquivos de instrução e passos automatizados de verificação.

O gargalo clássico de qualquer base de código é o conhecimento que só existe na memória de quem já trabalha nela. Um novo contribuidor precisa descobrir quais padrões seguir, quais frameworks usar e quais decisões arquiteturais são inegociáveis. Quando esse conhecimento não está escrito em lugar nenhum, cada pessoa reaprende do zero.

A proposta é inverter isso. Se um pull request é rejeitado porque não seguiu o framework correto, isso é uma falha de automação, não uma falha da pessoa. A correção é codificar a regra em um lugar onde tanto humanos quanto agentes possam consultá-la antes de errar.

Boris Cherny descreve esse processo como capturar quase todo o conhecimento de domínio em comentários de código, skills e arquivos de memória. O ponto não é escrever documentação bonita, mas criar mecanismos que impeçam erros recorrentes de acontecer.

Uma forma prática de começar é observar quais erros se repetem nas revisões. Cada padrão que aparece duas ou três vezes é candidato a virar regra automatizada, seja um lint, um teste ou uma instrução no arquivo do agente.

O papel dos arquivos de instrução na configuração do agente

Os arquivos de instrução, como Claude.md e AGENTS.md, são o mecanismo que direciona o comportamento dos agentes em uma base de código específica. Eles devem orientar o agente para o sucesso, não listar onde cada arquivo está no repositório.

Theo Browne, criador do canal Theo - t3.gg e da stack T3, alerta que você não deve deixar seus agentes escreverem esses arquivos. Escrever manualmente é o esforço que gera entendimento real sobre o que muda o comportamento do modelo. Você observa o que o agente faz, ajusta o arquivo e repete o ciclo.

A recomendação é começar sem nenhuma configuração extra. Envie os primeiros prompts com o mínimo de contexto possível e veja o que dá errado. Só então escreva as instruções que corrigem esses problemas, porque assim você sabe exatamente qual comportamento está tentando mudar.

Esses arquivos também servem para fazer o modelo recusar pedidos inadequados. Se usuários pedem repetidamente uma funcionalidade que não deve existir no projeto, uma instrução simples orienta o agente a parar e explicar por que aquele pedido não se aplica.

Como usar preview environments e feedback visual a favor dos agentes

Preview environments se tornaram infraestrutura essencial quando o código passa a ser gerado por agentes que trabalham fora da sua máquina local. Eles permitem que o agente teste a aplicação em execução, encontre bugs e documente o resultado sem intervenção manual.

Por muito tempo, o argumento contrário era que cada desenvolvedor já testava tudo na própria máquina. Com agentes rodando em nuvem, em abas de segundo plano ou em worktrees separados, esse argumento perde força. O ambiente onde o código roda deixa de ser um único computador.

Theo relata que criou um serviço próprio no Cloudflare para permitir que seus agentes anexassem vídeos a pull requests. A interface do GitHub aceita arrastar e soltar arquivos, mas ferramentas de linha de comando não tinham esse caminho. A solução foi construir um upload próprio e expor isso como skill para o agente.

Esse tipo de problema ilustra o padrão. Quando a limitação aparece, você constrói a peça que falta e a transforma em ferramenta reutilizável. O ciclo é curto, e o retorno aparece na próxima tarefa.

Automação de CI para agentes: o caso do Blacksmith

A automação de CI para agentes resolve um gargalo recorrente: o tempo de espera entre o push e o resultado dos testes. Plataformas como o Blacksmith oferecem execução mais rápida e uma CLI que permite ao próprio agente disparar a pipeline e ler os logs.

O fluxo tradicional é lento e manual. Você faz as mudanças, abre o pull request, espera o CI rodar, encontra um erro que não apareceu na sua máquina, copia o log, cola no agente e espera de novo. Cada iteração desse ciclo consome tempo e atenção.

Theo afirma que usa o Blacksmith para todo o CI da empresa dele e relata quase 3.000 jobs executados em sete dias. Segundo ele, a taxa de falhas caiu porque a plataforma oferece análises melhores sobre quais jobs consomem mais recursos e quais erros são transitórios. Esses números são relato de primeira mão do apresentador.

A parte mais interessante é permitir que o agente consulte os logs diretamente. Quando ele consegue disparar o CI e interpretar a saída, o ciclo de correção deixa de depender de copiar e colar manual.

Skills como caminho para o nível sênior

Skills e automações são o que separa um bom contribuidor individual de alguém que eleva o time inteiro. A progressão para sênior, staff ou principal passa menos por escrever mais código e mais por construir sistemas que fazem o código certo ser o caminho mais fácil.

Theo argumenta que isso não é novidade. A trilha para staff engineer nunca foi apenas entregar mais linhas. Sempre foi construir estruturas, processos e ferramentas que multiplicam a capacidade coletiva. A diferença é que agora você consegue fazer isso sozinho, em projetos pessoais, porque os agentes carregam o volume de código.

Projetos pessoais ficaram grandes demais para caber na cabeça de uma pessoa. Nesse cenário, a única forma de continuar evoluindo é escrever as regras e sistemas que mantêm o projeto coerente mesmo quando você não consegue mais acompanhar cada detalhe.

Se a empresa atual não valoriza esse trabalho, a próxima provavelmente vai. A habilidade de criar ambientes onde o código entra com menos atrito tende a pesar mais do que a capacidade de escrever o código manualmente.

O que não fazer ao configurar automações

Instalar dezenas de skills e plugins antes de entender o projeto é o erro mais comum. A recomendação é usar as ferramentas como vêm configuradas, observar o que falha e só então construir soluções específicas para esses problemas.

Arquivos de instrução que apenas listam a localização das coisas no código não ajudam. Eles precisam direcionar o comportamento para o resultado desejado, não servir como mapa do repositório. A diferença é entre dizer onde está o arquivo e dizer como aquela parte do sistema deve ser tratada.

Dumping de contexto, como despejar trechos de livros favoritos no arquivo do agente para influenciar o tom, pode ter efeito. Theo menciona colegas que fazem isso, mas trata como experimento, não como prática consolidada. O efeito existe, a previsibilidade não.

O princípio geral é reagir a problemas observados em vez de antecipar todos os cenários possíveis. Automação construída sobre falhas reais tem muito mais chance de sobreviver do que automação construída sobre suposições.

Tabela comparativa: automação manual versus automação codificada

A tabela abaixo contrasta as duas abordagens que aparecem ao longo do artigo, com base nos argumentos apresentados por Boris Cherny e Theo Browne.

Dimensão	Resolver caso a caso	Codificar em infraestrutura
Consumo de tokens	Alto, repete a cada ocorrência	Baixo, resolve a classe inteira
Consistência	Depende do prompt do momento	Definida pela regra escrita
Onboarding de novos devs	Conhecimento fica na cabeça de quem já está	Conhecimento fica no repositório
Custo de manutenção	Nenhum, mas o problema volta	Exige escrita e ajuste contínuo
Escala com agentes	Não escala, cada agente refaz o trabalho	Escala, todos herdam a regra

A leitura da tabela é simples. Resolver caso a caso parece mais barato no início e mais caro depois. Codificar em infraestrutura exige investimento inicial e retorna cada vez que o problema reaparece, seja com um humano ou com um agente.

Como começar na prática em cinco passos

Comece sem configuração extra e deixe os problemas aparecerem nos primeiros prompts. Esse é o caminho que evita automação especulativa e garante que cada regra escrita resolva algo que realmente aconteceu.

1. Rode os primeiros prompts com o mínimo de contexto possível e anote o que dá errado.
2. Transforme cada erro recorrente em uma regra concreta, seja lint, teste ou passo de CI.
3. Escreva o arquivo de instrução manualmente, sem delegar isso ao agente.
4. Configure preview environments para que agentes possam testar o que produzem.
5. Conecte o CI para que o agente leia os logs e corrija sem intervenção manual.

A ordem importa. Escrever regras antes de observar falhas produz arquivos genéricos que ninguém usa. Observar falhas antes de escrever regras produz automações que resolvem problemas concretos e sobrevivem ao tempo.

FAQ sobre automações com Claude Code

• O que são automações com Claude Code? São regras, testes, arquivos de instrução e passos de CI que codificam conhecimento de domínio para que agentes e pessoas trabalhem na base de código com menos contexto externo. Boris Cherny, um dos criadores da ferramenta, descreve esse processo como converter conhecimento de domínio em infraestrutura.
• Quem é Boris Cherny? Boris Cherny é um dos criadores do Claude Code, ferramenta de codificação agêntica da Anthropic que roda no terminal. Ele defende que automatizar o trabalho sempre foi a atividade de maior alavancagem para engenheiros, e que os agentes ampliaram esse efeito.
• Devo deixar o agente escrever meu Claude.md? Não. Theo Browne argumenta que escrever esses arquivos manualmente é o esforço que gera entendimento sobre o que muda o comportamento do modelo. Delegar essa escrita elimina justamente a parte que produz aprendizado.
• Quantos jobs o Blacksmith executa no caso citado? Theo relata quase 3.000 jobs em sete dias na empresa dele, com queda na taxa de falhas. Esse é um relato de primeira mão do apresentador, não uma medição independente.
• Preciso instalar várias skills antes de começar? Não. A recomendação é usar as ferramentas como vêm configuradas, observar as falhas reais e só então construir automações específicas para os problemas encontrados.
• Preview environments ainda fazem sentido? Sim, e fazem mais sentido do que antes. Com agentes rodando em nuvem, worktrees ou máquinas separadas, o ambiente de preview passa a ser o lugar onde o código é verificado de verdade.
• Como isso ajuda minha carreira? A habilidade de construir sistemas que fazem o código entrar com menos atrito pesa mais do que escrever código manualmente. Essa competência é associada a níveis sênior, staff e principal.
• O que significa loop no contexto de agentes? Loop significa automatizar classes inteiras de trabalho repetitivo, não apenas resolver ocorrências isoladas. Uma regra de lint que bloqueia um padrão elimina para sempre aquela categoria de erro.
• Qual o papel do conhecimento de domínio? É o que fica na cabeça das pessoas e raramente é escrito. Converter esse conhecimento em automação é o que permite que novos contribuidores e agentes produzam desde o primeiro dia.

Conclusão: de volta ao começo

A parte divertida de engenharia que parecia perdida, como configurar ambientes e criar ferramentas sob medida, não desapareceu. Ela mudou de escala e ganhou um motivo concreto para existir.

O que antes era hobby de quem gostava de customizar editor agora é infraestrutura com retorno direto. Cada regra escrita acelera você, seus agentes e qualquer pessoa que entre no projeto depois. Para quem quer se aprofundar nesse tipo de stack e nas práticas de engenharia moderna, o CrazyStack TypeScript reúne conteúdo prático sobre o tema, incluindo o conteúdo do Bootcamp do Dev Doido e os materiais do Gustavo Dev Doido sobre automação e fluxo de trabalho.

Se este artigo ajudou a organizar as ideias, compartilhe com alguém que ainda está preso no ciclo de resolver tudo manualmente.

Se você tem conhecimento valioso gravado em vídeos do YouTube, dá para transformar essa conversa em um artigo escrito e revisado. No Skala Blog, você cola a URL do vídeo, a ferramenta transcreve o conteúdo e gera um artigo pronto para você ajustar e publicar.

Source video